What Went Wrong:

Loading... This is one instance where I'm going to be perfectly honest. The engine behind Fenix Blade is a complete nightmare, and then some. It's horribly complex, often difficult to work with, and at times produces results that border on ineffable. That's not to say it's ALL bad... just that after reading the previous page, I didn't want anyone to think it's ALL good. Most of my problems stemmed from a scope of vision that far exceeded my ability to control, as we'll explore over the next paragraph or twelve.

First and foremost, I had (and still have) a problem with the engine's flexibility. The main issue wasn't a lack of pliancy; quite the opposite... the engine was too robust for its own good. There was some insane desire on my part to create an engine that functioned as a cohesive unit, as opposed to a group of individual elements that were loosely tied to one another through a couple of tiny variables and control routines. That last sentence sounded pretty idiotic, no? Good... that's the sort of impression I want to pass around before I delve into the really evil aspect of FB.

As one might imagine, getting dozens of individual parts to 'play nice' is already a difficult task, so going one step beyond that seems likely to be a fool's errand. No biggie, I've got 'Dunce' tattooed on the back of my kneecap, so apparently I'm up for the job in ways few people can possibly visualize. First, allow me to lay out how the engine works, on a simplified scale. Everything is based upon what I refer to as 'objects.' An object is anything that has a job, no matter what. The main character (on-screen) is an object, as are ripples in the water, birds passing overhead... even the spinning cursor in the GUI. Objects are ruled by behaviors, and there are well over 100 different behaviors, ranging from linear movement and pathfinding to transparency control and animation. The obvious benefits are that ANY aspect of the engine can be controlled by any behavior (or combination thereof, up to five)... eliminating thousands of lines of code, and providing a tremendous level of raw flexibility across the board. The behavior that makes the crystals bob atop the water in the first scene of Demo 2 is the same one that controls the bob of the GUI cursor when you select something in the menu. Nifty, says I.

The object system works well except for several glaring errors in its design. First, and God only knows how I managed to come up with this scenario, objects each have their own pool of common variables that are used by behaviors to track things. The variables are simply referred to as numbers, which worked just fine until I ran into a situation where behaviors would need to 'share' a common variable, which is totally unacceptable. When you have five different behaviors acting simultaneously on a single object (which happens with alarming frequency, mind you) you can imagine that at least twenty or so common variables are being used, if not more. This is a completely stupid setup, I'm sure you can agree; and I'll leave it as an exercise to the reader to envision the many headaches and 'growing pains' this caused me as I was coding the engine.

The object system also utilizes a painfully large amount of variables, making debugging a royal pain in the posterior. There just wasn't any way of getting around that, so I had to make due with the inconvenience. So, when behaviors had conflicts that I was not already aware of, obscure bugs often cropped up... and even when I had real-time debugging going full force, and a debugging dump file so massive it would have made the tower of Babel look puny, it still was difficult to locate bugs stemming from conflicts. Rather than stop and fix the growing problem, I shrugged my shoulders and worked around the problem. Looking back on the ordeal, I must have been lobotomized several years ago without my knowledge...

The object system, while powerful, was matched by the equally obtuse rendering system. I crafted a 2D rendering system that was (and still is) fast as hell, but I'm dangerously close to regretting my relentless pursuit of that extra handful of FPS. I'm quite happy with it NOW, but getting the damn thing to work right wasn't exactly what I'd call vacation time. Each room, or scene, or whatever you want to call it, is prerendered to a large buffer. As each frame is constructed, composites of sprites are merged with the background buffer, resulting in complicated scenes that would normally require half a dozen layers (or more) without using anything other than the background buffer. Well, except for parallax stuff and EV effects, but that's another story entirely. Bottom line, I got the performance I wanted, but I took it in the yang as far as development time goes. But wait... it gets better.

