Milestone 4 Paper Group 3 Auto Destructica 12/7/2008. Taylor Arnicar Michael Murray Caleb Carlton Andrew Deem Bryan Kim

Transcription

1 Milestone 4 Paper Group 3 Auto Destructica 12/7/2008 Taylor Arnicar Michael Murray Caleb Carlton Andrew Deem Bryan Kim

2 Auto Destructica is an exciting driving game loaded with fast-paced shooting action. You play the role of a convicted criminal, tired of being pinned down by the oppression of the law. After stealing a sturdy gray truck you embark on your escape to freedom, fleeing from the police and hired bounty hunters. At first your only tool at your disposal is a weak pistol, capable of fending off weaker enemies but not strong enough to defend you on your perilous journey. While your truck is sturdy enough to bolt on extra weapons, they aren't always easy to obtain. Along your way enemy vehicles will drop pieces of valuable scrap metal that can be traded in at garages for weapon installation. Not all enemies will drop these valuable pieces nor are garages easy to reach, forcing you to budget your resources while simultaneously maintaining your offense against your captors. Along the way you'll encounter different levels, with scenery varying from downtown highways to desert dirt roads. They are navigated through use of the keyboard, employing common WASD controls. Weapons, once more are available, can be switched with the number keys while the missile launcher also incorporates the mouse cursor for advanced aiming. Meaningful Play The key components to meaningful play in a game of any genre is the ability to make choices and experience consequence, giving the player a visible relationship between decision and outcome. By allowing the player to make choices they are able to transform the game into an experience, separating it from static media such as a film, TV show or magazine. Choice allows the player to experience the game in a unique way each time, letting them feel as if they are the factor that changes that experience from session to session. That was one of our main goals with AD. Side-scrolling shooters are not a unique medium and are one that is often very formulaic and repetitive. With AD we hoped to add both elements that are random and will change for the player even if they play the same way each time, while also adding elements that are player dependent. The main components to that are weapon selection and vehicle upgrades. The player starts with a baseline vehicle that, although capable of allowing the player to advance initially, does not allow for much advanced strategy or a very long game play session. Upgrades become available as the player progresses but are presented in a way that is dependent on player ability and strategic choices. Enemies must be defeated to drop scrap metal which can then be traded for new weapons, assuming the player can also maintain their health long enough to reach the upgrade garage. This is the first choice that allows for meaningful play in the game then becomes focused around earning upgrade parts. The player must balance their ability to deal damage to enemies with the availability to avoid taking damage, mostly through their choices in driving styles and relative placement near active enemies in the game's early stages. This creates a positive feedback loop where daring bravado may put a player at

3 undo risk, causing them to lose more health than could be compensated for with weapon upgrades, but allows for a greater reward when all enemies that drop scrap metal are destroyed. The second element then focuses on what to do when given the option to upgrade, integrating your choices into the flow of the game. Different items allow the player to attack and defend in different ways and cost the player according amounts of spare parts. The base pistol available at the outset may be enough early on in the game but is quickly outgrown as enemy numbers increase, as their health increases and as their speed and maneuverability grows more intense. Each of the other weapons has unique traits centered around their firing speed, damage dealt and ammunition availability. As benefits for the player increase, so does the cost. The machine gun, an improvement over the base gun only in firing speed, is the cheapest upgrade while the rocket launcher, capable of precision cursor aiming and high damage is the most expensive. These elements combine into the integrated feedback, based around another positive loop. Consequences in game play develop as a result of these choices right away, whether positive, negative or neutral. Players may be negatively affected by poor weapon choices as they may end up spending all their available parts on weapons that don't provide any benefits appropriate to their current situation. In a level with a high spawn of low level enemies, for example, the rocket launcher provides no increased benefit over any other weapon. Precision aiming and high damage becomes a moot point if enemies are both weak and slow moving. Therefore, the player is punished by being put into a situation that will likely result in them losing health. These effects could also be very positive when players make the right choice, matching the laser rifle, which has a high rate of fire while dealing a midrange amount of damage in this situation. The damage is enough to easily kill weak enemies while providing high rate of fire to easily attack swarms and any larger enemies that may spawn. The positive feedback loop in this situation is the player's increased advantage over enemies, allowing them to defeat them and earn additional items more quickly. A neutral choice may be if the player selects a weapon that provides no real detriment to their situation nor benefits either. This may affect players more later in the game, as some stage are extremely varied and enemies are present in greater variety, creating a real need for multiple weapons. At this point additional meaningful play develops from player strategy in using multiple items within a single context. This requires a combination of dexterity and strategy, in essence, a series of quick choices by the player made from moment to moment as play progresses. Quick choices result in rapid feedback, giving the player discernible results for every choice they make. This adds replay value in addition to meaningful play because there is no single correct or intended strategy, which emphasizes the importance of each choice made by the player. Meaningful play in the game is further developed by the game's artwork and overall visual design. In order for the player to find significance in what's going on within the

