PlanetJailbreak

Code design

  • warning: Declaration of flag_handler_relationship_content::ui_name() should be compatible with views_handler::ui_name($short = false) in /var/www/jailbreak/sites/all/modules/contrib/flag/includes/flag_handler_relationships.inc on line 62.
  • warning: Declaration of flag_handler_relationship_counts::ui_name() should be compatible with views_handler::ui_name($short = false) in /var/www/jailbreak/sites/all/modules/contrib/flag/includes/flag_handler_relationships.inc on line 118.
  • warning: Declaration of views_plugin_style_default::options(&$options) should be compatible with views_object::options() in /var/www/jailbreak/sites/all/modules/contrib/views/plugins/views_plugin_style_default.inc on line 17.

Jailbreak 2003: A New Hope

It's sometimes said that code isn't written, it's rewritten. This was certainly the case with UT Jailbreak. This popular mod for Unreal Tournament went through three versions from initial release in Summer 2000 to the final Jailbreak III Gold two years later. For the players, the transition through the different versions was just a download and some more fragging with new features. But for the coders and sometimes the mappers, working around older design decisions that couldn't be changed for the sake of backwards-compatibility could be little short of a headache.

So creating Jailbreak for a new platform, Epic's Unreal Tournament 2003, was at once a challenge and a breath of fresh air. Everything had to be written from scratch, but that also meant the freedom to re-examine everything.

Making plans

Work actually began on Jailbreak 2003 several months before Unreal Tournament 2003 was released. By looking at other next-generation Unreal games, or demos like XIII, it was possible to set out the form of Jailbreak's gameplay code: which classes did what and how they were to interact. As coder Mychaeel puts it, when the game was released, "those specs had literally only to be translated into UnrealScript code."

Has this approach paid off? Mychaeel had this to say about early progress on our Alpha versions: "I'm particularly pleased with the fact that I have had to spend only relatively little time with fixing bugs in Jailbreak despite the fact that we're close to being feature-complete. It seems that the time spent on laying out project's design beforehand is really paying off there; and anyway designing software is a lot more fun than debugging it, after all." Some months later, he agrees with this early statement, adding that most bugs have been simple to track down and fix.

So how did this actually work? Well, you can see the original design document on the Jailbreak Developer Network. Take for example what is perhaps the core concept of Jailbreak, the jail. Under UT Jailbreak, this was a ZoneInfo subclass, which was perfectly reasonable at first glance. But consider: A map couldn't have water inside a jail, because that would be a separate zone, and a player entering the water would count as having left jail. Similarly, Unreal Tournament's built-in effects such as pressure zones couldn't be used without being rewritten to work as jail zones in their own right. "The redesign gave us the chance to introduce new ideas directly into the design's foundations," says Mychaeel, and Mychaeel's simple but surprising idea was to have the jail not be a type of zone at all, but an information-holding item in a map that could automatically bind itself to the zone the mapper designated — hey presto, jails can be any sort of zone, they can be several zones, or even independent of zones completely. This approach to class design is visible through the whole of the Jailbreak 200x code: The arena binds itself in the same manner as the jail, and player start markers "know" whether they belong to a jail, an arena, or the main area of the map, all without being told. This is a considerable blessing to mappers, who under UT Jailbreak had to work with different classes and settings just to set these up.

Expandability

You can't predict the future, but you can learn from the past. Introducing new features into UT Jailbreak often meant having to jump through hoops to ensure old maps and mutators remained compatible, simply because those features hadn't been envisaged earlier. These were a source of UT Jailbreak's legacy issues. But what could be done to prevent this happening all over again, once Jailbreak 200x reached its first release and would have to undergo future development and enhancement with compatibility in mind?

The answer (we hope!) was to design the code in a modular fashion, both on a technical level and in the way Jailbreak 2003 presents itself to users. A core game type provides Jailbreak's gameplay and bot support. Non-essential aspects of the game are removed to mutators, or rather Add-ons, the special class of Jailbreak-specific mutators. These appear in their own area of the user interface for setting up games, and are able to fully interact with the core game rules. So features such as the jail release protection, the celebration screen, and the ever-popular llama hunt are included in Jailbreak 200x, but from the point of view of the code, they are merely mutators. For players, of course, they are bundled with the game and an essential part of the game experience.

This approach makes it simple to plug in new game components — after all, it's the same architecture as Epic's mutator system, whose vast flexibility is one of the reasons the Unreal series of games remains so popular. What other coders devise in future by way of Add-ons for Jailbreak remains to be seen.

Working with the game

Jailbreak is one of relatively few mods that don't change everything about the game: It's a gametype mod, period. That means no new weapons, player models or startup menus — though of course the player is free to add these by way of mutators.

Surprisingly, Mychaeel thinks this made certain aspects of coding Jailbreak harder: "It required thorough understanding of UT2003's software architecture since Jailbreak hooks into the game at a much higher level than a mod that strives to replace all content by its own. But that in turn lets us maintain a high level of compatibility to third-party UT2003 content -- gameplay-altering mutators, new weapons, player models, voice packs and so on."

Epic have taken a far more modular approach to their class architecture in UT2003, and we like to think we've made good use of this. The first shock a mapper might get is that there's no longer a dedicated class for the Jailbreak release switch: The generic GameObjective class does the job. There's huge potential in this, as mappers can subclass in any way they like: The switch can be touchable, shootable, or something completely crazy, as Mychaeel suggests: "If somebody was to develop a GameObjective subclass that has attackers win a game of chess before allowing itself to be triggered, that would be instantly usable in Jailbreak." This approach also means that there can be more than one release switch per team. Combine this with the fact that there can be any number of jails, even just one for both teams together, and there is a large field for mappers to experiment with.

Bot support

Bot support is an important part of the design of Jailbreak 2003. Because Jailbreak is similar to standard Deathmatch from the bot point of view, we don't have the problems suffered by sports game types: We can take advantage of most of the low-level bot code that comes with UT2003 already. That includes using the GameObjective class for the release switch, and making full use of the squad system.

The main challenge is getting bots to set the right priorities at the right time. UT2003's team game types keep a bot's general orders to attack or defend fixed throughout a game; in Jailbreak players however constantly have to weigh conflicting priorities and make a smart decision about attack, defense, or even flight. Of course bots shouldn't be "cheating" and know more than human players could, so part of Jailbreak's bot code exclusively deals with making educated guesses about other players' whereabouts based on openly available information.

As for squads, we carry along bots teaming up when they're following the same objective — more or less: Too many players in one place is usually not a good idea in Jailbreak. On a technical level though a squad is the instance immediately telling a bot how to behave, combining programming hooks that were previously distributed on the game type and the base bot code itself. Jailbreak constantly juggles bots between attacking and defending squads and has separate squad types for bots in jail (making them idly stroll around or take up hammer fights with other players) and in the arena.

The final stages

At time of writing, Jailbreak is almost complete. Beta testers are chasing up the last few bugs, coders are hastily implementing last-minute features, and mappers are polishing the eye-candy on their creations. The fact that UT Jailbreak still has a vibrant community is a testament to the mod's popularity. In a matter of weeks, we'll see if the latest incarnation of the gametype can repeat that success.

tarquin, 9 May 2004.