Dev Diaries

Introduction and index

These are the developer diaries that Martin Klima (lead designer on UFO:Aftermath) wrote during development of the game. Even though this is history now, it gives you the idea of what a developer goes through. ALTAR had a hard time getting the game done, and these diaries reveal why.

- Part one (March 5, 2002)
- Part two (April 5, 2002)
- Part three (May 20, 2002)
- Part four (July 20, 2002)
- Part five (September 20, 2002)
- Part six (October 20, 2002)
- Part seven (November 20, 2002)
- Part eight (January 30th, 2003)
- Part nine (February 27, 2003)
- Part ten (March 31, 2003)
- Part eleven (May 31, 2003)
- Part twelve (June 31, 2003)
 

Part one (March 5, 2002)

Welcome, dear reader, to this first instalment of the developer's diary for UFO: Aftermath. I hope that you will find it both enlightening and light-hearted; I abhor the dreary dullness of the hype-filled marketing-made buy-this-game "diaries" just as the self-indulged ego-trips of the developers who believe anybody is at all interested in their minutest whims.

As a result I am not going to talk much about my work as such but rather about the game we are working on; and I will try not to hide from you any doubts, sacrifices, dubious decisions and the like as they happen along the way. This is not to say that I will not be holding anything back, but I will try to be as honest and open as possible, under the circumstances.

Memoirs: In the beginning, there was a void…

In May 2001 we finished Original War. There are many stories about the crunch time and all of them are true. Original War was very special to us - it was our first major project - and at times we almost lost any hope of ever completing it. But then, you have to go on, even without hope, and this we did and actually sent the gold CDs to our publisher.

Cut to the empty office, one month later. The developers are trickling in. People are actually starting to speak to each other again. It was in this period of void when our producer at Virgin, Paul Whipp, first called me with a tantalising prospect of taking over unnamed but "very big" project. I expressed polite curiosity. And then it hit me: The Dreamland Chronicles: Freedom Ridge. The spiritual successor to X-COM. "Your attention to detail with your love of strategic games. It is perfect," said Paul.
Still we hesitated. Should we be finishing someone else's game? Isn't it too small a task? Or too big? Several things went for the "Yes" vote - the honour, the place in spotlight, the opportunity, the challenge; and at the same time the practical issues - here was the project, already sold to the publisher, the only thing that needs to be done is to sign the contract, and we can get to work. So we said yes, and never have been sorry for it.

Diary: Building a city

Last week we were to send a regular monthly milestone to our publisher. This one was very much anticipated as it should finally show how the game is really going to look like in the tactical mission (so far we used a only a flat, top-down, 2D view to simulate the tactical gameplay).
And really, there came one of those rare moments when several hitherto unrelated pieces fall into place, when untold doubts and reassurances are squashed a verified. To understand what is it really about, I need to get little bit technical.

UFO: Aftermath features random missions that can take place all over the world. The player sees about half a dozen icons over the globe, he clicks one and he enters the mission. A "Loading mission… Please wait…" screen pops up and some silly animation is played. The computer meanwhile works like hell - it takes into account the current strategic situation, the type of mission, the position of the spot, the time of the year and day and assembles the landscape and populates it with enemies. Then it has to sort it, build BSP trees, calculate lightmaps, create container objects, and other nifty things. Now, for your average 3D game, you have a level editor and it does this kind of thing and it takes it a couple of hours. How long are you going to wait before the mission loads?

Of course, you cannot have the pie and eat the pie. You cannot build completely general terrain with the level of visual quality we are now used to in 30 seconds. You must sacrifice some generality in exchange for speed. The question is where to draw a line.

We decided - for the city-based missions - to create several buildings for each region of the world, split them into basic elements, one or two squares wide (one square is three feet) and combine them to create streets. We would have some sort of editor or catalogue, that would load all the existing elements for one region (and there are hundreds of them) and a designer would then create a set of rules for each - this bit goes with that bit, can be repeated only twice, must be at least five squares from a corner, this sort of things.

But when we built the first scene the result was, well, disappointing - in the true sense of that word: we were disappointed because we didn't see something we expected to see. The 3D landscapes rarely look well - the limits on polygon count, texture memory and also on the amount of work allowed and allocated to them - they all combine to make them look quite bland. But our landscape looked even blander, with uniform lighting the repeated textures stand out even more than usual.

Do you know what is a lightmap? (If you do, skip this paragraph) When you create, say, a pyramid in 3D, you do a model (for simple pyramid, this would be four triangles). Then you add texture. The pyramid is pretty much the same from all sides, so you could easily use the same texture on all four sides - this would save you precious video RAM. But now the model will look the same from all sides and this would be both ugly and un-realistic. In reality, even a very homogeneous object has lighter and darker spots - because the incident light is usually non-homogeneous. Now you have two options: you can either use hardware lights - you tell the card that there is a light at coordinates this and this, pointing that way, with this colour, etc., and it will light the scene for you - or you can use lightmap - this is in effect another texture, applied over the first one. The point is that it is only greyscale (it only lightens or darkens the underlying texture) and can have much lower resolution (the card will blur it and you will get the nice soft transitions), so you still save memory. The lightmaps are generally a preferred solution: the hardware lights are limited in number and they can be used for better purposes.
So it was becoming clear we would have to have pre-calculated lightmaps and other options had to be considered. Now, the game is going to have about a hundred missions (at the longest setting). Say, a third of them are going to take place in city. This is about thirty cities. There are say five big cultural areas with unique architecture, so at worst it is 5 x 30 = 150 cities. More realistically, about a hundred, because it is very unlikely that all city missions are going to place in the same region. So why just not build a hundred city levels and put them on CD? This would be a total sacrifice of versatility for the sake of prettiness, but does anybody care? Majority of the players never finish games they start to play, let alone replay them.

But developers have their pride, too. We want to be able to say "endless possibilities" and we all know that "endless" means at least three hundred. So a compromise was made. The designers will use the small segments to build what we call "blocks": it may be one building, or several, surrounded by streets or open area. Each block will be individually lighted and the lightmap pre-calculated and saved. The city level will then be created by combining the blocks. With a hundred blocks per region, and an average level size 5 x 5 blocks, we have 242,519,269,720,337,121,015,504 permutations. Even with a large margin of error, this is endless enough for me (there is subtle error in this reasoning, can you spot it?).
So after this long digression, I get back to the magic moment when we loaded the first block-composed level and yes, it worked! It looked nice! Granted, there are still errors, there are holes where there should be none, some normals are reversed, but it is there, the atmosphere, the creepy, nasty feeling of the world deserted and betrayed, the aura of danger, moving shadows just on the border of your field of vision.

I am getting little bit carried away; and already belying my promise of impartiality, so probably it is time to stop.

Looking forward to meeting you in the next instalment!

