CAGD 370: Postmortem

ePortfolio

Blog Postmortem: The Finished Product

Publication - 12/13/25

The Goal

            My team, Treasure Hunters, was tasked with developing a functioning game prototype over the course of the semester, and at the end, it would be presented to our peers. As of writing, our team has successfully created a functioning game prototype called Vinebound. Creating this game prototype tested our team's collective knowledge on the iterative design process and agile development.

Game Summary

            Vinebound is about Nicholas Carrington exploring the Peruvian jungle in search of Aaru Springs, the fountain of youth. Nick is accompanied by his partners, Declan Frost, a skilled pilot, and Sienna Hargrave, an ex-military tactical expert. While exploring the jungle, they come across Sergei Volkov, a russian warlord hell-bent on using the fountain for ill intent, turning this adventure into a race with the fate of the world as collateral.

Lead Designer

            The idea of Vinebound was created by me; this meant I needed to convey my ideas clearly and concisely to my team members. Once I became lead designer, I began writing explicit documentation about the project to ensure my team members had a clear understanding of what we were trying to create, so we were all on the same page. I understood that if we weren't on the same page about key aspects, we would need to revise them, reducing the precise time we had to develop. Prioritizing communication was important to me, so I regularly checked in on team members to ensure they weren't being overworked and understood the material they were working on. I continued this process until a disagreement occurred during sprint 2 between the programmer and me regarding the main movement mechanic.

            After the disagreement occurred, I stepped back from monitoring the team and transferred that to my producer, who would check in with the programmer and report back to me. Behind the scenes, I analyzed how that disagreement came about and took steps to reduce the likelihood of it happening again. Those steps included creating a more thorough critique sheet for the mechanic, which featured a checklist of what the mechanic needed, along with suggestions and a video explanation showcasing my inspiration for the mechanic. After these changes were made, the workflow became smoother, with work being more accurate and requiring fewer revisions.

Paper Playtest

            This is the third and final iteration of the paper playtest map. The results of this were pretty successful, with consideration of whether the game and its mechanics were even viable. The translation from digital to paper worked out better than I had anticipated, with me focusing on key features rather than attempting to incorporate every single one. The key section, however, became too cluttered, reducing its readability; most of the larger information chunks could have been placed in the rule sheet.

                                    

            Regarding the paper rulesheet, this is where I could have made improvements. There was a bridge between the map and rulesheet, but the planks weren't nailed in. Some sections had confusing wording or weren't detailed enough, requiring the playtester to additionally look at the map's key for clarification. The organization of the rulesheet didn't flow with the playtesters, leaving many annoyed to read it. Changes that were noted down were more concise and clear explanations of mechanics.

Revised Grappling Hook

            

            The revision of the main movement mechanic resulted from a communication breakdown between the programmer and me. The programmer created the initial version of the mechanic, which I initially approved. But, a few days later, I withdrew that approval and created a Google document outlining specific critiques and required changes to better align the mechanic with the game's design. After the document was created, I sent a message in the team group chat stating the document had been created for the programmer specifically. However, the programmer later stated that he had not seen it.

            Due to the document not being reviewed, the movement mechanic remained unchanged for an extended period. During this time, I discussed the situation with the producer and received approval to work on an alternative version that more accurately reflected the design requirements. After completing this version, I presented it to the programmer and introduced the idea that the gravity-based swing would be combined with his existing system, which used dedicated grapple points. The programmer verbally acknowledged this explanation and claimed he understood this, and follow-ups indicated to me that he was actively working on the implementations.

            The night before the kinesthetic playtest, it became apparent that the programmer was unaware that the two separate systems were to be integrated. This led to a heated disagreement in class, during which I confirmed that the critique document had not been seen. After the document was reviewed by the programmer, the design requirements and the intended implementation were clarified.

            Following this incident, I had the producer become the mediator between the programmer and me to filter for clarity and remove any personal animosity that might have erupted from the disagreement.

Puzzles + Control Scheme

             A key element of this game's design was to have an assortment of puzzles for the player to interact with; an experience like this was distinct from other games by adding a new level of interactivity. I made some iterations on the puzzle by creating a better selection system, which was more intuitive, allowing players to choose the combination with greater ease.

            After our first playtests, we discovered that not all playtesters knowing the controls led to a very difficult and frustrating time, so we needed a control menu going forward. I decided that including the controls in a pause menu was an efficient use of space, as it made the pause menu more useful. Later on, my producer created a level selection bar in the pause menu, making it even more useful.

Tutorial Section

            Continuing on, we follow the trend of ensuring clarity for the player. Here is the tutorial section that gives the player the chance to learn the grappling ability in a controlled environment. Towards the end of the section, the player is shown in a museum-style setting what they are going to interact with in later levels. During the system playtest, all the players found the tutorial helpful, indicating that this design works. Despite the positive feedback we received on this section, there are still improvements that could be made. An introduction to enemies here could have been beneficial, instead of introducing them in the second level.

Feedback UI

            The work that I did during the last sprint revolved around player feedback using UI elements. This took more time than I anticipated. I used all the tools available to me to fix issues I was having. I went to the professor's office hours, tutoring, and just asked classmates for advice. Eventually, I got all sections of the UI working without errors. It took the entire sprint, but I got the feedback working in a way that helped the player's experience, which was the whole goal of it.

            The feedback UI is split into three sections: puzzle, abilities, and key count. The puzzle aspect was the easiest to work on, with it running in the existing blueprints. The abilities aspect followed similar logic but needed additional tweaks to ensure it wasn't firing continuously. The key counter was the hardest to get logic-wise wise with me needing both office hours and tutoring to help me out. After I got all three aspects working after a full week on them, I thought I was finally done. That was until I realized that after the player died, both the ability feedback and key counter stopped working. To get this working properly, it took up the last week of the sprint. Eventually, this worked after help from a classmate who figured out the issue with the player death system. After tweaking it, there were no more errors, and everything functioned correctly.

What went right? 

            Despite key aspects of the prototype being developed independently, they functioned without issues after being added to each level. This allowed the team to playtest faster as we didn't need to bug test as often.

            After multiple revisions, we had a movement mechanic that functioned exactly like the design document entailed. The quick turnaround on the grapple mechanic allowed us to create more engaging levels, which would represent it in the best light.

What went wrong?

            The primary issue faced as a team revolved around communication issues; periods of disconnect occurred, which led to explosive realizations, creating tense moments and a loss of morale. These moments occurred more than they should have, indicating we have much to learn regarding good, consistent communication. A step forward to prevent this is to create a safety net comprised of multiple levels of verification to ensure the work is being done correctly, to prevent work that is below par.

            An additional challenge involved role boundaries within the team. At times, some members would step outside their role, leading to an uneven distribution of workload. There were also instances where team members would be very territorial over work they had done in the project, limiting the collaboration potential. A step to prevent this is to have the producer enforce their role to emphasize they get final say on what goes and what doesn't.

The Result

            The final prototype for Vinebound is something I can say I'm proud of, as our team worked hard on the work we were assigned. By no means is it perfect, as there are multiple aspects we could have improved on if we weren't constrained by earlier bumps in the road. Overall, the prototype does land itself in the ballpark of what I had envisioned for Vinebound; the main thing I wish we had gotten to during development was the inclusion of the story I had written for it. The lack of the story's inclusion results from the issues during development. This course has taught me many things about agile development and the Scrum process. It has also emphasized how important constant communication is within a team. If a single person on the team is on the wrong page, the development process will suffer. The lessons I have learned from this class have allowed me to grow better as a game developer, and I will use them to succeed in mobile game development