I first got involved with Artex after emailing them to ask about the suitability of reusing the Ankh engine for producing a graphic adventure. However, it wasn't long before Jan Klose had persuaded me to help produce some graphics for TEK, Artex's up and coming real-time strategy wargame. 'No problem' I thought, 'it shouldn't take me too long to do something'. How wrong I was ! Four years on, and despite big changes in the Acorn marketplace, you're about to find out just what that 'something' is.
 


 
For those that don't know, TEK is a real time strategy wargame, a bit like "Command and Conquer". The game is set in the near future after a nuclear war, and centres around two global corporations who are battling it out over the production and control of a vital drug called SHOQ. From the gamplay point of view, the action involves the player directing their battle units across a three dimensional landscape in an attempt to achieve their mission objective. Of course, the opposing corporation have their own idea about what the player can or can't do and there's a good deal of mayhem to be had before anyone finally comes out on top.

It should be noted, since I'm not in possession of the most recent TEK beta, a number of the images produced in this article are mock ups that have been produced in Compo and are rendered in a higher colour depth than the final game. They also don't show the line of sight shading in action, and may show some elements that don't appear in the final game (although I believe everything I have shown should make it to the release version - plus other stuff too, of course !). The upshot is treat them as what they are - mock ups to illustrate features for this article.

TEK development

Figure 1: an illustration of the clean, futuristic look of TEK units and buildings

From the outset, I wanted to make TEK appear as professional as possible - I also wanted the graphics to share a common look and strove to create a slightly futuristic, clean and elegant style, especially for the buildings some of which are illustrated in figure 1. As usual, one of the best ways of generating ideas is to simply start sketching using what is around you for inspiration (figure 2). Amazingly, some of the initial designs were inspired by as bizarre structures as concrete water towers and tents - there were also a number of designs that didn't make it into the game, due to lack of time or poor design ! However, I didn't have a complete free reign since Jan had given me a list of buildings and their function, and this information strongly influenced their design. The units I designed also had to fit in with the look and feel of some of the existing units.

Figure 2: initial sketched artwork compared with finished in-game graphics

All the buildings were created and modelled in TopModel, which I actually prefer to other PC based 3D modelling packages I have tried. However, when it came to texturing and rendering the buildings, I opted to use Bryce on the PC since rendering is one area in which RISC OS machines simply can't compete. Transfering the models from my Risc PC to the PC proved problematic and in the end I was forced to write my own translation tool in order to give me the flexibility I desired. Specifically, I needed to be able to select individual groups to be able to texture different parts of the model, which the standard export program would not allow me to do. If anyone would like a copy of this (PC based) utility then let me know.

The advantage of creating rendered models over drawing is that they are easier to tweak and can be used to create additional in-game artwork relatively easily. I am also far more comfortable working in 3D than drawing.

Over the lifetime of the game's design, some of the buildings have gone through a several design stages, following feedback from the rest of the Artex team and external sources. For example, the initial buildings were too clean, and some, like the repair station, didn't fit into the way the game engine needed to work. Others were simpy reworked over time as a result of personal perferences.

One of the most difficult of all the graphical tasks was the creation of the destroyed buildings. However, it was one area that I was determined to crack, since the player's buildings could hardly just disappear, once destroyed. In the end, I found the best solution to this problem was to take the original model and replace sections, like walls, with jagged and extruded pieces. Other parts of the models were either distorted using TopModel's deformation tools, removed completely, or rotated to look like they had been blasted out of their original position. Texturing these models was quite difficult, and involved the use of textures from a stressed texture library I had recently purchased. I also ended up added 'blast craters' around the models so that they would look more natural when placed in the landscape. Hopefully the results look convincing (figure 6, below, shows some destroyed buildings).

 
 

Figure 3: masks

Another area that took a lot of time was creating three set of graphics for the terrains which provide the backdrop for the missions. Originally, I presented Jan with a selection of possible base textures (taken from parts of photogaphs, or texture libraries) from which a few candiates were chosen. The next problem to overcome was how to make more than one type of texture coexist within the landscape. The solution to this was to create a set of blend masks, which acted as transitions between one type of texture and another. The masks for these tiles were created in Artworks and then applied in Compo (figure 3).

 
 

