An insight into the making of UFO: Aftershock....

Having told this part of the story many times before, I am more than tempted to skip it. How Virgin approached us about finishing the game called Dreamland Project: Freedom Ridge (originally developed by Mythos, the creators of the X-COM series), how we found out that finishing it is not possible, how we renamed it first to UFO: Freedom Ridge and then to UFO: Aftermath, how we lost the publisher named Titus and found another one named Cenega - all this and more can be found for example here:

http://www.ufo-aftermath.com/pages/devdiaries.html.

Instead I would like to talk about Aftershock in more detail. It is some sort of substitute for the developer's diaries I was not able to write for this project, so it may be a tad too tedious in places; I appeal to your benevolence.

What is it about?

So what are all these games - UFO: Aftermath and UFO: Aftershock - about? Both our games combine a global strategy with small scale, squad-level tactics. In the strategy part of the game you research technologies, manufacture equipment and outfit your soldiers with it, and control your territorial expansion. In the tactical missions, you take your squad (maximum of seven soldiers) to fight the aliens or whoever might stay in your way.

Herein also lies the answer to the inevitable question: What does it all have in common with X-COM: UFO Defense? There is the motif of the alien conflict and some gameplay elements, the mix of the global decision-making and small-scale tactical missions. There are many differences as well; X-COM is turn-based, our games use system "plan in turns, play in real-time", X-COM was more about economical management, our games are more about RPG, etc. Is it like, say Warcraft and Dune.

The lessons of Aftermath

When designing UFO: Aftermath (then called UFO: Freedom Ridge) we were to large extent informed by our experiences of developing RTS Original War, our previous game. That project suffered mainly from our inexperience, but also from feature creep, frequent design changes and seemingly endless overhaul of art assets. As a result, we decided we wanted a simple clean design for Aftermath, one we could be sure of finishing on time, with as little extra work as possible. This approach paid off, as the game was finished on time (almost), bug-free (almost) and with all features we envisioned for it.

The downside was that game came across as perhaps too bland. The radical simplification of the strategic part of the game didn't go well with the more hardcore part of our fans and the constraints of the tactical missions (no multi-storey structures, limited ability to blow holes in the walls and enter buildings) were seen as too restrictive.

So the lesson we learned from Aftermath was twofold: we learned a lot about planning and managing the development, and at the same time we got a very good feedback from the players about their expectations of the game. The problem was that the two went against each other: obviously, the fewer features you plan for the game, the better the chance you will make it on time and on budget.

When planning Aftershock, we were bolder. We assumed that, having done a similar game, we can avoid the dead alleys and detours. Our design for Aftershock only added features to Aftermath (with the exception of the air combat: we didn't see a way of improving it and didn't want to just repeat it as it was). In the end, we managed to put in most of the features we wanted, at the cost of a heavy crunch time (we had fourteen programmers working on the game for the last four months) and dangerously cutting the time allocated to tuning and balancing the game.

Strategic game

So what did we change in the strategic game? One thing we liked about Aftermath was the Biomass: a tangled mass of alien lifeform creeping over the surface of the planet, easily visible from orbit. The Biomass worked as a visual clue of the player's progress: its growth and contraction corresponded to his victories and defeats and also to the overall phase of the game.

We wanted to have a similar strong visual clue in Aftershock and moreover we wanted the player to be actively involved in creating it. This is how the idea of 'tracks' was born: the tracks connect player's bases on the Earth surface and connect them to the common pool of raw materials. The player chooses which bases to connect and how; on one hand there is a progressive upkeep for tracks, on the other hand a denser and redundant network is more resilient to enemy attacks.

Several new concepts sprang from this simple idea: There will be some raw materials; the player will use them to manufacture equipment. There will be some territories; the player will be building tracks through them. If each territory had a base, building the track network would involve connecting all territories, this would be tedious and offer little choice. Hence, not all territories will be suitable for building a base: a territory is either a mine or a base.

"It isn't possible to build one's bases," was the most common gripe about Aftermath. So it was almost without saying that there will be base construction in Aftershock. There will be a list of buildings to choose from, the player selects a plot in a base, and orders a building to be constructed there. We had to determine how many building types there will be, how many buildings can be constructed in one base, and how are the buildings going to work (locally or globally).

Our concern here was complexity: what level of resource management is fun and when it becomes a chore? Our principle here was a "rule of a real-time strategy": in an average RTS mission a player is perfectly capable of building and managing at least a dozen different buildings, both for research and production, progress through a research tree and produce several different kinds of units.

In Aftershock, there is no actual combat in the strategic game and it is not one mission, it is the whole game. Therefore, we saw this as a minimum we can safely assume to be manageable. In the event, we have about 35 different buildings, a single base has 3 to 5 building 'plots' (this is influenced by the total number of bases, and this is in turn influenced by the idea of tracks), and the production buildings work globally (that is, all factories work on a single item simultaneously, irrespective of their location), while knowledge and defense buildings work locally (their bonuses are available only to the base where they are located).

