Some time ago, I decided to write a small C# “wizard” tool for enemy encounters and other level design patterns.  The idea was to create pattern types, that designers could define with a small amount of data (different for each type of pattern) that could be exported into a much more complex xml format that could describe when to spawn what enemies, what behaviors and properties to give them, etc. in order to make each instance of a pattern unique. 

The properties set by the designers were stored internally as an XML document, since XML in C# is incredibly easy to manipulate, and since the data would be different for each level design pattern.  It was easy enough to save out the raw XML data as it was stored internally, but the problem was how to transform this data into the format that would be read into the game. Enter XSLT.

C# has the functionality to transform data internally with an external XSLT file.  It’s easy enough to associate a XSLT file with a specific pattern, apply it at run time, and then simply write out the result.  At this point, it’s simply a matter of providing the designers with the data files necessary to generate their data.

The advantages here are great.  Putting the complex structure and syntax in an external file, and separating it from the designer’s view, allows them to concentrate on what’s  actually important.  The downside is that someone has to craft these XSLT files, which is a format that is a bit obtuse for someone used to functional languages.  Additionaly, XSLT has little to no debugging capability.

Now, more recently, I’ve had the challenge of writing an exporter from OpenOffice Calc, which also uses XSLT as filters for importing and exporting.  All OpenOffice documents are are stored as XML.  In fact, if you simply rename an .ODS file to a .ZIP file, you can explore the format, which is spread over several files inside the .ZIP, the most interesting of which is called content.xml.  This is the data that needs to be transformed in order to get the information out of OpenOffice into your own format.

What we wanted was a way to store properies of all enemies in a single table, so designers could tweak values easily.  The data then needed to be exported into a proprietary text format (not XML).  This is also relatively easy with XSLT, but as with anything, exporting from Calc with XSLT had its pitfalls.

It’s easy enough to access individual cells in a row in Calc.  Unfortunately, for some reason, they decided that if adjacent cells in a single row have the same value, it would only be stored in the first cell and an attribute on that cell would indicate the value repeats for n-number of cells.

With XSLT, there are no variables that can change their values, only constants within a single template (the XSLT equivalent of a function).  Consequently, there are no “for loops” in the traditional sense.  The way to get around this with XSLT is to use recursion.  In my script, I basically have every cell recursively calling the template on the next cell in the row, or on itself in the case of repeated cells, and track the cell heading (the first row of the table) separately.  Just thinking about it gives me nightmares.

At any rate, more and more data is being stored as XML, and consequently XSLT is probably here to stay.  It’s another tool that should be available in the game developer’s toolbox, but must be used with care.  To learn more, there are tons of resources on the web, but your best bet for a good introduction is the W3 schools site at http://www.w3schools.com/xsl/.

Filed under: Uncategorized | 2 Comments

A while back, after a talk I gave at our local IGDA chapter meeting, I got an email from a recruiter at a local game development company.  He was looking to fill a position for a tools engineer and wanted to know what he needed to look for.  I never got back to him (sorry!) mostly because I didn’t know what to tell him.  What makes a good tools engineer?  More importantly, what’s going to make someone want to take a position in tools development over a position in, say, game play programming, or AI programming, or graphics programming?  Is there a distinct difference?

I really wasn’t sure of the answers to these questions until recently, and it made me think a lot about… well… you’ll see.

The Fundamental Trait

During my thinking, I think I identified the fundamental trait that makes a good tools programmer, or at least a programmer that would rather be in tools than any other field of game development: the desire to fix things.

This is different from most programmers who enter the game industry.  Most game programmers want to create things.  They want to point at a portion of a game and say “You see that?  I did that.  I made that happen.”  As tools programmers, we can’t really say that.  I worked on Oblivion and Fallout 3, on the game team, but there’s nothing I can specifically point to in the game that I really created.  The closest I can get to is that I can point at the models and say “You see that model?  I made the tool that made that model more memory efficient on the 360.”

Game programmers want to create, and, in my experience, when you talk to people both inside and outside the industry and say you’re a game programmer, the first thing they’ll ask is “So what did you do on the game?” expecting that you’ll be able to point to something specific.  Gameplay programmers can say “I made that system work.” AI programmers can say “I made that person move.”  Graphics programmers can say “I made that thing render and look good.”

Tools programmers can really only point at the team and say “I made that work better.”  And honestly that’s how we want it.  We take joy in oiling the machine.

The problem with the fundamental trait is that it’s not the trait that makes people enter the game industry.  A programmer that takes joy in oiling the machine can do so in almost any industry, and, unfortunately, the game industry offers some of the worst hours, worst pay, and worst return on emotional investment of any programming industry.  So, the only people you’re going to get looking to be tools programmers are going to be those that are attracted to the game industry in the first place, and the problems that it stands to solve.  In my experience, this means creative people.

The Fundamental Dichotomy

Because you’re working with creative people, game industry tools programmers not only want to oil the machine, they also want to take part in its construction.  Like most good programmers, good tools programmers want to constantly try new things, learn new technologies, and generally broaden their knowledge and hopefully find a way to improve your tool chain as a result.

