The past few weekends I’ve spent a considerable amount of time digging in to Open Tournament trying to establish some order when it comes to asset organization and dependencies as part of our upgrade to Unreal Engine 5.4.
Asset management is one of the least glamorous things about game development, particularly on a project that anyone can contribute to like Open Tournament. Nevertheless, for developers it’s important to have a reasonable asset management to streamline work. Even for players poorly-managed assets can impact performance if you are loading in things that aren’t needed during gameplay — An easy mistake to make in Unreal Engine for amateur developers.
Hard References
In Unreal Engine, a hard reference is a direct link between two assets, such as a map and a texture that’s used in that map. Sometimes hard references are desirable, as it ensures that the engine properly packages and loads dependencies of an asset.
However, in some cases hard references can be problematic, and Open Tournament had a lot of these potential pitfalls. If a developer creates a map that includes a weapon, lets call it the Hamburger Gun, then that map has a hardcoded requirement on the Hamburger Gun. If the Open Tournament core team decided that the Hamburger Gun was out of scope and no longer wanted to support it, then that map would become unplayable until the hard reference was removed. Hard references like this make it difficult to change or replace assets without causing a ripple effect throughout the entire project. That’s a headache for developers, reducing our development speed and increasing the number of things we have to think about.
This isn’t a hypothetical problem! Open Tournament currently has a full (12+) arsenal of prototype weapons in it, but our closed beta builds later this year will probably not include all of these weapons. Nevertheless, we want a variety of functional maps for players to play on. So we need to ensure there aren’t dependencies preventing those maps from being used.
The Map-v2-Fix Problem
All of that is a preamble to talk about the real topic I wanted to discuss. For veterans of Quake or Unreal Tournament, it’s a problem you probably encountered at some time or another. Specifically, it’s about map variations that are trivially different from each other. An Unreal Tournament player might have a map folder containing maps titled something like:
DM-Deck-16
DM-Deck-16][
DM-Deck-32
DM-Deck-16-SE
DM-Deck-16-SE-Fix
DM-Deck-16-WinterCup2018
Most of these maps are simple adjustment of weapons & ammo, adding or removing powerups, and changing placement of these pickups. Some variations may adjust interactive elements like Jumppads, Teleporters, Lifts, and so on. Other variant maps might be created to include logos for specific events or groups. Further variations may be customized to another game type entirely, such as DOM-Deck-16, a version with control points for the Domination mode.
Maps: Mixed, Not Stirred
With Open Tournament, one of my long-term design & engineering goals is to address this longstanding issue. There are actually a number of possible technical approaches here, but it all starts with eliminating those hard references.
The vision for this is to think about a Map as the raw environment (geometry & visuals), and to consider the Loadout (whatever we end up calling it) as something applied on top. This has a lot of benefits:
Reduced Maintenance & Dependencies: As discussed above, developers are free to develop maps without having to worry about tight coupling of assets
Content Reuse: A map is no longer strictly intended to be played only one way. A map could have different configurations for a 1-on-1 Duel as compared to a free for all Deathmatch. Conceptually this can even extend to entirely different modes & mode-specific loadouts
Community Engagement & Player Choice: With the right architecture, it’s possible that loadouts can be shared in the same way that maps themselves might be shared. You could customize how you want to play, share with friends, and find the best configurations without having to directly modify and distribute full maps.
There’s even more that could be explored here, from procedural generation to dynamic loadout alterations, but suffice to say that I think this concept unlocks a lot of cool new possibilities for flexibility, creativity, and community engagement in Open Tournament. While there are some challenges we’ll have to tackle to bring this idea to light, the benefits are hard to ignore and I’m excited to see where it takes us.
What do you think?
Cheers,
Wail