DevLog + Post Mortem

Development 

Playtesting feedback 

After the playtesting session on week two, we received a lot of feedback regarding play and interactions. Many of them can be categorized as polish work rather than implementing new features. For example, there was feedback on camera movements, character speed, difficulty, and audio. 

Much of the feedback we received was also observations and feedback we gave ourselves after doing our own individual playtests. There was a lot of aligned feedback, so it was easy for us to implement as we had already started work to do so.

Development process

The development process was split into three major timelines. 

The first timeline was merging our characters into a single game. In this timeframe, we had to set up our Git, and create a single Scene in which all of our characters worked in the same space. We defined “worked” as being able to move, attack, and have all of the animations.

The second timeline was creating separate levels that would exist in our game. The three of us set out to create levels that fit the aesthetics of our characters. These levels would include enemies, space for movement, puzzles, and other interactive elements. Within this timeline, we also set up level management scripts that would take players from one level to another; in parallel with this, we also decided which levels would come first and so forth.

The third and final timeline was polish. Here, we took in all the playtest feedback and implemented ones we thought were apt to the game. Additionally, we polished up enemy movements and animations, in-game audio, colliders between objects and characters, and other movement related tasks. The majority of this timeline was meant for debugging, as many hours were spent finding bugs and glitches that would make gameplay choppy. 

After debugging and polishing, we published the game. There are Windows and Mac builds, in addition to a web playable build.

--------------------------------------------------------------------

Post Mortem 

Successes

Our characters shared a single theme which allowed us to easily build an environment for them. While sharing a cohesive theme, each character remains unique in terms of art styles and features. The Devil has a morbid look and shoots projectiles following a curved trajectory. The Ghost is cute and floaty and has a long range shooting attack. Mr. Skeley has squeaky bones and can deliver lethal melee attacks. 

Besides, we designed three levels that emphasize different gameplays. The first level is linear and allows players to practice their attacks against a group of slow moving enemies. The second level focuses on player movements and precise timing. Players also need to utilize the specialty of each character to get rid of obstacles. In the third level, players firstly need to work out a small puzzle in order to trigger the fight with the final boss. During the battle, each character needs to find optimal positions to damage the fast moving boss without being hurt. The different focuses on the levels can most likely keep our players engaged and entertained.  

Struggles

The struggles that we encountered mostly came from the technical aspect rather than the design aspect. 

First, we had trouble coding the gate for the scene changer. After a brief troubleshooting, we figured the problem was that we used “OnCollisionEnter” on a set-triggered box collider. 

Then, we went into fixing the camera since it was sometimes too close or too far from the characters. It was a quick fix after we tried adjusting the numbers around the camera scale. 

The third and the most tricky obstacle we encountered was with GitHub and it happened twice. Since we were working remotely through a shared GitHub repository, we very much relied on the push-and-pull function. Although there were constant error messages during merging that wasted a lot of our time to get around them. Moreover, we faced a number of situations where a certain scene turned completely blank after a push-and-pull process. To be honest, we still haven’t figured out a solution to the problem. All we did was to try everything we could interact on the GitHub interface and sometimes directly emailing the project package to each other to avoid using GitHub. 

Lessons learned

From this project, we have learned how to balance out the different stages and debug the issues with GitHub. These experiences will help us through any problems that can happen while working as a team with unity.

Next steps

Our next step to make our project more polished would be to work on more details of the game we were not able to add due to GitHub issues. 

• UI: Our current UI system does not match our overall design. Also, there was an issue with the button that didn't seem like one. In our next update, we will make changes to these issues. 
• Visuals: Some of our enemies are missing animation. For a better gameplay experience, we could change the animations to match each characteristic of the enemies. Also, changes to the level 2 environment can be made with 2D lighting to enhance the feeling of exploring the castle.