Lesson 1 – Production Skills

On the Monday of Week 2 we had a guest lecture given by Paul MacGillivray, a project manager who has worked for large projects such as Horizon Zero Dawn. This lesson was invaluable for me being the technical lead of my game as managing the scope and time of our project would be invaluable in the coming months.

We were first introduced to the Production Triangle that weighed up Cost vs. Time vs. Scope. For example, games that have been famously unpolished or buggy on release such as Cyberpunk 2077 (2020) suffered from an extremely large scope of a fully open world immersive RPG, at the expense of having a very high cost to make and ultimately not enough time, resulting in features being cut and many bugs being present on launch.

Assessing Scope

Getting an idea for the scope of the game is done by breaking down the key features of the game into deliverables, essentially a list of sub-systems for each system in the game. These are then further down broken into tasks for each step towards achieving these deliverables.

For example, one deliverable of a singular game character would be:

• Concept Art
• Model
• Texture
• Rigging
• Porting to Engine

Then the time for each task needs to be estimated and assigned to a member of the team in order to work on multiple deliverables concurrently. We were advised not to over-assign work to ourselves or others as this can lead to overall reduced productivity for the team as a whole. Paul also suggested being liberal with time estimations, as building in extra time is always better than cutting it close.

It is also important to give tasks a priority. Naturally, higher priority tasks must be completed before lower priority ones.

Stages of Development

• Pre-prod – Planning and prototyping
  • Get data to plan out rest of dev
  • Prove core is good enough to proceed
  • Working towards vertical slice
• Prod – Building the game
• Alpha – First content pass
• Beta
• Release
• Post-Launch

Planning for Contingency

Things will not always go to plan in development, so time at the end should always be built in for fixing bugs and polishing the game. Paul recommended at least two weeks before our project’s deadline for this.

Tools

The primary tool recommended was using whiteboards, either physical ones or online, such as on Miro or Figma. Google Sheets can also be a valuable planning tool for assigning people tasks as well as managing certain aspects of the game. We were also recommended the tool Jira as a professional task-tracking software used in the industry with full compatibility with Miro, with Trello also being a good pick as it is more user friendly.

Lesson 2 – Project Management

In this lesson we were taught by Sophie about how we should manage our project, what features to prioritise and ensure there is an enjoyable finished project at the end.

User Stories

We first discussed the need to write user stories for features, in the format of “As a [user], I want [feature] so that [outcome]”. For example, some examples of user stories for Oh, Rats! would be:

• As a player, I want to upgrade my abilities so that I can feel a sense of progression.

User Retention

When developing, playtesting is vital throughout in order to track user retention. This includes understanding and taking note of any pressure points and frustrations players have when playing your game and let that inform the project management.

Focusing on what the player sees (a.k.a not focusing too much on hidden systems first if their impact is not immediately noticeable to the player) as well as what they want is vital for a project like this.

Crisis Management

In a project like this a crisis that endangers development time is inevitable. Therefore having preliminary measures against it to minimise impact is important.

This was especially important for our game, as the absence of one of our members up to this point already meant it has impacted our project planning without, for example, concept art.

There are multiple ways to plan ahead so the impact of any crises is minimised. The first is to consider the skill level of each member of the team, and plot them against the development goals and potential features of the project. Under time constraints, the features that require skill sets in the team’s weak points should be the first to consider cutting.

It is also important to write down all the possible risks to the project, their time impact, and what can be cut in their place to make up for it. We were also reminded that recovery is not the same as rest. Recovery from a crisis cannot take away from time for rest, as dedicated rest time is always necessary to work at peak performance.

Also stressed was the importance of knowing our limits, and to be able to give our team a heads-up of them ahead of time. Ideally we should be able to say “near enough” and prematurely get to a minimum deliverable product, but sometimes it is necessary to say “i’m out” if need be but still be able to negotiate with the team as to how the work can be finished, or what needs to be cut.

At the end we were given the most important lesson, that being:

The Best Game is a Finished Game