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-a-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.
Martin Klíma
ALTAR interactive