5.3 Discuss and agree on required changes

Why discussion is required

After evaluating the prototype, the team must discuss and agree on required changes. This is a collaborative production activity. Feedback does not automatically become a task list. Some comments conflict with the design vision, some are outside scope, some are symptoms rather than causes, and some are essential before the project can continue.

Prepare for the change discussion by converting evaluation findings into change themes. For example, raw feedback might include 'camera clips', 'enemy hard to see', 'corridor too narrow' and 'combat feels unfair'. These may belong to one theme: spatial readability during combat. Grouping helps the team solve causes rather than patch every comment separately.

Bring the right information

For each proposed change, prepare:

• The evidence: who observed it, what happened and in which build.
• The affected criterion: creativity, user-friendliness, technical feasibility, production scope or risk.
• Severity: blocker, major, moderate or minor.
• Options: possible ways to address the issue.
• Impact: likely effect on time, cost, assets, code, testing and other tasks.
• Dependencies: whether the change affects the critical path.

This preparation allows the discussion to stay practical. For example, 'Make the world bigger' is not a workable change until the team understands whether the problem is exploration depth, camera scale, level pacing, art density or player expectation.

Prioritisation methods

Use a simple prioritisation method appropriate to the project. Common approaches include:

• MoSCoW: Must have, Should have, Could have, Will not have for now.
• Impact versus effort: high impact and low effort items are usually early wins.
• Risk-first: tackle changes that reduce technical or critical path uncertainty.
• Milestone readiness: focus only on what is required for the next gate, such as user trials or publisher review.

At Diploma level, you should understand trade-offs. A change that improves creativity may increase production risk. A change that improves usability may reduce mystery or challenge if handled poorly. A technical simplification may preserve schedule but reduce the distinctive hook. The discussion must make these trade-offs visible.

Workplace example

A Hobart team receives feedback that players enjoy climbing giant machinery in a 3-D platformer but frequently fall because depth is hard to judge. Proposed changes include adding a shadow blob, changing camera angle, widening platforms, adding ledge grab and adding a full tutorial level. The team decides the required prototype change is to add ledge grab and improve camera framing because those directly address user-friendliness without expanding level scope too much. A tutorial level is deferred.

Common mistakes

Do not enter the meeting with a hidden decision already made. Also avoid treating every change as equal. A change that unblocks testing may be required now, while a cosmetic improvement can be scheduled later.

Agree on the problem

A productive change discussion starts by agreeing on the problem, not the solution. If players fail the first encounter, one person may suggest lowering enemy damage, another may suggest better animation telegraphs, and another may suggest a tutorial. Each solution assumes a different cause. Ask: what evidence do we have? Did players not understand the controls, misread enemy intent, lack enough resources, or simply face a challenge above the intended difficulty?

Use the evaluation criteria to keep the discussion anchored. A change is required when the prototype does not meet an agreed criterion or when a risk must be reduced before further production. A change may be optional when it improves preference but does not affect milestone readiness.

Compare solution options

For each major issue, compare at least two realistic options. A useful comparison includes:

• Design effect: how the option changes player experience.
• Technical effect: code, engine feature, performance and platform impact.
• Asset effect: new models, animations, UI, audio or format changes.
• Testing effect: what must be retested after the change.
• Schedule effect: how it affects current tasks and the critical path.
• Risk effect: what uncertainty remains.

For example, if a 3-D game prototype has poor navigation, options may include adding a minimap, changing level layout, adding landmarks, improving lighting contrast or adding objective markers. A minimap may require UI programming and art; level layout changes may affect greybox work; lighting changes may affect performance. The best option depends on criteria, not personal taste alone.

Professional negotiation

Game teams include different disciplines with legitimate priorities. Artists may protect visual coherence, programmers may protect maintainability, designers may protect player experience, and producers may protect schedule. Use respectful language and evidence. Say 'The user trial evidence suggests players are missing the exit because the silhouette blends into the wall' rather than 'The art is wrong.'

If disagreement remains, escalate according to the project governance. The creative director, product owner, producer or trainer may make the final call. Record the decision and any known risk. Agreement does not always mean everyone personally prefers the option; it means the required personnel accept it as the project direction.

Australian workplace context

Professional communication also includes inclusive behaviour. Online teams should make space for quieter participants, avoid discriminatory comments and keep records in agreed systems. If feedback sessions include external participants, keep commercially sensitive information secure and follow any non-disclosure or client confidentiality requirements.

Common mistakes

