Mini-postmortem on the use of gameswf in Oddworld: Stranger's Wrath

gameswf was used for the UI shell screens in the game Oddworld: Stranger's Wrath.

gameswf was used for all the UI screens outside of regular gameplay, as well as the Inventory, General Store and Bounty Store UI. Things that did not use gameswf include the weapon-selection UI, the pop-up tutorial text, and the in-game HUD. I did most of the code side of it, and Gautam did most of the design side.

Gautam posted some screenshots & explanation of some of the UI screens: http://gbabbar.com/html/directionOther/systems.htm

I've graciously stolen these screenshots from Gautam's site:

Pros

• It worked, the screens look pretty good and have some animation and other eye-candy that might not have happened otherwise

• Localization wasn't too painful (we didn't do Asian localizations though, only European).

• Flash is a great WYSIWYG tool for doing layout

• Flash is quick and productive for doing basic UI scripting

Cons

• Flash is not a very scalable programming tool for those used to C++ (at least the way we used it) -- ActionScript is too permissive and debug output isn't verbose enough, so it's really easy to have typo bugs. gameswf itself can be a little more verbose, which helps.

• ActionScript is not C++ and Flash is not Maya -- I was the only programmer on the team who really understood the UI scripts, and there was only one artist who was really up to speed on Flash authoring. All bugs/features had to go through the two of us. This proved to be a little bit of a bottleneck during debugging/QA. If one of us had been unavailable, there would have been an extra learning curve for someone stepping in to do our tasks.

• I had to write a lot of annoying glue code. There were two main types of glue; the stuff to integrate SWF resources with the game's resource & build systems, and the run-time binding to pass data/control between C++ and Flash to implement the UI.

  The resource glue was very time-consuming. SWF is optimized for small internet downloads, so the data is packed as small as possible and image data uses zip and jpeg. Whereas the game engine is designed to minimize load-times as well, so it uses power-of-two DXT formats for images, and prefers to store other data as close to in-memory format as possible.

  The binding glue isn't hard to write, but it's a little annoying.

• Font management was a constant minor headache. We ended up with two independent font systems in the final game; one for C++-driven in-game text (HUD, weapon UI, tutorial pop-ups), and then gameswf's font system for all SWF text.

• Multi-language debugging is not very fun.

Was it worth it? I think the results look good, but it's hard to say how much different a simpler system would have looked. Using gameswf consumed quite a bit more of my time than if I had done something simpler directly in C++, so in that sense, it was a mistake to use it. Some of that effort resulted in better and more debugged gameswf library code, but a lot of it was soaked up in proprietary engine integration. I'd say using gameswf did cut down on programmer/designer back-and-forth, although there was still a lot of that required.

Should you use it in your project? I would say that, like most other middleware, you should not count on it to shorten your schedule. It does introduce a big ball of code into your app that probably nobody on your team understands. On the other hand, ideally it gives you a fancier GUI and smoother programmer/designer collaboration.

NOTE: Scott Bilas wrote a great article on using Flash for game development: What About Flash? Can We Really Make Games With It? I think many of his points apply to using gameswf, so it's well worth reading. I wish that article had been available when I was working on the Stranger UI.