4 game there needs to be a unified sense of environment that catches the player's attention and maintains their interest. The main component of this is consistency, the whole game needs to flow visually. Our strategy to ensure this was to reuse graphical elements whenever possible and to incrementally develop elements based on each other. This means that once we developed the car used by our player we then used it as a starting point for our enemies, giving the vehicles similar proportions, similar shading techniques, and so on. The same strategy was used when developing levels, once one level was finished it became a template for those to follow. By working in this way the levels change in theme, swapping highway for dirt road, but maintain a consistent structure, looping speed and interface layout. As a result, when the player switches levels or encounters new enemies there is nothing wholly unexpected to distract them from the flow of the game. Elements appear unique and distinguishable but maintain their relevance to the rest of the game. Although we had originally intended to implement a negative feedback loop to continuously adjust the difficulty of the game based off of the player s skill level, the game became somewhat dull (even for beginners) under such circumstances. Ultimately, we decided take the opposite route and employ a positive feedback loop that rewards more aggressive behavior. After a certain amount of time spent in a level, a boss timer elapses, and the game starts trying to add a boss to the level, at which point no new enemies will spawn. It will not actually add the boss though until the screen is clear of enemies. This means the player has up until the time that the boss timer elapses to kill as many enemies as possible. Killing enemies involves risking the player's health, but the more enemies the player kills before the boss timer elapses, the more chances the player has to pick up scrap metal, and the more scrap metal the player picks up, the more weapon upgrades and ammunition they can buy. On the other hand, the player could also try to avoid all the enemies, and keep as much of their health as possible, and not get as many upgrades. Both strategies are equally valid, but in the long run, getting the upgrades is probably more helpful, since the upgrade, as well as ammo systems for more powerful weapons revolve around the player's amount of scrap metal without it they cannot shoot their most damaging weapons. Furthermore, with the unique properties of each weapon, our game rewards players who use their collected scrap metal wisely. For example, instead of purchasing two (cheaper) powerful forward-shooting weapons, it would be more beneficial to wait to buy one backward-firing weapon (like the TNT dropper) so that the player can also attack enemies sneaking up from behind. Players who utilize their scrap metal carelessly will likely end up struggling more during the game, while careful planners are much more likely to find success. Auto Destructica creates it s own unique type of game play. The rules of the game create emergent behavior, requiring the player to create their own strategies to play. One rule in particular that creates emergent behavior is how the enemies are spawned. They are originally spawned with a constant velocity and sent to the (x,y) coordinate of the hero car. Since they do not change direction or velocity except by colliding with walls, eventually you can discern a pattern in the enemies. This pattern, however, creates

