Going Gold - Julian 'Loomer' Figueroa
		Simulation Interface - Joseph Donaldson
		Interface Design - Joseph Donaldson
		Code Releasing the Demo - Mike Arkin

Going Gold
by Area-S guest reporter Julian 'Loomer' Figueroa
On the day of code release there is a nervous tension coming from the office of Matthew Paul. Matthew is the asset manager for Battlezone and is the person responsible for creating the gold, silver and the duplication master CDs that eventually go out to the four corners of the world for duplication. So on this momentous day that culminates the past two years of hard work, Matthew is kneeling next to the CD burner with a glazed look in his eye. Possibly his curent pose is due to the excitement of finishing up the project or, more likely, it's simply that Matthew hasn't been to sleep for the past forty-eight hours. On his knees with his head resting atop the CD Burner, he looks like a monk at prayer. Most on the team assume that the hours of staying up are getting to him, but if you look at the things that are involved in the life of the asset manager… you can begin to understand the plight of poor Matthew.
On the average day, you won't find Matthew quite as out of it. As the asset manager, Matthew is the proverbial glue that holds the Battlezone team together. Each day Matthew comes in and wakes the programmers up from their zombie states with a rousing version of TAPS played over the PA. He then proceeds to create the latest build of Battlezone incorporating all the new code, art and design issues that have been fixed or created since the last build. After creation, the build is sent off to quality assurance for testing and generation of bug reports.
However, it's not just about coming up with a new build to be tested each day. The asset man for Battlezone is much more of a Renaissance type. When Matthew has "free time" you can find him creating multiplayer maps, tweaking art for the game, helping play test and acting as the in house tech support for the entire team.
Another responsibility of Matthew is to make sure that the programmers are properly fed and taken care of. This usually involves administering a balanced and scientifically specific diet to the team. A typical meal for the average programmer is a mix of brine shrimp and other minute aquatic creatures. A qualified nutritionist must administer these meals or abnormal bugs tend to creep into the builds..
However, on this special day, Matthew is putting the finishing touches up on a second attempt at a master build. The previous attempt, which culminated with a gigantic ceremony involving several thousands pounds of pudding was finished at about 8:00 am. However, after all the fanfare a small defect had been found by quality assurance, thus bringing Matthew back from the confines of his comfy bed to begin work on yet another build.
The creation of a build is very intense and there are some rules that must be followed for the completion of a successful build. First, you absolutely under no circumstance must answer the phone if it rings. Second, the virgin is always the one killed during the making of a build… and lastly… oh wait.. sorry. That is the rules for Scream. When making a build, the computer must be primed and ready to go each time a new build is put together. This involves defragmenting the hard drive, checking for all known viruses and a number of other steps to insure that the build of the gold master is as pure as the wind driven snow. Now, after the tests and the CD has been burned onto a gold master CD, the CD is taken to Quality Assurance where they try their hardest to find bugs or errors.
After many hours of testing, the gold master CD spawns five other CD's: two more gold CD's, two Silver CD's and one Glass CD are then duplicated from the original gold master. These CD's will be offered up as prizes in the Activision three-legged race and egg toss, which are held at the Battlezone Release party. Actually they will be shipped off to various points of the globe so that the worldwide production of Battlezone can begin.
Now, returning to Matthew, sometime later in the day we find him much more alert and aware. The master CD, which he has made, has passed through the final testing of QA and the five master CD's are ready to begin worldwide production. With much fanfare, he can now return to the duties at hand. Some of the artists are causing a stir in their cubicles. It's past feeding time and they are starting to get edgy. So as Matthew grabs the kelp bucket and starts to head down that long hallway one more time, you can notice a little smile and an extra spring in his step. He knows that anxious gamers all over the world will soon have their very own copy of his gold master CD.

Simulation Interface Design

by Joseph Donaldson

Throughout the design process of Battlezone, the game has changed tremendously from the early prototypes. However, one thing has remained a constant in the equation: the fact that Battlezone would compromise neither its strategy nor its action roots. I had a chance to talk with George Collins, the lead designer for Battlezone, about the evolution of what OGR has called the “best interface ever created.” He had this to say of the origins and changes that came about along the way:

“Originally Battlezone was developed as an indoor game where it was top down and with very few units. The commands that you issued were all with function keys. For instance, to have your troops follow you, you would simply issue an ‘f1’ command. The important thing was that you were able to direct your troops as necessary while staying in the first person point of view.”

“As the game became more centered on the vehicular combat and entered an outdoor world utilizing the Interstate 76 engine, it became clear that more units would be involved in the game. Many games try to be hybrids, mixing genres, but they often compromise one aspect of the genre. With Battlezone it was important for the interface to be able to let you easily order your troops strategically while remaining in the fray of combat. That way you would get all of the immersiveness of being up close and personal in combat, while knowing that at a moment’s notice you could send in your wingman to help save your ass if you were in trouble”

“Originally we had the game set up where you would do most of the commanding from a ‘starmap’. (An overhead map similar to the Radar screen that is in the game now.) You basically controlled your units like a Command and Conquer style game, but you had the OPTION of joining in the fight. However, based on early feedback from playtesters, they felt that this made the game loose it’s immersive feel.

“So we restructured the game to allow for more ease of use and commands. Instead of limiting the number of units, we decided to limit their roles. Each unit was given a specific role as opposed to having units perform multiple tasks. For instance, you issued one command to the scavengers and they would know what to do. This helped free up the micromanagement immensely, and allowed us to put more of a focus on what everyone loves, the combat! It also surprisingly made the game much more strategic than we had envisioned. Instead of worrying about micromanagement of gathering of resources, you simply issued one basic command. So you could concentrate on directing your entire war effort with ease!”

For those of you that have played the demo, you know how easy it is to move your units around from anywhere on the battlefield. However this was one design issue that was well planned out from the beginning.

“In most RTS games you use a pointer interface. You select a unit, then select another place on the map to send it or another object with which the unit will interact. However, in a first person game you can’t see the whole map at one time. You can only see what you have in front of you. So it was very important that you could call up your units using the number keys, and then select the most common functions available to that specific unit and then issue your orders that way.”

For example, with the scavenger, you simply select from your list of units using the appropriate number and then have it simply collect scrap.

“Another interesting feature that was added late in the development of the game was a map which brought up the entire world. The wireframe map at the bottom, which came about near the second interface change, shows you a first person shot of where you are (which is fine for playing the single player games as the missions tend to point you in the right direction and it’s never really an issue to be able to see the whole map.) However, as we were playing multiplayer, it became important for there to be a map in which you could see everything and know where all of your units were. So if you hit the caps lock key, it brings up a world map which displays everything.”

As you can see, the interface design for a real time first person strategy game requires universal perspective and attention to detail. In next week’s installment, we will get a more in-depth look at some of the original concepts of yesterday’s game and how they have turned into the game that everyone is raving about today!

Interface Design

by Joseph Donaldson

This week we' re talking to the people who shaped much of the interface that will allow you to participate in the Battlezone world(s). First we chatted very briefly with Battlezone Lead Artist Carey Chico about the evolution of the game 'shell'. For those of you not up on your developer's lingo, this is the part of the interface outside the game sim from which you access the major components and options for the game (selecting the side you want to play, selecting playing modes, configuring game controls, etc.) and through which you move into and out of 'the actual game' - the 'sim'.

"I had already worked a lot with interface design before coming to Activision, so I already had some pretty well established ideas in my head for how a shell should work," Carey said. "We definitely wanted something that was quick and easy. Everything had to be streamlined. We also wanted every component of the shell to be consistent - everthing needed to work the same way. If the 'exit' button was in the top left of one screen, it should be in the top left on every screen. This makes the shell flow. The shell shouldn't be a game itself. You shouldn't have to spend time hunting around for the function you want on every screen."

"The look of the shell, with which we're very happy, actually came about in part as a result of an accident. Several months ago all the high-res art I was going to use for the shell was accidentally deleted from my hard drive."