Palettes. Damn palettes. I love eight bit color modes, but working with palettes is about as fun as watching mold grow on stuff in the 'fridge. I had some cool ideas, mostly better suited to higher color modes, but what the hell... I wanted the speed AND the compatibility afforded by mode 13h. So, I decided to do the whole game using a single palette. Yes, you read that right. Aside from small color bands, and colors reserved for the GUI, FB Demo 2 uses a single palette for everything. Granted, I can modify it with selective tints, and do smooth fades any way I want, but I'm stuck with the 240+ colors I chose several years ago. The upshot is I can do really decent transparencies and smooth fades using LUTs, and even access palette rotation... something I use less every day. The downside is having to adhere to a single palette, which as it turns out isn't so bad after all. Getting the palette routines to play nice was painful. The palette is controlled inside a timer, so rolling tints and fades work in a consistent fashion (and speed) no matter what else is going on. Oh... almost forgot... I managed to get weighted scanlines and partial interpolation support working; small speck of light in an otherwise dim experience ;)

I was also stymied by a severely mangled save-file format. Just for kicks, I tried to work up an extremely un-hacker-friendly save file format. It was a total bear to code, but it was worth it when I got a friend of mine (and avid game cracker, as I once was) to try and edit his save game. Didn't take him long to give up -- his jaw dropped when he compared two save games, just seconds apart from one another, and found that only the headers of the two files matched. Any way, there were several nasty bugs lurking in the save game code, which decided to manifest themselves over the course of three months. A simplified save game format would have made this less of an irritation, but I'm a dork like that.



And now for something completely...

Loading... Different? Let's take a look at design flaws within the demo, as opposed to the engine. First off, I quickly found I was a slave to my initial character designs. I originally intended for Minx to accompany Montag to the Northlands Inn, allowing both of them to explore the hidden base, but Minx's strong aversion to cold climates made this an impossibility. There's also the issue of Minx heading into the Geas mine by herself. I didn't intend for that to happen either, but Montag was definitely out of the picture, and Rhyss and Panzer were holed up on the other side of the peninsula, so with no other operatives in the area, I was forced to send her in solo. This turned out a little rough, as the enemies were designed to be faced in greater numbers, and the scenario is forced upon the player. The level of difficulty is also compounded by the presence of a simple puzzle which required a good deal of backtracking to bypass. Ouch...

My original idea was to have a group adventure, as opposed to just Montag making his way through one mishap after another. The plot sequences leading to the events in Demo 2 just wouldn't allow that, and since the demo is a real chunk of the actual game, I couldn't funk up the plot elements just to make my idea work for the time being. This severely changes the tone of the demo, but not enough to make me feel it's not fit to represent the actual game. You are finally allowed to have some group adventures after you hit the rendezvous point on the other side of the peninsula, but until then you're limited to just Montag and Minx... and sometimes even less than that. I'm a little disappointed... I was hoping to explore the characterization of Rhyss and Panzer more in this scenario, but the design wouldn't permit it.

Getting the Northlands Inn scenario to play out correctly was a truly unpleasant excursion into the dark side of game design. Things worked out perfectly when Montag was in the party by himself, but with other characters present the engine would occasionally go off in the weeds and give some rather disturbing output. I managed to work around it, but I still feel a little burned by the whole situation. Originally designed as a scenario for multiple party members, I had to hack it down to a single character, and by then it was too late (in my mind, that is) to work the other characters back into the mix. Hardly what I'd call getting out of a pickle gracefully.

Getting into the action was a tad difficult at first, due to the fact that Demo 2 starts out at the beginning of a long transition from one scenario to another. The upshot of starting out on the Crimson Dragoon is having access to supplies and training, both of which come in handy considering you'll soon be thrown into the wild after leaving the ship. Unfortunately, starting on the ship means you're subjected to Tessa's briefing (although you'd be worse off without it, I'm sure!) and Montag's various musings as he explores the ship. I love the atmosphere at this point in the game, but I can understand how some people want to instantly jump into the action... and this setup won't let you do that.


Next: Audience Reaction