Welcome, dear reader, to the third part of our developer's diary chronicling the making of UFO: Aftermath. And the usual thank you to everyone who read it and commented on it, either to me directly, or on our boards (http://www.ufo-aftermath.com - this reminds me, we relaunched our webpage, be sure to visit it!). Your comments and interest in the game are our lifeblood; as we have not been receiving that much support from our publisher (as I will describe later); they are the only things that keep us going.
Memoirs: In the beginning was the idea
--------------------------------------
When it become clear that we would not be able to use any of the materials created by Mythos, we had to decide what approach to take. One option we had was taking the original Design document and start from the scratch, bypassing the middleware Mythos was using ("bypassing" is such a lovely word; meaning anything to anybody; in this context it would mean developing them ab initio). This was obviously out of question, healthy self-confidence is one thing, cocksureness is quite another.
The other approach was to effectively start working on our own game, trying to stay true to the unwritten sprit of the genre - a very specific sub-genre, in fact, of squad-based tactical combat, combined with large scale strategy and management, dealing with alien threat.
The latter approach was the one we have chosen and we delineated for ourselves several areas there that were likely to cause problems, either because of their overall complexity, or because of them being old-fashioned and rapidly dying out, or a combination thereof. These areas include, most notably, the combat system and base management; but the combat system was the one that we dealt with first and therefore I will speak about it first as well, keeping the other for the next instalment.
Small squad tactical combat games are traditionally turn-based (think X-COM, Jagged Alliance, Fallout Tactics). There are periods of real-time combat in these games, usually when there is no other action, but when the bullets start flying, the game will switch into a turn-based mode.
(I now feel obliged to give short explanation of what turn-based combat is, though I can hardly imagine somebody would suffer through two and half parts of this diary without that prior knowledge. In turn-based combat (TB), you and your opponent (i.e. computer) take turns, i.e. first you move all your soldiers, than the opponent moves his, etc. During your turn, each of your soldiers has a certain amount of points, usually called "action points" (APs) or "time units" (TUs) and each action a soldier can take (e.g. a step, a shot, re-arming) has some costs in terms of these points. The soldiers can spend their points in any order, so that you can decide on the actions of one depending on the outcome of the actions of his comrades.)
The problems with TB system are twofold, firstly that it is unrealistic in the sense that, though it is supposed to simulate many things happening simultaneously, the actions in fact happen sequentially, which can occasionally yield bizarre results, and secondly, the moments of acute thrill (your turn) are punctuated by long periods of boredom (computer's turn). As a result, TB games are rapidly going out of fashion with publishers (as I will also describe in due time).
Turn-based games have their merits, to be sure. They give the player total control - the characters never do anything stupid unless told to do so. The player is not rushed; it is not a battle of twitchy mouse-fingers. The inconsistencies of this model can be creatively used to your advantage.
We were thinking about ways of preserving these merits and alleviating the failures and in the end we came up with a system we call, for the want of better name, Simultaneous Action System (SAS). The key feature here is to separate the planning and execution of the orders.
You plan out orders for your soldiers, stringing them together as you see fit - you can order them to move there, then here, then shoot, then reload, etc. For each order you can see how long it will take the soldier to carry it out. When you are satisfied, you press the "run" button and the soldiers start carrying out the orders given to them.
Some of you may know a similar system from, for example, Combat Mission (an excellent game, even though Bruce Geryk thinks so) or Laser Squad Nemesis. But the crucial difference here is that the soldiers need not to carry out all orders given to them - if something unforeseen happens, e.g. a new enemy unit is spotted, the game will pause and allow you to review and revise the standing orders. Of course, you can also pause the game at any time yourself.
SAS - and here I speak as somebody who has actually played it, not as somebody who invented it (I am not, anyway, that credit goes to our lead designer, Vlada Chvatil) - successfully fuses the advantages of turn-based and real-time systems. You are in complete control and you don't have to wait for the computer to finish its turn; you can give orders at your leisure and you get heated action.
You shall see.
Diary: Run-up
-------------
May is the month of E3, or the Electronic Entertainment Expo, the biggest trade fair for the games industry. May is the month when hours and days are wasted preparing nice looking demos, to pull the wool over the eyes of game journalists and - if you are lucky - big buyers from national chains.
But it is not E3, nor our demo, that was on our minds most of the past month. I am not at liberty to comment on our present business relationships, but there are some interesting developments here that I hope I will able to write about next month. For the time being, I am afraid that we - or at least myself - could not concentrate on developing the game as much as we - I - wished.
Which brings us back to E3. For all its wool-pulling, it is still a place to go and bring something home from. I do hope we shall bring home good news for UFO: Aftermath.
Martin Klíma
ALTAR interactive