Avoid solution jumping. Also avoid accepting a change without checking dependencies. A small UI change can require input remapping, localisation preparation, save data changes or new controller prompts. Required changes must be realistic within the production plan.

Agreement must become a production record

A change is not truly agreed until it is recorded in a form the team can action. In game development, agreed changes usually become tickets, backlog items, change requests, task cards or sprint work. The exact tool may be Jira, Trello, Azure DevOps, GitHub Issues, a spreadsheet or the LMS project area. The principle is the same: the decision must be visible, traceable and testable.

A strong change item includes:

• Title: short and specific.
• Reason: linked to evaluation evidence and criterion.
• Owner: the person or role responsible.
• Priority: must, should or could; or blocker, high, medium, low.
• Acceptance criteria: how the team will know the change is complete.
• Dependencies: assets, code systems, engine settings, other tasks or approvals.
• Estimate or timebox: expected effort or maximum investigation time.
• Test requirement: what must be retested.
• Version target: the build or milestone where it should appear.

Example: 'Improve third-person camera collision in corridor combat. Reason: players lost sight of enemies in build 0.3, failing user-friendliness criterion. Owner: gameplay programmer. Acceptance: camera no longer clips through corridor walls in test arena; player and nearest enemy remain visible during dodge in 8 of 10 standard test passes; no new severe motion discomfort reports. Retest: combat readability user trial.'

Update the production schedule

Changes affect scheduling. Use production and testing scheduling techniques such as milestone plans, sprint boards, dependency maps and test windows. If a required change affects the critical path, adjust the schedule before work begins. For example, if the player controller must be rewritten, level design, animation tuning and user trials may all need to move.

Manage scope

Not every agreed idea belongs in the prototype phase. Use a change log to record accepted, deferred and rejected items. Deferred items are not forgotten; they are scheduled for later review. Rejected items should include a reason, such as outside target audience, too costly for milestone, conflicts with creative direction, unsupported by evidence or dependent on unproven technology.

Version control and asset integration

When changes involve scripts, scenes, prefabs, materials, animation controllers or imported assets, use version control and naming conventions to reduce integration problems. Avoid changing shared assets without notifying affected team members. Asset format issues, such as incorrect scale, missing textures, incompatible rigs or oversized files, should be recorded as integration tasks rather than hidden inside general design tickets.

Common mistakes

A common failure is writing vague tasks such as 'Fix combat' or 'Make it better'. Another is forgetting to update test plans after changes are agreed. If a change alters controls, UI or core mechanics, previous feedback may no longer apply and the affected areas must be retested.

What agreement looks like

The performance criterion requires that changes are discussed and agreed. Agreement means the required personnel understand the change set, accept the priorities and recognise the consequences. It is not enough for one developer to start altering the build after a conversation. For a prototype moving toward full product, uncontrolled changes can destroy the evaluation baseline and create new risks.

Confirm agreement by summarising:

• Which changes are required before the next review or user trial.
• Which changes are deferred to full production or later milestones.
• Which suggestions are rejected and why.
• Who owns each action.
• What date or build target applies.
• What must be retested.
• What risks remain.

Then ask required personnel to confirm. In a workplace this may be approval in a meeting record, project board, email, milestone sign-off, sprint planning session or client review note. In an online learning project it may be confirmation through the LMS, team channel, project document or trainer feedback.

Manage conflict and baseline risk

Prototype teams can disagree strongly because the prototype represents both creative vision and technical investment. If conflict remains, use the project hierarchy and criteria. For example, if the lead artist wants dynamic shadows for mood but the technical lead shows they fail on target hardware, the group may agree to bake lighting or use stylised shader cues. The decision should be recorded as a production trade-off, not a personal win or loss.

Protect the baseline. A baseline is the agreed state of scope, build and plan at a point in time. Once changes are agreed, do not keep adding unapproved features during implementation. This is especially important before user trials. If the build changes unpredictably, trial results become hard to interpret because you cannot tell which change caused which outcome.

Example

A Gold Coast studio agrees to change a prototype before a publisher pitch. Required changes are: simplify inventory to three slots, replace a placeholder enemy with a greybox boss that tests the main mechanic, and cap the test level at five minutes. The creative director also wants weather effects, but the producer defers them because they do not affect the pitch criteria and would risk the build. The meeting record confirms the decision. The team now has a stable plan.

Common mistakes

Avoid silent agreement, where people say nothing in the meeting but later continue working to their own assumptions. Also avoid scope creep disguised as polish. If a change was not agreed, it should not enter the milestone build unless the required personnel approve it through the same process.