(oops.)

"So we had to go back and do it again. This actually gave us the opportunity, however, to re-think everything. I kept seeing the images of the game 'reticles' (targeting cursors) in my mind, and their characteristics helped to shape the entire grid-like wireframe look of the shell. One this look became articulated, it seemed to me a natural choice to pour in the oodles and oodles of Battlezone green."

Note: we're working on getting some examples of the "old" and "new" interfaces for side-by-side comparison, but understandably the team is hesitant to show rejected designs. What do you think? Email us.

Code releasing the Demo

by Mike Arkin, BattleZone Producer

Well, the game demo is code-released. You'll find it in the April issue of PC Gamer.

That's not as simple as it sounds. First off, Activision doesn't always make a demo before the game ships, because in general we don't want to put something out that is less than what we consider to be the best we can do with the time we have. And that was the plan originally with Battlezone.

But we approached PC Gamer about making an exclusive cover demo for them and they were pretty interested, so we figured that we'd take what we had -- the game is pretty far along and definitely playable -- and put it together.

Unfortunately, it's a little tougher to make a demo than just taking the first two levels of a game and shipping it off to a magazine. We faced three main challenges:

First, we had to decide what to put into the demo. Naturally, we want people to see enough of the game so that they get excited, but not so much that they won't be interested in seeing the final product after we've put all that work into it. There are four training missions in the game. That's usually a lot for a demo but essential for Battlezone. These training missions allow players to gradually learn about this new genre, a game that requires strategic asset management and resource allocation and also puts you in an agile anti-gravity tank that is fully loaded with an arsenal of powerful weapons.

Because of the space limitation of the demo disc, we couldn't put all of the levels that are ready and playable now in the demo. Each level adds more vehicles and weapons, so we included the first two moon missions, which provide plenty of game variety. Players begin the level on foot, then they jump into one of four vehicles. Each of the vehicles -- the Razor, the Grizzly, Bobcat and Thunderbolt -- plays and handles completely differently, has a unique cockpit and players will learn which is best for a given situation by playing through all four. This is one of the things that makes Battlezone really unique -- you can pilot a variety of very different vehicles.

The second issue was the programming. We had to lock out the multiplayer mode from the code, omit later missions, include the intro movie and add the title and ending screens. This left the code a little more stripped-down than it is in the full version of the game, but the single-player gameplay is mostly unaffected. Programming was mostly handled by Linus Chen, our crack shell programmer. Linus had his hands full, because we also decided that this would be a good time to drop in our new shell. It was well worth it, because the new shell looks FANTASTIC!

Finally, we had to remove assets to bring the game down to the right size, about 50 MB, plus the 20 MB intro movie. Each structure, surface, sound and texture in the game is a unique file and Matthew Paul, our Asset Manager, had to decide which files to pull from the full version of the game, such as the Soviet units and textures, sound effects, etc.

After we pared the game down to a manageable size that will still provide an excellent introduction to Battlezone, we handed the game over to our Cross-Production team, who added the installer program. From there, it went to our Quality Assurance testing group for five or six days, during which time we fixed between 60 to 70 bugs, balanced the gameplay and optimized the missions.

Bugs are always an issue from both the players' standpoint and the game developers'. Our principle in getting this game demo out was to remove every bug we could find and to leave none which would adversely affect the gameplay. We're hoping that if there are bugs, gamers will want to let us know via the Web site or Usenet groups so that we can fix as much as possible. We'd rather have gamers testing the hell out of the game.

We're sure that the 3D card support is good and this game is a lot of fun to play. Look for it in the April issue of PC Gamer. In the meantime, though, be sure to look for our Internet demo right here next week ... and you should have seen what it took to get the Internet demo down to 20 MB!

We'll get back to you next week.

Activision is a registered trademark of Activision, Inc. ©: 1997 Activision, Inc. Battlezone is a trademark of Atari/JTS Corporation ©: 1980, 1997 Atari/JTS Corporation. All rights reserved. Licensed by Activision.