Final Project Reflection

What Worked

Our team naturally fell into roles that aligned with individual strengths. I took the lead in organising meetings, initiating brainstorming sessions, and drafting the game’s core theme and mechanics. Balancing three courses at once required careful time management, but having a clear direction early on helped maintain focus throughout the project. Others gravitated toward programming, connecting design elements to educational theory, and developing the critical evaluation. This division of labour minimised confusion about responsibilities.

Despite working across three different time zones, our communication was consistent and effective. We relied on Slack for updates, shared documents, and scheduled video calls, which ensured alignment even when real-time collaboration was not possible. Our synchronous meetings were also efficient and effective, allowing us to address key decisions quickly and ensure everyone was on the same page before moving forward. This combination of asynchronous updates and focused live discussions was essential for keeping momentum, particularly when feedback needed to be exchanged between meetings.

One of our strongest achievements was articulating the game’s purpose and educational value. From the outset, we aimed to simulate authentic teaching challenges, such as managing student relationships while maintaining well-being. In our final presentation, these mechanics clearly reflected Gee’s (2003) principle that games facilitate learning by immersing players in meaningful, problem-rich contexts. Feedback from Rachel helped refine our tone so that the portrayal of teaching felt realistic and balanced rather than overly idealistic or cynical.

What Did Not Work

Although roles were clear, workload distribution was uneven. The initial proposal, covering mechanics, narrative arcs, and educational objectives, was produced early, but despite invitations for suggestions, little was changed from this first draft. As a result, the project leaned heavily on the initial design rather than evolving collaboratively.

On the technical side, programming responsibilities ended up concentrated in one person’s hands. While offers were made to help with dialogue, assets, or testing, these were seldom taken up, which created a bottleneck. In another area, contributions were delivered reliably when assigned, but there was limited proactive engagement with shaping the design. This mismatch between early enthusiasm and ongoing involvement slowed progress at points and left gaps that could have been addressed earlier.

What I Would Do Differently

If I were to approach a similar project again, I would start with a transparent discussion of availability, skills, and project interest before roles were assigned. Fullerton (2014) emphasises that effective design teams depend on aligning members’ strengths, motivations, and availability with project needs. Such an upfront conversation could have prevented the uneven contributions that emerged over time. My early belief that more people meant greater productivity overlooked the reality that mismatched expectations can hinder progress.

I would also introduce smaller, incremental deadlines instead of relying on open-ended collaboration. Fullerton (2014) notes that iteration is essential in the design process, as breaking development into smaller steps allows for early feedback, continuous adjustment, and prevention of last-minute stress. This would have encouraged more consistent contributions and allowed the team to identify and address problems sooner.

Finally, I would scale the scope of the project to match available resources. Fullerton (2014) highlights the importance of realistic constraints, noting that limitations can promote focus and creativity rather than restrict them. While our chosen engine offered powerful capabilities, it also demanded more time and technical expertise than we collectively possessed. A simpler platform would have allowed us to produce a more polished result within the same timeframe while still meeting our learning objectives.

Greatest Takeaway

The most important lesson I learned is that successful collaboration depends on early transparency about skills, time commitments, and expectations. Fullerton (2014) points out that the foundation of a strong design team lies in shared understanding of roles and responsibilities, which not only prevents misunderstandings but also supports motivation and engagement. I would now approach group formation more strategically, seeing it as a key factor in shaping the project’s trajectory.

Another significant insight came from the feedback stage. Feedback from Rachel on the tone of our game prompted us to adjust the balance between challenge and encouragement in the player experience. Gee (2003) argues that learning experiences are most effective when they encourage critical reflection and adjustment in response to feedback. In future projects, I would integrate user testing earlier and involve members of the target audience from the start, using their perspectives to refine mechanics, tone, and accessibility before production is complete.

Ultimately, this project underscored that game design is not just about mechanics and storylines, but also about process: how collaboration is structured, how scope is managed, and how educational goals are embedded into play. Gee’s (2003) work reinforced for me the value of designing experiences that allow players to engage with authentic, context-rich problems, while Fullerton’s (2014) guidance on teamwork, iteration, and constraints provided a framework for understanding where our process succeeded and where it faltered. These lessons will shape how I approach both collaborative and individual projects in the future.

References

Fullerton, T. (2014). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. CRC Press.

Gee, J. P. (2003). What Video Games Have to Teach Us About Learning and Literacy. Palgrave Macmillan.