CAGD 370 BlogPost Postmortem

What Went Right?

What went right was that the prototype worked and was playable for the final playtest. With the programming I did for the player movement, the features we wanted the players to use were functioning and worked how we anticipated. The wall jump and double jump worked for the playtest and the wall jump platforms worked how we intended them to.

Players were able to get an additional jump when platforming onto blue walls. Players were able to combine jumps and make their way up the buildings by executing multiple wall jumps in a row. We consider this a huge win because we wanted the players to do more wall jumps since it was not apparent in the last playtest. This was a success because players were having fun with the jumping and our goal is to make the platforming as fun as possible for the players. The double jump worked well, and players enjoyed this aspect. 

Something that we implemented later in the development process was multiple enemy balls. I was not able to make a single enemy ball have the AI to chase the player throughout the entire level, so I made multiple with each covering a certain section. This worked out well for a prototype since it gave the player a dilemma of choosing a path by an enemy ball or going the harder route to avoid the enemy ball. The respawn of the enemy ball was a success because this gave players a couple of seconds to get away from the enemy ball before it started to chase the player again. 

Additional Enemies Placed

I was able to get a blinker working for the player to know when they were touched by the enemy ball. We felt that this gave the player much better feedback when they got caught by the enemy ball. The speed up and slow down tokens worked to change the player's speed as intended and players were able to avoid enemies by increasing their speed. They had to avoid slow down tokens so they would not get caught by enemies. This added another level of challenge for the player when platforming. 

Enemy Movement Pattern Highlighted in Blue

While this is not related to gameplay, our group was able to commit all changes to our project's GitHub. This was something we struggled with at the beginning sprints. Even though it took us time to learn GitHub, it was a lot easier and less frustrating as a team when we all were on the same page and knew how to upload our changes to GitHub.

GitHub Project

What Went Wrong?

What went wrong was that the player's movement was not based on the camera position. This meant that the camera could be facing to the right of the player, but the forward key would not have the player move straight in that direction. The player was stuck with the four directions of movement. We tried to compensate for this by having the level go mostly forward so the player did not have to change directions much. This worked to an extent, but this was not what we wanted ideally. Throughout the playtests, this was the number one issue that I could not solve.

Player Movement Script

Something else that went wrong was that the code was not optimized or clear enough for all the group members to understand. This was due to me trying new methods to get the player controls to work how the play testers wanted them. At times I would scrap code that did not work; however, some code would not be deleted and would stay in the scripts; usually as variables not being called. This led to confusion of what code was being used and what code was not needed. At one instance, I left two different speed variables in the movement script. It did not break the code, but when another team member made a new script referencing the speed variable for speed up tokens, they had referenced the wrong speed variable.

 

Variables and Functions of Player Move

It was the speed variable that was no longer in a function, so while the script did not create any errors, it was not increasing the speed variable attached to the player. This was due to poor coding practices by me, and I will make sure to resolve this for all future projects.

What Would I do Differently?

For future projects, I will make class maps for programming and use better and cleaner programming techniques. The code was not optimal for this prototype, and this led to confusion at times as to what worked and what could break the game. The coding also felt "stiff", meaning that it was hard to add new elements of the game to the established code. This was mostly apparent with the player's movement script. Another thing I would do differently is set up a working GitHub project at the beginning of the production cycle so that everyone knows where to upload work from the start. I would also seek help and assistance from others outside the group if no one in the group has a clear answer. While my team members were helpful and knowledgeable, some programming errors and questions I had were difficult for us to solve on our own. I plan to meet with tutors and professors that have more experience and a better understanding of programming topics for future projects. Then, I will reciprocate this knowledge to individuals in my team that this programming will affect, (e.g., other programmers, level designers, and the lead). Another small detail that I missed this project but will help other team members in the future, is to comment on my code to let them know what certain functions or lines of code do. Even though they may not know coding dialect, adding a brief description will give them an idea what it is doing.