Part two (April 5, 2002)

Welcome, dear reader, to the first sequel in this developer's diary series. I would also like to thank everyone - who has shown their interest in the first part, and for all the support our whole team has received.

I would also like to invite anyone who is interested in the game to take part in the discussion about UFO: Aftermath that is being hosted at www.chatbear.com/?1785. Any comments and suggestions are welcomed (if not accepted) there.

Memoirs: The practical considerations

It was in July 2001 when we really decided to face the challenge and go ahead with Dreamland Chronicles. The first obvious step was to find out where Mythos had left off. Four CDs arrived at our office, neatly marked as Milestone 14. There was some code on them, and some art, and even an executable.

But really nothing even remotely like the screenshots we saw floating around the web. The executable only showed the strategic game (albeit very pretty). There were some models from the tactical game, and some of them could even be opened. The code did not compile (other people's code never compiles on your computer) and, as far as we were able to tell, it did not contain any part of the tactical game.
On the other hand, there were SDKs of almost every engine known to mankind - NetImmerse, Havok, Miles.  None of them working, their licenses having expired long ago. "No, there is no other code. No, the licenses cannot be renewed," our publisher assured us.

In case you are not familiar with the concept of middleware, there are many packages that aim to "pre-invent the wheel", i.e. to provide a developer with a package that handles certain tasks common to most games. A well-known example is the graphic engine - be it LithTech, the Quake engine, or, as in our case, NetImmerse. These engines handle the actual display of the game, as well as exporting the 3D models from 3D modelling programs (like 3DS Max or Maya), and building the scene in custom editors. But you can also have e.g. a sound engine (Miles in our case) that plays sound f/x and music for you and automatically handles e.g. playing multiple samples at the same time, sound compression and other things.

In any case, if you use an engine, you use its API, which means that you only tell the engine what to do and do not care about how it is done. This is convenient as long as the engine works. If it does not, you can throw most of that code away.

It is always a nasty business when a project is cancelled. Obviously, there must be a lot of personal animosity. I have but scant knowledge of the circumstances of the cancellation DC: FR, but any developer in such situation would have little inclination to carefully gather all code and assets to make sure somebody else can take up right where they left off.

One thing we had, however, was the original Design document. Different perceptions of the general role of design documents aside, this was the most specific thing we had in our hands and was also the one that actually helped us the most.

Diary: First shots

The past month was not clear sailing. It was not sailing at all. I hope I'll be able to write more about it one day, when it will be just one of those funny stories, such as, you know, when you lost your way in the mountains, and almost froze to death, and then, at the last moment, you met the St. Bernard… I surely hope a St. Bernard is just around the corner now.

But besides the frantic phone calls, there was some development actually going on, and that is, I assume, what is really interesting to you, not the industry gossip. The most important thing was our first playable. Did you know that "playable" is a noun as well as adjective? That's how publishers call something that cannot be shown to press for the want of graphics polish (otherwise it would be a "demo" or "trailer"), but has at least some rudimentary functionality (i.e. you can control the units, maybe give them some orders).

Our first playable features one city level (I wrote about it extensively last time), four soldiers, and four aliens. You can order the soldiers to shoot the aliens and aliens will shoot at you if they spot you… and whoa! there is a game.

We were very eager and little bit afraid about how it will play. We already built a little program that used standard Windows interface to display top-down map, with soldiers displayed as circles and aliens displayed as rectangles. There we tested our concurrent turn based system (I hope to write more about it in the memoirs section, next time) and it was working fine. But how will it feel when you can't see all the soldiers at the same time? When you have that big 3D building obscuring the view? When you can rotate and zoom in and out?

It is different. It's more personal. The circles and squares in the bird's eye view are but tokens, symbols you move around and manipulate. Sometimes one of them blinks and disappears. In the playable, you can see real men walking around, sporting real weapons, meeting real aliens, with real ray-guns. You can actually see the shooting and get the feeling of combat.

On the other hand, yes, it is not as clear as a neatly ordered grid with some well-defined symbols. At present we have not yet implement the "hidden unit highlighting" feature that will show the ghosts of units hidden behind (or inside) buildings. Therefore you have to constantly rotate the camera to keep your units in view. And the camera controls are also not as good as we want them to be.

But this is beside the point. The point being, that we finally moved from abstract to concrete, from the model to the real thing. We can see how the play dynamics work and we can adjust the game parameters to make the game flow as smoothly as we can. We can tweak and twist the ways the player controls the game to achieve the same goal. We can and will add various things to make the situation more clearly to the player.

But doing all this we must be very careful not to lose what we already have - that bond of care and attention between the player and the little men moving on screen. I believe this is the key issue in our game: this game is not only about tactics; it is about people as well. You control your men and women, but you also care about them. Their lives matter to you and their deaths - though sometimes inevitable (or rather unpreventable) are not to be taken lightly.

I am starting to sound like our marketing department again, and some people complained that the last piece was too long, so I will stop it right here.

Looking forward to meeting you in the next instalment!

Part three (May 20, 2002)

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.

Part four (July 20, 2002)

Welcome, dear reader, to the new part of the diary of the developers of UFO: Aftermath. Obligatory thank you to everybody who read the previous part and commented on it on our boards. Next, I should probably apologize, as I am writing this instalment more than one month later then I should and intended to.

Explanation may bring understanding if not forgiveness and explain I will try.

Memoirs: Things going sour

It was around Christmas last year when we could not help noticing a strange thing. The milestone payments from our publisher, Titus, grew even more delayed.

Maybe I should explain some aspects of the developer-publisher relationship in general terms, even though many a reader has undoubtedly already heard about it. Still, I constantly receive letters from people confusing the two and therefore I'll try to explain briefly. If you already know what the cross-collateralised royalties are, please feel free to skip the next four paragraphs.

We, ALTAR interactive, are the developer. Therefore, we develop: we code, we design, we program, we model, we render, we compose, we write and we sub-contract. We do not publish and distribute - this is publisher's job. The publisher takes the game when it is finished by us, has it pressed, packed and properly marketed and then actually sells it, via various distribution companies, to the players.

The development is a protracted and costly business. An average game takes about two years to complete and costs more than a million dollars to finish, that is, the developer spends more than a million dollars developing it (it should be noted that for UFO: Aftermath both numbers are lower). In an ideal world, the developer can pay this by itself and bring the finished game to publisher, just as an author can go to the (book) publisher with a completed novel under his arm.

But million dollars is a lot of money for most small companies and indeed for many developers and so, just like a writer could, they ask the publisher for and advance that would allow them to create the game. It is customary that the publisher and developer than settle on an outline of the work, detailing what and when shall be ready (this is called the milestone schedule) and the publisher than gives the developer the advance in instalments, very much as if the author would submit a new chapter to his publisher each month, getting a part of the agreed advance.

These payments are called milestone payments as they are subject to the developer completing the corresponding milestone and the publisher approving it. No milestone no payment - it is as simple as this and this is a great way how to make the developer complete the game on time.

Let's now move back to our story now (do not despair if you feel that you still do not know what the cross-collateralised royalties are, maybe next time). Maybe it should have been a warning to us, when Titus signed our contract, dated August 3, on August 23rd, explaining that otherwise they would not be able to send us the "on signature" payment. However, delays and excuses are something you will get used to very soon when developing computer games and summer, as we all know, is the period of drought for publishers.

However, the situation did not get much better even early this year, when the windfall of the holiday season was supposed to ring in, nor did $40 millions for sale of Shiny enable the beleaguered Titus to meet its obligations to us. Just before E3 it become apparent that we will have to part ways and it fell to us to find a new publisher for UFO: Aftermath.

But this is another long and convoluted story I hope I will be able to relate in full (including the happy ending) in the next instalment of this diary.

Diary: The strategic part

But enough of boring industry gossip. The fact that we are looking for a publisher does not mean that we do not work on the game. We are still committed to our release date in Q1/2003 and we are moving along for this target.

The most impressive advancement over the past month or so is the beta version of the strategic game - but let me explain what we mean by that first.

In UFO: Aftermath you are in one of two "modes" you are either in a tactical mission (i.e. you are blasting away the aliens) or in the strategic simulation, where you carry out research, re-equip your soldiers, manage your bases and decides what tactical mission you will play next.

When designing the game we tried to put more stress on the tactical part - we expect the player to spend there about three quarters of his total "game time". At the same time we wanted the strategic game to be able to stand on its own, to be more than "go there, do this" kind of wobbly prop. The strategic game should give the player as much freedom as possible, it should present the player with true alternatives and reward strategic thinking.

On the other hand, the strategic game should not bog the player down with micro-managing of every single aspect of the game. The player thus alternates in two roles: while in strategic game his is de facto leader of CoE (Council of Earth, the umbrella organisation of the Earth resistance), making decisions about the direction of research and manufacturing, and also deciding which tactical opportunities need/deserve attention of the CoE's most elite special combat unit (currently we call it the Phoenix Legion). The latter are then solved by the player in his second role, that of the commander of Phoenix Legion.

Besides selecting the tactical missions, the player also decides about the types of bases he conquers or founds in the conquered territory. These in turn influence his military strength (which again influences e.g. the chance of successful air interception), the speed of research or manufacturing, etc.

I could go on about this for a long time, but this should be a diary, not a preview, and I am also running out of space. So, briefly, where are we now? Broadly speaking, the strategic game works: the UFOs are flying, the player crafts are pursuing, the research is being carried out, and the territory is expanding and contracting.

It also seems to work in the other sense of the word - though it obviously needs a lot of balancing, tweaking and polishing, the basic gameplay dynamics appears to work all right. Even when everything you do in the way of fighting is selecting Player wins/Enemy wins checkbox and pressing the OK button, it is an interesting game.

I hope I will be able to write more on this subject next time, along with a progress in our search for the new publisher.

Part five (September 20, 2002)

Welcome, dear reader, to part five of our developer's diary; where we describe our toils in bringing you UFO: Aftermath. As is customary, I would like to thank you all for the words of encouragement coming our way; and again ask your forgiveness if we cannot reply to your letters quickly enough. But keep them coming, they help us to go on.

This diary is going to deviate from the pattern set by the previous installments, where the Memoirs and Diary section were entwined like poisonous ivy and sweet pea; there will be only a sort of Diary here. The reason for this irregularity is twofold: firstly, the Memoirs part, which was intended to slowly catch up with the Diary part, now approaches a period I still cannot write freely about - our protracted negotiations with the new publisher are not over yet, I regret to inform you - and secondly there was an interesting event taking place last week I would like to dwell on in more detail.

Diary: Our first chat

There was a first public chat about UFO: Aftermath this past Thursday (Sep 19, 2002). For the details of the chat you can go the excellent Pete's page www.ufoaftermath.co.uk (which is well worth visiting in any case, if you haven't been there yet) or you can find the links in the Press section of our official page (www.ufo-aftermath.com). You can find there both full and edited logs of the chat, so I won't quote it here excessively. However there are couple of things I would like to say about the chat as such, and then there were some questions I wish I had answered differently or more broadly and, contrary to usual situation, I can actually put forward this esprit de l'escalier.

