The game uses a "survival" type of gameplay, where the user must try to minimize the lives lost whenever a dot slips off the screen. Also, the "dots popped" status offers a feedback system for the user to get the most "pops" while trying to click away the dots before the next wave of dots are spawned.
You can play my game here.
For my final flash game, I created a survival/defense clicker game called “Dot’em Nukem Forever.” Much of the visual design in this game is based on of Paul Preece’s popular Desktop Tower Defense (DTD). I mainly focused on adapting DTD’s simple and minimal “look” behind each tower and enemy. Moreover, I attempted to mimic Preece’s palette of relatively low-contrast colors while keeping sufficient contrast to deliver a visually defined and engaging experience. However, I did however use two different typefaces in my game (Stencil and Century Gothic). Generally, I used the Stencil font for the more “macho” and army effect with start buttons and restart buttons. I also decided to choose the more contemporary and simplistic Century Gothic as the main font for my in-game status text boxes. Though these two fonts have a very different style, I believe the contrast helps add some personality and humor to the game play experience.
This game does not necessarily offer a level-by-level challenge as it is a “survival” type game and can go on for quite some time if the user is inclined and capable in indefinitely destroying wave after wave of spawned dots (the player’s enemy). Overall, there are two major challenges the player faces while playing this game. The first challenge is to race against the clock timer to annihilate (by clicking furiously) the evil dots before more spawn each round (roughly 15 seconds). Second, the player must prevent any dots from escaping off the screen, which deduct a life from the player per dot escaped. This also means that the player should, in all cases, always keep the dot count as low as possible since new upcoming waves of dots can inevitably overwhelm the player.
When a player loses all their lives, I purposely allowed the dots swarm the screen until you press the retry button, giving the game a bit of a personality.
Alike my previous flash assignment, I have learned to lose track of the number of problems I came across whenever I worked with flash. Nevertheless, there were a few that stuck out. The first problem I had involved me choosing not to use classes to reference my enemy characters (I was also a bit stubborn), which posed a severe problem when trying to reference individual instances of the same movieclip that are added onto the stage. Especially because the majority of my game revolves around dynamic coding, I’ve come to learn that understanding how the class system works in Adobe Flash is an absolute necessity when characters are frequently accessed and adjusted as the player continues playing. Thanks to Dr. Delwiche’s help, I was able to gain a better understanding of how classes work and as a result wrote my code more efficiently than I ever could have without classes. The other major problem I had was programming each wave with additional difficulty. In this, I had to add a ton of counters in order for each new “wave” of dots to be increasingly more challenging and impossible for the player. Fortunately, I was able to find very helpful suggestions and advices from dedicated AS3 forum sites such as kirupa.com, stackoverflow.com, and republicofcode.com. Moreover, I heavily used Keith Peters’ Actionscript 3.0 Animation text as a guide in creating my random spawn positions of characters and learning to apply velocity concepts.
All in all, I am very pleased with the game I created because of its ability to sustain itself on loops of code (aside from minor flaws). I was actually surprised by how much the final project helped me improve my skills as a programmer and taught me to be a systematic thinker. I will surely miss those love-hate moments of coding and hope that next semester’s html5 will be just as fun. Thank you, Adobe Flash. =)