5 possibilities for strategy. One strategy I witnessed a play tester use was to keep the car in the top right hand corner of the screen while waiting for enemies to spawn. Once they appeared on screen, he would quickly move down to the bottom left corner and attempt to sneak behind the enemies. Another strategy witnessed was to keep the hero car in constant motion as the enemies spawn, causing a natural scatter with spaces between the enemies with which you can maneuver through. These strategies are by no means degenerative, they add to meaningful play rather than detracting from it. As the player progresses through the game, their strategies for success evolve as their skills with the core mechanic of the game do. Meaningful play is achieved while the player notices their own skills and strategies becoming better as they progress through the game. Sounds in Auto Destructica also play a role in creating meaningful play. They immerse you into the game play. Auto Destructica uses sounds from freeways, sounds of real cars starting, and weapons sounds to mirror the action seen on screen. Sounds alone however do not create meaningful play. It is the combination of the sounds, settings, and game play that merge into a full sensory experience letting the user lose their sense of self and become immersed into the story and game play. Uncertainty is another large part of the meaningful play in Auto Destructica. Since we made the game, we know exactly how all of the game mechanics and timers work, but from talking to play testers, we have found that they feel a large amount of uncertainty about when enemies will spawn, what their speed and direction will be, when garages will come, when bosses will come, and when bosses will shoot at the player. The time it takes for a garage to show up is randomly generated, somewhere between 15 and 25 seconds, bosses try to show up after 30 seconds have elapsed in a level. We were surprised with the fact that players were uncertain about when the bosses would shoot, because the bosses in fact shoot based on a simple 3 second timer. Some play testers speculated that it was based off the boss' position on the screen, but most simply had no idea. We had debated the idea of making bosses shoot on a random timer, but because of the already existing player uncertainty we thought this would be unnecessary and excessive. We didn't want the players to feel overwhelmed by not knowing what was happening when, and why. One of the few things that the player is certain about in AD is that the regular enemies spawn from the left side of the screen, and the bosses spawn on the right side of the screen, and follow a simple pattern of movement, shooting at the player. The large amount of uncertainty that players are left with though allows them to test out lots of new strategies to see how they work. This also helps to give the game a large replay value. Implementation: Organization At the onset of creating the game, we were just creating small test modules and snippets of code that functioned, such as getting a scrolling background, or a box that can move up, down, left, and right. We started combining these together, and debated the idea that we might want to make our game class-based, which could theoretically help us later on in the design process if our game got very large. After a while, we had a significant

6 portion of the game's functionality, and we decided simply not to move our code into classes so as not to change the way the game was designed and accidentally break something, once it was already working. Because of this, a class diagram would be a bit out of place. Even though we chose not to use custom made classes in our game, we did keep our code very organized. We kept all of our variable declarations on an earlier empty frame, with large comments separating the variables into different sections based on what they relate to. (Ex: Enemies, Weapons, Bosses, Health, Score, etc). We also kept the rest of our code as neat and well commented as possible in distinct, reusable functions. This can even be measured quantitatively, since an earlier version of our code was more than 200 lines longer than our final version, and yet had significantly less functionality & features implemented. Game Objects: Main Character Vehicle The player-controlled vehicle is composed of a base movie clip, which displays the additional features as soon as they are acquired or requested. As soon as the game state is initialized, all possible features (weapons, tires, damage, etc.) are added to the car as child movie clips (tires are the only movie clip with animation). Most of these movie clips are given an alpha of zero, making them invisible. For example, all weapons except for the default pistol are made invisible. Additionally, there are various states that tires can be in (i.e. turning left, turning right, stopped, and spinning). Depending upon which key is being pressed, the desired tire states will be made visible, while the rest will be set to invisible. Adjusting the alpha of children is not the only way in which the player s vehicle responds to keyboard button presses. Each time one of the movement keys are pressed (W, A, S, or D), the vehicle adjusts its velocity, dictating its movement in the X and Y directions (this is done through use of an enter-frame action listener in conjunction to the keyboard up/keyboard down listener. The enter-frame event listener also checks for collisions with other objects, such as enemies and stage boundaries, and adjusts the vehicle movement accordingly. There are other keys that, when pressed, affect the environment, but don t necessarily manipulate the controllable vehicle. For example, clicking the mouse causes the player s vehicle to shoot the active weapon, while space bar is used have the car enter the garage for vehicle customization. (Both of these features are discussed in more detail below.) Enemies The enemies within the game are other vehicles that move around the screen, and provide a threat in that they hurt the main character by colliding with him, or shooting him. All enemies spawn off of the screen on the left side of the stage and set their trajectory to the main character s vehicle. Each enemy will have a random speed, but will not be greater than the maximum allowed enemy speed (determined by a variable). Once an enemy is on screen, it will move around the stage boundary, and will only be removed from the screen if its health is completely depleted. There are currently two types of enemies a police car and a bounty hunter vehicle. Each of these enemies has a limited