So, firstly my thanks go to Olav and Kahnn who organized the chat and brought up the idea in the first place, to all the voices on the chat, and also to everybody who was here, regardless of the number of questions he asked.

The chat itself, though attended by relatively small number of people, was an exciting affair for both myself and J.R., our one-man PR army, who also participated. And I do not mean only the understandable elation that is a direct result of relatively large number of people you have never seen or heard from before taking interest in your work and actually listening to your answers. Nor am I speaking about a pleasant surprise at the reasonability, pertinence and positive spirit of the questions being asked.

Even though these two emotions were foremost at first, on reflection I realized something more profound: though not yet finished, our game already exists in the minds of the people who care about it and from this point of view - the point of view of the game itself, if you will - the roles of the developers and future players are equal and interchangeable.

But enough would-be philosophical musings. I promised to get back to some of the questions and answer them more broadly, so let's get to the point.

One question that crops up over and over again runs along the following lines: "Aren't you daunted by the legacy of the game whose 'intellectual lineage' you are a part of?" where, of course, the 'intellectual lineage' is meant to include games such as X-COM: Enemy Unknown and other games set in the X-COM universe. (For the record: UFO: Aftermath is not an X-COM game. It does not use X-COM trademark, or any distinct art, characters, designs or features of the X-COM series of games.)

In the chat I said that we could only hope that the people will still compare us favorably with these popular games once people have actually had a chance to play UFO: Aftermath. Even though this answer nicely sums up our attitude about this question, to some it may feel like we are dodging the issue.
 
So what do we actually think about it? We are lucky enough to get a lot of support from our fans, or rather from the fans of those older games. Thanks to that, even though UFO: Aftermath certainly is not the most eagerly awaited game of the next year, it is an eagerly awaited game. And to us, our responsibility to the people who are waiting for UFO: Aftermath far outweighs the responsibility to any old game. We do not want to compete, we do not want the players to say: "Aftermath is better than Apocalypse because of …" or "Unlike in TFTD, in Aftermath you can…" We simply want the players to say: "Aftermath is a good game." Period.

Another question we encounter frequently (one we also heard in the chat) is about the amount of freedom you are going to have in the game. In the chat it was phrased as follows: "How linear will the game be? Can you play for an unlimited amount of years or do you have to get rid of the aliens by a certain date?"

