Vol.32 No.2 May 1998
Battlezone - Eighteen Years Later: Remaking a Classic
"What?!" I responded. "You want to remake an old vector graphics tank battle game?"
To be honest, I wasn’t particularly happy with the concept, never having been thrilled at taking what someone else had done, and trying to one-up it. Here at Activision, we have a ton of creative talent, dozens of untried worlds, genres and ideas. Why did we have to grab from the old to make the new?
Yet the more I thought about it (and the more I accepted the inevitable), the more it evolved into one of the greatest licenses I could possibly imagine working on, one without boundaries or restrictions.
I remember playing Battlezone in my childhood. I was a sucker for anything that jumped out at me and made me feel like part of the action. Battlezone had what no other game at the time had: 3D graphics.
Figure 1: A full texture map for the American APC.
Figure 2: The APC texture map applied to the model.
Figure 3: All the textures for a vehicle were compacted onto single 256x256 sized images.
Figure 4: The UV coordinates were used to apply them to the whole vehicle.
The green vector lines had so much going for them back then. They were much clearer and less pixelated than the other video arcade games of the era, and they had such fluidity of motion that it was pleasing to watch the shapes take form. Star Castle, Cosmic Chasm, Armor Attack, Tempest and Battlezone all had very distinctive looks and, as such, are now fondly remembered by all who played them.
So when it came for us to decide on the Battlezone license, everything came down to concept. Did our idea fit within the Battlezone universe? Did our game have the innovation needed to be connected with such a well respected game? Our answer was "yes."
We were set on creating what was to be, at the time, a new hybrid of gaming: taking the fast pace and visually engrossing world of action games and combining this with the intelligence and sophistication of a real-time strategy game. It was in this newly combined genre where we would find the destined successor to the classic Battlezone.
While the game premise remained related to the classic, we pushed the relationship as far as we could go. The story was fleshed out by our excellent game design staff (comprising Lead Designer George Collins and Associate Designers Jens Andersen and Will Stahl). Their intent was to capture the Battlezone mystique, giving the little alien UFO from the old Battlezone a starring role in the process. The basic story relied on a resource known as bio-metal (created by the UFO guys). This led to a secret extension of the cold war as the Americans and the Soviets raced through our solar system vying for control of the metal, which could be fashioned into amazing weapons and vehicles (such as the “super-cool” missile the UFO launched at you in the original Battlezone that made you jump right out of your skin!). The battles would range across nine planetary surfaces including the moon, Venus, Mars, Europa, Io and Titan. The last planet, Achilles, would wind up being an Earth-like artificial planet set up by the aliens and the source of the bio-metal.
The vector-based graphics, so omnipresent in Battlezone, were to find a home in the new version. Since the player has to simultaneously command a large military force while remaining in the cockpit immersed in battle, this led to the need for a clear way to control the game dynamics. If the player had to pop out of his tank to look down on the map and control the units, it would not only halt the feeling of immersion, but his tank would immediately be pummeled by the enemy. To prevent this mishap, Ken Miller, our 3D graphics guru, created a topographical radar map for the HUD in the cockpit. It displayed all pertinent information about the battle, including unit location and terrain elevation. It looked very cool and we made the decision to carry the green color over to make it look "Battlezone-ish." In addition, there is actually a special weapon called the "sitecam" which, when turned on, renders the terrain in first person transparent with gridlines, and this certainly brings a little of the original game back to the player.
Figure 5: Mars rocky sand - solid.
Figure 6: Mars rocky sand/rock - cap.
Figure 7: Mars rocky sand/rock - diagonal.
Figure 8: Mars rock - solid.
One area where we thought the current technology could improve upon the original was in the terrain system. Of course, everyone who played the original arcade Battlezone knows that the terrain consisted of a horizon line in the distance with sharp pointy mountain peak shapes and the infamous volcano. (Editor’s Note: the volcano was worked on by Owen Rubin, author of one of this issue’s articles.)
Originally, our terrain system bordered on the ridiculous (in fact, leaving the terrain like the old Battlezone might have looked better). Limited to a single repetitive tile, it was extremely difficult to get any results that could be considered realistic. We set out, with the help of George Sutty, to create something visually pleasing, fast to render and memory friendly. He started with a tiling system that relied on a series of 16 texture maps to cover the terrain with two ground coverings. We initially chose 128x128 tiles. There were solids, edges, caps and double caps. The solids were the individual material types that were tileable. The edges were where two materials met, and were split at the midpoint of the edge. The caps were where one material met at the corners of another. The double caps were where two separate areas of one material met over another.
Ultimately, the system had holes. Our results, while satisfactory, were not truly impressive. During the E3 conference, as I walked around the convention floor, it became obvious that if our game was to catch anyone's attention we would have to improve the terrain system. I flew back to discuss options with George Sutty and based our experimentation on landmark products such as Looking Glass Technologies' Flight Unlimited II, Eidos' Flying Nightmares and Novalogic's previously released F22 Lightning II. Through our research, we made fundamental changes which stayed with us for the duration of the project. In fact, the results were so astounding that parts of our methodology were borrowed for the games Heavy Gear I and II.
George Sutty and I spent a day flying straight up, turning nose downward and pausing in some of the various flight simulators (most notably Novalogic's F22 Lightning II) to help inspire our new changes. It was amazing to me after playing F22 for a while, thinking how gorgeous the non-tiled terrain looked, to find out that it was tiled! Their texture tiles were marvelous. They had also done a smart thing by placing the cloud layer at the precise height where the terrain would start to become visibly tiled. No wonder I hadn't noticed it before! It was after this kind of research in a number of other simulators that we figured out our new tiling method.
Instead of having two materials meet at the midpoint of an edge for the edge tiles, we decided that having the materials meet at the corners diagonally would permit greater control over the tiles. This also dropped the required tiles to four for any two materials. Having already surrendered a serious amount of memory real estate to tiles, this enabled us to increase the mean tile size to 256x256.
At this point, we experimented with the tile scale/size relationship. Aircraft simulators typically apply a larger scale to the tilesets because of their higher flight altitude. The higher the altitude, the smaller the pixels look. Since our game involved vehicles hovering only a meter off the ground, the pixels at flight simulator resolution would look huge. We experimented with various scale/size resolutions until we narrowed it down to 256x256 pixel tiles covering a scale of 20 meters. At this size they were big enough to hamper repetition, yet small enough reduce pixelization.
Locked in our tile scale/size relationship, I could then take real world images and translate them into textures. I searched for image data that could be successfully (and legally) transformed into texture tiles. Satellite imagery was not resolved enough for closely viewed ground textures so I opted for Kite Arial Photography (KAP for short). This type of photo is characterized by vertical camera shots taken at relatively low altitude -- perfect for making texture tiles. I even found fine river images I could transform into river tiles for Achilles (which unfortunately would not be used in the final product). Also, by that point the Mars Pathfinder had generated a huge library of pictures of the Martian surface, and I grabbed some to see how they would look. I was astonished. The rocks really looked like rocks when viewed from our vehicles while zipping across the terrain. A big thanks to the Mars Pathfinder mission for all their hard work in making the new Battlezone!
There were two cleanup tasks needed to optimize the photo images for use as tiles. An unfortunate downfall with a software based renderer, which isn't a problem with the new 3D accelerator cards, is jitter. As a tile recedes further into the distance, each pixel resolves into smaller screen regions. As this happens, the renderer finds two pixels on the edge of a pixel location and consequently flip flops between the two. This became a problem in areas of sharply contrasting regions of the texture. Unfortunately you have to give up some of the sharp contrasts to get rid of it (and introduce mipmaps, which may still produce the effect if they're not correctly prepared). As it turned out, a combination of sensible color correction and a good Photoshop Gaussian blur filter set at 0.3 did the trick and we ended up with some nice blending.
The last trick in the process was getting the pattern on the tile to not look patterned. This took some work, as any attempts to remove patterning resulted in a tile that looked like one solid color. The fog effect, which was mostly there to increase frame rate, helped solve this problem as well. The fog was set at a distance around the region where the tiles would begin to show their ugly "tiled" faces. By the time you started to recognize the pattern, they vanished behind a colored curtain.
Figure 9: Here, you can see the ground fog effect implemented.
Figure 10: Multi-pass textures can produce cool visuals — like shockwaves following the shape of the terrain.
When the tiling and material system were complete, we set out to develop a terrain editing system that would be efficient and extremely easy to use.
The biggest obstacle was the sheer amount of terrain data. Our terrain grid was a height map, based on a 128x128 area called a "zone." Typically a single mission map consisted of three to five zones. Each piece of height map data was a number correlating to a positive value on the y-axis (the material type and orientation were in a separate data file). Because of the size of the elevation data, traditional methods of manipulation were inefficient. We decided it was necessary to create a proprietary editor to handle the data easily and allow various control tools.
The main goals for the editor were ease of use and optimum conversion times, to speed up the process of creating and editing the maps. We settled on a terrain editing system that was based directly on the engine. We could jump into the game using a default height map and "sculpt" the terrain to our liking. Then, in the same session -- without backing out of the simulator -- jump into the tank and cruise around our newly created terrain, making adjustments and fine tuning it until it was perfect.
We also created a set of manipulation tools to make the sculpting fast and effective. We could choose the brush size and whether the brush painted round hills or flat plateaus. We could specify the angle of the round hill, and cut and paste terrain areas into other zones. We made a blur tool to soften ridge edges and plateaus so that the intended realism of the world was enforced. When the terrain was complete, you pressed a key and switched over to the material painting module that let you to place and rotate the various terrain tiles -- all while remaining in the simulator.
This was the first time an in-engine editor was created at Activision. As I look back on it, I think "How obvious! Why didn't we think of this before?" For years, production teams relied on external editors and converters to get their terrain into their game engine. It just seemed so logical to let the engine perform the tasks it was built for. Our system was eventually the inspiration for several other Activision toolsets used in other productions.
The system was completely successful, and the game designers pushed out maps like a fast food joint cranks out burgers (but with more finesse and care, of course). Jens Andersen even successfully recreated the infamous "Mars face" for one of the missions.
With the terrain system in order, we set out to optimize the production pathway using one of the best 3D packages: SOFTIMAGE|3D (SI3D).
Before we chose SI3D, we used the tried and true methods developed by the Interstate 76 (a previous Activision game) team for getting models into the engine. This required a large amount of input and manipulation in another modeler to create models and place textures. While this system worked for them at the time, it was more than our game needed. I had my SOFTIMAGE system sitting on my desk from the defunct Planetfall project. I demonstrated to Andrew Goldman, my director, the model building and texture mapping processes in SI3D, along with the DirectX conversion utility, and it pretty much spoke for itself. I remember one of the ways I tried to prove the program's worth was by texture mapping five vehicles with the same texture. All I needed was the "that is totally cool" sign from the lead programmer, and all was golden.
With SI3D, I could realize an average of about five polygon models a day. I was able to complete the first pass of all the models in about two months of modeling. Each model had a maximum of 150 polygons (not triangles). Our engine was capable of outputting a single face with a maximum of eight vertices, so the polygon count was limited only by how efficiently our surfaces were created. For example, if the side of a fuselage had three segmented polygons, I could potentially reduce that number by making sure that the faces were coplanar.
The process in SI3D started with a cube, which I pulled into various shapes, based on Art Director Kino Scialabba's intense designs. We developed a vehicle design which involved rotating parts for the engine areas, resulting in extremely dynamic vehicles. It typically consisted of a piece that rotated on the z-axis, which was the parent for two objects rotating on the x-axis. Together they created a very cool look and permitted lots of vehicle configurations. Sometimes they were in the front. Sometimes a vehicle had two systems, front and back. As long as we had the correct rotation axes we could constantly find new shapes and configurations for the parts. Kino and I designed a vehicle for the Soviets which had separate cockpit and engine areas. We wanted to make it so that when the main vehicle was destroyed, the cockpit part would detach and become a small vehicle -- useful for escaping impending doom.
A model file consisted of vehicle parts, weapon placement geometry and a collision box. We exported a model from SI3D as a DirectX "xfile," then converted that file to our own "geo" format. The texture application relied on UV coordinate placement in SI3D, and all the vehicle textures were stored on single image maps consisting of the various vehicle pieces compressed into a 256x156 texture. We aimed for realistic, hard edged textures created by our brilliant artists Willie Rosas, Rick Sanchez and Art Director Kino Scialabba. They rolled out about one texture map for a vehicle per day, and sometimes two.
We relied on this system for our six-month production cycle. In the end, we created about 76 building objects and 56 vehicle objects. All of these had their own texture maps, and all of them turned out to be pretty cool designs in their own right.
One of the most amazing things about the "shell" (the multiscreen interface for starting the game, selecting options, and the like) is that it was done with basic Win32 dialogue box programming. To every programmer out there I want to say that this is not the way to create an interface for your game, unless you really really have to! (Kudos to our programmer Linus Chen who was able to cope with the system and crank out a visually stimulating shell without the ugly obviousness of the traditional Windows interface).
The irony of events always seems to amaze me. As it turned out, the major factor contributing to the development of our shell was the simple fact that the previous shell had been inadvertently deleted. As a result of this mistake, I had a chance to rethink the look of the shell (since I hadn't really liked the original anyway).
There are three major objectives that I think of when designing a shell. The first and foremost is that the screens progress logically and fluidly throughout their interactions. The second is that everything the user had the potential of pushing, pressing or toggling returned some sort of feedback. Many times I have played games where pushing a button didn't result in a graphical dimple or audible "squish." This always gives my mouse button finger a headache, for the sound of a button reinforces the way the mouse button feels when pressed. Sometimes, when I received no feedback, I always felt I had just rammed my finger into a stone wall.
Lastly, I want a shell to remain visually consistent with some aspect of the game. The shell was the one part of the game which would strengthen and reinforce the Battlezone nostalgia. I received positive feedback on the reticles used for the games weapon aiming system. They had this nice holographic feel and were partially transparent with a bit of glow. They seemed to be a nice throwback to the original “Battlezone green,” so I aimed to incorporate the reticle designs into the shell. The shell backgrounds were subtly reminiscent of those heavily illuminated designs found in the early book transcribing days when the monks toiled over biblical pages for months at a time. Little green lines sparked out to touch other screen objects. Tiny computer chip etchings extruded out of control areas. Everything seemed to have grown into place. The effect made a visually interesting patchwork while giving players something to look at while waiting for mission launches or multiplayer game setups.
Our attempts to recreate the visionary nature of the previous Battlezone could only be judged by one thing: the gameplay. Was the game fun, addictive and action-packed? There was a point where Andrew Goldman had to step in and tell us "No new features!"
Carey Chico was the lead artist for Activision's Battlezone. He also worked on the unfinished remake of Planetfall (based on an old Infocom text adventure). Prior to Activision, Carey was a preproduction art consultant for Virgin Sound and Vision.
There is simply so much to do in the game, so much action and strategy to apply, that a gamer could play for a month and still not have tried something. Never before as a game player have I seen a game where I could have my ship destroyed in a ferocious battle and respond with vengeance on foot while staring through a sniper's scope and waiting for a fellow team member to arrive and pick me up to continue the battle. There have been several times where I didn't care if I lost a mission because I still had some strategies to try. It is in the sheer number of options where the new Battlezone shines. One would hope that the new Battlezone will be remembered like the old, for its contribution to the never-ending hunt for fun.