Mini-postmortem on the use of gameswf in Oddworld: Stranger's Wrath
gameswf was used for the UI shell screens
in the game
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
I've graciously stolen these screenshots from Gautam's site:
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
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
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
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.