The simple and true answer is: "The former. You can take your time and finish the game when you see fit." However, if we want to be honest, we also have to point out the other side of coin. By giving more freedom to the players, we, as designers, forsake the ability to twist the plot any way we like. While in Original War we had tightly scripted missions, a very strong story, many characters, personal likes and dislikes, love, hate and betrayal, in UFO: Aftermath we will not be able to go into this level of detail. There will be story, there will be unexpected twists, but it will necessarily be more broadly sketched. You will not see the level of personal interaction you would be able to if we constrained the player's options more.

In this context I must mention Jagged Alliance. This game did an excellent job in giving almost total freedom to the player (in JA2) and at the same time had a lot of interpersonal interaction. But designers of JA2 had some advantages over us - they had a limited, albeit large, set of characters the player could choose from, and they had a relatively small number of places where important events happened. (And last but not least, they had about twice as much time on their hands.)

So in UFO: Aftermath, the stress is not on predefined events or scripted behaviors. The game relies more on the emergent situations - you are in command of your men and of all of the important resources left to humanity. Your enemies are many and, for most of the game, they are stronger than you. It will be up to you to outsmart them and to cleverly evolve your characters. We hope and believe that the events that will occur in this way will be no less interesting than pre-scripted ones, exactly because of their utter unexpectedness.

So this concludes this part of the developer's diary. Please forgive its more theoretical tone and see you at the next installment.

Part six (October 20, 2002)

Welcome, dear reader, to the sixth part of our developer's diary; here I try to describe what we have to go through in order to bring you UFO: Aftermath. As is the custom here, I would first like to thank everybody for his support of our game, especially to the people who take part in our message forum, www.ufo-aftermath.com, for the steady stream of fresh ideas they pour to us.

In this diary I would like to tell you a little bit more about the current state of development and about the direction we are taking the game into.

Diary: Our last build

In case you are wondering if I am going to reveal the name of our publisher today, I am sorry to say I am going to disappoint you once more. The lack of the publisher does not stop us (yet) from working on the game and so we duly produced a new build of the tactical game so that we could appraise its qualities and decide how it measures up to our expectations.

The tactical game is finally in a stage where we can start truly testing its features. The game finally uses the stats of the weapons the soldiers are actually equipped with, instead of some nearly-random values; the soldiers can choose their mode of fire and decided if they are going to walk or run.
All this adds immensely to the atmosphere of the game, but still, there are various issues that do not work quite as we imagined. Take the actual shooting for instance. We all know that bullets move at supersonic speeds and so there is no chance of you actually seeing it (or hearing it, for that matter, if it is going to hit you). You can see the muzzle flash and you can see the impact, but not the actual trajectory of the bullet, if you are not using tracer rounds.

However, most of the tactical games show the trajectory, as do many movies - just think the slow flying laser beams in Star Wars. The games I speaking here about are mostly turn-based games and it does not really matter that much there if a single shot takes about that much time as walking three feet. It adds wonderfully to the tension and thrill of the game: you can see the bullet slowly flying toward its target and pray that it does hit. Let's face it: shooting is raison d'etre of playing tactical games and it is only fair if the player spends more time on this then he would in reality do.

This however has repercussions for our system. In simultaneous action game every action must take a "reasonable" amount of time and it would be ridiculous if an alien could make couple of steps before a bullet, fired from the distance of fifteen yards, hits him. An alternative is to slow down time (this is the approach a Russian game E5, now in development and with wonderfully similar command system to UFO: Aftermath, uses).

However, with seven men at your mission, it may well happen that the game will slow down because of a soldier you are not paying an attention to. And then there are also shots the aliens fire at you. Should the game slow down because of them as well?

Obviously, the easiest and in many ways best solution is just to break free from the tradition and do not display the trajectories at all, just as in real life. However, when we tried this, the result was strangely unsatisfying. I'd venture to say that most of you, my kind readers, are just like as far as fire fights are concerned - your experiences and expectations come from computer screen, not from an actual combat mission (and certainly not from a combat mission against aliens and mutants) and we just came to expect there will be something visible when we fire at somebody, even if we know that it is nonsense.

Besides, if there is some kind of a connection between the attacker and his target, it makes the overall situation clearer and easier to understand. We tried drawing a solid line from the muzzle to the hit spot and while, at least in my opinion, it worked fine, our artists complained it spoils their carefully crafted artistic look of our cities.

At present the question is not yet settled, but I expect us to arrive at some sort of compromise.

Part seven (Nov 20, 2002)

Welcome, dear reader, to the seventh episode of this developer's diary, wherein I try to chronicle the joys and sorrows that are the development UFO: Aftermath. First, the obligatory thank you to everybody who supports our game, especially to the people who participate on our forums, at www.ufo-aftermath.com, and supply us constantly with their fresh ideas.

This diary will be devoted to more rumination about the tactical game, destructive ideas, run-time lightmaps, and will reveal the name of our publisher: CENEGA publishing, based in Prague, Czech Republic - this is the last minute information, I type it just when this file is being uploaded, so please expect more information in the next installment.

Diary: The squares of the city

The last installment of this diary dealt with the issue of the proper visualization of combat, i.e. how to display, in an unobtrusive and unambiguous manner, who is the attacker and who or what is the target. When dealing with this problem, we also come to question one of the axioms we set for ourselves when we began to work on this game, namely its squareness.

Let me explain. Originally, in those bygone days of yore, when Titus was actually paying for development, UFO: Aftermath was scheduled for 16 months of development time, from the original design idea to a completed and fully tested game. This is not too much time and therefore, to make things easier and more manageable for us, we decided to develop a grid-based game, instead of fully general 3D game.

In a grid-based (or square-based) game, space is partitioned into a grid of uniform squares, in our case 3 x 3 feet. All movement is only possible on these squares, i.e. you cannot plan yourself to move to, say, corner of the square. Obviously, when moving the soldiers do cross the boundaries between these squares and if you pause the game at that moment, you can actually see a soldier standing inbetween two spaces of the grid. But you cannot do anything there - if you order him to shoot, for example, he would first finish his step, thus moving to the center of the next square, and only then he will be able to start shooting.

