You can view my game here.
It is without a doubt that this assignment’s caliber of challenges has brought me to another level of appreciation for game developers. For our latest dungeon game assignment, I have attempted to create a third-person shooter called Tanking in the Loop, where the user controls a tank to blast away aliens and escape the hostile loophole. Most of my visual design choices came from a mix of SNES Megamen and N64’s Super Smash Bros. (particularly the light colors and contrast look). Moreover, I wanted the gameplay to be similar to the NES’ Battle City, which utilizes a bird’s eye view of the player to interact with the game environment.
In my game, the user/player undergoes three levels. In the first and second level, the player must dodge past enemies, grab the guarded weapon, destroy a cracked wall, kill a boss, take its key, unlock a locked door, and exit the level. In my third level, I laid out five different colored keys and expressed a riddle in the status message box related to the color of the keys that opens the door to an exit. If the player inserts the wrong key to the door, the door is supposed to (since I still have not finished fixing an issue with the door and key collision check) disappear and spawn a enemy in its place and the game comes to a dead end.
In the making of my game, there were three recurring issues that stuck out to me which I had to fix in order for the essential portions of my game to work. The first was the four-way bullet collision check, where I had difficulty having my enemy characters check for and detect the bullet collisions. Sometimes, the null error messages would incur much later than the event that caused it. Thus it took me a long time to understand it, but I was finally able to see that it had something to do with the “null object” being referenced. Therefore I learned to put null checks (e.g. if (bullet != null)) to every object I make null inside the onEnterFrame function so that I can minimize this issue.
The second main problem I experienced was fortifying my in-game wall objects so that the player never crosses them. It was not until I reread Rex’s chapter 8 section on wall collisions that I had a better understanding of how the wall class worked. The problem was finally fixed when I reread the “this” method call as a class expression that is used in function parameters to call “whatever” that is interacting with the selected class.
Another major frustration I faced was preventing text box status messages from continuously checking to display only one message. For instance, I programmed my game to display “Lock ‘n load” whenever the player would collide with a weapon object, which ended up displaying itself over other one-time check displays of status messages. The problem was that after the player collides with the weapon object, the weapon object continues to be in contact with the player. Therefore, that status message would always overwrite other status messages. Fortunately, I was able to think about the null checks I had in place and decided to add Boolean statement that checked to limit the “Lock ‘n load” status message display check to a one-time.
As of now, I am still pretty unsatisfied and stressed about the amount of flaws that are in this game. However, I’m also grateful to know that I am learning new and challenging content and synthesizing new and old knowledge to build a greater understanding for programming languages.