Project 3 Postmortem

Intro:

My group and I set out to make a four-player competitive survival game called "Hydration Hunt".  The objective of the game is to outlast the competition by collecting water and placing it back at your corner.  If a player runs out of water, their health decreases until they die.  The game is asymmetrical due to the fact that there are four players, and each player functions differently.  We have a trap player, who places little traps that cause opponents to stop moving or can cage themselves for defense.  We have an ice player, who can freeze enemies in place and slide across ice very fast.  We have a grass player, who burrows underground and attacks with greenery.  Finally, we have a chain player, who can quickly leap from one area to another or grab and send enemies flying elsewhere.  Prior to selecting characters, players have to choose between one of three stages.  The stages included are a polluted area, where factories and smog hinder the players' visibility, an area where polluted/dirty water rises and causes players to get poisoned upon interacting with it, and finally, a drought based stage where the environment collapses beneath the players.  After selecting their characters and stage, the players compete for water until the game ends with the last person standing, and that player wins, the cycle repeats after everything.  

I collaborated with two other individuals on this project, and we split the workload as such: One of us did the primary coding and level modeling, another one of us did the character modeling and animation, and the last one of us did any extraneous modeling, such as ice shards & towers, and did all the sound design, including music, as well as the menu designs.  We all took part in note-taking & setup during our playtests, and would share feedback and keep ourselves on track through online communication.  This project ended up having several things that went right, but also a few that went wrong.

What went right:

The first, and most obvious thing that we did correct, was deciding what social issue we intended to focus on and how we integrated that into the mechanics of our game.  One of the challenges we gave ourselves for this game was to make it a "game for change", that meant that with our game, we'd have to think of a social issue to reference and draw attention to with our game.  The issue that we decided to reference in our game was water scarcity & pollution. However, instead of simply making a reference to it in our game, we decided to develop our entire central goal and level design around this issue.  The main goal is to collect water before the rest of the players, causing conflict due to the fact that water is limited.  This is meant to mirror real life conflict caused by limits in water availability & we, as well as those who played the game, thought that making this our central theme & mechanic worked extremely well.

The second thing we did correct was making our game asymmetrical, we accomplished this by making each character function differently, and that certainly had affects on the balance of the game.  It would make the game more fun to play and each character had strengths and weaknesses that others could draw from, however, while the core controls of the characters were similar (i.e: run, shoot, jump, special), the special abilities were unique enough that no one felt the same.  These mechanics made our game quite asymmetrical, as we noticed that everyone was using different strategies for how they'd play the game, which was the intention.

The third thing that we did correct was more behind-the-scenes, but that was the breakdown of roles and tasks.  In order to keep ourselves on track, we created a spreadsheet with tasks that needed to be accomplished and assigned different people to them, we made sure that we would do what we were good at so that way, we could ensure that our game got finished on time, in addition, prioritizing what features to include in our game and what features to exclude from our game became easier because of this spreadsheet.

The fourth thing we did properly was our level design and aesthetics, our level design was meant to be open to serve the function of being an arena.  Our levels were designed exactly like that and, while they all served the same function, they still looked unique enough and had unique enough traits that each stage felt different, in addition, there would be clear reasons as to why some of the effects in each level were occurring, for example, in the polluted arena, smog covers the stage, this is because there are factories that appear all over the level, and that causes the players to know what's happening, and why it's happening.  This is the case with every level in the game, and it makes the game more interesting because of the mirroring to real life.

The last thing we did well was the sound design.  Each sound corresponds pretty well with the associated character & they sound appropriate in the context of the game.  They are also unique enough that each sound helps differentiate every character.  In addition, the music was appropriate for each stage, and was fitting for the environment.

What went wrong:

The first thing that went wrong, on the fundamental level, were the creative differences between two of the people on our team.  When we first proposed the project, we agreed that the aesthetics would be extremely low-poly, and while, to an extent they were, we meant for the characters to consist of simple shapes and have exaggerated proportions.  While, to an extent, we were able to make those characters have exaggerated proportions, there were a few characters who looked too realistic, which led to some clashes in the art style.  This led to a bit of frustration among us, and while, in the end, it didn't make much of a difference, it was notable.

The second thing that went wrong was that the division of the work was a bit unbalanced, while we all took care of a specific type of task (i.e: I created all the sound, one of us did character modeling & animations, etc.), the person who was in charge of programming ended up doing quite a lot, which made the workload seem mildly unbalanced.  It led to a few complaints and scheduling issues when it came to what we wanted accomplished by every playtest.  While this wasn't a huge issue in the idea that all of us were trying to create a single game, and so everything was coming together, regardless of who did what, it was notable.

The third thing that went wrong was when it came to the controller assignments, it wasn't terribly efficient, since every time we tested, we needed to change player assignments.  It could have been more practical if we assigned one controller to one character rather than customize them.  It's not a huge thing, but it's notable.

The fourth thing that went wrong was that towards the end of the project, the Unity Collaboration wasn't working.  It wasn't working on my end, which meant that there were a few days where I literally could not push any changes.  This meant that I couldn't contribute much until I managed to get access back, which led to me sending photographs or files over to the rest of my teammates, who had to do some things on my behalf.  One example was sending audio files & screenshots for our character selection screen.

The final thing that went wrong was the delay in acquiring models.  While our character modeler did a good job on making & animating the models, it took him a very long time to put them in the game.  This led to a lot of stress in the project's last few days.  We needed them immediately in order to test them with the game, and it took a very long time to put them in the game.  We were effectively at a bit of a standstill until those models got in.

What I learned:

I learned a lot during this project.  There were several mistakes we made, and several things we learned from them.  One of the things I learned was how creative differences can cause issues and changes in projects.  This was self-evident in how we wanted our aesthetics to be developed one way, but were developed in a vastly different style for the final product.

The second thing I learned about the project was how to divide workload.  While the workload was a bit unbalanced, we all stuck to our dedicated duties and worked to a deadline.  We also all kept each other in check and made sure everything was in order properly.  We also made sure we approved of each others' designs & work.

The third thing I learned during the project was how to balance a game and how easy it is to come up with ideas off one core concept.  Usually when making games, I have to think first about the kind of game I want to make and then focus on everything afterwards.  With this game, we started off with the core concept, and developed our mechanics based off that and that really helped me in my next project because I was thinking "competitive", and I came up with my concepts based on that.

The fourth thing I learned during this project is how to model characters.  Prior to this project, I hadn't modeled any characters, and although I ultimately didn't do the character modeling, I was assigned to do so first and nearly finished, had our 3rd partner not decided he'd do all of them.  I learned several techniques in Maya and how in detail I needed to go in order to make a character.  In addition, I learned how I needed to make sure I could export models to Unity as well as how to make low poly characters.

The final thing I learned when making this project was how to create my own sounds completely from scratch.  Prior to making this project, while I had done sound design, it was mainly done for soundtracks.  In this, I had to create and balance all the sounds in the game, and it was a new experience for me because I had to do some unique things in order to create the sound effects, for example, in order to create the sound of people treading through water, I moved my hand through the water a few times.  And there were several more examples like that.  It was a very unique thing to do and I'd like to try it again in the near-future.