Figure 4: three different terrains

The reason for using Artworks over a package such a Photodesk for the masks was that it allowed me finer control over the shape of the blends while also retaining the ability to edit the masks easily. Originally, a complete set of blend tiles was created by applying the masks by hand in Compo. However, with the advent of Composcript (a scripting language for Compo) I soon realised I could save a huge amount of time by automating the process. I can now point Compo at two types of base tile and let it generate a full set of blend tiles automatically. It makes me shudder to think how long that process used to take ! Once a set of tiles have been generated, they can be used to create varied looking landscapes without requiring large amounts of memory - something that is still is in relatively short supply. Figure 4 illustrates the different kind of environments that can be created.

Figure 5: line of sight

One of the more unusual features of the TEK engine are hills, which can be used to hide behind. This enhances the gameplay considerably, and looks fantastic when combined with the engine's other unusual feature - line of sight shading (figure 5). You can actually drive up to a building and fail to spot an enemy unit that is hiding round the far side, alternatively you can use the high ground to see more of the surrounding landscape. It's a really impressive feature that also looks great and all credit goes to the TEK programming team for creating something really special. However, getting the textures on the hills to look right proved quite difficult, since the rendered hills didn't match the appearance of the flat tiles of the same texture type. The solution to this proved to be a matter of trial and error (fortunately, this tricky problem was tackled by the other Artex graphics artists) but we got there in the end.

The package that I found to be most useful when creating graphics for TEK was Compo. This proved invaluable for a number of reasons. First, it could be used to create mock-ups of the levels (some of which are shown here). Second, its powerful masking features were extremely useful when creating features such as the cliffs and explosions. Finally, the introduction of Composcript enabled otherwise tedious tasks to be automated, saving me a considerable amount of time. Other packages that were used (not previously mentioned) include TreeDruid (PC), which was used to create the tree meshes, Photodesk, for texturing, Illusion (PC) for particle effects such as the explosions and an animated waterfall and Xara X for the tracks in the snow and other road markings.

Xara X was also used to create a set of interlocking relief (height) maps for the rivers. These were then imported into Bryce (which specialises in the creation of 3D landscapes) and applied to a terrain object. The original terrain was then erroded and had a bit of noise added to it before being textured and rendered. This was done to make the rivers more natural and bring out some of the definition in the procedural texture. Probably the most difficult aspect of producing the river graphics was setting up the viewing angle to make the rendered terrain the same size as a tile used by the TEK engine. Once again trial and error got me there in the end.

Figure 6: explosion stages and destroyed buildings

While I could continue to describe how other elements of TEKs graphics were tackled (vegetation, ambient buldings, units, etc), I will finish by describing the soloution to one problem that was discussed on the Acorn Arcade forums a while back. The problem involved trying to create a set of sprites (in this case explosions), that had a one bit mask, from original images that had 256 levels of transparency. I found that the quick and dirty solution involving the use of a cut off level below which everything is transparent and above which everything is opaque resulted in the original quality of the images being lost. For example, if the cut off level was too high, most of the explosion was removed making it look unatural, while if the cut off level was too low, the explosions exhibited a halo (the background image was visible through the explosion). After some discussion and messing around I found a better solution to this problem involved using two strategies. First the transparency mask was converted to a one bit dithered mask. Second, the explosion was blended with the most common background texture to force outlying pixels to blend with the background texture 'faster' that they would otherwise have done. The combination of these strategies looks quite effective and is a good compromise, given the limtations of the rendering engine (figure 6).

That's about it for now. Hopefully this article has whetted your appetite and also helped demonstrate some of the difficulties and solutions that can be encountered while working on the graphics for a game of this type. It's amazing to think that I still haven't met most of the TEK team, and virtually all correspondence has been conducted via email. If all goes well the real test of how good a job the team has done will come in a few weeks time when the game released. In the mean time, if you want to ask any follow up questions about this article then feel free to email me (max@autumn0.demon.co.uk).