The Toolsmiths Google Group

Posted on March 28, 2011 by Jeff Ward

The IGDA Tools SIG has a new discussion group! We’re moving from using the IGDA hosted Mailman group (called Tools-Discuss) to a Google Group called The Toolsmiths.

The purpose of the group is to provide a discussion forum for all types of game tools development, from command line tools, to UI-focused tools, and middleware applications. This can include things like best practices in version control, building and build servers, exporters, level editors, deployment scripts, and game to tools integration. Basically, if you do it as a tools developer, we want to hear about it, and discuss it with you.

See you on the list!

Data Driven is Half The Battle

Posted on February 14, 2011 by Jeff Ward

I was recently invited to do a talk at Game Forum Germany, and the talk I gave was called “Data Driven Is Half the Battle.” I’ve made the slides available on my website if you would like to take a look.

The purpose of the talk was to show that just making game systems data driven is not the end of the road to making your game configurable, especially when you want the rest of your team to be able to edit these configuration files. Formats like XML and JSON are awesome, but by design lack any context for the properties and values they control. This is good thing from a programmer’s perspective, since it means that we can define the meanings of properties and valid values, but a bad thing from the perspective of someone who has to edit those files. Either the system needs to be really well documented, you need to create a tool that ensures that people editing can only supply valid values.

Maintaining these tools can become a huge pain in the ass, though, especially when features or data modules are being added frequently.

My proposal to fix this was to use reflection, either custom coded in C++ or one offered by the language you’re using. This is the one I have the most experience with and the one I’m most comfortable using. Interestingly fellow Toolsmith Geoff Evans actually has an article in Game Developer this month about using reflection in Helium, which is worth checking out if you’re looking to implement this sort of behavior.

However, this does not mean this is the only solution, especially if you’re moving data between multiple systems and / or multiple languages. In this case, a data definition system, might be more worth your while, especially if you can just use the data definition to dynamically load the class as specified (this would be possible to do in dynamic or duck typed languages).

No matter what, the key takeaway of the talk was twofold: 1) Make it easier for people to modify data, and everyone will be happier, and 2) Make it easier for your programmers to do so, and they’ll do it more frequently, with fewer bugs., which also makes everyone happier.

Common Problems: Preserving Atomic Changes When Checking In Builds

Posted on January 11, 2011 by Jeff Ward

One of the things I’d like the Toolsmiths to be is a place where we can discuss our common problems, and hopefully come up with common solutions. Toward that end, I’m starting a new series on the blog called “Common Problems”, and I’m kicking it off with something that I’ve seen as a common problem recently.

We all know the benefits of having continuous integration and / or nightly builds. What I’ve found to be problematic, though, is when distributing that build to other members of the team means checking the build into source control, specifically when it is checked in to the same directory that other team members use to do their work. This setup is beneficial in many ways. This directory, we’ll call it the “data” directory, is basically a snapshot of the project. Team members pull from that directory and it has the most recently compiled executable plus all configuration, data, and art files needed to run the game. They can then easily change anything in the directory, test, and commit. It’s quick easy and painless, for the most part.

Generally artists and designers only check out the “data” directory, make their changes, and check back in so that everyone can partake. If they’re good artists and designers, they make sure that their changes work before checking in, and everything they’ve worked on becomes an atomic commit in any modern source control system. Since their not editing the executable, these changes almost always remain atomic.

Coders, however, check out both the “data” and the “code” directories. They will frequently edit the code and the data to get something working, and, after testing, they will then check in both directories atomically. However here’s the problem: there is a period of time between when the coder checks in new code and when the build machine will check in changes to that code into the data directory. During this time there is a disconnect between the executable and what’s in the data directory. In the best case scenario this doesn’t affect the team in any significant manner. Worst case, the game will crash because expected data has changed or been removed. Again, best case here is that someone realizes this is just a disconnect in the data and waits for the next build. Worst case, an erroneous bug gets created that someone actually spends time trying to solve.

I’ve tried to come up with possible solutions for this, but only have half answers:

Do not build continuously, and instead have programmers check in builds whenever they change the executable. This can be accomplished by setting the target directory to your data directory. The down side of this is that, on large teams, it would be a race to check in your executable before others. In addition, a careless coder could stomp out another’s executable changes. This would be hard, but not impossible.
Hold checkins to the data directory that modify code until the build is complete, and then check them in. This can be problematic because if the same data changes while the build is working, the source control server will reject the change. Furthermore, coders that pull during this time will get the code, but not the data. This is also extremely hard to implement.

What are your solutions for this problem? Do you have this problem? Why or why not?

Call For Submissions: Game Development Tools Book

Posted on March 23, 2010 by Jeff Ward

I thought I would bring to the community’s attention this new book on Game Development Tools that’s looking for submissions. Here’s the call:

We invite you to submit a proposal for an innovative article to be included in a forthcoming book, Game Development Tools, which will be edited by Marwan Y. Ansari and published by A. K. Peters. We expect to publish the volume in time for GDC 2011.

We are open to any tools articles that you feel would make a valuable contribution to this book.

Some topics that would be of interest include:

Content Pipeline tools (creation, streamlining, management)

Graphics/Rendering tools

Profiling tools

Collada import/export/inspection

Sound tools

In-Game debugging tools

Memory management & analysis

Console tools (single and cross platform)

This list is not meant to be exclusive and other topics are welcome.

The schedule for the book is as follows:

June 30th – All proposals in.
July 15th – Final list of accepted authors are informed and begin articles.
August 15th – First draft in to editor
September 15th – Drafts sent to other book authors for peer review
October 15th – Final articles in to editor
November 30th – Final articles to publisher (A K Peters)
GDC 2011 – Book is released.

Please send proposals to marwan at www.gamedevelopmenttools.com.

Regardless of whether Toolsmiths readers get into the book, it sounds like it could be great.

IGDA Board Elections

Posted on February 22, 2010 by Jeff Ward

The Toolsmiths was created, and is an integral part of, the IGDA Tools SIG. Right now, the IGDA is holding elections for its new board. There are 23 candidates for 5 positions on the board, and you can read all of their statements at the IGDA’s website. In addition, Boston Chapter member and indie developer Scott McMillan has subjected each of the candidate statements to some scrutiny, and asks them some important questions about where they feel the IGDA is going over the next few years.

The elections are very important, especially this year. In the past, the IGDA has had image problems, in no small part because of the actions of certain board members. It is important that we get board members that are actually extensions of our own voices, so that the IGDA can actually represent us as developers. If you are a member of the IGDA (which I really hope you are) please go vote.

GDC Approaches

Posted on February 21, 2010 by Jeff Ward

GDC gets closer every day. This year, instead of doing an official IGDA roundtable to talk SIG business, we’ve decided to just get together for beers at a local bar. The location and time is yet to be determined, but I would like to find out what night the membership / readers would prefer.

So please take a moment to visit the site and respond to the poll in this post to let us know when you’d most like to gather, and we’ll see you at GDC!

Loading ...

Tools Programmer Fundamentals

Posted on January 18, 2010 by Jeff Ward

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?

IGDA Board Nominations Open

Posted on December 23, 2009 by Jeff Ward

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.

Improving Builds (GameX Talk)

Posted on December 14, 2009 by Jeff Ward

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?

The Dependency Question

Posted on September 1, 2009 by Jeff Ward

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.