PFD Week 2: A Successful Failure

A Successful Failure

This is the 2nd blog in the series where I actively talk about the progress I'm making on my chosen professional skill titled, "Game Development through Team Collaboration".
This week will go over the initial week of the team-project, how it succeeded and how it ultimately failed.

Game Idea Development

Coming up with a Game Idea

At the beginning of the week, me and the team got together for a meeting where we brainstormed different ideas for what we could develop. Before coming up with pure game ideas, we thought of conditions that we would want for these games that include:

• Game must be estimated to be completed within 6 months.
• Simple concept for the game.
• Game must be 3-Dimensional or 2.5D at a minimum.

With these conditions in mind, we began brainstorming genres for the game, and following up with that we came up with gameplay ideas. Some ideas were created solely by a single person, while other ideas were team-built, but they all conclusively were conceptually finished as a team.

(Whiteboard brainstorming session)

Some crucial points were made during the brainstorming session, including a point to keep the project as close to "small and simple" as possible, an idea I personally pushed to the team. Unfortunately, we neglected this until after ranking the ideas from best to worse. With this in mind, game ideas like "Planet Profiteer" were just too large of an idea, as the finished concept for the idea would be far too out of scope for our <6 month timeline.

There were definitely some challenges, mainly with agreeing on ideas, deciding what to add / remove as a team and generally trying to funnel down into a team-wide agreement on an idea. This was thankfully resolved over time due to the strong communication amongst the team.

After that, the team collectively voted to rank the ideas from "worst" to "best".

Idea Ranking

(ranked 4th best idea)

(ranked 3rd best idea)

(ranked 2nd best idea)

(ranked best idea)

With 4 being the worst, and 1 being the best, we were close to deciding on the Galactic Real-estate God Company game, until a few issues were raised:

• "Is this game small enough for the <6 month timeline?"

• "Is this game designed enough?"

• "Is the game simple enough to develop?"

With questions arising like this, after debating for a small while we ended up settling with "Tides of the Moon", the lowest rated game idea that ended up agreed upon. This is because the idea was actually the simplest, easiest to develop in time and also the most fleshed out idea. A high concept was already created by the team-lead, and he exclaimed the significance of this idea. The game essentially plays like Starfox, where you shoot and fly on a fixed plane, progressing forwards through the level.

With my discontent with the unoriginality, I agreed to contribute to the idea as it would act as a good trial run for the team.

Team Collaboration Process

Working as a Team

To actually work as a team, the team-lead set up a Github Repository so that all member could contribute. Direct contributions were going to mainly be me, the other programmer and the team-lead, as the Sound Engineer and 3D Artist could transfer assets through the programmers to implement. Below is an example of contributions being pushed:

(example of github commits)

Project Outcome

The Quick Failure of the Project

What unfortunately went wrong was that all members couldn't agree on how to make the gameplay have good "game feel". One reason to why this happened was due to a lack of design documents, causing all members to have independent interpretations of the project which was fundamentally detrimental to agreeing on a gameplay iteration as a group. I believe that fuelled the disagreements with "game feel" but was also caused from a simply lack of good controls in the game, with the game being trapped in such a specific genre that we couldn't solve it.

One misunderstanding caused from the lack of design documents was the controls. Some members of the team expected a more level-based world where the player needs to dodge the environment to progress, while others expected a more open world to focus on solely killing enemies.

Kanban Methodology Reflection

However, the team was extremely productive when it came to the Kanban board. Using Trello to host this, the team put together a board of tasks and assigned them with members and unique labels. This was a great benefit to the project, and it will be something I will try and incorporate more in the future.

This experience is similar to insights from Atlassian’s Agile Coach, which highlights that Kanban methodologies significantly enhance workflow efficiency and team collaboration in agile environments (Atlassian, n.d.).

(Kanban board via Trello)

Critical Reflection and Analysis

Taking away from this, I've learned that there should be a higher priority for centralised design documents, and that the team should consistently communicate to be on the same page with how everyone interprets the future of the project. In the future, I will personally try and influence the team to communicate more frequently, and ground our interpretations to a centralised design document, which would significantly improve clarity across the team.

To address the issues arising from the lack of a centralised design document, I intend to propose a structured action plan for our next project phase. This plan will include dedicated weekly design review sessions where we update and refine our design document collectively. By setting clear milestones and allocating specific time slots for these discussions, I believe we can significantly improve our alignment on gameplay mechanics and control schemes. This strategy will help us avoid misinterpretations and ensure that our decisions are synchronised across the team.

The reason I think we didn't have sufficient design documents and communication was partly due to a team-wide anticipation to begin developing the project in-engine. The excitement to just immediately start developing clouded our judgements for long-term success and ultimately caused this to happen.

Most of the week was spent trying to make the game feel intuitive and enjoyable to play, but ultimately the team mutually conceded to the project due to the unexpected difficulty, with the hopes of taking what we learned to another project.

Reflecting further on this week, I realized that my own approach to communication contributed to some of the challenges we faced. I noticed that I sometimes rushed decisions in order to keep up with the pace of development, which may have led to misunderstandings about the design intentions. Moving forward, I plan to take more time in discussing and clarifying ideas with the team, ensuring that every member feels heard and that our shared vision is clearly defined.

I learned the fundamentals to my role within the team, to contribute efficiently and openly to the team while also keeping decisions to be mutually agreed amongst members. 

Prototype Preview

A preview of the Tides of the Moon prototype can be viewed here:

https://youtu.be/ptvbR03zP3Y

(Tides of the Moon Prototype video)

Incorporating Trust Within the Team

According to Duhigg (2016) in his Harvard Business Review article “What Google Learned From Its Quest to Build the Perfect Team”, psychological safety is essential in team environments as it fosters a culture where members feel safe to share ideas, take risks, and collaborate without fear of negative consequences (Duhigg, 2016).

With reference to the previous team collaboration theory on trust, I learned that I should also try and develop trust with other's and vice versa. I believe I personally have less trust for others compared to myself, and that it could cause potential problems in the future, if it hasn't already. From these industry insights, I've reflected upon this strategy and will try and incorporate this to myself and those around me to succeed. To achieve this, I will be transparent when communicating, encouraging team feedback and being less involved in other member's specific tasks.

I also recognise that building trust within the team is essential not just for smooth collaboration but also for long-term project success. I have observed that my own tendency to rely more on my judgments has, at times, hindered open collaboration. In future meetings, I will actively encourage feedback and work on being more open to alternative viewpoints. By consistently demonstrating reliability and openness, I hope to develop an environment where trust is built over time, and where every member feels comfortable contributing their ideas without hesitation.

Conclusion

In conclusion, the first week was spent developing a prototype as a team which I believe ended up being successful to my skill development, but unfortunately the game has issues arise that nobody could solve. For the next week, I assume we will come together to come up with another idea that we can develop even better on with the experience we've acquired, only this time we will develop a strong design document to lay the foundation to a team-synchronised idea.

As strategies to implement to improve the team's synergy, I plan to incorporate trust within the team which will correlate to the higher long-term success of the project. As actionable goals for next week, I am going to communicate more about design, put time and effort into a future GDD to achieve team synergy and re-enforce use of the Kanban methodology.

References

Atlassian (n.d.) Kanban. Available at: https://www.atlassian.com/agile/kanban (Accessed: 28 January 2025).

Duhigg, C. (2016) ‘What Google Learned From Its Quest to Build the Perfect Team’, Harvard Business Review, [Online]. Available at: https://hbr.org/2016/11/what-google-learned-from-its-quest-to-build-the-perfect-team (Accessed: 28 January 2025).