Finally, there was the question of 'interfacing' strategic and tactical parts of the game. The vintage element of these games is the very small squad of soldiers that handles the actual combat. Honestly, it is simply ridiculous: the whole Earth saved by six soldiers? Do these guys ever sleep? What about their injuries? But these are the rules of the game, and if anything, we tried to strengthen the RPG elements in Aftershock and we had to find some plausible explanation how it is possible to send the same squad in every mission wherever it may be.

In Aftermath we used the infamous 'chopper': it would simply take off from a military base nearest to the mission and deliver the squad in the area. The transport between the bases was instantaneous; this was rationalized as traveling via teleports (that had to be researched, otherwise the chopper would always use the same base).

This worked as a gameplay device but players complained about not being able to have several choppers, and it simply looked contrived, even to us. Thus the idea was quietly dropped and we were looking for a different solution. We came up with the idea of the 'flying island' we named Laputa after the flying island from the Gulliver's Travels (I chose the name because it appeared to be an obvious cultural reference, but I have yet to meet a person who knows what it is).

Laputa would hover some two thousand kilometers above the Earth surface and would be able to project the squad to an area below - to, say, an area the size of half the Europe. The player would be able to control Laputa, but its movement will be quite slow: positioning Laputa will be a strategic decision as well.

Where does this Laputa comes from, who built it and why? Why it can bring only a small squad to surface? How did player come to control it? All these questions had to be answered by the game background story.

Story and squad

I receive a lot of game ideas submissions from people outside the industry. They usually view story as linear progression of events that takes you from the beginning to end, very much like when you read a book. However, creating a story for a computer game (at least in our games) works backward: you know where you need to get to and you are trying to find a story that fits with the facts and gameplay elements you want to use.

In our case, we had the idea of Laputa and another thing we wanted was more stress on role-playing elements of the game. The roots of our company are in RPG and this is one aspect of the design we put in all our games. In Aftermath, however, we felt we didn't quite make it. The soldiers had their names and stats and you could level them up and train them in various specializations but that was about it. The specializations only added bonuses to some skills and in the end, all the soldiers looked exactly the same: there was little room for individuality and specialization.

One thing we could do about it was to give more impact to trainings: in Aftershock, most, if not all, trainings give soldiers some unique new ability. Sometimes it is as simple as ability to use a weapon that would otherwise be unusable, sometimes it is really a new ability, for example third level sniper training allows the soldier to target body parts of the enemies.

But we wanted it to go deeper than this. If you want to have really distinct characters, you have to have different races and this brings us back to the story - we had to somehow populate the Earth with several different races of people. We weren't creating an RPG so we settled for meager three races: normal humans (a scouting and light combat unit), cyborgs (heavy, offensive unit) and psionics (vulnerable support unit).

The final element of the story was the necessity to tie it with the plot of the previous game. This had to work on two levels: on one, immediately obvious level, the story of Aftershock must pick up where Aftermath left off. Did Reticulans finish their experiment? And if they did what happened to the Biomass?

On other, more complex level, the story in the sequel should explain what was just glossed over in the previous installment. Why did the Reticulans come to Earth? Why did they eschew the subordination and deference presumably common to their race?

Of course, I cannot divulge the whole story here and I have already said more than enough. When you play the game, you may pause to consider how we managed to fit the story to all these requirements.

Tactical environments

While there was a general consensus that the tactical missions were the best part of Aftermath, there were several recurring complaints: it is not turn-based, you cannot enter houses, and buildings cannot be destroyed. To this list we added two grievances of our own: one, missions were composed from square blocks; while it allowed great variety of missions, their layout was very similar in every mission. Two, there was about the same number of assets for each of the five different architectonical areas (e.g. West Europe, Far East, etc.), but the player usually did not play the same number of missions in every area; as a result, some assets were seen many times, some rarely if at all.

We decided to ignore the first complaint (about real turn-based game). We are rather fond of our "plan-in-turns, play-in-real-time" system and we wanted to keep it, possible improve it a little bit.

On other points, there was a general agreement that something must be done about it. Multi-storey, destructible and "enterable" building seemed like a mere technical problem, so we started from the end. We wanted the missions to vary from each other, but this variety had not to be based on the mission location, but on its 'type'. On the other hand, the missions of the same 'type' on different places of the globe had to look similarly (so that we could reuse our art assets). Now what type of structure looks the same all over the globe? An industrial complex. Really, a factory, processing plant or a warehouse look very much the same in Tbilisi, Georgia as in Atlanta, Georgia.

This tied in nicely with our idea of resources. There will be one type of raw material - a basic, low-tech, cheap one, almost ubiquitous - found in common industrial buildings: abandoned warehouses, factories or chemical plants. And then there will another material - more sophisticated, more expensive and rarer - found in more sophisticated structures: old nuclear plants, secret military bases. There is also a third type of raw material in the game, that of 'alien extraction'. This is found in old crash-landed UFOs and alien bases (obviously, these also look exactly the same wherever they are).

Composing missions

