September 20th Post-Mortem

Intro:

My game is meant to be a direct reference to the Area 51 raid that was supposed to take place on September 20th, 2019, hence the title.  The main goal is to infiltrate all the stages and get to the deepest part of the facility.  Once you beat the last level by getting past a certain amount of points, you win.  You play the game by moving around an arena pointing and clicking at the enemy or by using joysticks, with the left stick to move and using the right stick to aim and right trigger to shoot.  You progress by destroying a certain amount of enemies, following which you progress to the next stage.  The enemies can harm you by colliding with you and shooting you.  If your health is reduced to 0, you lose the game and need to restart.  There are UFOs that attack you as well as creepy aliens.  You have to defeat them in order to continue the game.

What went right:

In terms of what I succeeded in when it came to this game, they were mainly in terms of concept.  The biggest success that I found with the game was through its setting, given that it was inspired by an event that happened rather recently, I was able to take advantage of that and make my game work well with the aesthetic and it made the game end up having a mix of realistic and digital/alien styles that don't seem too vastly different, and work together well.  For example, in addition to fighting police, the enemy fights against aliens.

The second success I had in my game was the pacing.  Given that the game is based on a military raid, the game had to be quite chaotic, and with the speed that the player has, as well as the speed which the enemy attacks you with, is somewhat fast.  While the enemy moves somewhat slowly, their bullets do not.  This led to a fair amount of fun in terms of running away while trying to hit the enemy and that sense of speed was touted as fun by others.

The sprites of the game were praised, while initially, the sprites were somewhat generic and didn't take advantage of the setting, I eventually managed to expand my horizons by adding levels that looked more mechanical and creating UFO sprites, which led to a fair amount of praise since it actually felt like the player was infiltrating an alien place.  The art style's praise was mainly that it integrates these realistic characters with these non realistic characters and backgrounds in a way that isn't too jarring.

The challenge of the game was praised, people appreciated that the game wasn't just a walk in the park (i.e: NYU Playtech testers).  They also appreciated that the game was testing you more on how you can perform from what you've learned rather than just throwing new challenges at the player out of nowhere, and that each level builds upon what was done in the levels before.

My final success was my open level design.  I wanted the game to not have simply forward movement, but to be a place where the player actively needed to use their space to their advantage and I thought the best way to do this was to have the level be open.  This helps maneuver around the level easier.

Overall, the greatest success of the game was that I managed to integrate all the concepts and gameplay functions that I wanted to into the game. 

What went wrong:

Unfortunately, there was a lot that went wrong with the project, and this would really detract from the game.

My first big failure was the gamepad integration with Unity, I created the game to work with the Steam Controller, the Steam Controller doubles as a mouse and keyboard function, and therefore, doesn't require different scripting, unlike any other controller.  This would be a problem however, because some of the mappings wouldn't work properly, for example, the game's movement would not work with the steam controller, which was rather strange since it ultimately should have worked just like it would on the laptop.  This really hurts the game because it cuts off an avenue for gameplay.

My second failure are the hurtboxes for the player.  Unfortunately, the player gets hurt by others quite easily and it just happens immediately without much notice, this could be a problem because it'll feel as if the player is constantly dying and it will make the game feel very unfair because out of nowhere the player just loses health.  It's for this reason that I made the player's health quite large, but it's still a problem that the player's hurtboxes are massive.

My third failure is a simple one, and that is that I made the switching between levels much too sudden.  Rather than adding a cool delay between stages or a win and click to progress scene, the game just immediately switches between scenes, this can be a bit jarring for the player, and can really make the game a strain on the eyes at times.

My fourth failure, and probably my biggest aesthetic one is that the levels aren't well made, given that it is an open sort of game, there is only so much that can be done, however, my level design of open arena with patterns layered all over doesn't note much about character beyond a digital or machine based environment, and even then, there isn't much character to the environment, there are no additional objects to show where one is, there are no unique features about the stage beyond the color and tile design, and that really makes the game seem overly same-y as the player plays through.

