Inspiration
In August 1994 I had completed my PhD and in September went on a long vacation to Japan. When I returned I knew I would have several months before my job in Chicago would begin in early May. I had a Silicon Graphics Indy which I bought to finish my PhD. I had begun using GL for my PhD and I wanted to learn more about it. This would be an ideal way to do it. This gave me the time and the means and the motive. As for a deadline, there was the EVE-4 art show and the Silicon Graphics IndyZone3 Contest. The prize for the IndiZone contest was an Indy.But what kind of game to write?
Just as authors are encouraged to write about things they know about I felt I should make my game about something I know about. This helps give the work integrity.
I have always been a fan of TOHO Monster movies - Godzilla and other such creatures rampaging across Japan destroying everything in their path. One night I was watching my LaserDisc of Radon ('Rodan' in the US) and came upon the following scene ...
and there was the game ...
(note this is a capture from my personal copy of the Radon LaserDisc - TLL 2011)
Concept
Above is a quick drawing I made setting out the general look of the game.
The original idea was that you would play the army trying to destroy the monster and hence I called the game battalion. However as I thought about this some more it became clear that this was going to turn the game into a strategy game more than an arcade game since it would take time to control all your units. Playing the monster I could make an arcade game. I probably considered some other names briefly but none of them were contenders. I did a quick web search - since the web was so young it didnt take long, and couldnt find another game named battalion, so I decided to stick with it.
Back in the early 80s I had played am apple ][ game called 'Crush, Crumble, and Chomp' which was a strategy game where you picked one of several monsters (Giant Lizard, Giant Insect, Giant Octopus, Giant Robot, etc) and one of several cities (Tokyo, San Francisco, New York) and one of several goals (survival, destruction, etc) and you attacked the city until the army destroyed you. I enjoyed playing that game and thought that there was a good arcade game to be found here.
Even in this first drawing you can see ' the look' of battalion - the monster in the center of a plane with tanks shooting missilies and ballistic shells at him, which is basically what the scene from Radon was.
Implementation - Silicon Graphics and GL
The most important things to deal with up front were the limitations imposed by the hardware. The indy had a software z-buffer so z-buffering was available but slow. The graphics had 8-bit dithered colours. Transparency was possible but needed to be used sparingly. Software texture mapping was possible but it really slowed down the graphics. The CPU was 100 Mhz and the machine had 64 MB RAM. The machine could run its standard display in stereo and would talk to the StereoGraphics glasses to give desktop uesrs stereo. The machine could produce some pretty decent audio, and came with a camera. It was the first real 'multimedia' desktop workstation. This wasn't bad, especially for $10,000 at the time. The game needed to be written with this computer in mind as the platform.
I wrote the first version of battalion both as a CAVE game and as a desktop game.
Issues related to both versions:
This also had an effect on the game as the CAVE version would need to have 4 separate graphics processes runing independently from the computation process. Similarly the stereo desktop version would need 2 separate graphics processes running independently from the computation process.
The look of the monsters was very simple since I was creating them out of blocks and spheres and pyramids. I decided to give it a consistent 'childish' look, like it was a child playing with toy monsters and tanks, but the users never thought about it at that level, they just wanted to go blow things up.
I wanted to have sound and music, which meant learning how to deal with the SGI sound routines since I needed to have one music track as well as multiple sounds playing at the same time. The sounds I digitized from the actual films so they would be authentic. They were also really short to avoid copyright issues. The music I created with a guitar and a small drum. It was pretty bad. I wanted it to tie in with the 'child-like' nature of the graphics but since no-one understood that the music just sounded crappy.
I used data files to lay out the locations of all the objects (trees, buildings, starting positions of several tanks, etc) on the plane. This allowed me to build and alter the city easily. I could create simple structures like a beige cube with windows and then put those cubes together in different patterns to create different buildings. I also created specific buildings like a water tower and hangars and homes, and fast food restaurants for variety. I wanted the monster to be able to destroy parts of larger buildings without necessarily destroying the entire building. Ideally I would have made all the buildings out of many small objects but that overtaxed the machine so I compromised. I wasnt sure what people would want to destroy so I added in a variety of buildings. I felt that the user shoudl get points for destroying any kind of building but the user would get no credit for destroying trees.
There would be multiple monsters in the game (more on this below) and I wanted the terrain to affect the different monsters. Flying monsters can fly over low buildings but not tall ones. Gasseous monsters can move through anything. Tall monsters can't walk through anything (unless they blow it up first.)
I had thought that people would make their own cities and added text on how to do this into the data files, but very few people did this. I ocassionally thought of creating a tool to help with this but never did.
I didn't give the user the possibilitty of winning. I thought of having multiple levels with different towns, getting bigger and bigger, but the monster never (or perhaps rarely) won in those movies so it felt wrong to give the user the option of winning. Several users objected to this.
I started out with one monster, my cute red version of Godzilla. His 'googely' eyes would eventually give him the name 'Googelon.' The monsters were meant to be sympathetic so Googleon had big eyes and moved his legs like a wind-up toy. He had arms for a short time but they distracted from his appearance. Since the ground was going to be green the monster needed to have a high contrast and red worked out well. Googelon quickly became the mascot and the icon for the game.
Since the original inspiration for the game was Radon, there had to be a flying monster, so Flutter was born. Both Googelon and Flutter had beam weapons and I wanted something to have a particle weapon so the robot Techs was created. I also wanted something very different, a geseous monster, so the Vapour was created. I was personally never fond of playing the Vapour but he would turn out to be the favourite monster from those that have told me of their favourite on the web. I had several others planned but they only reached the drawing board stage. One would have been an insect that left webs behind to trap vehicles. Another was to be a rock (ala the 'Monolith Monsters') who could only fall over in the direction it wanted to go ... but I couldn't figure out how to make it fun. Another would have been a monster with multiple heads where several of the heads moved and attacked automatically and you controlled only one of the heads.
Flutter was interesting because getting him to fly, though this also meant he need to cast a shadow on anything under him. He didnt seem to look right while flying until I had him bank while he was turning. Flutter also gives the game its most 'cinematic' moments during the demo as he flies over the camera. I was really happy with that effect.
Monsters, military vehicles, and shells each have particular characteristics so that new ones of each type could be added easily.
Each monster is defined by its characteristics:
Each military vehicle is defined by its characteristics:
Each weapon (creature or army) has characteristics:
The miltiary vehicles would need to move on their own and act 'intelligently.' In general their strategy is to move towards the monster and stop at a point where they can attack. The vehicles turn towards the monster. If the vehicle is within range it will attack as often as possible. Most miltiary vehicles are on the ground (tanks.) Some miltiary vehicles ( helicopters) could fly at a low level, and then airplanes would fly at a high level. The tanks can not move through each other, and the helicopters can't move through each other. Having the miltary attack at different heights meant that they player would need to look up and down as well as around, making the game harder/more interesting for the player. The vehicles on the ground and at the low height have a specific radious so no other object at that level is allowed to move nearer than that radius to the vehicle. This means that for each iteration all of the vehicles that are outside their attack radius try to move forward. If they are not blocked they move forward - if they are blocked then they don't move. When enough vehicles are on the screen this gives a pleasing flocking behaviour, though I hadn't known I was implementing flocking at the time.
Originally the monster's health was given by a number (0-100) which is easy to program but not very easy to see at a glance. This was quickly changed to a health bar that is full (and green) when the monster is healthy then yellow and half fileld when the monster is hurt and finally red and almost empty when the monster is near death.
Issues for the CAVE version
In the desktop version you generally played the game from a location behind and above the monster allowing you to see what the monster would see. For the CAVE version you were the monster - no monster was drawn. This way the army was literally attacking you. You moved around with the joystick as usual, but how would you shoot? I decided to use the head tracking so you would shoot in the direction you were looking.
Issues for the desktop version
I liked how some videogames started out with the action going on so the user could watch and get the idea of the game from the game itself. I wanted to have that in my game. Since the military vehicles were already moving on their own, all I needed was to get the monster to move 'intelligently.' If the monster had more than its minimal energy it would move forward. If there is something interesting within its detection range then it would turn towards that interesting thing. It will prioritize its targets: first priority are the most powerful military vehicles, then the lesser military vehicles, and finally the buildings. If it is within attack range it will attack its target. While not overly sophisticated it does give a pleasing effect.
Since the game came from films, I wanted to add some 'cinematic' views. Instead of having just the single (useful) view from above and behind the monster I added two more views. One is an overview of the plane. The second is a view from the latest military vehicle to enter the scene. In the demo mode the views cycles through these three views giving the user a more dynamic view of the battle. The user can also pick any of these views during the game.
Due to various issues in the projections in the CAVE, fog can't be used. In the desktop game fog allowed the user to hide the edge of the plane. This is good because while the positions of the military vehicles are known throughout the entire (infinite) plane, the vehicles are only drawn when they are on the smaller finite plance. This means that the vehicles 'pop' in at the edge of the plane - the fog hides this. At the time the fog couldn't be used on the indys because it took too much graphics power.
When each of the monsters died something different would happen - Googelon falls over and stops moving. Techs tips over and explodes; Flutter falls to the ground and bursts into flames, and the Vapour slowly goes transparent. As a little cinematic bonus I wanted to have Techs' solar panels to fly off in an interesting way when he exploded. When techs explodes its solar panels fly off in a predetermined direction to match the spin of the camera so one of the panels flies by the camera.
There were some problems to deal with
With a finite town on an infinite plane the player can get lost and not know how to get back to the town. The way around this was to add an arrow on the ground pointing back to the center of town when the user gets too far away.
The enemies need to get stronger so the game gets harder as it goes on. This was solved in several ways. Each time the military shoots there is an accuracy associated with the shot based on the time the game has progressed. This accuracy improves as the game goes on. Each type of vehicle spawns at a certain rate. As the game preogresses the vehicles spawn faster. More powerful vehicles also begin spawning as the game goes on. All of the military vehicles came from the movies - the standard tanks and helicopters. The high-level bombers. The maser tanks and the high-tech hovering monster killing machine ala the Super-X. The monster's final 'enemy' was Ultraman (or one of his kind anyway) which introduced the first humanoid character into the game. I thought this was a nice twist to make Ultraman the bad guy, but it also meant creating a character that could walk and do poses with his arms to fire his weapon.
The final version(s)
The CAVE game appeared in the EVE 4 art show. The dekstop game won the IndiZone 3 contest and suddenly I had a second Indy, and a cute clock.
The version that was made available on the IndiZone 3 CDROM was slightly different from my version so I decided to release the 'director's cut' on my web site.
From August '95 through January '96, battalion was downloaded over 7000 times from over 4000 unique locations. Almost 50% of the downloads come from the U.S., another 6% from the U.K., 4% from Germany and Canada, 3% from Japan, 2% from Sweden and Australia.battalion was also downloaded from: Argentina, Australia, Austria, Belgium, Bahrain, Brazil, Chile, Colombia, Croatia, Czech Republic, Denmark, Dominican Republic, Estonia, Finland, France, Greece, Hong Kong, Hungary, Ireland, Israel, India, Iceland, Italy, Latvia, Luxembourg, Mexico, Malaysia, Netherlands, Norway, New Zealand, Poland, Portugal, Romania, Russian Federation, Singapore, Slovenia, South Africa, South Korea, Spain, Sweden, Switzerland, Thailand, Taiwan, Turkey, Ukraine, United Arab Emirates)
Overall I was very pleased with the game. I had become rtrher proficient at writing and optimizing OpenGL code, I had a new indy, and the game was popular.
Revision - OpenGL
By 1996 the Silicon Graphics specific GL was replaced by the more generic OpenGL which was avaialble for multiple platforms, though usually at a cost. A free version of OpenGL was created and called Mesa, making OpenGL avaialble for almost every platform. This created the right environment to finally take the time to update battalion to OpenGL.
The major changes that need to be made involved the I/O interfaces. GL had built-in window, mouse, and keyboard functions. These were now accessed through external routines such as tk and aux.
Since the software was going to need some rewriting anyway, it seemed like a good time to update the game.
I decided that it would be good to have multiple monsters in the game at the same time. This would allow a networked version of the game and a more interesting single player version of the game. Since I already had the various monsters I set a new timer for how often a new monster could appear on the plane. This monster would use the same 'demo' movements that I already had. The only major change needed to the source code was to have the miltiary vehicles attack the nearest monster to them.
I also added on a couple more vehicles for variety - the missile firing trucks (from the original Radon clip) and a fast moving fishter with missiles to complement the bomber.
I added on a high score list that keeps track of the high score for each monster. The demo part of the game was eligible for a place on the high score list.
The networking was pretty rudimentary but it would allow multiple players to each pick a monster and fight either as a team or try and destroy each other.
I decided to fix the music and add a modified version of the score from the first Godzilla film to create the corect mood of the films rather than the 'child-like' mood I had initially wanted. This put me rather close to copyright issues, but since I've never made any money off of the game I felt it was OK.
With the OpenGLdesktop version working, I then reported the OpenGL version to the CAVE. I also changed the CAVE version - the biggest difference there was that the monster was now visible in the CAVE. In the original CAVE version, many people wanted to know 'what they looked like' as the monster, so now this gave them a way to do that, though it meant the player was now controlling the monster rather than being the monster.
The final version(s)
In 1997 I submitted battalion to Silicon Graphics' Creator contest where it won again, and was availableon the Hot Mix 17 CDROM. By this time SGI was being a little less generous in their contests so I only won a Nintendo 64.
Now the OpenGL version joined the GL version as a download on my web page and was soon joined by the source code for the game. This was back in the days when we called it 'freeware' before the term 'OpenSource' was invented. Putting the source code on the net allowed other people to make the game work on their systems.
Expansion - beyond Silicon Graphics
Just as GL gave way to OpenGL, tk and aux gave way to GLUT, so the interface routines needed to be rewritten slightly again, but this allowed for graphical menus and an easier way to change parameters.
With OpenGL and GLUT, battalion was quickly ported to other platforms (the * show which versions I did personally):
The GeoWall and back to 3D
The stereo visual code has been sitting dormant inside the desktop version since the code was converted to OpenGL, with no good way to deploy it. The AGAVE / Geowall made it possible to update the stereo code and play the game in the form that it was intended.
The final exam