What Went Right:
This is one instance where I'm not going to be humble. The engine behind Fenix Blade is a dream come true, and then some. It possesses the flexibility and performance to handle any idea I shove down its throat, and it doesn't even begin to struggle on ancient hardware.
From a technical standpoint, Fenix Blade (which I'll abbreviate as FB for the duration of this document) had the benefit of a smooth, efficient engine. There is almost no redundant drawing within the renderer, which initially made little difference as far as performance goes, but quickly became crucial to maintaining a silky smooth 70fps as scene detail and object density began to climb. So far I've been able to play Demo 2 (in pure DOS) from start to finish at 70fps sync'd without ever dropping a frame on my old p233. Even as CPU speeds continue to aim for the stratosphere, I felt it was important to remember people who languish in the midst of ancient hardware, whether simply by choice, or necessity. Part of the reason for the long development time has been extensive optimization -- and in truth, there are plenty of areas that still need to be optimized, assuming I find the time.
From the start, ease of use was a major priority in my designs for the game. I wanted to enable the player to experience the entire game without ever having to change input devices during the course of game play. The GUI, menus, and controls reflect that particular imperative, and special care was taken to insure that all menus operate under the same guidelines, i.e. the accept key moves you deeper into the sub-menus, while the cancel key moves you back a step. It's a pet peeve of mine for sure, but I hate playing games where you have to juggle using the keyboard with a gamepad/mouse/whatever, and to be fair in some instances it's impossible or merely impractical to do everything with one input device. Fortunately, FB doesn't fall into that category! Users are free to remap their keys and gamepad buttons, and the changes are saved with their games.
Collision detection is suitably tight, and player response is toned down to be fluid without feeling 'twitchy.' This is especially noticeable when using a gamepad, where polling the input device only thirty times a second produces a nearly undetectable lag in user response -- but in doing so helps maintain smooth motion, and reduces the twitch factor to boot.
Along with the moderately robust drawing system, the graphics accompanying the demo turned out much better than I had anticipated. There is abundant attention to detail, and each surface is accompanied by numerous imperfections and aberrations. I also made a point to keep open surfaces to a minimum, and although it at times produces areas that feel a little tight, the overall appearance is enhanced by the lack of redundant tiles. Multi-stage real-time sprite shadowing gives the illusion of 3D shadows without the nasty overhead associated with using a shadow layer (or ever worse, multiple layers...ick), and improves the sense of characters/NPCs being a cohesive element in the environment.
The big surprise, however, turned out to be the enemy artwork. I've never fancied myself an artist, and still don't, but I'm quite pleased with the way the enemies turned out. There is a distinct lack of variety at this point, so I had to make due with the sprites that I had already turned out. I spent a lot of time texturing the sprites and placing heavy shadows on them so they would have a more solid feel to them, as opposed to my typical style of artwork, which is usually rather flat. FB also employs a technique that I have yet to see in a RPG of its type, which is enemy detail progression. Instead of simply swapping palettes for enemies, each new enemy changes (and improves in) weapons, armor, details, and of course color. I've provided a sample to illustrate the point. This cuts down on my work load significantly, while avoiding the feeling that you're being stingy with your artwork.
Some of the environment effects (which I refer to as EV effects) were particularly effective, and most people quickly made note of the water that seems to be present in many parts of the demo. Indeed, water, fire, and air are particularly important to the style of the world, and naturally the game itself. I decided it was important to make these elements stand out when compared to other aspects of the world in order to accentuate their role in the game world. As such, it wasn't enough just to draw a pretty layer and call it a day... the characters will need to interact with these elements as the game progresses, so it was necessary to enable the engine to handle the elements as parts of the environment as opposed to a layer, which just sits on top of something. Objects can make fog and smoke part as they move through it, ripples appear as they penetrate a watery surface, or burn as they come into contact with fire. Toward the end of the game (NB: not the demo) many puzzles are based upon interaction with elements, so this was an important step in achieving my ultimate goal.
Aspects of Design...
FB is more about exploration and discovery than anything else. Sometimes, exploration involves more than just running around various landscapes, instead delving into the feelings and attitudes of the characters whose lives advance the story. There is no easy way to accomplish this, and it usually involves a substantial amount of text. Since you will have nearly a dozen possible (note, I said possible) characters in your roster a certain points, it was necessary to tailor their responses while interacting with the world.
This was accomplished via dynamic scripting. Each character has their own response to every interactive element in the game, whether it be a rock, lever, table, mirror, chest, etc. This increases my work load quite a bit, but the rewards are well worth the effort. You can gain significant insight into the feelings and disposition of a character by studying their reactions to objects in the game world. Minx, for example, sees things from the perspective of a youth who is oblivious to danger and evil influence. Panzer, on the other hand, chiefly categorizes objects by how difficult it would be to destroy them -- hinting at his short temper and propensity for rash response. The individual responses turned out to be extremely effective in helping to characterize the players.
Also, something that several shortsighted people quickly dismissed as bad writing, individual characters employ slight dialects while speaking. Minx makes frequent use of slang while speaking, and has a very happy-go-lucky overtone to her dialogue, even when she's knee-deep in danger. Tessa, being a high ranking officer in the Solancian Guard, is much more stilted in her discourse, and avoids unnecessary verbiage that might induce confusion while handing out orders to her troops. Montag... well... he's blessed (or cursed, perhaps) with a unique perspective of the universe, and his dialogue makes that abundantly apparent. The goddesses you come across are extremely formal in their choice of words and sentence construction, because we all know it's disrespectful to attempt casual conversation with a higher power, right?!
Some Unique Ideas...
The whole battle sub-engine was a royal pain to code, but I didn't feel like pulling any punches for this game. It's complicated because the individual components of the sub-engine (user input, spell scripts, AI, animation, rendering) all work concurrently. So, while the enemy is trying to decide how to bash your skull in, and your third character is casting a spell that is in the midst of hitting five enemies within three seconds, you are still free to move about the battle menus and issue your commands. Everything works together to create a seamless environment for issuing commands, and I love the way it turned out!
Spells also work concurrently, which was a little tricky to pull off, but it was hardly as painful as getting everything to play nice. In doing so, spells with multiple targets take much less time to complete, and we all can probably agree that random battles certainly do not need lengthy spell animations to slow down the action. I thought some of the spell effects in Demo 2 were rather nifty, but they pale in comparison to most of the powerful spells acquired later in the game. Again... short, furious eye candy that doesn't take all day to complete. I haven't heard any complaints yet; groovy.
Building over the top of FF6's already robust battle mechanics, I added in a stamina system allowing players to modify their defensive and offensive potential via their stamina level. This worked pretty well, but needs to be tweaked. Right now the penalty for low stamina is way too harsh, basically crippling the character until their level is higher than 75%. This also brings charms into a more important circle as far as game play goes. Issuing charms to characters prior to battle will often help a player maximize their fighting potential, and possibly make all the difference between success and defeat in lengthy boss battles.
I also took the visuals a step further and implemented visual cues to indicate upcoming battle actions on the part of enemies. You always know what you're about to do, but in most games it's impossible to anticipate enemy actions unless they have some sort of special animation prior to taking action. Visual cues allow players to counteract enemies casting powerful spells or using slow techniques. This will become especially useful in later stages of the game, where spells and techniques may take a long time to complete, and there is ample opportunity to interrupt an enemy attack before it completes. At the very least it allows players to set up their defenses accordingly, and so far it's working extremely well.
I did something weird and abandoned the traditional Cartesian coordinate system when dealing with polygons. Normally this would sound completely absurd, but I've used it to create some startlingly cool effects. Instead of defining polygons as absolute coordinates, I refer to them as a collection of points relative to a center point... each point containing a value for the angle and magnitude. This allows me to effortlessly scale and rotate polygons, and I can also apply wave formulae to the angles and magnitudes, creating some truly weird... almost organic animation. The obvious downside is the need to define polys without using absolute coords, which makes visualization a little tense on my part, so I had to construct a little utility to help me out with that task. Regardless of the obvious problems, I find it a welcome change of pace, and the additional animation possibilities are still being explored as I write this.
I decided to give the player a little extra incentive to explore the game world by filling it with hidden items. This isn't exactly realistic, but then again who needs to be obsessed with realism when we create games to help escape reality? In Demo 2 there are over sixty hidden items, and not only does finding them raise your score (another unusual thing to see in a RPG), it also provides you with valuable supplies that might otherwise cost you a considerable amount of money to acquire. Healing items are very expensive in FB, so I made them abundant throughout the world... if you feel inclined to look for them. As far as I'm concerned, any design element that encourages the player to explore the world (without REQUIRING that they go through with it) is a great thing, so I'm working to include as many of them as possible.
Next: What Went Wrong