My final failure is one that I touched upon earlier and that is that there is little to no registration for when the player loses health.  Sure, the player's health decreases in the inspector, but the player does not know that, as the designer, I have to inform the player in some way that their health is decreasing, which I was not able to do.  It's quite a large mistake too because it means the player doesn't have all the necessary info to play the game at their best.

Future Goals/What to change:

My first future goal is to add further story integration, while there is certainly a story present in the game, which can be viewed in the instructions, the gameplay itself doesn't add anything to the story, nor does it indicate anything about the story.  This is a major problem since, without that, the player has no narrative reason to be invested.  If I were to further integrate story, I'd try adding dialogue options to my game.

My second future goal is sound design, while I have background music in my game, I want to add sound effects such as hits, grunts, explosions and so on.  It would add even more registration for what is going on as each thing would have unique sounds to them.  Naturally, I'd make all the sounds myself and use those, and it would add a whole new dimension to the game's aesthetics.

My third future goal is to increase the variety of levels, by this, I mean have each level be more than just an open arena, make the levels similar to mazes or have them have cover, or subtle in-jokes or references in the sprites, I could have some potential references to Area 51's memes in the backgrounds such as having stills of Naruto Runners going throughout the levels, there are several possibilities for the level design that can add both aesthetics and functionality to the game.

My fourth main goal is to properly integrate a gamepad or joysticks into the game.  While the game does work with the steam controller, that is essentially just doubling as a mouse.  I think it'd be better if the game was specifically meant to run on a proper twin joystick setup as that was what the game was supposed to be like and that was what the game's direct mechanics were built from.

What I've learned

I've learned a lot during this project, however, the issue is that I've only learned them after the project was over, and had I used these beforehand, my game would be far better than the state it is currently in.  My first lesson is that it is important to get the fundamentals of the gameplay completely working before shifting focus onto anything else.  The reason this is important is because if you start working too much on another aspect of the game, you run the risk of completely forgetting about the main gameplay before it's too late.  Instead, if you run into a problem with the central gameplay, don't just immediately start working on something else, try to fix the problem, if you don't, and you start finding yourself getting frustrated, do another aspect of gameplay really quickly (i.e: Make ONE sound effect or make ONE visual asset, etc.), and then go back and try to fix the gameplay.  However, it's also completely viable to just keep trying to fix the gameplay of your game and nailing that down before moving onto anything else.

My second takeaway was explained earlier, but basically, spend time fixing the issues with the game rather than simply ignoring them to accomplish something else.  This should be done because the more these problems are ignored, the more they pile up and eventually, after you manage to accomplish those other tasks that were easy, you will have to spend so much additional time trying to fix fundamentals that didn't work in the first place.  If anything, when you find yourself just hitting a wall over and over when trying to solve a problem, take a small break, do another task in the game for 5-10 minutes and get right back to solving the problem.

My third takeaway from this game was to set clear goals for each playtest and figure out what needs to be gained from those playtests.  By this, I mean to use the playtests as deadlines for features, for example, if there is a playtest 5 days from when you start your project, you decide what you want done for that playtest as soon as you know when it is, it could be controls, aesthetics, anything, as long as you know what you want people to see when you playtest the game.  It also helps streamline and map out your game more accurately and allows you to fix bugs before they go too far out of hand.  In addition, each playtest has to have a purpose, you should go to playtests asking what aspects of your game you want public opinion on.  If you don't do that, playtests might be pointless because you don't know what you are focusing on.

My final takeaway was a failed attempt by me at organization, and this was mainly due to my lack of commitment to that organization method.  I created a table with individual tasks, their priorities, and times that they would take to finish, unfortunately, I didn't stick to this table and I suffered for it, had I done so, I can imagine I would have been far more productive on every aspect of the game and wouldn't have been struggling to get it working on the day that it was due.