Monthly Archives: January 2009

To .Net or Not to .Net

Posted on by
46

Some comments to my previous post were asking why we decided to switch from .NET to wxWidgets. Here was why we decided to switch:

* The .NET Forms Designer was very unstable for us. Editing code that gets parsed back into the forms designer lead to forms that could no longer be edited in the designer. Cryptic internal exceptions when trying to edit forms were difficult / impossible to troubleshoot. Sometimes the form would appear but silently remove user controls placed within it. We ended up having to hand code all our UIs because the forms designer would inevitably break our layouts. This was especially true with user controls and controls loaded from assemblies outside Windows::Forms.

* Windows::Forms is buggy and lacking features (Multi-select tree view anyone?). We encountered bugs that we had to workaround that compromised our user experience because Windows::Forms is closed source (why is that anyway? we couldn’t think of a single good reason for Microsoft to keep that source close to their chest). wxWidgets comes with full source and we have made fixes and added features that have been picked up by the main line. wxFormBuilder is a superior solution to this problem and its fast and extremely stable.

* We like to tightly integrate code between our game runtime and tools, and we see this as key moving forward with the next generation. This means we have native C++ code that we wanted to call from .NET (and sometimes *god forbid* vice versa!). This lead to managed C++ (C++/CLI) wrapper classes that ended up creating more work for us. Using .NET made it feel like we had less choices rather than more choices when it came to organizing our code (you must use DLLs), integrating code (especially with intricate data structures), and deploying our tools (.exe.manifest and .exe.config madness just to use an assembly in another folder). All of these things are easier with wxWidgets and native code and we are able to spend less time troubleshooting .NET idiocy and more time creating what our users want. Also, mixed-mode debugging is no fun and gathering callstacks from a crashing tool across the managed/unmanaged barrier isn’t really possible or supported by .NET.

* We already had a good C++ reflection system and data-driven property system (they are in Nocturnal). This gave us type checking, serialization, automatic type conversion, and property sheets without using .NET. These were the killer features to us for using .NET, and having our own solutions to these features that gave us the freedom to ditch .NET for our level and asset editor in about 1 man month.

* Embedding technology based on .NET as a plugin in another product (like Maya) is impossible and/or dangerous and/or difficult. This goes back to what I said about having more choices rather than less choices. wxWidgets integrates with Maya very easily.

* Getting support from Microsoft is a joke. The community is a better source of support than contacting Microsoft directly. Several of our tickets we closed in their tracking system (without a real resolution that we could use) because they were fixed in ‘their internal builds’. They just hung us out to dry on a lot of things. If we are going to be paying for a development environment and UI toolkit then it either needs killer support or it needs to be open source so we can fix it ourselves. Getting stuck at the mercy of a company that won’t release service packs to fix your bugs and makes you pay for them in the next product cycle that contains little in the way of other benefits is immensely maddening. Also, the public hotfix directory is a joke… They need to make fully tested service release so we can get on with our lives!

* wxWidgets is cross platform. I like to believe that someday we (as a studio) won’t be as dependent on Windows as we are now, and wxWidgets gives us strategic room to grow in this regard. The Linux and Mac ecosystems have a lot of things that are desirable compared to Vista/Windows7. Not having to reboot your server farm every 2 weeks due to kernel memory leaks in the 32 bit emulation layer is one example :)

Ultimately switching to wxWidgets simplifies everything in our tools pipeline, makes refactoring and making major changes to key subsystems easier, and makes our tools easier to deploy to our users. It was an easy choice to make, and we haven’t looked back since. We still have several small tools that use .NET and going back to work on them and fix bugs is no fun after switching to wx.

C++ Events and Delegates

Posted on by
11

Hi folks,

One of the coolest things about working for a company like Insomniac Games is being able to open source technology that our tools team creates.  Nocturnal is our open source project, and one of the most useful things included with the ToolsFramework project is its c++ event and delegate system.

Any programmer that has used Microsoft’s .NET framework will tell you that the events and delegates implementation in .NET is incredibly useful. It pervades the entire Windows Forms framework. UI element callbacks, plug-in APIs, and application automation are all made easier by this design pattern. Unfortunately jumping into the .NET Framework doesn’t go without significant trade-offs.

When Insomniac ported its tools from .NET to wxWidgets we definitely wanted something as slick as .NET events and delegates. This is what we came up with, and we have been iterating on it for several years now. Most of our key libraries and applications lean on it heavily.

This implementation supports a lot of tricky cases that aren’t easily handled by function (or member function) pointers alone. Delegates can be added and removed within delegates of the same event and objects that own events can be deleted from within delegates of the same event.

To get started, just typedef the Signature template with your return and parameter types. Then use the Event class (a member class of Signature) to make a multi-cast event, or Delegate to make a single-cast event.

EventDemo.zip

Geoff Evans
Insomniac Games

EA's Prototyping Framework

Posted on by
1