7 number of hit points (e.g. Police car has five) that are decremented each time the main character shoots them or collides with them. Once the enemy s health reaches zero, a movie clip of an explosion (ten frames long) is added to the enemy object and once the animation has completed, the enemy object is removed from the screen. There is a variable used to limit the number of enemies allowed on the screen at one time. This variable increases as the player progresses further through the game. The game will create enemies every frame until the maximum number of enemies has been reached. Bosses Although a boss is a form of an enemy, it is implemented in a slightly different manner. The bosses are generated off screen just like enemies, but they only appear once all of the enemies (a number determined by the level) have been killed. Furthermore, a boss has a unique movie clip graphic, and a distinct amount of health a number much larger than the typical enemy. Bosses also are given different A.I., primarily the ability to shoot at the player. Scrap Metal Scrap metal is the currency used to purchase upgrades for the player s vehicle. Each time an enemy dies, there is a probability (currently 0.5, but this number may change) that scrap metal will be generated. If a scrap is generated, it spawns in the enemy s coordinates as soon as the enemy is removed from the stage. Each scrap is assigned an enter-frame action listener which constantly updates its position. The scraps move at the same speed as the road and the surrounding environment. Every frame, the scraps are checked for a collision with the main character. If a collision occurs, the scraps are removed from the stage, and the player s tally indicating his/her number of scraps is incremented. Garage When the player is driving and battling other enemies, an image of a garage will move across the screen (traveling at the same speed as the ground) every minute or so. This garage movie clip spawns off screen on the right of the stage and adds an enterframe action listener every time the garage timer object expires. (The delay time of the garage timer is a randomly generated number somewhere between 25 and 50 seconds). Once the garage appears on screen, the player can press the space bar to activate the garage menu, in which he/she can purchase weapon or health upgrades. If space bar is pressed when the garage is not on screen, nothing happens. Every time the garage reaches the left side of the stage, its enter-frame action listener is removed, and the garage symbol is moved to the right side of the screen where it remains until the next garage timer expiration. Weapons and Projectiles There are five total weapons available within the game each with its own movie clip graphic and firing properties. Each weapon fires a specific type of projectile that has unique damage properties. In order to distinguish which weapon is firing, a variable is used to keep track of the active weapon (This variable is set every time one of the numbers 1-5 is pressed). However, if a weapon has not yet been purchased, then pressing

