Week 2: Team Contract

Work Preferences

During the Monday session of Week 2, our team spent time getting to know each other’s work preferences and strengths. We found that most team members prefer working independently, which made it especially important for us to establish clear communication and structured collaboration.

In terms of strengths, our group is well-balanced. We have both analytical thinkers and creative thinkers, allowing us to approach design problems from multiple perspectives. This balance is particularly valuable in game development, where systems-driven thinking and creative exploration need to coexist.

 


Establishing a Team Contract

Based on these discussions, we worked together to create a team contract that everyone agreed to follow.

The contract clearly defines:

  • Our communication methods

  • How we collaborate as a team

  • Our decision-making process

  • How we handle conflicts

  • How data is stored and accessed

  • Our core working hours

  • What motivates us and our shared values

We also decided to have a group meeting every Tuesday and Friday to update on what we have done so far, or work on the project and team website together. Having this agreement in place helps set expectations early, reduces the risk of misunderstandings, and provides a shared reference point if challenges arise later in the project.

 


User Stories

After finalising the team contract, we shifted our focus to user stories. Using the user story structure, we began by defining the player’s needs and intentions. From there, we broke these needs down into specific tasks required to implement them.

We also discussed which tasks could be completed in the early stages of development, helping us prioritise work and align our efforts with the requirements of the vertical slice. This exercise made the scope of the project clearer and allowed us to plan more realistically for the upcoming sprints.

 


Tuesday Group Meeting:

Art Direction

During our Tuesday group meeting in Week 2, the two team members responsible for art began developing a mood board for the project. This process focused on collecting visual references to help define a consistent art style, colour palette, and overall atmosphere for Soul Keeper. Establishing this visual direction early on is important, as it provides a shared reference point for both artists and developers as production moves forward.

At the same time, Ollie took responsibility for documenting the team’s progress and uploading updates to the project website. This helped ensure that our development process was clearly recorded and accessible to everyone on the team.

Mechanics Prototyping

As the mechanical designer, I set up our project’s GitHub repository and invited all team members to join. This was an important step in preparing for collaborative development, allowing us to manage version control and work efficiently within a shared Unity project.

Engine Comparison

I also began early prototyping in Unity, using Swan’s environment concept art as a reference to block out the scene. At this stage, the focus was on functionality rather than visual polish. I implemented basic WASD movement for the player character, creating the foundation for navigation and interaction within the game world.

 


Organising Tasks with a To-Do System

During the Thursday session, our team focused on turning our previously defined user stories into actionable work. We took the tasks we had broken down from each user story and placed them on a to-do list. To visualise progress clearly, we divided a large sheet of paper into two sections: To Do and Complete.

Whenever a task was finished, it was physically moved from To Do to Complete. This simple system made progress visible to everyone in the team and helped maintain motivation, as we could clearly see work being completed over time.

 


Scheduling Key Project Events

We then wrote down upcoming weekly project events, such as presentations, studio sessions, and playtesting, onto a calendar. This allowed us to keep important milestones visible and ensured that deadlines were not treated as isolated moments, but as part of a broader development timeline. Having these events clearly mapped out helped us plan work more realistically and avoid last-minute pressure.

 


Weekly Roadmap

After setting up the task board and calendar, we created a roadmap organised by week. For each week, we identified what needed to be achieved in order to move the game forward and placed these goals into the corresponding sections of the roadmap. This included development targets, testing phases, and preparation for feedback or presentations.

By doing this, we gained a clearer overview of the project as a whole. It allowed us to assess when specific tasks should be completed, how much progress was expected at each stage, and where our sprint points were located. Looking at the project through multiple lenses: task completion, progress level, and milestone timing. That made it easier to decide what to prioritise and when.

Leave a Reply

Your email address will not be published. Required fields are marked *