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....

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!

tools for starting a new c++ project

Here are some tools I recommend for anyone starting up a new project (on Windows), most of which are free for personal use or somewhat cheap...

Perforce (http://www.perforce.com/) - source control that's easy to setup, easy to use, and has a free personal license.  I know many programmers don't see the point of source control for small personal projects, but I find it invaluable.  First and foremost having a changelist history will become invaluable as your project grows, and it also helps you pick up where you left off when you happen to have months in between development.

Visual Studio (http://www.microsoft.com/Express/) - even if you don't use this for primary editing (I use slickedit for actual code writing) it's invaluable for managing projects/compilation, and the debugger is invaluable.  If you're not down with using VS for whatever reason, you can always go the mingw route (http://www.mingw.org/) and compile using gcc + makefiles.  I've heard mention of Code::Blocks (http://www.codeblocks.org/) as an IDE to use with mingw, but I haven't tried it myself.

Slickedit  (http://www.slickedit.com/) - this has been my primary IDE for nearly a decade now.  At first glance most people don't see the point, but the beauty of this program is that you can configure exactly to what you like, and eliminate the rest.  If you don't want to spend money however, there's plenty of other free/cheaper options out there, but your best bet would probably be XEmacs (http://www.xemacs.org/).   It's not pretty, but it can do pretty much anything you could ever want in an editor.

Jira (http://www.atlassian.com/software/jira/) - this is a fairly powerful issue/bug tracker that has some decent licensing options (right now they have a 5-user for $5 promotion actually).  the UI is a bit brutal, but it's all web based and definitely has all the features you'll need (plus plugin support for everything else).