8 the number key associated with it will do nothing (and the active weapon remains the current one). The default weapon that the player is given at the start of the game is the pistol. The pistol fires at a fairly slow rate and shoots a bullet as a projectile. (A bullet takes 1 health point from any enemy is encounters). Another weapon that fires a bullet as a projectile is the machine gun, but the weapon timer delay is set to half the timer used for the pistol, meaning the machine gun fires twice as fast. The laser gun shoots at the same rate as the machine gun, but shoots a laser beam projectile, which does 2 points worth of damage. The three fore-mentioned weapons all shoot forward; however, the TNT dropper weapon drops sticks of dynamite (which causes 4 points in damage). Dropping the TNT sends it backwards (to the left side of the stage) at the same velocity that the road passes by the stage. Finally, the last weapon, the rocket launcher, takes the coordinates of where the mouse clicked, and sends a rocket projectile to those mousecoordinates from the main character s coordinates. Each rocket takes away five health points from an enemy. Other There are other objects found in the game that aren t an essential part of the game s core mechanic, but contribute to the overall experience received by the player. For example, information about the player s current health, score, scraps collected, etc. are displayed near the bottom of the screen. These objects are either a dynamic text box (which gets updated frequently) or a movie clip (that gets updated to a specific frame on its individual time-line). Additionally, icons of all weapons appear near the bottom of the stage, and have a bounding box displayed on top of them when they are the active weapon (this is done by adding the bounding box as a child of the weapon icon). Problems: Many problems arose during the development of our game, (as was to be expected). One was when we attempted to give the game a sense of dimension. Scaling objects dependent upon their location (i.e. smaller the more distant) in the game was relatively easy to implement. However, making all objects appear in their appropriate layer (either behind the player s vehicle or in front of it) presented a difficult problem. Our solution was to create two separate containers for the enemies a back container and a front container. Maintaining these two containers was difficult, primarily because we had to check for when enemies switch between the containers, which is dependent on the position of the player s vehicle at the given moment. Ultimately, double the work had to be done because each container had to be check for collisions. Furthermore, any changes to the process of checking an enemy container had to be updated twice, which led to several hours spent debugging. In the end, the solution worked and produced to the desired effect. Another problem encountered during development was that since all projectiles were originally in the same container, it was possible to shoot a forward projectile, such as a bullet, and then switch weapons and drop a backward moving projectile, such as the TNT, only to see the previously shot bullet to change directions and move in the same direction as the TNT. The solution for this problem was to once again create multiple

9 containers: one for forward-moving projectiles and one for backward-moving projectiles. The function for adding projectiles then had to be updated to accommodate for multiple containers, and a little debugging was required to ensure that each fired projectile was added as a child to the correct movie clip container. We ran into significant problems in trying to create collision detection between enemies. Taylor spent about a week, and got enemies to usually bounce off each other correctly, rather than passing through one another, but there were still occasional times where collisions would not be detected, or due to an obscure glitch in the logic two or more enemies could become stuck together. At this point we decided that it was better to not have the enemy collision feature in the game at all, if we couldn't get it fully functional, so we removed it. Mike later worked on it again, and took a different approach which worked completely, but involved moving the enemies apart from one another whenever there was a collision. This made the game have a jumpy, glitchy feel to it though, which we felt detracted from the meaningful play of the game, so we eventually removed this and left it as it originally was, where enemies can pass through one another. Implementing boss fights was a bit tricky, and took more than a full week of coding to do. Creating boss fights required re-organizing a fairly large portion of our code into different re-usable methods since the boss fights have their own function called on ENTER_FRAME. We reused various code segments during normal game play and during boss fights, which we put into functions. Getting the game to move onto the next level correctly, resetting all the timers correctly, and correctly increasing the difficulty based on the current level were all challenges we faced. We were having problems with removing the boss' projectiles from the screen, because flash thought they were in a different container than we thought they were in, but using action script's debugger with break points, and running the game in Debug Mode helped enormously to solve this problem. Without it, the problem would have taken much longer to solve, if we could have solved it at all. Our last significant challenge came from trying to tie together all the different versions of our game that we had developed. This problem arose because we would start with one version dated 11-20, for example, then three different people would take a copy of that version, and code / implement three new features. About a week later, someone would then have to take those three versions, extract just the unique new features from each of them, and put them all together into a new version of the game. This was often very difficult because one person would change some variable names so they would make more sense, or would re-organize some code, or the new code they put in would be scattered throughout various places. Iterative Development