This approach has many advantages - it makes it easy to solve the finer issues of planning orders (route planning, collisions, waits, etc.); it makes the game easier to play (either you can get somewhere or you cannot, you don't have to try it twenty times, hoping that if you click the correct pixel you would be able to get into a position where you would see them and they would not see you); it looks prettier (all animations fit precisely, as the units can only move a fixed distance); and last but not least, it is the solution most turn-based games adopt (X-COM, Jagged Alliance, Incubation, etc., etc.).

Originally, we wanted to use this square based approach for all gameplay-related features: path finding, visibility, and line of fire. However, here the drawbacks of grid come into play. While planning the route on squares is fine (and actually it is one of the reasons why we are using squares in the first place), when checking a line of fire it turns out it is too rough. We had an opacity value for each square, i.e. how much it obstructs the line of sight. For an empty square it is 1, for a square occupied by e.g. a house it is 0. For a square with, say, a tree, it is, say, 0.5. Therefore, if somebody stands behind a tree, you are able to shoot at him, but with a penalty applied, as he is partially concealed.
Then it can easily happen that you will see the line of bullets going through the trunk of the tree. Or through a corner of a building. Or a car standing in front of the soldier. One way to look at this is to say that this is a reasonable abstraction. In what is fundamentally a turn-based game, the player cannot expect us to show him exactly what the situation looks like, rather, we show him only a schematic description of the scene, with all the information he might require to make an informed strategic decisions.

The other way is to say that this is just unacceptable. The player bases his decisions on what he can see, if he sees a car in front of his character he does not expect him to be able to shoot, nor be shot at.

The latter is the course we decided to pursue. We trace several rays from the observer to the target and based on their results we decide if there is a path that could be used for the former to spot or shoot at the latter. So while the game remains grid-based, you will not see the artifacts I mentioned above.

Diary: And there was light

The loyal readers may remember lightmaps, which were covered extensively in the first or second installment of this series. Originally, the lightmaps took a very long time to generate and we thought that we would not be able to re-calculate them at run-time. This would pose serious, but soluble, problems with destructible objects (if, say, a fence casts a shadow on the ground and that fence is destroyed, its shadow should disappear as well - we would have to have pre-calculated "lightmap patch" for every destructible object on the scene) and it would completely rule out flares, or reduce them to hardware lights only.

The savvy reader, who knows what a hardware light is, will kindly skip this paragraph, the rest can read on. When a graphic card displays a polygon (a basic element of any 3D scene), in a process known as shading, it takes into account several things: the most important is its texture, i.e. a picture that is "painted" on that polygon (there may be several textures for a single polygon and their mutual influence and blending is beyond the scope of this paragraph). Then comes the light - you can "tell" the card that there exists a light source with such and such color, such and such direction, etc. The card then takes into account the relative position of the polygon and applies the light accordingly (the polygons that face the light are lit more than those that are parallel to its direction). These are the hardware lights and the important thing about them is that they cannot cast shadows - if there is another polygon between the one the card is now shading and the light source, the card does not care about it - the programmer must check for it and tell the card to turn off the light for the poly in the shadow.

Obviously, you have a big problem if only part of a polygon is in shadow - you cannot turn on the hardware light for a part of the shading only. This can be solved by pixel shaders up to a point, but most people just use lightmaps. The hardware lights are then used for the objects where the lightmaps cannot be, either because their relative position vis-à-vis light sources cannot be established in advance (e.g. the soldiers in UFO: Aftermath), or because they themselves are new light sources (e.g. flying rockets, etc).

Anyway, our programmers have really done a great job here and managed to speed up the calculation of the lightmaps by several orders of magnitude. This makes it possible to have a real real-time lighting - you can throw a flare, see it fly and when it lands, the area around it lights up, with absolutely life-like shadows - it looks magnificent!

I hope you are going to like it.

Part eight (January 30th, 2003)

Welcome, patient reader, to this new episode of our developer's diary dedicated to chronicling the development of UFO: Aftermath, the game of tactical combat and strategic conquest. While the second sentence of these diaries is traditionally used for thanking our loyal fans for their continuous support, today I would like to do not only that, but more: I need to apologize to everybody at our forums for not being to able to post there as much as I used to or would like to. The development itself is now growing more intense by the day and there is only so much time on our hands. Be assured, though, that the forums are being read and hints are being taken, even if we cannot comment upon them all. Thank you again for your support.

Memoirs of the Void: The quest for a publisher

The increased workload mentioned above is, of course, due to us having a new publisher, the existence of which I was happy to report in the previous instalment. As developer/publisher relationships and, if the e-mail I get and forums I read are anything to go by, the very process of selling the game are a source of both interest and speculation, I would like to tell you more about what has happened during most of the past year. I shall name no companies (beside those that were named already, i.e. Titus and Cenega) as I believe the names are not important, it is the process itself that we are trying to describe here.

It was just before Christmas two years ago (in 2001) when we first got a hint of the circumstances of our then publisher, Titus Interactive. Milestone payments were delayed and the approval of milestones was withheld for financial reasons. We dragged on, but the situation grew steadily worse and eventually we were told to go looking for a different publisher, discretely at first and quite bluntly later.

"Why didn't you start looking immediately when you sniffed trouble?"  This is a very good question, and I am glad that you asked. Most contracts - publishing agreements - between a developer and a publisher expressly forbid the former to show his work to anyone, especially to a company that might be in competition with the latter. If the relationships become strained, you have to tread very carefully: you do not want to give the other side an excuse for cancelling the contract.

So eventually, an agreement was made with Titus, allowing us to look for another publisher (and yes, we were making discreet inquires even before that). Eventually, we reached a tentative, preliminary agreement with two companies: one was a big, independent developer, who was willing to fund the development, the other was a mid-sized publisher, specializing in the strategy genre, who had been willing to publish the game internationally once it was finished. That was at E3 and when we returned home from there, beside the unforgettable line: "It's PC and you have to think, that's nothing for us," we got from one of the other meetings, we had a really good feeling that things were moving in the right direction.

They weren't. For three months, the negotiations dragged forward. "These things take time," was the constant reply to our queries. Occasionally, some small improvement was made, a guarantee provided or increased, and some "very productive" conversation took place. But still it seemed that we were going somewhere, and the contract was just around the corner.

Then came ECTS in London, where the three of us met again. The publisher looked positively enthusiastic. They asked all the right questions about the game, they introduced us to the producer who would be working with us, and they assured us that the last few problems would be solved in the next week. The developer seemed guardedly optimistic as well, and yes, they were going to sort out the last few problems in the next week and then the contract would be signed.

It wasn't. It become obvious then that this contract was not going to happen, although we still kept hearing the same line, "these things take time." They do, obviously; much more time than we had on our hands at the time.

While all this was taking place, the development of UFO: Aftermath was going on. It was now a very different game than it was in the spring, as we had changed most of the code, the art assets and also the name during the course of development. And we also looked for other publishers. We knew then that we had to act really quickly, because our resources were quite spent at that time and we were in real danger that the whole project would have to be cancelled in order to save the company.

About this time, actually also at ECTS, we made the first contact with Cenega, a fledgling but ambitious publisher, located, of all places, in Prague, Czech Republic (in case you don't know, our own company, ALTAR interactive, is based in Brno, Czech Republic). We knew Cenega before that, of course. Among other things, they distributed our previous game, Original War, here. We also knew they has decided to become a global publisher and that they were looking for games to enhance their line-up. They were a logical choice for us, just as we were a logical choice for them.

The negotiations were tough but to the point and just before Christmas we were able to sign the deal. Let me say here that while Cenega is certainly not the biggest publisher out there, they approach and conduct were nothing but professional the whole time; in this respect they could be a model for many bigger companies it was our unfortunate lot to deal with. We have also utter faith in their ability to market the game when it is published.

All is well that ends well. This did not end yet, as we have to finish the game and you have to play it, and only then we can say if all is well. However, this was a very important step, and one that has made a good ending possible.

Next time, I shall again write about steps we are taking to achieve this.

Part nine (February 27, 2003)

Welcome, dear reader, to the next part of our series of developer's diaries, where we report on the development of UFO: Aftermath, a tactical, squad-based game of turning back an alien invasion. Thank you for coming back to this, and thanks to posters and visitors to our forums and thank you to everybody for stopping by in our last official chat on Wednesday, February 19. Those of you who did not make it there, yet want to know what we spoke about, can still read the transcript of the chat at: http://ufoaftermath.co...?c=chat&p=transcript.

Diary: Degrees of Freedom

A hotly debated topic on our forums recently was the question of tactical options in the game and their number. This can be summed up as follows: in real life, just as in some games (e.g. Jagged Alliance), the soldiers can stand, crouch or lay prone and move in these respective positions, they can shoot a single shot or a burst and they can decide how much time they spend aiming to increase their chance to hit. The questions being asked are: will these options be available in UFO: Aftermath? Which, if not all? And if not all, is it still worthwhile to play the game?

The last question, obviously, is the most important one, but before I get to it, let me set the record straight and explain how these things are going to work in UFO: Aftermath. You can walk and run: the latter is faster and noisier, the former is slower and stealthier.  There is no crawling. When attacking, most weapons have two modes of fire (all others have only one; no weapon has more than two). These are typically aimed and burst fire and the mode you choose governs your chance to hit the enemy and the time it will take. When firing in aimed mode, soldiers will kneel down, more to give the player a visual indication of the mode of fire than to get more cover.

I know for a fact that there are people out there on our forums who will be hugely disappointed by what I just said (despite the fact that this is basically what we have been saying the whole time). But please bear with me. Before I explain our decision, let me tell you more about the way tactical combat works. This is not directly related to the question we are discussing, but I hope it sheds more light on our approach to the game.

While the soldiers move over a square grid, the line-of-sight and line-of-fire calculations are done using the level geometry. This means that we take a soldier's position and trace a line from him to the enemy. If the ray intersects with any environment object (or, more precisely, with a solid texture; if you have a large polygon with transparent texture with only a small opaque circle in the middle it will only block the line there) the LoS is blocked. Obviously, this would not be very good technique, because the soldier cannot change his position continuously. Therefore we trace several rays from various points in his square to several points in the target square and average them.

The other thing we take into account in these calculations is the soldier's facing. The "fields-of-vision" are "oriented" - soldiers do not have eyes on the back of their heads (and yes, you can select the facing of your soldiers when they stand).

Now let's get back to the tactical options. Let me state for the record that I do not think that our game will be super-realistic (leaving aside its fantastical premise). Yes, the actual soldiers have more options (more degrees of freedom). However, the question I am posing here is: would it necessarily be a better game if we implemented them all?

There is no doubt that the multiple tactical options are essential to any good game, or rather to any game at all. A game like Snakes & Ladders, where your movement is completely governed by the dice and board, would not be very interesting if it was not for its spiritual meaning. But it does not follow that the more tactical options a game has, the better it is. Even quite a small number of alternatives at any given time can make for an interesting game. In chess, for example, there are only 20 alternatives for the first move and nobody would say that chess is a shallow game.

The question here then, is what to keep and what to drop. When comparing our experiences from various tactical games, we came to the conclusion that no matter how many modes of movement or modes of fire we had, we only used two of them. In Jagged Alliance, for example (I keep speaking about this exceptional game, as it is perhaps closest to the ideal of a truly realistic tactical game), I never used crouching and I always allocated as many APs to a shot as was possible. Doubtless, there are players out there who had a different strategy, but I do believe that for many this strategy also entailed a reduction of the game complexity.

When we started to design UFO: Aftermath, our goal was to make a game that would be accessible to all kind of players, not only to hardcore veteran wargamers. We have no illusions as to UFO: AM being a truly mass-market game - we are surely not going to compete with The Sims or even C&C Generals. But if we can make the game no more complex than say, Civilization, we would have hit our mark.

For this reason we wanted to have only two modes of movement, two modes of fire and two stances. We decided for run/walk because it is little bit easier to implement than run/crawl (prone units occupy two squares instead of one). We decided on aimed/burst fire because it is quite an obvious choice. Both these decisions are, in my opinion at least, good ones, and will make UFO: Aftermath a good game. I am not sure at the moment about stances: we have standing/kneeling, which again is somewhat easier than standing/lying prone. However the stances are directly connected to the modes of fire. Therefore if the stance had its intuitive meaning (kneeling gave you more cover, but took time to get in and from), the player might feel frustrated when he would have to switch the mode of fire in order to get into desired position. As a result, the stance currently has no implications for the soldier's visibility or vulnerability and it is only, as mentioned above, a visual representation of the mode of fire. This is one option where we might yet change the system and decouple the stances from mode of fire, but given the project's deadline, it is by no means certain.

The usual assertion of the "hardliners" on our forums is: "That isn't real! That isn't how it works!" This is actually a poor argument. We are making a game, not a simulator. We try to have enough tactical options to make the game interesting but not so many as to make it overwhelming.

What these "hardliners" are actually trying to say is: "This is too abstract. This is not intuitive." This is a valid objection and one we must address. The reason why ordinary people can play a game like say, Combat Mission, reasonably well, even though it has many more possibilities than chess, is that they can make assumption about the workings of the game world. Even without ever playing the game they can assume that a single soldier with the Sten has little chance against a Tiger tank. They know that an armored car is going to be faster than a foot soldier and that they would not send two guys with Luger pistols against a knoll with a Bren machine gun nest on top of it. In chess or any other completely abstract game you do not have this mass of prior knowledge and therefore you have to do quite a lot of study if you want to play reasonably well.

However, I maintain that the level of abstraction we adopted in UFO: Aftermath is absolutely adequate; making the game little bit more abstract will make it more accessible to people who have no previous experience with this kind of game. We want the player who does not come from a military background to think: "Wow, this is just as I imagined war to be." We do not want MIB veterans saying: "This is just like when I was fighting the Cerillians back in '97."

Part ten (March 31, 2003)

Now that we have moved into the area of double-digit installments of developer's diary for UFO: Aftermath, I want to again thank everybody for taking their time to read them; especially to those of you who are with us from the beginning.

The last diary caused quite a stir on our boards (in as much as such gentle and reasonable people as populate the forums can get stirred) and led to a very useful exchange of ideas and opinions. Thanks again to everybody who participated - the rest of you can at least take a look at the discussion at http://www.ufo-aftermath.com/forums.

Diary: A day in the life

These diaries have traditionally consisted either of my fragmentary recollections of dealings with various companies, i.e., with the history of the project, or of various explanations and exhortations about the supposed pros and cons of the game.

Now the former thread has run its course, and you, the kind reader, are completely up-to-date, and the design of the game is fairly stable, and there are no dramatic changes I would have to report (though I think there are bound to be some, and I will speak about them in the next installment). But for the time being I think it might be interesting for you if for once you could actually read what you were supposed to read all the time, that is, a diary.

Dear diary,
Today I got up late; playing Warcraft III till 2:00 a.m. didn't help things much. I knew I had to write that wretched developer's diary the first thing I get in the office, so maybe I was just trying to postpone the inevitable. However, when I arrived, the lead programmer told me about a subtle problem with alien AI: as you know, dear diary, we compose the city missions from blocks. These blocks have pre-computed values of "cover" for each square, i.e., how much a given square is covered from enemy sight (and fire). This calculation is pretty expensive and cannot be recalculated in run-time. Therefore, whenever a wall is knocked down, the aliens will gather there in droves, as no spot is better protected than the one inside a solid structure. Furthermore, squares just behind a wall or in a corner between two walls have high values of cover as well.

We talked about it for a while, then decided to set the cover to 0 for the squares the walls stood on and mark out every square the alien tries to hide on that does not meet his expectations - that is, if he stands on a square with a high value of cover and still can see four soldiers, he will mark that square as suspicious and try to go somewhere else.

Then we discussed some subtle issues related to the heads config - an Excel file that lists all available models of the soldier's heads and hair and their combinations, as well as animations for speech. We try to have as many data as possible outside the codebase, usually in Excel files (we then export the data into plain text - our program cannot read and parse native Excel format), but is an uphill battle. Yesterday, for example, we - the project manager and the programmer responsible for it - talked for an hour or so about the integral mutant weapons (i.e. their claws or maws or slime they spit). These should be in the same table as other weapons, along with M4 and AK-47. But how should we mark them as belonging only to a particular type of mutant? Should this information be rather in the weapons table or in the creatures table? And just how general should this solution be? Can there be more than one integral weapon for melee attack? The solution we arrived at was not very general but easy to implement and time is of the essence for us.

But that was yesterday, so let's return to the present. After going over the heads list, I went to see the chief artist to tell him about it and also ask him about some problems we had with one of the transgenants. Just before I got back to you, my diary, a call came from our producer at Cenega Publishing, about his visit scheduled for tomorrow. Just as I hung up I realized I don't know if we agreed that he is coming this Thursday or next Monday. I contemplated calling him back, but then decided time will tell.

Then there was nothing that I could use as a pretext for not writing this article. I hope you enjoyed it and I promise next time I'll speak more about the game than about myself.

Outlook: The coming of E3
As I am writing this, March is about to end and the last snowflakes of the year drift by the windows of my office. But by the time you read this, it will be the beginning of May and the E3 will be just around the corner. Therefore I will share the information about UFO: Aftermath vis-à-vis E3, such as we have at the moment, with you now.

We are going to be located on the stand of our publisher, Cenega Publishing, in Kentia Hall, at booth 6323. While many call Kentia Hall the "Hall of the Damned" for being a refuge of hundreds of manufacturers of the most useless and weird peripherals and paraphernalia imaginable, it is also home to many medium-size publishers, like German CDV or French Monte Cristo; indeed, out of the 400 exhibitors currently listed on E3 website (www.e3expo.com), 199 are located in Kentia Hall. We do believe that Cenega's booth is not going to get lost in there but will become a center of much deserved attention and a stepping-stone to a large stand in the South Hall next year!

We will be showing a beta version of the game: it should be working more-or-less as the final game is going to, but with a lot of tuning and tweaking still ahead of us. Not all mutants and transgenants are going to be ready, nor all graphics and sound effects. E3 is a show and we must take this into account: it is much better to show one really polished part of the game than half a dozen work-in-progress scenes. Besides, the more important a person you are demoing the game to is, the less time he or she has for you, so it is very important to have a very short and focused presentation.

Obviously a lot of "useless" work goes into making these demos. The programmers (who shoulder the main burden of their preparation as the art assets usually need little alteration) constantly grumble about the extra code that prevents them from working on more important and critical sections of development and which will be thrown away the moment the show is over. Still, you can have the best game in the world, but does it matter if nobody knows about it? The hype, despised as it is, is a part of making a game, just as code and sound are.

The returns on the extra work going into a demo are measured in terms of people who saw it. So stand up and be counted: come to visit us and enjoy our demo.

Part eleven (May 31, 2003)

There has been a lull in these reports from below the deck of the ship that will soon bring you UFO: Aftermath. Thanks for your patience, all of you who watch our journey, and again I invite you to take part in the discussions of our progress in the forums on the game's website at http://www.ufo-aftermath.com/forums.

E3, the big picture

There was a lull, and this was entirely due to the preparation for E3, E3 itself, and the aftermath of E3. I hinted at the first in the previous installment of the diary; I am going to dwell more on the second and third now.

You have probably already read so many reports from the show that you know everything there is to know about the games on display this year. Actually, it is very likely you know much more about E3 than I do, as I spent most of my time at our booth, demonstrating UFO: Aftermath to the eager visitors. Still, I can confirm the generally upbeat atmosphere of the show. Last year, I remember going through the halls feeling as if all the screens were showing various trailers of the same game - a third-person action racing game with football in the intermissions.

This year, there was much to look at, and much of it was on the PC, which was definitely a pleasurable experience. Still, there is no denying that the room for PC games gets smaller and the consoles get better every year - some of the best-looking console games look almost as good as older PC games. But more important  than the look of the games on display was their variety. I didn't see anything strikingly original - something that is going to change the gaming the way Dune 2 did. Indeed, it is very possible that all basic forms of computer games (FPS, RTS, RPG, etc.) are already known to Man and that our task is going to be improving the formula (redefining the genre, as they call it in the ads) not inventing a new one. But this year I had a distinct feeling the formula is being improved and that there are many possible directions it can be improved in and that many of these directions are being explored at the moment.

My personal favorite of the show is Vampire: The Masquerade - Bloodlines, a game from Troika, running on the Half-Life 2 engine.  You have perhaps seen the trailer for Half-Life 2 (if you haven't, be sure you do, this is a rare opportunity to see the future), so imagine the same level of detail, but in a much richer, more colorful world. The static screenshots do not do the game justice; in motion it looks amazingly real and solid.

UFO: Aftermath at E3

But let's go back to Kentia Hall and Cenega's stand. It was quite handsome and spacious, with two tiny meeting rooms and a total of seven computers, two of them running UFO. (Korea: the Forgotten Conflict and Shade: the Wrath of Angels also had two each. The seventh was running Gooka). As usual, the version we brought with us (having snatched it from the hands of our programmers at 4:00 a.m. before driving directly to the airport) didn't work too well, so on the evening before the show we went to a Counter-Strike game center close to our hotel and used their Internet connection to download a patch that, as usual, miraculously made everything work. We then spent a nice night burning this new version on fifty CDs we had promised Cenega we'd bring with us.

Next day, the show started in earnest. Journalists, distributors and retailers were brought to the stand, introduced and shown the game. There was also a constant influx of passers-by, who saw the spinning globe on the screen, muttered "This must be a new X-COM," and came closer to have their hopes squashed - this is no X-COM. Still, the reaction of all these people was thoroughly positive. Obviously, this has much to do with my prowess in demonstrating the game. But besides this, I believe our visitors genuinely liked the more tangible and authentic things about UFO:A. They liked the way the game looked, admired the great variety of mission environments, enjoyed the game combat system with simultaneous action, had fun watching the collapsible machine gun turret in action, and generally welcomed the concept of the game. The game was still far from completion, but it seemed that our visitors (who could see beyond that and imagine how the game will look when it is finished) liked what they saw.

This report from E3 would not be complete without a mention of the visit by mike9o, a distinguished member of our forums, who brought with him the questions from the readers of fan page www.ufoaftermath.co.uk. We showed him the game very thoroughly, and his positive reaction and endorsement were very important to us. It is one thing to impress a journalist who greets you by saying: "I'm already running forty-five minutes late, so make it short," and another thing to make an impact on someone who knows what the game is about and where to look.

Overall, this past E3 was a pleasant experience. Lots of nice games, lots of positive feedback, lots of people who saw what we are doing and liked it. This should give us strength for the coming months, where the final crunch awaits us.

Part twelve (June 31, 2003)

Greetings, my dear friend, and friend of these diaries. We have rounded the first dozen and our story is slowly drawing to a close. The crunch time is upon us and the glimmer of gold disc can be seen not far away… But enough of this poetic verbiage. Last time I promised I would write more about the way the game works and now it is the time to deliver.

While the tactical gameplay is pretty much set for some time now and we are now balancing weapons stats and strength of enemies, the strategic game was in very much rudimentary state. Now, our strategic game is the less complex part of the game, yet still it is more than a mere engine for tactical mission generation. We always wanted the strategic game to be a game in it own right, it should be able to stand up on its own. UFO: Aftermath should be interesting even if you could win a tactical mission by a mere click of a button.

If you follow the development of UFO: Aftermath for some time, you know that the strategy game - that's the part with the spinning globe, flying UFOs and various markers - revolves around the territorial expansion. The principle is very simple: there are some flashpoints on the border between yours and enemy's territory. A successful mission there could tip the balance of power and deliver you a large stretch of territory (or you could lose a large stretch of your territory by losing or ignoring it). At any one time, there are several possible missions (about five or ten) and you must decide which one you shall commit your squad to. When you select a mission, a chopper flies from one of your bases, carrying your men to the spot. Then you play a tactical mission, win or lose, and then the chopper lifts you back. Each mission is active only for a limited period of time; if you ignore it, other human troops will take care of it and your squad will not be involved

A successful tactical mission will increase your influence over territory, while the alien victory will increase their influence. Obviously, the interesting question here is the exact way this is implemented. For generation of the missions we use a sort of an abstract "influence" field both for the player and the aliens. We then combine these fields to find places where there is the greatest "tension" between the two - these are the spots where the next mission is most likely to appear. When we know where the mission is we determine its weight, or importance. We take into account the distance from the player's territory, its difficulty and some other things. This is then how much impact this mission will make.

How do we interpret this impact? This is going to be a subtle point and I am including it here because I believe it can illustrate the nature of choices a developer is making when designing the game. The bases on the globe divide its surface into areas or spheres of influence. We use a Voronoi diagrams to generate them, so each base controls all the territory that's closer to it than to any other base. As a result, the areas of each base are vastly different, depending on their distance. The largest territory by far belongs to the base on the Eastern Island. Now should the influence of mission depend on the size of the territory or on its distance to the nearest base? Imagine two otherwise equal missions, one taking place in Europe and other one in Africa. Should the first make bigger impact (it is closer to a base), lower impact (it is in a smaller territory) or should it be equal? And how many territories should be influenced - only the one where it takes place or also the neighboring ones?

In the end we decided to put the game before realism, so in the example above their impact would be equal. It is slightly illogical that a victory in a mission can have the same influence over a base several hundred kilometers away as it does over a base just next to it. On the other hand a base in a bigger territory is not more important - it does not have better aircrafts, provide more research or manufacturing. So it is only fair that it conquering it is as simple, or as difficult, as conquering a base in a more densely populated area.

We also decided that the outcome of a mission should influence other territories beside the one it is taking place in, albeit much less. Again, this influence does not depend on the actual distance from the mission to a base. The size of territory therefore does not play any role in the game. You have to realize that the player does not see the bases he does not own and therefore he has no way of knowing how big is the territory he tries to capture. In this way it is much more predictable what will be the effect of a mission and predictability is the basic prerequisite of any strategy.

Another element of the strategic game which underwent significant development are the dogfights, or interceptions as the old fans call them. Originally, we thought the interceptions will simply be automatic - when an alien craft is spotted a military aircraft will take off from the nearest military base and try to engage it. However, feedback from the players and our own experience have induced us to include more gameplay here. So now, when an UFO is spotted, the player is asked whether he wants to launch an interception. If he does, a military jet will pursue the UFO and when the two meet, the dogfight starts.

There appears a window in the center of the screen: in the right you can see a short video, on the left you see outlines of both yours and enemy crafts. When a plane is hit it turns red (damaged) or gray (downed). At any moment, the player can click the Retreat button to salvage what is left from his aircrafts. When the damaged aircrafts return to their base, they must be repaired and while the repairs are under progress, that base cannot launch any interceptions.

This again is certainly not the most realistic simulation of aircombat, however it adds to the player's feeling of involvement with the game. The dogfights moreover relate directly to the tactical missions: if the player is successful, it may become possible to explore the UFO wreck and recover various important artifacts and equipment. If, on the other hand, the player loses, the pilots can manage to bail out and it is then necessary to rescue them.

So how do we measure up against the goals outlined above? Quite well, I believe. The strategic game is not the most complex undertaking you have ever seen on your computer screen, however it is engaging and easy to understand. Next time, I shall write more about the changes we made to the tactical game.