With the second game jam coming to an end I decided to create a blog post about the lessons I learned from the this week. Mainly I will be focusing on what went well and what didn’t. I will then finish with reflecting on what I have learned and how I will aim to do better.
Since we had to form our own teams, pick a genre and pick which systems we want to use as inspiration, this lead to the first 1 -2 days being spent forming a team and coming up with an idea. Fortunately we had a discord to help form teams, and forming one was soon done after. On the next day we spent the day coming up with an idea for the game, though we got along with each other pretty well, the project was over scoped, this was possibly due to the fact we didn’t have lot of time and wanted to begin immediately so we tried to fit everyone’s ideas and leave it there, without considering how long each peace of work would take to make. In addition, I wanted to make a game that was bigger and better compared to the previous one I made which may have affected how the project was going to look and function. One of the other things that I think slowed down the project was external factors outside of the university.
In the end I feel like the cons of the project can be summed up to a lack of organisation while also trying to deal with the stress of getting the project playable and finished in 4 days, with evidenced playtesting while trying to handle external factors.
Looking at the pros of the group project, the project was definitely a step up, compared to the previous project as there was more gameplay and mechanics for the player to use. This is because the core gameplay loop was about hiding from enemies in bushes while trying to reach house to deliver letters all with in 5 minutes. In addition, the narrative was improved as well since the story was all about delivering soldier’s mail to their families to making people happy in sad times. an example of the game is show below in fig 1.
Though the art struggled a bit due to lack of experience with Unity’s materials and making 2.5D games, the aesthetic of late 1800s to early 1900s was achieved especially in the environment. This because creating a old timely map as the environment was a focus of the game. Below you can see what the map looked like without the game elements in fig 2.
Another thing that went well was getting along with each team member as though organisation was lacking, me and the rest of the team got on very well and had no arguments. In addition, while coming up with the idea for our game we also spent time planning out our target market. One of the artists was able to immediately create 3 personas of our target market as they were well experienced in that area.
From play testing, most of the results most were positive with the aesthetic being the most well received area of the game. People liked the gameplay loop but as results stated improvements were needed and some thought there wasn’t enough. If this idea goes further more mechanics could be added, mainly to ensure that there is challenge and something to encourage the player to move forward. Though the game was set during a war, it only implied in the art and narrative, which prevented us from upsetting any play testers.
After the playtesting, improvements were made to the game, mainly adding a counter to show you how much mail was left to deliver and also increasing the guards speed by 0.5units every time you delivered a letter. Play tests justified this by stating it would help give them a challenge as it was generally quite easy to avoid the guards. A picture of the improved game is show below in fig 3.
Conclusion
Reflecting on what has happened if I want to avoid feature creep from happening again I should look at the backlog of the tasks that need to be done in order to meet the overall goal. From there I should make decisions as to what we should focus on and where we need to make changes in order to meet the end product (Pries and Quigley 2011).
For the next group project if I became the scrum master I would use a burn down chart to keep track of the teams progress and also use it to keep track of time. Each day I would fill in how much work has been completed based on the scrum board, this would be put into a graph and then compared to a predicted graph of how much should be complete. After the stand up meetings I would state that we need to get this many tasks done my the end of the day to ensure that we stay on target. If were are facing troubles I would also bring it up and suggest that we make changes so that we can meet our deadline Reflecting on what has happened if I want to avoid feature creep from happening again I should look at the backlog of the tasks that need to be done in order to meet the overall goal. From there I should make decisions as to what we should focus on and where we need to make changes in order to meet the end product (Pries and Quigley 2011).
Despite everything that has happened, we did manage to get the gameplay loop working and the aesthetic was enjoyable. In addition, playtesters did enjoy the game and improvements have been made.
Bibliography
PRIES, Kim H. and Jon M. QUIGLEY. 2011. Scrum Project Management. Boca Raton, Fla: CRC Press.
Figure List
Figure: 1. Max Oates. 2021. Screenshot of gameplay [screen shot].
Figure 2. Jeanett Pechtel. 2021. Game Background [Digital].
Figure 3. Max Oates. 2021. Screenshot of improved game [screen shot]
MaxMakesGamesBlog 