We also developed a very nice set of rules for creating the missions: we envisaged a tree-like hierarchical structure, where every node would contain a list of actual components (in-game models) that can represent it as well as rules for possible child nodes. This would allow creating mission templates that would allow generating almost endless number of well designed yet unique missions.

All that was left to do was to develop a tool for creation of these templates and create the art assets for it. As it turned out, this is easier said then done. But the real problem lied elsewhere.

In a 'conventional' 3D game (e.g. any FPS) the levels are prepared in advance in some bespoke, usually homemade, tool. When the level is designed, the tool then usually calculates some static data (i.e. data that will not change during playing). These include the lightmaps and BSP trees (or other collision structures). Calculating this data can take anything from five minutes to five hours, but this done offline - the game then loads the resulting data along with the level.

This approach cannot work for a game with run-time generated levels. You cannot precompute a lightmap for a level that will be assembled dynamically. In Aftermath, we circumvented the problem by dividing scene into independent blocks and precomputing lightmaps (and certain data structures) per block. This required us imposing certain restrictions on the blocks (e.g. a light from one block cannot illuminated objects in other blocks, no geometry can protrude from one block to the next) and these in turn led to the unsatisfying feel of the in-game levels mentioned in the beginning.

So these were the two main problems we faced: how to compute lighting in real time and how to compute the collision structures. Let's start with the former.

Our first idea was to use only hardware shadows. We would have some lightmaps, but we would not calculate shadows for them, they would be here only to add atmosphere and break the repetitive tiled textures. The shadows from all objects, soldiers and enemies will be calculated in real-time by hardware.

But there were important flaws: it was a performance hit, it did not look as good as the nice soft pre-rendered shadows and there would have to be a lot of additional tweaking. About that time, we happened to read an interesting article in Games Developer about using shaders for precomputing radiosity. Most people these days, stated the article, use shaders - small programs that run on your video card - for real-time effects. But as the shaders perform geometry and graphics-related calculations much faster than CPU, we could use them to render bitmaps that we could later use as 'normal' lightmap. Calculating radiosity is a very computational intensive task and the authors of the article claimed that using the approach they suggested they were able to reduce the time it took to render the lightmap greatly.

We never planned to use radiosity in Aftershock, but we got another idea: couldn't we use this technique to calculate a simple lightmap with cast shadows? Even if this calculations takes as much as ten seconds - unthinkable for real-time application - it would be OK if it is done only once, when the level is loaded.

After some time we got the first version of the system running. Lightmapping a level took fifteen minutes. Through various optimizations, tuning, constraints and the like, we cut it down to two minutes, including loading, calculating BSP trees and creating various data structures for the game. This was about twice as much as we set ourselves as the highest value of our misuse of the player's patience. A game when one level loads in 50-80 seconds would be criticized, but it might get played if it was fun otherwise. A game with loading times of 100-150 seconds is simply unplayable.

In our effort to reduce the loading times we kept on decreasing the 'randomness' of level, that is the number of variant parts it includes. In the end, we decided to drop the randomness altogether. If we use our tools to create several variants of a mission, calculate the lightmaps and data structures for each, we would be able to load these data like any other game. We will need more space for the game data (because in effect a same component will be present several times) but these days almost everybody got a DVD drive. There will be limited replayability, because once the player sees all missions, there will be nothing new for him, but as the missions will also differ by objectives, enemies present, etc, it hopefully will not be a big problem.

In the end, the game shipped with over 100 missions, most of them with three different lightmaps (day, night and dusk/dawn).

Right and wrong

In closing, let me sum up what is, in my opinion, the best and worst things about the game. There won't be five of each, but let's see:

The best thing about the game is the right level of complexity. There are many technologies, weapons or buildings, but not overwhelmingly so. The player can see we do not consider him to be a dumb and spoiled brat, yet at the same time he has a realistic chance of trying all equipment within the game.

This complexity also allows for several 'right' ways of doing things. There is nothing more pleasing than reading Aftershock forums where the players argue if the psionics are good for one's squad or not. This shows that the Psionics work just as we envisaged them to: they are good for one style of gameplay, but this style is not compulsory.

On the downside, I feel bad about leaving out the runtime construction of levels. We were very close to making this work, but in the end it just didn't happen. I don't think a player will notice much difference, certainly not on first playing the campaign, and besides the idea that randomly generated levels are all different from each other was always dubious at least: if they are generated from the same components, they will always look very much the same. It is quite possible that we are going to be the ones most disappointed about this cut; it would have been such a nifty piece of coding!

The other thing that didn't quite work was the final crunch. While overall I think this was the least stressful project we worked on, the end more than made up for it. Eventually, we had to ship the game even if we knew that we would have to patch it. We reasoned, maybe erroneously, that bugs can be fixed in the patch, but the features we cut are gone for good, so we worked on the features even when we should have had only fix the code.

Overall, I am quite happy with the game. The players seem to genuinely like the game in its own right, not just as an improvement over Aftermath. There is an immense satisfaction in that.

Martin Klíma,

Lead Designer of UFO: Aftershock