10 Auto Destructica began as the idea of a space game. Similar to Galactica with it s fast paced shoot-em-up action. As our team began to discover the finer points of Adobe Flash, and as the group members learned each others talents, Auto Destructica morphed into a uniquely different game than it was first envisioned. Our team established a box on stage that can be moved in four directions with the arrow keys. At this stage, our team argued about the future of our game. As a story began to develop in our heads, we changed the setting of our game from space, to the highways. What was first a space game (concept art 1) changed into a freeway driving, third person shooter game. Our group had two reasons for changing the setting of our game. First, we established a storyline that took place on freeways rather than in the skies. Secondly, as a group we decided a highway based shooter was more original and interesting a concept for a game. The basis for that conclusion was our groups combined history of gaming. We had all played a hundred space shooters and decided we would like to see a land based counterpart. From this stage we began developing our game to fit our story. We created the illusion of a fast paced moving road by using what we knew from the Bob() examples in class to move the car on top of a constantly looping video clip for the road. We discovered how to scale the car as it moved up and down the Y-Axis of the road using a simple scale function. The road image was created such that the first 800x500 (stage.stagewidth()) of it matched the last 800x500. This was an easy way to create a seamlessly flowing background. To give the impression of moving across a landscape we put multiple background layers behind the road. Each one looping at a different speed giving the impression of moving across a great distance while you play. At this point, we had the basic structure of our game set out. After some play testing we decided to use Booleans to store false or true values dependant on whether the arrow keys were held down or released. This way we could stop the car from moving just by lifting a finger off the key, and also it allows you to keep the car moving by holding the key pressed. This is actually an integral feature of any game that requires constant movement. No player wants to be repressing many keys for an extended period of time. Our team kept the core mechanic of our game simple so players were not overwhelmed with button mashing and could immerse themselves in other aspects of the game. Approximately 20% into our development time, our team had a car moving along the our backgrounds. It was without weapons and enemies, but it was playable. We had five play testers apart from out group play through the game and tell us their opinions on a survey. All the testers noticed most AD s lack of weapons and enemies. The movement of the car was smooth, a few small adjustments to speed it was set. With structure down, our team began brainstorming features that would follow our storyline, and create meaningful play. Our team agreed that the play testers were right, the first thing that we needed were weapons and enemies.

11 -The main enemies in AD would be police cars, as per the story line, and after art was in place we soon had enemies spawning on screen. Just having the cars on stage was not enough, they needed three new features. They needed hit detection so we could log when the enemies collided with our hero car. In addition to hit detection, AD s police cars needed to cause damage to our hero and be vanquish able by the player. -Concurrently with the development of the enemy cars, our team developed a main gun for the vehicle. It allowed you to shoot small black dots in front of the hero s vehicle. For these bullets to do anything, each bullet must have it s individual hit test box. From the addition of one crucial element, our team ended up with a slew of new features to implement. First to come was the hit test boxes. After some discussion and research our team decided to create a invisible container behind the hero car, the enemy cars, and each bullet fired. The invisible object behind the cars and enemies act as hit boxes. The hit boxes alpha values are set to zero so they are invisible under the actual artwork of the game. The separate hit boxes allow us to check for hit detection between each individual bullet and all the enemy vehicles. Also, making the individual hit boxes smaller than the art of the individual cars allows the game to disregard small collisions that would seem unfair to most players. Again, these few additions to our game, after much play testing required some work. The hit boxes on the bullets were found to double as shadows on the bullets. This a problems we observed while play testing, it was much hard to see where the bullets would collide. After implementing a shadow to each bullet, it was easy to see the path of each bullet and play accordingly. Having a single weapon was not enough for a full fledged game our group decided. We implemented a weapons switching system that would allow you to change weapons. Once again, the addition of the weapons switching created the need for a way to buy new weapons with which you could cycle. This Garage feature filled many needs in our game. The first essential need it filled was as a resting time for Auto Destructica s players. The fast paced nature of our game is demanding and after a period of constant play, some time is needed to rest your senses. Another feature the garage filled is to refresh life and ammunition. In the garage you can purchase life and ammunition to replenish the hero. The garage was also adds the ability to buy new weapons to make your hero car stronger as your progress throughout the game. With the garage in the game, the only piece we were missing towards a full fledged game was the scrap metal. We decided scrap metal would be the currency with which you can buy health, ammunition, and new weapons at the garage. Scrap metal would be dropped by enemy cars after they were destroyed. The scrap metal as currency