The dichotomy here is that, at some point, you need to stop these creative people from being creative, and earlier than you would the rest of the game team.  They need to stabilize their tools for use by the team, and therefore they enter support for code a lot sooner than the rest of the team, and support is the one thing creative individuals dread.  It means the end of creative solutions, and the start of debugging drudgery.  Keeping a balance of both is tough, but necessary, to keep the best tools programmers on your team.

Achieving the Balance

In my opinion, there are a few things you can do to help keep this fundamental balance between oiling the machine and constructing the machine.  It boils down to the fundamental roles of your tools team during the different phases of a game’s production.

During pre-production, give your tools programmers some time to be in full construction mode.  Allow them to try new things, new pipelines, new technologies.  Let them look into converting the build system to Erlang, rewrite your Win32 tool in C#, or improve the interface on many tools.  This is a prototyping phase, and should be labeled as such.  Things made during this time do not necessarily need to be working, just prove that something will be more efficient than what is already available.

During code production, you should select the prototypes that make the most sense to implement and implement them.  Here, your tools programmers are working very closely with the other teams to make sure all of their needs are going to be handled.  They’re constructing the tools and letting out creative energy, but the tools now have clients (the team) and the client’s needs have to be met.

As the game enters production, the tools team needs to transition to support and minor improvements.  At this point you’re mostly looking at bug fixes, but all of your tools programmers should be researching how well tools are doing “in the field” and look for ways to improve interfaces and save other team members time, either now with minor changes or during the next phase.  When code lock down occurs, this should include tools, and the team has entered support mode.

However, once code lockdown occurs, the tools programmers, provided they have time, should be already entering pre-production on their new tools.  Now is the best time.  The problems of their technologies are fresh in their mind, and if they can fix them now, when more of the core team moves on to pre-production they can start being productive immediately with new tools.

This cycle helps keep your tools programmers creative, and helps them really point to the whole process and say “I made that work better,” which is exactly what they want.

What do others think?

Filed under: Business, Productivity, Programming, Teams | 5 Comments

The IGDA has opened nominations for the Board.  From the newsletter that went out to IGDA members:

As we approach the start of 2010, it is time for us to begin the process of electing new representatives to our IGDA Board of Directors.  These are the people who will be adding their voices to the decision making aspects of your association and choosing the direction for the organization to follow for years to come.  Each of these individuals gives of their time and energy to move the association forward in the direction they feel most represents the will of the membership and the good of the association.

The link to nominate Board members is here: http://www.igda.org/elections/nomination-packet Note that you have to be an IGDA member to nominate a Board member, and you must be nominating another IGDA member.  (We recommend you be one anyway, and please note in your membership profile that you are a member of the Tools SIG)

It’s important to remember that the Board affects how the IGDA is run, and in many ways, it is the public face of the IGDA.  In some people’s eyes, the IGDA had a huge problem with public relations last year, partially because of the positions and actions of some of its board members.  This is your opportunity to make sure that developers that you respect get on the board and represent your interests, so please do not skip out.

Filed under: SIG Business | Post a comment

As many of you know, I’m a stickler for a good build process.  In my mind, a any game team can loose a lot of time and money just waiting for their builds to complete, or waiting for a build that won’t crash every 10 minutes.  This is mitigated somewhat by programming processes like unit testing and the like, but even with these, it is important that you have a clear and defined process for getting the build from check-in to team without any significant snags.

A few months ago, I gave a talk at GameX about improving builds and build process, and I’ve finally gotten around to posting the slides on my website, here.

There are a few things I wish I’d hit in the talk that just didn’t make it in, including talking about ways to distribute asset optimization and best practices for version control, but much of that is in flux for me right now, especially with my new found fascination with Mercurial and distributed version control (and it’s very real lack of binary / large file support).  Even without those concerns, I’ve yet to see anyone really tackle best practices in distributed asset optimization, including best practices in file composing (taking multiple files that make up a level, and composing so that they load faster), so it wasn’t something I was prepared to address.

What about from the readers?  What would you have liked to see in this talk that never got mentioned?  What would have rather I’d spent more time on?

Filed under: Builds | Post a comment

Hello!  I am happy to announce that our humble blog has just moved over to a new host (from WordPress.com) and is sporting a shiny new domain name thetoolsmiths.org!  This opens the door to adding new content to the blog with plugins (polls, etc…) as well as making it possible to add new features besides the blog (job board anyone?).

Do you have an idea of something that would be handy?  Drop us a line or leave a comment and tell us what is on your mind!

Right as the site was updating there were some posts, so make sure you didn’t miss them:

• Building on the Cloud
• Playing with Prototyping Tools

Cheers and keep making great tools, folks…  :)

Filed under: Announcements | 1 Comment

Over the past few years, cloud computing has become the next big thing for enterprise software.  The ability to easily scale resources to meet the needs of the end users cheaply is very attractive.  Amazon, Sun, Google and now Mictrosoft (among others) are all offering cloud computing solutions.  I’ve recently been playing around with the AWS (Amazon Web Services) to see what you can do with this technology, and I can already see a few ways it could be applied to games.

