Playing with Prototyping Tools

Hey readers, my name is Casey O’Donnell, I’m one of the new Toolsmiths around here. I’m a bit of a strange one, having worked in the industry, studied the industry, and now as a professor at the University of Georgia. My research has begun to focus more and more on tools, tool development, and open source software. I still do a bit of game development that should be announced soon; a small development project that used Unity (a not-so open source tool), which I and my team enjoyed using (minus the lack of SVN integration).

In my efforts to put the tools and tool-chain wiki together (another one of many projects that was sidelined during the summer), I stumbled upon the (now not-so) recent blog post of 2D Boy, announcing the release of their rapid protyping framework (“BoyLib“). I don’t like having design students get bogged down in technical issues right away, so I am always looking at a variety of different tools for testing and thinking through game mechanics. While evaluating the BoyLib framework, Jeff Ward suggested that I compare it to Angel and AngelXNA [Jeff on AngelXNA], both of which were new to me. This is also read through the lens of my current efforts to port IndieLib to Mac OS X. Thus I spiraled further down the rabbit hole of rapid prototyping.

One of the primary advantages of AngelXNA that I’ve found is its linkages to XNA and the Game Studio asset pipelines. While rapid prototyping, it is nice to not give a second thought to how your assets will be imported into the game. Of course this isn’t entirely the case, sounds must still be in particular formats and in particular places for XNA to properly locate them. BoyLib uses irrKlang and Angel uses FMOD for sound importing, which buys you some flexibility greater than XNA. IndieLib uses DevIL for its image reading and TinyXML for XML. BoyLib also uses TinyXML for XML. Angel makes liberal usage of .ini configuration files and Python for scripting. Angel uses Box2D, BoyLib doesn’t seem to include a physics engine of any kind, so you’ll be coding that up from scratch. AngelXNA of course implements the underlying physics in an XNA friendly manner. IndyLib really excells in the 2D realm. The developers have clearly thought through the issues that most often affect 2D game development. Things like layers are an underlying construct, so end up being elements you pay attention to at the outset rather than thinking about them after the fact.

Ultimately, what I found interesting about each engine was its approach to pipelines. Getting art assets and design data into an engine becomes the crucial component. Image libraries, text file parsing, and supported scripting languages quickly become the focus for engineering problems on these engines. All except AngelXNA that is. The real plusses and minuses for each engine seem to come down to file support, preferences toward coding conventions, and supported platforms. While AngelXNA is great for prototyping and does an excellent job of using XNA’s asset pipelines, it creates Windows only binaries, and while it may allow you to prototype on your Xbox, taking it other platforms will provide not an insignificant amount of work.

Of course Angel has has had a bit more time to mature that BoyLib, and AngleXNA benefits from this history. IndyLib, though quite promising, offers the least amount of support for various file types and means by which to get things moving. Not to mention that Angel works on Windows, Mac OS X, and AngelXNA on Windows/Xbox 360 Community. BoyLib and IndieLib are currently stuck without a Mac port, which is something I’ve spent several days now really investigating. Combined with Angel’s overall better support for various file types, it seems to have the overall edge for a robust protyping tool and overall indy “engine.” That isn’t to say that IndyLib doesn’t have a great deal going for it. Indeed its focus on the 2D may very well make it a more desirable tool in some cases.

I was also intrigued by the near ubiquitous support for some sort of USB controller for these engines. This seems to indicate the for many game developers, the likely idea seems to be to really use these to develop prototypes for consoles rather than as “engines” in the more traditional sense. These are frameworks used to test out mechanics and user interactions quickly and relatively inexpensively. Personally, I’ve found that a USB Xbox 360 Controller can really provide an identifiable and productive gaming experience more quickly than the mouse or keyboard when trying out simple game mechanics and user interaction methods. Thus having controller support right away is a treat for most of these libraries.

This post is also an invitation, I’d like to get a sense of what frameworks readers are using. What works for you? What doesn’t work? What Open Source frameworks do you use? What closed source tools/frameworks do you use (assuming you can say)? As I gather all of these bits and pieces together, you become my greatest assets, so let me know what tools and tool-chain bits you want to see on the wiki.