SteamEngine is the name I have given to a 2D graphics/game engine library that I’ve been working on for fun for about the last decade or so.  The library itself has gone through several different versions and has been implemented in a few different languages (none of which have ever been published).  The most current incarnation of the library is developed in .NET using GDI+.  Earlier versions were almost always developed using a combination of VB6 and GDI (Windows API calls).

I have never had a complete working version of this library.  Historically, I usually get something built up about half way (about far enough to get a working demo going) before I get sidetracked and move on to something else.  I always eventually come back to this, however I’ve come to accept at this point that I may never have a complete version that I can actually build a game with.  I’ve taken a very zen approach to this reality; the whole point is the journey rather than the destination.

The earliest versions of this library came about as a large chunk of structured code indivisible from a simple RPG that I developed while I was still in college.  I eventually lost interest in this game because, though it was simple to quickly generate a map and populate it with monsters, I didn’t plan for level development, story, or any meaningful kind of AI (everything was hard coded).

Taking what I learned from that first experience, I went to work on writing map editors that would provide a user-friendly interface to level editing, effectively allowing me to focus more on writing a proper game engine instead of trying to hard code an entire game into a program.  I had some pretty good results, however I was still using the structured approach and I wasn’t putting much thought into overall cohesive design or consistency.  Obviously, things would quickly bloat out of control and become unmanageable.

After that I made the shift to object oriented design and started building things back up again.  This was still back in the VB6 days.  VB6 is a very frustrating language to work in sometimes.  I loved VB6 as a language because I wanted to be able to build things quickly and not have to worry about getting too “under the hood” with my code.  I wasn’t planning on trying to sell anything or compete with the latest Prince of Persia release, so I didn’t exactly have to create ultra fast code.  Plus, I was an embedded software engineer at the time that only ever worked in C and assembly, so it was a relief intellectually to be able to operate at much higher abstraction levels when I got home from the office.

So on and on it goes until we get to the here and now.  I’m still chipping away at it, although things look nothing like what they did the first time I decided I wanted to build this library in the first place.  Like I said, there’s a good chance that I’ll never finish, which is just fine with me.  I enjoy tinkering with it when I have the time or the interest, like an old car in the garage.  It’s nice to be able to just develop without being driven to a deadline or having to worry about dropping features to make a release date.  Very liberating for a guy who does this kind of stuff for a living as well.

I’ve put this blog together here so that I have a handy way to document what I’m doing.  Most of the time I’ll pump out a class or two and then not work on anything at all for months.  When I get back to it I typically have a rough time remembering what I did so this will hopefully help me cut down my own learning curve.  Also, I know that there are plenty of other people out there who like to do this kind of thing; maybe such people can pickup ideas or inspiration here.