12 still plays on the fact that our hero is running away from the police and only uses the scraps of metal he collects from their cars to upgrade his own. Constantly tying the storyline into the game play makes the gaming experience in AD more meaningful to the player. With many aspects of our game completed, it was time to test and refine our product. This process began at the hit testing code. There had been some problems with the enemy cars colliding with one another. Our multiple hit test detection code worked fine for detecting hits between the hero car and the enemies, and the enemy cars and bullets. It did not work for collisions between the enemy cars. As time progressed our team could not complete this feature and deemed it too technically difficult. Another feature we as a team decided to remove was the road kill code. The road kill code randomly spawned animals and pedestrians that would move across the road as an obstacle for the hero car. After play testing, this feature seemed to clutter the game stage. More importantly, the feature did not add to the games meaningful play. While it added something for the player to do, dodging animals and innocent people has nothing to do with the story of our game, in fact it distracts from the overall story. Originally we had the hero car start with a machine gun but again, after play testing this was changed to a pistol to increase the difficulty and add a sense of evolution as you unlock the machine gun and other stronger weapons. Our team experimented with placing information bar (scoring, health ammunition, weapons) in several places on stage. First we tried the top right hand corner but soon discovered that this was not easy to keep track of because it was too far away from the actual game play. Next we tried it along the bottom curb of the road. This proved to be much better. The information was all easily accessible during game play. The player was not required to take his attention of the game play to read his scores/health With these features in place and play tested the next thing we wanted to implement was boss battles, an opening menu, and levels. The backgrounds for the additional levels had been created during the first 20% of our development, the code to switch between levels, and scaling difficulty was the only thing missing. The scaling difficulty was the most difficult to achieve and required play testing outside our group to asses the true difficulty of the level. After level switching was complete, the opening menu came next. Our team added a controls section on the opening menu to help the players understand the controls of the game before they play it. The first glimpse of the storyline is also available on the opening menu. Once the player is familiar with the controls and story line, they can click start game to begin play. Lastly the bosses were implemented. Our team decided bosses were essential for meaningful play. They introduce a sense of accomplishment upon vanquishing them that allows the player to loose their sense of self and become immersed with the story of the game. They also serve a functional purpose in giving the player a relatively large amount of scrap metal that allows them to purchase upgrades, or gain more health.

13 Future Work Currently, Auto Destructica has a slew of features which add to the meaningful play of the game. Removing existing features would only detract from the gameplay itself. This certainly does not mean AD is complete and without need of future work. In the future, our team plans to go through our code and remove any memory leaks that may eventually slow our game as you progress through the levels. We envision it running just as fast on level 10 as it does on level one. More levels, enemy types, and weapons will always increase the meaningful play as well as the replay value of our game. Since our game story fits well with the levels that are currently playable, a sequel or perhaps just a continuation of the original story would be necessary with the implementation of new levels. Adding new levels that are meaningless and have no concurrent story element would detract from meaningful play rather than adding to it. One current feature that is in need of improvement in future versions of the game is multiple hit detection between enemies. We plan to fix the enemy cars' hit detection so they will bounce off each other when they collide. This was a feature we wanted to put into AD, but were unable to solve the technical difficulties involved in the time available. Play testing will be necessary after the implementation of this feature to test whether it does in fact add to meaningful play. The cars not bouncing off each other may create emergent behavior, allowing players create strategies based upon their knowledge of how the cars move. Finally, we plan to keep our game updated with the current web browser technology so it is always reachable and playable to new users. In addition, we plan to upload our game to popular flash gaming sites, such as giving us a huge playtesting base as well as a massive source for new game ideas. Conclusion Auto Destructica was envisioned as an addicting, endless side-scroller game. We believe that we have done an excellent job reaching this goal. Utilizing the knowledge we have gained through the class, we have been able to create a game that is filled with meaningful play, lots of replay value, a balanced difficulty, and above all, it is great fun to play. Although we couldn't implement every single feature we initially thought of, we are extremely satisfied with how Auto Destructica turned out.