Maverick Development Diary
Note: This was originally written sometime in 2005 back when the project was completed. I'm actually kinda surprised at how detailed it is...
Maverick: An Inside Look at n00b Game Design
As of August 5, 2005, the project that 5 computer science students at the University of Texas at Arlington have been working on is finished. It is a first person, non-violent “paintball” shooter (an oxymoron some of you will say) set inside Nedderman Hall, the building on our campus where, not coincidentally, most of our computer science classes are located. This document aims to outline some of the high points and pitfalls associated with this project, and chronicle the entire lifecycle of the project.
The Beginning
The project was originally assigned way back in late January 2005. At the time, there were like 10 people that wanted to work on the project (teams could only be groups of 5). So we had to draw names to decide who would actually work on the project. At first, I didn’t even get my name drawn so I was originally supposed to work on a PowerPoint plug-in of all things, but a guy who did have his name drawn offered to switch with me. So there I was, on the road to game development.
Now the ideal situation probably would’ve been to have complete creative control when it came to the idea behind the game. We probably would’ve come up with some off the wall, creative concept that could only come from the minds of twisted 22-23 year olds. It would’ve probably been the next great 2D shooter on a budget, in the spirit of Alien Hominid (if you get a chance, go play that game. Now). It would’ve been the most awesomest of awesome low budget games, with maybe low detail graphics but at least an interesting concept to get by with. But the game had to actually have a purpose: teach people about UTA, and show them what kind of cool projects computer science students do there. Ok, I guess that makes sense. It’d be a bit silly to expect your average university to give students complete creative control over the content of a video game, but a guy can dream right? Anyhow, this sort of taught us one parallel with the game industry: dealing with a publisher. Except in this case, the publisher is represented by a professor in the Computer Science department. She had all these incredible ideas in mind about having almost the whole campus represented, all sorts of interactive mission objects, cars, fully modeled campus landmarks, lots of NPC’s (like random students walking around), multiple school mascots as the enemies, and basically tons of other things that didn’t end up in our game at all. Haha. Now, when we first were assigned the project, we threw around the idea of creating a game engine from scratch. We quickly realized that that would’ve been a full project itself, so we got rid of that idea (would’ve been cool though). So early on, we decided we would end up using an already existing game engine. But we didn’t have a requirements definition yet, so we didn’t know which engine to pick…
The Design Document
Over the course of a about a month, our design document (or requirements document) was laid out. To anyone familiar with software development, the requirements document pretty much details everything that should go into the project you’re working on. You don’t really mention “how” things are going to be done, but rather “what” things are going to be done. For our project’s document, we described the purpose of our project, what kind of project it was, what the menu’s look like, who the players control, what enemies there are, how many hit points they have, what sounds they make, and pretty much every single thing that would eventually go into the game. We intentionally aimed pretty low when it came to complexity, because we all were pretty inexperienced, and we didn’t want to promise the world and not deliver anything. We even had a guy on our team who barely even plays video games so that obviously limited things even more.
The basic ideas we kept in mind from all of our “publisher’s” requirements was that the heroes of the game were our school’s mascots, the enemies in the game were from other schools, and that it took place on campus. Early on, we toyed with the idea of making things like Quake 3 Arena: some sort of rumble pit to decide which school mascot was the best…it would be 1 on 1 (or maybe 2 on 1) battles between our school’s mascots, and a ladder of other school’s mascots. Beat all the mascots, you beat the game. But we decided that was a little too basic. So we decided to go the traditional story progression route. And I use the term “story” very loosely. Basically, one school comes into our building, steals something valuable to us, and we have to go get it back. Truly epic storytelling rivaling the best that Hollywood has to offer. Ahem.
The school we decided to make our enemy was Texas A&M (which would later get renamed to avoid any potential copyright issues) and the item stolen to be the “Hall of Flags”, which is basically a bunch of flags from different countries mounted on the ceiling, and used to represent multiculturalism and unity at UTA. Or something. We hammered out all of our other requirements concerning the game and presented them to the class (and our professor) for review. We passed on our first try.
Choosing a Game Engine
When deciding on what engine to use, we knew that we needed something relatively easy to use, that could help us get a basic first person shooter done fast. Now, there is a difference between a 3D engine, and a game engine. A 3D engine would pretty much only deal with the graphics side of things, while a game engine would (hopefully) encompass graphics, audio, physics, input processing, AI, etc. As you might expect, we wanted the latter. What we ended up doing was to go down our list of requirements, and assign them points depending on their importance. Something important (should render 3D graphics) would get assigned a value of 3, while unimportant items (works on Linux…no offense to the Linux users out there) would get assigned a value of 1. Then we’d take the engines we had researched, and if they satisfied the requirement, they’d get the points for it. Whoever had the most points would be considered for use. The Torque Game Engine, 3D Game Studio, Crystal Space, Ogre3D, and the Reality Engine were initially researched. We would end up using Torque (www.garagegames.com) due to its extensive community, all-encompassing engine, lenient license, built-in tools, and relatively cheap price. The fact that it was already used in a popular first person shooter (Tribes 2) didn’t hurt either. Once again, we presented our comparison to the class and professor, with demos of each one. We passed our review, and were now ready to develop. At this point, it was about mid-June, with about a month and a half left to go in the project. We had our list of requirements though, and we were ready to go.
Starting development
Oddly enough, actually building the game took the least amount of the total class time. We were basically stuck in “planning” for 5-6 months, and didn’t start building the actual game until the last month or so. It also didn’t help that there were some delays with ordering the engine, so we worked with a demo version with limited knowledge (the full documentation is included when you actually get the license to the engine). So we started around the end of June, and planned out a schedule. We told ourselves by July 19th, that we would at least have the first level fully playable and ready. By July 19th, we…sort of had things ready. There were 5 people on the team, so things were split up like so:
My part on the project was the programming for the player and doing some of the audio work. Programming for the players wasn’t anything too difficult, although it simply took a lot of tweaking. There was lots of adjusting values, loading up the game and playing with it, readjusting, reloading, so on and so forth. For example, the character’s initially had somewhat “floaty” Halo-like jumping. I thought it was kind of cool, because I envisioned the player jumping into the air, shooting like 5 enemies before he/she even landed. Our levels were somewhat enclosed though, so that wouldn’t have really made much sense, so I toned it down. Also, I wanted the player speed to be somewhat midrange, and I think I eventually accomplished that pretty well. I also had to work on other unglamorous things such as setting health values, detailing how the player responded to damage, what happens when he/she dies, what happens when he collides with an item, etc. Nothing one would immediately see and go “that sounds fun!” but definitely important parts of the game that required their own unique set of solutions. Thankfully, the Torque scripting language made this process somewhat painless, as it didn’t require time wasting recompiles just to test minor changes. For the sound effects, I decided to do my best cowboy impersonation and do the voice of the main male character. For the female character I pretty much took that same male character, tweaked the pitch and added a couple effects. Quick and dirty, but it got the job done I suppose.
Our interface design was relatively basic. For the main menu, one would be able to start the game, view a help menu, view and change different settings, or quit. A similar pause menu would be included in the game also. There would be a basic numeric health meter, armor meter, and ammo counter at the bottom of the screen, with icons next to each one, and a school logo on screen at all times. Once again, nothing fancy, but I think our “GUI guy” did a great job considering this was his first time ever working on anything game related.
Our level designer was really the only other guy on our team who had some sort of experience with game development, and I think it actually shows. He did a pretty good job recreating the layout of the building and made things “mazy” enough to keep the level somewhat interesting. There’s an event at our school called “E-Week”, where presenters come and set up booths in the main hall, so that’s where the idea of all those blue walls came from. Sort of a cheesy way to extend the length of the level, but it worked. And I think he quite possibly put the most beautifully textured vending machines I’ve ever seen in a game, haha. He was also the only one who had any art skills, so we thank him for all the wonderful icons in our game.
Our 3D Modeler actually had zero modeling experience, but being the trooper that he is, tried anyway. He used a cheap 3D modeling program called Milkshape to make everything. He initially experimented with creating the enemy models from scratch, but ended up using ones from a book we had, which was the smart thing to do. No use trying to recreate the wheel…especially if you’re not much of a “wheelmaker” to begin with, heh. He did do the models for the weapons from scratch, and created an absolutely hilarious looking final boss that we all enjoyed.
To be honest, we may have been a bit too optimistic in giving the least experienced person (when it comes to games at least) on our team the AI and weapon coding job. We knew that we weren’t going to do AI and weapons from scratch anyway (we used some code already made available by the Torque community), so we thought it wouldn’t be too difficult to implement it into our game. Unfortunately, since he didn’t really have much experience even playing video games, that kind of limited him. All of the genre conventions and terms that everyone else took for granted were completely new to him, so he basically had to learn about video games while making one. He did try though (he bugged me all the time with questions, haha), so I can’t fault him too much, but this field is just not for him. He even said it himself, “I’m never touching game development again”. We would obviously end up getting some basic AI and weapons in the final game, so it did eventually get done…just not as quick as we’d hoped.
Our demo that we wanted to have by July 19th? Didn’t happen. We had a level done, a player in it, a basic menu, and some items, but we still didn’t have our HUD, AI, or properly behaving weapons. We initially thought about showing an early demo in front of the class, but we ended up scrapping that idea, as I don’t think we were really confident in the product we had at that point. We would eventually demo what we had of the game to our “publisher” on Monday, July 24th. She was impressed with a few parts of it, but you could tell there was a bit of disappointment...a lot of our features we had on our requirements still weren’t implemented, and the ones that were implemented were at a very basic level at that point. She gave us suggestions which were geared more towards her original vision of the game as far as having things more interactive, and having more info about our school in the game, but we knew that the majority of her suggestions couldn’t get implemented in the timeframe that we had. Thankfully, she understood this too, so she wasn’t too hard on us. She said she kind of wanted this to be a project worked on by multiple groups, so future classes would simply build from our base. So this gave us a little confidence, knowing that we just needed to make a decent foundation to build from, and we’d be ok.
The Home Stretch
Going back a bit, what we did end up doing on July 19th was schedule the rest of our project. This included the final two levels, the final boss, and obviously, completing the full game. Everyone had pretty similar tasks for this last stage of development, so we at least (at that point) had experience on our side. At this point, I was sort of a “technical lead” on the project as I had the most experience with it, and I picked up on the general layout of the engine much faster. So I would assist my other teammates with any questions, and just in general try to make their job easier. In game development, I would imagine that the programmer’s job is to make the artists and designers job much easier, and I feel that I accomplished that during the last few weeks of the project. My other tasks during this time was to do the basic AI for our final boss, and also do a bit of design work and populate all of our levels with enemies, items, and weapons. So I would just go through the in-game mission editor, placing spawn points for everything, and then write the corresponding code to load things in. I mostly just tried to get a feel for pacing and rewarding the player at just the right time. With the enemy location, I tended to go for “strength in numbers” since I knew our AI wasn’t really anything special (the Serious Sam school of game design), which probably was the best thing for our game, considering our limitations. Since we had a lot of hallways in our game (some leading to dead ends) I would place an enemy at the end to keep players on their toes, or place an item so the player at least gets some kind of reward for going down yet another dead end, heh.
The final boss was in the game wasn’t too difficult to program as we once again took an old-school approach to game design: give it a crapload of hit points, and have it be 4-5 times the size of the player. So as long as you keep dodging, you can avoid damage, and you just have to unload all your ammo into the boss. Pretty simple stuff, but this was one area where atmosphere kind of helped. Our level designer made things somewhat dark and spooky, and our 3D Modeler made the boss evil-looking but at the same time absurd, so there was a bit of dread, yet humor involved in the level that adds to its charm. At the last minute, I thought it’d be an interesting twist to have it rain during the level, so I added that in, played a looping 30 second rainstorm sound effect and everything was golden. Add the boss constantly shooting at you, and you get a somewhat intense boss battle. The final level is actually the part I’m impressed with the most…of course, I’m biased. Unfortunately, the final level also includes the one major bug in our game. For some reason (and my theory is because of the way Torque processes/loads 3D models) the game randomly freezes when the boss is added. It doesn’t happen all the time, but it’s happened and I couldn’t completely fix it. Also, for some reason the firing point for the boss doesn’t always get set correctly so it ends up not even shooting at the player. Once again, it seems to happen completely randomly, but it’s annoying nonetheless. Besides that, the game itself was pretty stable. I also added some old songs I made to the title screen at the last minute just to spice things up a little. Everything else in our game was pretty much done also around August 1st, much improved compared to the version we had shown just a week and a half before. We pretty much just had some minor interface issues and bugs to work on. So on August 4, 2005, we decided to call that version of Maverick final. In industry terms, “we went gold”.
Judgment Day: August 5, 2005
On the night of August 4, we still had to come up with a presentation for our product. We hammered that out in about a couple hours, and then also each came up with documentation for our part of the project, and some ideas that could be added or expanded on in the future. Both of these were for the groups that will work on the project in the future. On August 5, 2005, we set up our booth and unveiled Maverick for the first time to the public at 10 a.m. I have to admit, seeing other people play your product for the first time and actually get some enjoyment out of it was a great feeling. A lot of the other students in our class got some laughs out of the game and gave us props for our work on it. Around 1:45 p.m., we did our presentation and demoed the game in front of an audience, which managed to once again get some laughs, and to be honest, that’s what we were going for. It may not be the most advanced game in the world, but if it plays well and gets some laughs out of you, we think we did our job. As far as our original design document/requirements definition, we pretty much fulfilled all of the major ones, so we were happy about that. There were always suggestions from other students and professors about places and things that should’ve been added to the game, but we stayed focused on what we had, and I think that made the project work better. The dreaded “feature creep” never affected us. We took a realistic approach to the project, took into account our experience levels, and still managed to make something that put a smile on everyone’s face. Hey, no complaints here.
Maverick: An Inside Look at n00b Game Design
As of August 5, 2005, the project that 5 computer science students at the University of Texas at Arlington have been working on is finished. It is a first person, non-violent “paintball” shooter (an oxymoron some of you will say) set inside Nedderman Hall, the building on our campus where, not coincidentally, most of our computer science classes are located. This document aims to outline some of the high points and pitfalls associated with this project, and chronicle the entire lifecycle of the project.
The Beginning
The project was originally assigned way back in late January 2005. At the time, there were like 10 people that wanted to work on the project (teams could only be groups of 5). So we had to draw names to decide who would actually work on the project. At first, I didn’t even get my name drawn so I was originally supposed to work on a PowerPoint plug-in of all things, but a guy who did have his name drawn offered to switch with me. So there I was, on the road to game development.
Now the ideal situation probably would’ve been to have complete creative control when it came to the idea behind the game. We probably would’ve come up with some off the wall, creative concept that could only come from the minds of twisted 22-23 year olds. It would’ve probably been the next great 2D shooter on a budget, in the spirit of Alien Hominid (if you get a chance, go play that game. Now). It would’ve been the most awesomest of awesome low budget games, with maybe low detail graphics but at least an interesting concept to get by with. But the game had to actually have a purpose: teach people about UTA, and show them what kind of cool projects computer science students do there. Ok, I guess that makes sense. It’d be a bit silly to expect your average university to give students complete creative control over the content of a video game, but a guy can dream right? Anyhow, this sort of taught us one parallel with the game industry: dealing with a publisher. Except in this case, the publisher is represented by a professor in the Computer Science department. She had all these incredible ideas in mind about having almost the whole campus represented, all sorts of interactive mission objects, cars, fully modeled campus landmarks, lots of NPC’s (like random students walking around), multiple school mascots as the enemies, and basically tons of other things that didn’t end up in our game at all. Haha. Now, when we first were assigned the project, we threw around the idea of creating a game engine from scratch. We quickly realized that that would’ve been a full project itself, so we got rid of that idea (would’ve been cool though). So early on, we decided we would end up using an already existing game engine. But we didn’t have a requirements definition yet, so we didn’t know which engine to pick…
The Design Document
Over the course of a about a month, our design document (or requirements document) was laid out. To anyone familiar with software development, the requirements document pretty much details everything that should go into the project you’re working on. You don’t really mention “how” things are going to be done, but rather “what” things are going to be done. For our project’s document, we described the purpose of our project, what kind of project it was, what the menu’s look like, who the players control, what enemies there are, how many hit points they have, what sounds they make, and pretty much every single thing that would eventually go into the game. We intentionally aimed pretty low when it came to complexity, because we all were pretty inexperienced, and we didn’t want to promise the world and not deliver anything. We even had a guy on our team who barely even plays video games so that obviously limited things even more.
The basic ideas we kept in mind from all of our “publisher’s” requirements was that the heroes of the game were our school’s mascots, the enemies in the game were from other schools, and that it took place on campus. Early on, we toyed with the idea of making things like Quake 3 Arena: some sort of rumble pit to decide which school mascot was the best…it would be 1 on 1 (or maybe 2 on 1) battles between our school’s mascots, and a ladder of other school’s mascots. Beat all the mascots, you beat the game. But we decided that was a little too basic. So we decided to go the traditional story progression route. And I use the term “story” very loosely. Basically, one school comes into our building, steals something valuable to us, and we have to go get it back. Truly epic storytelling rivaling the best that Hollywood has to offer. Ahem.
The school we decided to make our enemy was Texas A&M (which would later get renamed to avoid any potential copyright issues) and the item stolen to be the “Hall of Flags”, which is basically a bunch of flags from different countries mounted on the ceiling, and used to represent multiculturalism and unity at UTA. Or something. We hammered out all of our other requirements concerning the game and presented them to the class (and our professor) for review. We passed on our first try.
Choosing a Game Engine
When deciding on what engine to use, we knew that we needed something relatively easy to use, that could help us get a basic first person shooter done fast. Now, there is a difference between a 3D engine, and a game engine. A 3D engine would pretty much only deal with the graphics side of things, while a game engine would (hopefully) encompass graphics, audio, physics, input processing, AI, etc. As you might expect, we wanted the latter. What we ended up doing was to go down our list of requirements, and assign them points depending on their importance. Something important (should render 3D graphics) would get assigned a value of 3, while unimportant items (works on Linux…no offense to the Linux users out there) would get assigned a value of 1. Then we’d take the engines we had researched, and if they satisfied the requirement, they’d get the points for it. Whoever had the most points would be considered for use. The Torque Game Engine, 3D Game Studio, Crystal Space, Ogre3D, and the Reality Engine were initially researched. We would end up using Torque (www.garagegames.com) due to its extensive community, all-encompassing engine, lenient license, built-in tools, and relatively cheap price. The fact that it was already used in a popular first person shooter (Tribes 2) didn’t hurt either. Once again, we presented our comparison to the class and professor, with demos of each one. We passed our review, and were now ready to develop. At this point, it was about mid-June, with about a month and a half left to go in the project. We had our list of requirements though, and we were ready to go.
Starting development
Oddly enough, actually building the game took the least amount of the total class time. We were basically stuck in “planning” for 5-6 months, and didn’t start building the actual game until the last month or so. It also didn’t help that there were some delays with ordering the engine, so we worked with a demo version with limited knowledge (the full documentation is included when you actually get the license to the engine). So we started around the end of June, and planned out a schedule. We told ourselves by July 19th, that we would at least have the first level fully playable and ready. By July 19th, we…sort of had things ready. There were 5 people on the team, so things were split up like so:
- Interface design (menus, heads up display, etc.)
- Player and Item programming and Audio (programming related to the heroes and powerups, voices)
- Enemy and weapon programming (AI, code for weapons and how they behave)
- Level Design and 2D art (Nedderman Hall levels, GUI icons, cutscenes)
- 3D Modeler (player, enemies, weapons, signs, whatever)
My part on the project was the programming for the player and doing some of the audio work. Programming for the players wasn’t anything too difficult, although it simply took a lot of tweaking. There was lots of adjusting values, loading up the game and playing with it, readjusting, reloading, so on and so forth. For example, the character’s initially had somewhat “floaty” Halo-like jumping. I thought it was kind of cool, because I envisioned the player jumping into the air, shooting like 5 enemies before he/she even landed. Our levels were somewhat enclosed though, so that wouldn’t have really made much sense, so I toned it down. Also, I wanted the player speed to be somewhat midrange, and I think I eventually accomplished that pretty well. I also had to work on other unglamorous things such as setting health values, detailing how the player responded to damage, what happens when he/she dies, what happens when he collides with an item, etc. Nothing one would immediately see and go “that sounds fun!” but definitely important parts of the game that required their own unique set of solutions. Thankfully, the Torque scripting language made this process somewhat painless, as it didn’t require time wasting recompiles just to test minor changes. For the sound effects, I decided to do my best cowboy impersonation and do the voice of the main male character. For the female character I pretty much took that same male character, tweaked the pitch and added a couple effects. Quick and dirty, but it got the job done I suppose.
Our interface design was relatively basic. For the main menu, one would be able to start the game, view a help menu, view and change different settings, or quit. A similar pause menu would be included in the game also. There would be a basic numeric health meter, armor meter, and ammo counter at the bottom of the screen, with icons next to each one, and a school logo on screen at all times. Once again, nothing fancy, but I think our “GUI guy” did a great job considering this was his first time ever working on anything game related.
Our level designer was really the only other guy on our team who had some sort of experience with game development, and I think it actually shows. He did a pretty good job recreating the layout of the building and made things “mazy” enough to keep the level somewhat interesting. There’s an event at our school called “E-Week”, where presenters come and set up booths in the main hall, so that’s where the idea of all those blue walls came from. Sort of a cheesy way to extend the length of the level, but it worked. And I think he quite possibly put the most beautifully textured vending machines I’ve ever seen in a game, haha. He was also the only one who had any art skills, so we thank him for all the wonderful icons in our game.
Our 3D Modeler actually had zero modeling experience, but being the trooper that he is, tried anyway. He used a cheap 3D modeling program called Milkshape to make everything. He initially experimented with creating the enemy models from scratch, but ended up using ones from a book we had, which was the smart thing to do. No use trying to recreate the wheel…especially if you’re not much of a “wheelmaker” to begin with, heh. He did do the models for the weapons from scratch, and created an absolutely hilarious looking final boss that we all enjoyed.
To be honest, we may have been a bit too optimistic in giving the least experienced person (when it comes to games at least) on our team the AI and weapon coding job. We knew that we weren’t going to do AI and weapons from scratch anyway (we used some code already made available by the Torque community), so we thought it wouldn’t be too difficult to implement it into our game. Unfortunately, since he didn’t really have much experience even playing video games, that kind of limited him. All of the genre conventions and terms that everyone else took for granted were completely new to him, so he basically had to learn about video games while making one. He did try though (he bugged me all the time with questions, haha), so I can’t fault him too much, but this field is just not for him. He even said it himself, “I’m never touching game development again”. We would obviously end up getting some basic AI and weapons in the final game, so it did eventually get done…just not as quick as we’d hoped.
Our demo that we wanted to have by July 19th? Didn’t happen. We had a level done, a player in it, a basic menu, and some items, but we still didn’t have our HUD, AI, or properly behaving weapons. We initially thought about showing an early demo in front of the class, but we ended up scrapping that idea, as I don’t think we were really confident in the product we had at that point. We would eventually demo what we had of the game to our “publisher” on Monday, July 24th. She was impressed with a few parts of it, but you could tell there was a bit of disappointment...a lot of our features we had on our requirements still weren’t implemented, and the ones that were implemented were at a very basic level at that point. She gave us suggestions which were geared more towards her original vision of the game as far as having things more interactive, and having more info about our school in the game, but we knew that the majority of her suggestions couldn’t get implemented in the timeframe that we had. Thankfully, she understood this too, so she wasn’t too hard on us. She said she kind of wanted this to be a project worked on by multiple groups, so future classes would simply build from our base. So this gave us a little confidence, knowing that we just needed to make a decent foundation to build from, and we’d be ok.
The Home Stretch
Going back a bit, what we did end up doing on July 19th was schedule the rest of our project. This included the final two levels, the final boss, and obviously, completing the full game. Everyone had pretty similar tasks for this last stage of development, so we at least (at that point) had experience on our side. At this point, I was sort of a “technical lead” on the project as I had the most experience with it, and I picked up on the general layout of the engine much faster. So I would assist my other teammates with any questions, and just in general try to make their job easier. In game development, I would imagine that the programmer’s job is to make the artists and designers job much easier, and I feel that I accomplished that during the last few weeks of the project. My other tasks during this time was to do the basic AI for our final boss, and also do a bit of design work and populate all of our levels with enemies, items, and weapons. So I would just go through the in-game mission editor, placing spawn points for everything, and then write the corresponding code to load things in. I mostly just tried to get a feel for pacing and rewarding the player at just the right time. With the enemy location, I tended to go for “strength in numbers” since I knew our AI wasn’t really anything special (the Serious Sam school of game design), which probably was the best thing for our game, considering our limitations. Since we had a lot of hallways in our game (some leading to dead ends) I would place an enemy at the end to keep players on their toes, or place an item so the player at least gets some kind of reward for going down yet another dead end, heh.
The final boss was in the game wasn’t too difficult to program as we once again took an old-school approach to game design: give it a crapload of hit points, and have it be 4-5 times the size of the player. So as long as you keep dodging, you can avoid damage, and you just have to unload all your ammo into the boss. Pretty simple stuff, but this was one area where atmosphere kind of helped. Our level designer made things somewhat dark and spooky, and our 3D Modeler made the boss evil-looking but at the same time absurd, so there was a bit of dread, yet humor involved in the level that adds to its charm. At the last minute, I thought it’d be an interesting twist to have it rain during the level, so I added that in, played a looping 30 second rainstorm sound effect and everything was golden. Add the boss constantly shooting at you, and you get a somewhat intense boss battle. The final level is actually the part I’m impressed with the most…of course, I’m biased. Unfortunately, the final level also includes the one major bug in our game. For some reason (and my theory is because of the way Torque processes/loads 3D models) the game randomly freezes when the boss is added. It doesn’t happen all the time, but it’s happened and I couldn’t completely fix it. Also, for some reason the firing point for the boss doesn’t always get set correctly so it ends up not even shooting at the player. Once again, it seems to happen completely randomly, but it’s annoying nonetheless. Besides that, the game itself was pretty stable. I also added some old songs I made to the title screen at the last minute just to spice things up a little. Everything else in our game was pretty much done also around August 1st, much improved compared to the version we had shown just a week and a half before. We pretty much just had some minor interface issues and bugs to work on. So on August 4, 2005, we decided to call that version of Maverick final. In industry terms, “we went gold”.
Judgment Day: August 5, 2005
On the night of August 4, we still had to come up with a presentation for our product. We hammered that out in about a couple hours, and then also each came up with documentation for our part of the project, and some ideas that could be added or expanded on in the future. Both of these were for the groups that will work on the project in the future. On August 5, 2005, we set up our booth and unveiled Maverick for the first time to the public at 10 a.m. I have to admit, seeing other people play your product for the first time and actually get some enjoyment out of it was a great feeling. A lot of the other students in our class got some laughs out of the game and gave us props for our work on it. Around 1:45 p.m., we did our presentation and demoed the game in front of an audience, which managed to once again get some laughs, and to be honest, that’s what we were going for. It may not be the most advanced game in the world, but if it plays well and gets some laughs out of you, we think we did our job. As far as our original design document/requirements definition, we pretty much fulfilled all of the major ones, so we were happy about that. There were always suggestions from other students and professors about places and things that should’ve been added to the game, but we stayed focused on what we had, and I think that made the project work better. The dreaded “feature creep” never affected us. We took a realistic approach to the project, took into account our experience levels, and still managed to make something that put a smile on everyone’s face. Hey, no complaints here.