Running games on the cloud is an obvious use of these resources.  Need a game server accessable from anywhere in the world?  Start one up on a virtual server.  The ability to build machine images (AMIs on Amazon), complete with your own software running on operating systems like Linux, OpenSolaris, or even Microsoft Windows Server gives you that possibility for pennies a day.

But, where cloud computing could really come in handy is in game development.  Imagine starting a build distributed across the cloud, in which thousands of virtual machines simultaneously start processing individual bits data.  You might see builds going from minutes or hours to just a few sconds.

And the cloud isn’t just for processing either.  Some companies offer services for managing data that would traditionally reside in a relational database, and as well as file storage services.  You could even use your own machine image running some flavor of SQL.  With that capability, why not store assets in the cloud?  An asset control vendor could use the software as service (SAS) model for asset control, supplying developers with web and client based views into an asset database on the cloud itself.

The big problem here is that we’re trading bandwidth for processing power and flexibility.  The build process may take a few seconds, but retrieving the results to local machines may eat up every bit of build-time savings and then some.  We may see overnight builds turn into overnight downloads, and that’s no savings at all. 

Bittorrent file serving (available on AWS) may be useful as a build distribution model, but with most users on a single network, it doesn’t seem likely to make a difference.  Limiting the download process to necessary files only is simply the flipside of building necessary files only, so may also offer little in the way of savings.  Doing a bit by bit comparrison of files built on the cloud, and downloading just the file differences, may be a way to reduce the download time, assuming there are chunks of data in a binary file that remain constant between builds.  Other optimiztions almost certainly exist.

All in all, it could be a big win, but until someone proves it, we can’t know for sure.

Filed under: Builds, Middleware, Revision Control, LinkedIn | 1 Comment

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.

Filed under: Frameworks, Prototyping | 3 Comments

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.

Filed under: Builds, Productivity, Programming, debugging, pdb, visual studio, windbg | 1 Comment

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.

Filed under: Dependencies, Programming, Tool Design | 1 Comment

This ongoing series delves more deeply into each of the “six reasons your game development tools suck” as argued in my very first post.

Many game companies struggle with delivering tools quickly and cheaply.  Money is always an issue wherever you go.  After all, the bottom line is what keeps a company afloat and it’s employees employed.  No one wants their company to fail, to lose their jobs, or to lay off their workers.

Game companies are in an especially difficult position.  Attempting to balance a workforce spread over multiple disciplines — art, design, programming and production — is hard enough, but when you consider that those disciplines have their own specialties within each one, the task is even more difficult.

The obvious solution is to cut corners wherever possible, and that oftentimes falls squarely on the shoulders of  the tools team.  Why?  Because most game companies don’t make money selling tools.  Tools programmers serve in a support role, and therefore (in the minds of most game execs) are less valuable than those working directly on the games.

Tools teams very rarely get the full support of management, and game teams can’t be stalled waiting for tools to be completed.  The unfortunate sentiment among those in power is that there’s no time for tool design.  Get it done and get it done now.

There is no time for design, so the thinking seems to go, but what does that really mean?  Does that mean that the programmer implementing the tool charge blindly into development without thinking about how the tool needs to function?  Of course not. 

The programmer has a vague idea of what to do, and without ever writing it down or validating his thoughts with the end users in any formal way, begins to implement the design from his own mind.   He still thinks about it a great deal.  Perhaps 75% of his time is spent thinking and only 25% is spent typing.  There are probably still many  unanswered questions, but as the tool begins to take shape, some answers may start to become more obvious one by one.  The tool seems to practically design itself, but in reality, design is going on quite informally.

But wait!  What if one of those unanswered questions causes a serious problem?  What if the best answer to that question requires a rewrite of major portions of current code-base?   What if the other possible answers are so undesirable, that the rewrite actually appears to be the best option.  Because the design had been postponed until the code was in the process of being written, redesign is now very expensive.  Code that has been written will go to waste, and new effort must be exerted to replace it.

If the programmer takes this problem to a (non-technical) manager, concerned with cost and speed of developing the tool, the manager may come to the very justifiable conclusion that a rewrite is not the way to go.  Instead, just make a work-around for this one problem, in other words, a hack. 

As long as that’s the end of the story, then that’s probably okay.  Unfortunately, more issues may arise, with similar outcomes.  Also, once delivered, the end users will likely have feedback.  After all, without any formal design process, many of their needs/wants/concerns went unheard.  And now the real fun begins.

It’s already been established that the quickest solution is more desirable than better architecture and code, and so as feature requests are delivered to the programmer from the users, more and more workarounds are put into place to deliver a new tool quickly.  This leads to code that is difficult to maintain and potentially very buggy.

The end users are now saddled with a tool that does basically what they want but perhaps has stability or performance problems.  The difficulty  to fix those issues increases as time goes on as the code becomes more brittle and spaghetti-like.  Fixing one thing breaks something else, leading to a never-ending maintenance cycle that really makes no net improvement whatsoever.

Filed under: Programming, Tool Design, LinkedIn | 2 Comments