SDLconsole support

I decided to dust off the SDL wrapper for my console class to see how it's held up.  Somehow my switch to unicode support introduced a nice obscure link error that took at while to track down - project settings were correct, just needed to include sdlmain.lib now explicitly.  The wrapper was sort of half implemented and there was no useful keyboard support other than up/down/enter, so I went ahead and plugged in some basics so none of the menus are blocked.

It will need quite a bit of work to make it pretty that's for sure, but the basics are there.  Extended ascii characters in the font for one so that my grass and walls show up would be nice, and then some sort of method to expose true 32bit color support for SDL but still be able to bucket it for the console builds.  I have a couple ideas on how to have the property system automatically support this extra data without too much trouble, and then it would be a matter of just making sure there's plenty of fallbacks when the extra data in unnecessary/unwanted.

Progress

I've knocked out some major steps that makes it likely that this project might actually playable at some point.  I've updated the picasa gallery with 5 new screenshots, check the entire album out here.  I'm nearly up to 150 submissions in my source repository so far, spanning over 2 years (with huge gaps, looks like I didn't touch the project for a year and a half altogether), and it's finally starting to get some legs.  Lots of work ahead of me no doubt, but I'm excited to have made it this far.

• Inventory is now implemented in a mostly usable form.  Creatures have a configurable list of body slots that Items can be equipped too, along with all the appropriate hooks for status modification down the road (cursed items, status changes, etc).  I spent quite a bit of time on the inventory screen as well, which worked well in testing out both the inventory and UI frameworks.

• Combat has been scrubbed a bit as I try to figure out how exactly the mechanics of attacking, dodging, and damage absorption should work.  I've gone and forth on a couple systems, but for now I think I've settled on the idea that items themselves hold the most influence on combat values, while creature stats and skills either scale those values or enforce a minimum.  Weapons for example dictate a base chance to hit, attack speed, and damage range, and a player's agility would modify the minimum chance to hit and attack speeds, while the matching weapon skill would scale the weapon's base values.  I have no idea if this approach will work or not in the long term, but for now I've got something in that I can start playing with.

• It's now possible to level up!  Coming up with an XP table generator is voodoo magic, and I ended up spending an hour or so playing with some weird combination of formulas that eventually generated something that looked "right".  The more important part is that it's now possible to go past level 1, so there's actually a point to killing all those goblins and rats.

• Level Generator and Populator classes are now roughly implemented, and I moved my basic cave generator into it's new (data driven) home.  Now it's trivial to tweak all the various parameters of the generation or creature population, and no longer requires recompiling the executable.  I think the growing pains with my property reflection/serialization system are starting to yield some awesome rewards.  It's very rewarding to watch all the individual components I've been working start to come together.  This shot shows the debug console with some of my in-game debug commands to inspect the  type registry, and then dive into the properties of a specific type/instace.

I'm looking forward to start adding more and more of the actual game bits now that the underlying frameworks are mostly working.  I can tell there's going to be more fun ahead already... I'm pretty sure my current implementation of time in the engine is going to be asking for a rewrite very shortly.

Macros really are evil... :(

I knew my property system macros were fragile, and I ran into a fun one the other day when adding properties for the new level generators.  When loading up some test data my structure was getting turned into garbage, which I eventually tracked down to the second property in the struct having an invalid offset.  Thankfully Visual Studio's debugger is badass, and was able to find that I had accidentally setup a string property (12 bytes) into a string pointer (4 bytes), doh!

struct LevelPopulatorCreatureInfo
{
    TString* CreatureName;   // this shouldn't be a pointer, and throws off all other offsets by 8
    ...
}

ADD_PROPERTY(CREATE_PROPERTY_CUSTOM(LevelPopulatorCreatureInfo,String,CreatureName));

The question now is to add some verification asserts to the already convoluted macros, or should I bite the bullet and refactor the system to make the compiler do the type checking?  This might be a fun post to look back on in a couple months....

Macros are evil...

For some reason I thought it would be clever (and elegant) to wrap my property system declarations in some simple macros, which of course worked decently for simple cases...

DEFINE_PROPERTY_STRUCT(ACreatureClass,Range_Int,BaseXpValue));

DEFINE_PROPERTY(ACreatureClass,float,BaseEvasion));

The macro handles creating a new Property class instance and adding it to the DataType's list of properties, etc etc. Now recently I find myself add a new Property_Array class (now that I'm actually creating a game I have need of data driven lists), which worked out fairly well initially

#define DEFINE_PROPERTY_ARRAY(ClassType,PropType,PropName) Type->Properties.Add( new Property_Array(#PropName,GET_OFFSET(ClassType,PropName)) );

Which worked great for my test case for array of integers, but quickly fell apart once I wanted to make an array of enums (or for more pain, an array of structs of arrays...). I've since refactored the macros to support embedding of property creation within the array property creation macro, but it's turned into a real mess that I'm not proud of...

ADD_PROPERTY(CREATE_PROPERTY_ARRAY_EXT(ACreatureClass,ItemBodySlot,BodySlots,CREATE_PROPERTY_ENUM(ACreatureClass,ItemBodySlot,BodySlots,NumItemBodySlots,ItemBodySlots,ItemBodySlotNames)));

