Monthly Archives: September 2009

Playing with Prototyping Tools

Posted on by
4

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.

Debugging in the Field

Posted on by
1

Developing in-house game tools presents a myriad of debugging issues. You can’t always nail down bugs to reproducible steps (if you even have QA resources to concentrate on that). Frequently content creators will complain about rare issues that force them to reboot the tools or use bizarre workarounds then things go wrong. Remote debugging works in some of these scenarios, but is mainly useful for debugging crash bugs. Errant “drag and drop” or “click and drag” problems require sitting at the machine to properly deal with.

In these cases its handy to be able to deploy a debugger onto the user’s machine so you can dive in and see where your code is going wrong. To be successful at this you need a couple of components: the debug symbols from the compile, the source code, and a debugger.

On Windows the debugging symbols are separate files from the executables. PDB files contains the information debuggers need to map addresses of code and data in a running tool to the source code counterparts. In Visual Studio, PDBs are only generated in the Debug configuration by default, so assuming you distribute something like a Release build to your users you will need to turn on PDB generation in that configuration. Its under Linker… Debugging… Generate Debugging Info. Set it to Yes (/DEBUG). When you prepare and publish your tool set, make sure to include these PDBs with the executables (EXE and DLL files).

PDBs can get quite large, so it may be a good idea to not always pull down PDB files when users get the latest tools. Insomniac’s tools retrieval script has some command line flags to pull down PDBs and code only when we know we want to debug something on a user’s machine. Using -pdb will get the executables and PDBs, and -code will get the executables, PDBs, and source (all from a label populated when the tools executables were checked in).

Once you have the PDB and code on the machine you just need a Debugger to dig in with. On Windows you have a choice: Visual C++ Express Editions or WinDBG (from Debugging Tools for Windows). Both are free to install so you aren’t bending any license agreements here. Visual C++ should work pretty much like you expect on your development box, but can take a while to install and patch to the latest service pack. WinDBG on the other hand is very quick to install, but takes a little getting used to. Typically you must show the UI you want to use (Callstack, Memory, etc…), as well as potentially manually setting the PDB search path (from File… Symbol File Path). It’s a very different experience but its so quick to deploy it may be worth checking out.

The Dependency Question

Posted on by
1

One thing I’ve been interested in for a while is what I call “The Dependency Question” as it relates to tools. The question is, when and how do you share code between your game and your tools, specifically tools that are communicating with the game either directly while it’s running or through things like asset files. There are many options on how to do this, and even more opinions on how to do it wrong. From a dependency standpoint, though, you have two options.

First, you can have the tools and the game depend on a shared library of resources. The tools have their own UI, tick or don’t tick at their own rate, and may or may not use the same renderer as the actual game. By creating tools this way, you have tools automatically update their own behaviors as new features are added to the game, or even automatically generate their own UIs if you’re using a dlls and a reasonably robust reflection system. The problem here is that if you’re not using the game’s update and render loops, you still have to boot the game to see everything in action. This can create long turnaround time for assets, especially if your game takes a long time to boot and / or load. That said, this allows you to keep your tools slightly smaller, it reduces dependencies on what are often unnecessary game libraries (like threaded sound and in game UI), and can make the tools less prone to break due to game changes.

Your second option is to either make the tools dependant on the entire game, or make the tools embedded in the game. Now, I think every studio has a small amount of “on the fly editing” capabilities in their engine, but there are very few that are willing to take the full plunge and make their game the editor. In some cases, this is because they can’t afford the extra memory or processor time to fit an editor on a console dev kit. That said, in game editors, or editors that can run the full engine stack, can reduce asset turnaround time significantly. Given a properly designed tool, artists, designers, and scripters can actually edit objects on the fly, and see their changes affect the environment immediately. Once given a tool like this, few would want it taken away. However, these tools can also get cumbersome as well. Because you’re working in the game engine directly, few tools developers in this scenario will take the time to develop good user interfaces, as it tends to clutter up the screen quickly, instead relying on weird key or button combinations to achieve the desired result.

In both cases of dependency, the one thing you need to avoid is the dreaded #IFDEF EDITOR block, and I know you’ve all seen them, and they almost always defeat the purpose of having shared code in the first place. The idea behind shared code is to make sure the editor behaves the same way the game would under the same circumstances. #IFDEF EDITOR blocks, by definition, create inconsistencies between editor and game. But these blocks almost always become a necessity at some point, which is why some studios prefer to forgo the dependency question entirely, and instead opt for a tool that outputs a platform independent format (XML or JSON for example) then has various versions of the game decide what to do with them. The game can ignore blocks it doesn’t understand, and fill in missing blocks with default values if needed. This keeps game and editor independent, so that mismatches can be safely dealt with. However, it still incurs the wrath of the slow turnaround time, and the necessity to maintain two separate code bases.

In my opinion, dependency is a requirement. The idea here is to protect against game changes, include the ability to preview your game, and shorten turnaround time to the game whenever possible. Toward this end, you should limit yourself to dynamically linking in only the libraries you need, which is usually your rendering libraries and your game object libraries. Try using reflection where possible to generate your UI against game objects so that changes in game objects don’t require complete editor recompiles. Save and load objects to a text format (XML is my favorite, but you can choose whatever you like) at least during development so that you can protect against mismatched resource bugs, and, lastly, use a robust shared command system to transmit changes to a running game to shorten turn around time.