This is news to me. Apparently EA has release one of its prototyping GameJam frameworks to the public on Google Code. The framework (called Angel) is available here:
http://code.google.com/p/angel-engine/

From the site:

Angel was originally made by a group of employees at Electronic Arts Los Angeles for use in a GameJam they were planning for April of 2008. The source was opened in January 2009.

Angel provides:

  • Actors (game objects with color, shape, responses, attributes, etc.)
  • Texturing with Transparency
  • “Animations” (texture swapping at defined intervals)
  • Rigid-Body Physics
    • A clever programmer can do soft-body physics with it
  • Sound (.wav only)
  • Text Rendering with multiple fonts
  • Particle Systems
  • Some basic AI (state machine and pathfinding)
  • Config File Processing
  • Input from a mouse, keyboard, or XBox 360 controller
    • Binding inputs from a config file
  • Tuning Variables that write out to a config file
  • In-Game Console
  • Logging

It should be noted that Angel is not a framework for beginning programmers.  Again, from the site:

Angel is designed for experienced engineers. That doesn’t mean that it uses all sorts of crazy programming techniques or is difficult to use (quite the opposite: see #1), but nor does it hold the developer’s hand very much. It’s expected that a developer has at least some experience exploring a codebase to see how it works.

I think this is fine for a prototyping framework, as they’re made to get “out of the way” so that a programmer can do exactly what they want quickly.

I look at prototyping frameworks as one of the key tools a company can provide to programmers. It allows them to quickly and easily investigate a new system in your game without having to go through the complicated mess of your engine (and, yes, regardless of how awesome your engine is, it’s still a complicated mess). In my mind, this is a big thing, and I hope it continues to evolve over the next few years.

The Build Pipeline

Posted on by
1

Hi everyone, I’m Jeff Ward, Lead Architect and co-founder of metrics middleware company Orbus Gameworks, located in Cambridge, MA.  Although I’m sure I’ll have a change to talk about the use of metrics as an extension of your tools at some point, for my first post, I wanted to talk about something near and dear to my heart: automated builds and continuous integration.

Now, I know, build process isn’t technically tools related, but, like most technical obstacles to good process,  it usually falls to tools programmers to actually set it up, and it’s usually up to us to write any custom integration our game might provide, but that’s a completely different post.

There are a lot of things to consider when writing a build system, but in my experience, any reasonable build system will be able to the following:

  • Do a complete, clean build of all current code and assets from scratch without any user interaction.  This is commonly known as a “one button build”.
  • Be able to do incremental builds of code an assets when prompted, and be able to perform these builds quickly regardless of the number of files or assets.
  • Automatically update executable versions and package working builds together for distribution.
  • Inform interested parties about changes in the latest build, or any errors that occur during the process.
  • Be run regularly, at least daily.  Continuously is better.

The great thing is that, most of this can be accomplished without any special tools.  Almost any build scripting system has the capabilities to make your build vision a reality without too much effort.  Favorites include make, ant, scons, jam, waf, rake and msbuild, among others, and most of them will even do dependency checking for you (so long as you structure them correctly).

But this is really only the first step on the track to creating a build system that will really save everyone at your company time and money. Let’s face it, an automated build system and build server doesn’t solve the “bad build” problem, which is the key to actually getting your artists and designers to be productive.

The first step on the track to success is using continuous integration.  Continuous integration is a process by which new code is contagiously integrated (aka, built, hence the name) so that an up to date version is always available.  What this means in layman’s terms is that every time a file is checked into source control, it kicks off a new build of the game.  This means that the available executable are always up to date with the latest and greatest features, or that you’re informed of a broken build as fast as possible after a check-in.  Of course, this can be a complete nightmare if you’re not using any automated testing, but that doesn’t mean the concept isn’t completely off the wall for the general game developer.

Let’s say you’re not doing any automated testing.  New versions of the build could go up every day, or every hour, but there’s no way for your developers to know whether they’re getting good builds.  You have a few options:

  • Don’t run daily builds.  Have a programmer in charge of creating and deploying “good” builds every so often.  This is a bad idea.  It takes time away from a programmer who has other things to do, and puts a person in charge of what should be an automated process.
  • Run daily builds, but only have people update when “good” builds are made.  This can also be a bad idea.  It still requires a person send out an email informing the team of “good” builds.  And what happens when someone updates by accident?
  • Run daily build that goes through an established pipeline.  “Good” builds that pass through the pipeline can be push to a centralized location after they’ve been verified.

This is the “smoke test” concept.  I know many companies do this, but most do not formalize it, or don’t follow it with every build.  In a lot of cases, smoke testing builds doesn’t even start until late in the development cycle (beta or release candidate stages) and that’s really too bad, because lost time at the beginning of a development cycle is just as bad as lost time at the end, so you should always prepare for it.

So what tools can you use to automate a build pipeline?  Well, the product we use at Orbus is a continuous integration server called Cruise, which is made by the same company that originally made Cruise Control (though Cruise Control is a free, open source project and Cruise is a commercial project, though limited agent builds are still available for free).  The nice thing about Cruise is that, not only are individual tasks parallelizable, but portions of your pipeline can wait for user interaction.  For me, here would be a common pipeline:

  • Run continuous integration on code builds (every check-in triggers a build)
  • Successful code builds trigger asset builds, and the two are bundled together as an artifact.  At this point, anyone can grab this particular build, meaning people waiting on the latest and greatest (who don’t care whether or not the build is “good”) do not have to wait for user interaction or testing.
  • A select test team tests the build for any obvious flaws, and can confirm (through Cruise) that the build is good, and the build is copied to a more centralized location for the rest of the team.
  • If you’re really good, the build is then automatically distributed to the team.

The agileness of continuous builds with the safety of a smoke test, every time.

The 6 Reasons Your Game Development Tools Suck

Posted on by
9

There are many reasons game development tools fail.  Perhaps not all of these apply to you, but every game studio I’ve seen has had one or more of the following problems.

1. Design as you go
All too often, game companies are in too much of a hurry to allow proper upfront design of tools.  As a result, programmers end up designing the tools, anyway.  Unfortunately, since they have to continually show progress, the tools are designed as they are coded, which doesn’t really save any time at all, and leads to a host of problems.  As tool development gains inertia, the earlier code becomes more and more difficult to change without breaking the entire system.  When given a choice between rewriting code  and creating a workaround, the least expensive of the two (in the short run) is generally preferred.  Major changes to support new features or a more desirable workflow become more and more difficult as the code becomes too brittle to support it’s own weight.

2. The system model of design
When programmers design interfaces, they tend to expose the underlying data structures directly.  That is the most logical method for someone who understands the inner workings of the system, and often gives the most flexibility the the users.  The end user, however, has a different view of the system based on his his own goals.  He doesn’t need to know the underlying implementation details, just the end result. The system model can give the desired effect, but may seem overly complicated or downright illogical to the user.

3. Leveraging the wrong technology
A lot of us, especially with engineering backgrounds, cringe at the thought of “reinventing the wheel.” Recreating something that already exists somewhere else goes against everything we’ve learned, but taking a tool designed for one thing and turning it into something it was never destined to be, will cost more time in the long run than just writing a new tool from scratch.  Often, the remains of the old tool clutter the interface or drag down the performance.

4. Complicating the interface
“The simpler, the better,” should be every tool designer’s motto.  The more interface the user has to deal with, the more difficult it is to use the tool. Focusing on the goals of the end user, should make apparent what interface items should be readily available, and which should be hidden away in a menu somewhere.  The most common operations should be the most accessible and easiest to use.

5. Extraneous features
Often, the tool designers aren’t communicating with the tool users, which always leads to a handful of features that just aren’t used.  They probably seemed really important during design (at least in the programmer’s mind), but time constraints or misunderstanding on the part of the users keep them from fully utilizing these features.  The time wasted on such things should have been used to improve the most commonly used functionality.  Instead, they clutter the interface or add additional steps to a process that should have been much simpler.

6. Designing for advanced users
Let’s face it, there are some people in your company that are more technically skilled than others, and I’m not talking about programmers.  Often, the more technical designers (the ones with scripting or programming backgrounds) are the ones who are able to use the internally developed tools more effectively, leaving the rest of the design staff to struggle.  This is also true of other disciplines, but design has it the worst, in most cases.  Game development tools should target the average user, with advanced functionality neatly tucked away where the more technically savvy users can find it, if necessary, while the more common functionality should be out in plain sight, easily accessible and understandable.

All of these issues lead to one overarching problem — low usability.  Tools that are unusable, do little good to anyone, and higher usability leads to happier and more productive employees.  Every minute that an employee spends fighting with the tools is a minute that could have been spent making a better, more polished game, something every game company struggles to achieve, and addressing problems like the ones above will help tremendously.  I’ll talk more about these and other issues more in-depth in future blog posts.

Tools SIG: A New Year

Posted on by
5

The IGDA Tools SIG is proud to announce that we are relaunching the IGDA Tools blog with new authors, new technology, and a new name, The Toolsmiths!  Along with a new design, we have enlisted the help of 3 new authors, all of which have a very clear opinion on game industry tools.  All of us are hoping that we’ll be able to make this blog a great place for commentary on the current state of tools in the industry, a breeding ground for distributing ideas, a test bed for new technology, and a soap box from which we can improve the industry (through tools, of course).

So without further ado, our new authors are:

  • Me, Jeff Ward, Lead Architect, Orbus Gameworks
  • Geoff Evans, Senior Tools Programmer, Insomniac Games
  • Dan Goodman, Founder, Robotic Arm Software

I’ve asked that each do a blog post over the next week to introduce themselves and give you a post on something they’re currently interested in. If you have ideas for things you’d like addressed on the blog, please feel free to comment, or send any one of us an email.

Enjoy the new blog!