And with the (ab)use of the temporary LastProperty it's a pretty frail system, where any bit of manual monkeying when defining properties could very easy cause bad things. Alas I've resisted the temptation to refactor the entire system altogether for now (got to make a game you see!), but at least there's a nice juicy comment admitting the problems with the approach. As if that somehow makes it okay to write bad code....

(broken) los, (sorta) working combat, and other misc features

I've added a stab at some basic line of sight using a couple ideas. My first thought was to use the midpoint circle algorithm to generate the list of end points which I would then run traces along using Bresenham's line algorithm to generate the points. That of course generated a very pretty circle without nearly enough traces to cover the actual interior area.

Round two, generate a circle of end points using ol' fashioned cosine/sine, stepping the angle by an educated guess (Pi/(Radius^2)) and then trace to those end points using Bresenham's again. This generated slightly better results (near perfect @ 4 > Radius <= 8 or so), but anything other than that small set of magic numbers causes holes due to Bresenham's skipping. Next step is to just breakdown and write a trace that correctly touches all cells, and will give me the flexibility to handle various 'edge' cases depending on the angle of the trace (stuff like illuminating the walls of a corridor). For now I'm living with half-working solution #2, telling myself I have much bigger fish to fry...

From roguelike

At any rate, adding even broken LOS makes a huge difference in the feel of the game, and adding the various bits starts to glue everything together. More stuff keeps catching me unexpectedly, such as the seemingly simple combat text. When to capitalize, when to not, arbitrary formatting of strings based on various attack attributes, etc all add up to a bit more than you'd expect.

at any rate, basic combat is in with some bells and whistles. Goblins all get daggers - which they drop on death of course, although you can't pick them up, rats get their claws, and you the daring 'DEBUG' get your amazing hand of god which annihilates anything if it manages to hit.

making a game is... hard

I've finally gotten my "engine" up to the point that I'm actually starting to make a game of sorts, which is sort of like hitting a brick wall given that I haven't really thought much about how the game I want to make will actually work.

Take a simple attack for example - the attacker conceivably needs a set of values to represents how accurate their attack will be, how long that attack might take, and possibly how much damage that attack would do were it to hit successfully. Of course on the other side you have the victim, who conceivably has some sort of evasion or dodging properties, some damage absorption/resistance, and of course a health value which our attacker is attempting to deplete. It all sounds relatively straightforward right? Pretty much, except now we have to figure out what sorts of relationships all those properties have to each other, what sort of equation do we need to work out to make something that's workable much less balanced, or even worse... fun.

For the chance to hit I went with something pretty simple really:

- Accuracy (Some summation of various Attacker stats)

- Evasion (Another vague summation of various Victim stats)

- ToHitCap = Accuracy + Evasion

- ChanceToHit = BaseChanceToHit + ScalingToHitValue * (Accuracy - Evasion)/ToHitCap

Basically this means that if my accuracy matches your evasion then I have no advantage or disadvantage in hitting you, but as my accuracy starts to outpace your evasion it becomes easier for me to successfully hit. I have no idea if this is going to work very well in the long run, but so far it seems to be working well enough, and leaves me free to keep both those stats somewhat unbounded.

Now I just need to work out about 5 more of those sorts of encounters, implement an inventory system (or at the very least a weapon for the player to wield), and I might actually get to the point where someone might confuse this project for a game...

progress on the ol' roguelike

Been working on UI stuff mostly, added frivolous stuff like multi-colored strings, extended ascii character support, and more animation. You'd think it'd be completely wasted on a text-based game but it's keeping me entertained so that's really all that matters. Anyways, here's the first screenshot posted for posterity...

From roguelike

As you can probably see the executable is currently named aethrya, which I now think is pretty crappy for a title (and I really have no idea where it came from), but I've been too lazy to change it (and I keep telling myself it doesn't really matter until I get to the point where I want to release something anyways). According to source control the project officially started on August 12th 2007, and I've only recently picked it up again as of a couple months ago. I've spent quite a bit of time working on creating the base engine parts that are independent of the game to be made (honestly I have no clear idea what kind of game I'm actually going to make yet), which has been quite a bit of re-inventing wheels and whatnot - which has been incredibly educational.

I've been working professionally as a game developer for over six years now, and during that time I've always worked with existing engines, which means I end up taking a ton of functionality for granted without ever getting a chance to dig into the how/why. From simple stuff like templated data structures to more complex reflection systems and even garbage collections, it's been highly entertaining, educational, and a bit humbling.

I'm not sure I'll be inclined to start this sort of endeavour from scratch again in the future, but I'm definitely glad I've put the time into this effort, even if it never matures into an actual game someday - and I strongly recommend anyone with too much time on their hands to reinvent a wheel from time to time. Jeff's post at Coding Horror on this is a bit more compelling than my own: http://www.codinghorror.com/blog/archives/001145.html.

Bit of irrelevant trivia - the player is currently bright red to test out the '!' for bold colors on the TextColor property importing. Exciting stuff, really!