5.6 Confirm endorsement from required personnel and develop prototype into a complete product

What endorsement means

The final criterion requires you to confirm endorsement from required personnel and develop the prototype into a complete product. Endorsement is formal or documented approval that the prototype has met enough criteria to proceed. It may come from a creative director, producer, client, publisher, product owner, trainer, assessment supervisor or other required personnel named in the project process.

Endorsement is not the same as everyone saying they like the game. It means the required personnel accept the evaluation evidence, agreed changes, remaining risks and development plan. They are authorising the team to move from prototype uncertainty into fuller production work.

Forms of endorsement

Depending on the workplace, endorsement may be recorded as:

• A signed milestone approval.
• Email confirmation from authorised stakeholders.
• Approval in a project management system.
• Meeting minutes with action decisions.
• Client acceptance of a prototype milestone.
• Trainer or assessor approval in an LMS.
• Producer sign-off to enter vertical slice, alpha or production.

For an online learning project, keep endorsement in a retrievable location. A chat reaction alone is usually weak evidence unless the project process accepts it and it clearly identifies who approved what.

Conditional endorsement

Endorsement may be conditional. For example: 'Approved to proceed to full production provided the team resolves the camera collision issue before content expansion and completes a performance test on target laptops.' Conditional approval is common because prototypes rarely solve every issue. Record conditions as tasks with owners and dates.

What required personnel check

Before endorsing, stakeholders may check:

• The prototype meets creative and user-friendly criteria sufficiently.
• Major user trial feedback has been evaluated and addressed or scheduled.
• Technical feasibility is credible for the target hardware and engine.
• Production scope is realistic.
• Asset pipeline and integration risks are understood.
• Legal and licence issues are not blocking production.
• WHS, privacy and participant data obligations from testing have been handled.
• The next development stage has a plan, schedule and risk register.

Example

A Fremantle indie team presents a 3-D ocean survival prototype to a funding partner. The partner endorses progression to a vertical slice after reviewing playtest findings, a revised scope, proof that the water shader can run on target consoles, and a plan to replace temporary sound effects with licensed or original audio. Endorsement is recorded in meeting minutes and the milestone payment is released according to the contract.

Common mistakes

Do not assume endorsement because no one objected. Silence is not approval. Also do not proceed to full production while major required personnel are absent unless the project governance permits it. Confirm who has authority and record the approval.

From prototype to production

Once endorsement is confirmed, the team develops the prototype into a complete product. This does not mean simply adding more levels to the prototype project. Prototypes are often built quickly to test ideas. They may contain temporary code, placeholder assets, rough UI, duplicated scripts, unoptimised materials, hard-coded values and incomplete data structures. Moving to a complete product requires planning.

Start with a transition review:

1. Identify which prototype systems can be retained.
2. Identify which systems must be refactored, replaced or rebuilt.
3. Confirm the final creative direction and core gameplay loop.
4. Define production scope: levels, characters, mechanics, UI, audio, platforms and content volume.
5. Update technical requirements for target hardware and software.
6. Confirm asset pipeline, naming, formats, version control and integration process.
7. Build a production schedule with milestones and testing windows.
8. Update risk register and critical path.

Technical debt

Technical debt is the future cost created when quick solutions are used instead of robust ones. Prototype technical debt is normal, but it must be managed. For example, a gameplay programmer may have used hard-coded enemy values to test combat quickly. In production, those values should move into data assets, configuration files or editable components so designers can balance the game without changing code.

Basic programming techniques matter here: modular code, readable naming, separation of concerns, version control, comments where useful, data-driven design and error handling. Visual scripting should also be structured and documented. Messy prototype logic can slow production and increase bugs.

Protect the creative core

The endorsed prototype usually contains a creative core: the mechanic or experience that justified development. Production planning should protect that core while improving usability, reliability and content depth. Avoid expanding features so much that the original strength is diluted. If user trials showed that a simple grappling mechanic was the main delight, do not bury it under complex inventory systems unless the criteria support that direction.

Example

A Launceston team receives endorsement for a 3-D time-loop puzzle prototype. The time rewind mechanic works and players love it. Before full development, the team rebuilds the prototype scripts into a reusable event system, standardises puzzle asset prefabs, creates a level design template, and schedules performance tests. This avoids copying fragile prototype logic into every level.

Common mistakes

Do not keep all prototype shortcuts because they seem to work. Also avoid throwing everything away without analysis. Some prototype work may be valuable. The skill is deciding what to carry forward, what to clean up and what to replace before production scales.

Roadmap after endorsement

Developing the prototype into a complete product requires a roadmap. A roadmap translates endorsement into staged work. It should show what will be built, when it will be tested, which dependencies must be resolved and how the team will know each stage is ready.

Common game development milestones include:

• Vertical slice: a small section built to near-final quality to prove the full production approach.
• Alpha: major features and content are implemented, though not polished.
• Beta: content is largely complete and focus shifts to bug fixing, optimisation and balancing.
• Release candidate: build is considered ready unless serious issues are found.

Not every project uses these exact terms, but the development process should still include staged gates and testing. For a student project, milestones may be prototype endorsement, production plan, first complete level, content complete, test build and final submission.

Schedule testing from the start

Testing is not something added at the end. Include functional testing, user trials, performance testing, compatibility checks and regression testing in the schedule. If you add a new enemy system, schedule tests for AI behaviour, animation integration, difficulty, performance and player readability. If you add new assets, schedule import and optimisation checks.

Use critical path management. Identify tasks that block many others. Examples include player controller finalisation, save system, network architecture, character rig, level streaming, UI framework and target platform build pipeline. Delays in these tasks can delay the entire product. Address high-risk critical path items early.

Hardware and software requirements

A complete 3-D game must be planned for target hardware and software products. Consider input devices, screen sizes, GPU capability, CPU load, memory, storage, operating systems, platform storefront requirements and engine version support. Technical constraints affect creative decisions. For example, a mobile 3-D game may need simpler shaders, shorter sessions and touch-friendly UI. A PC game can assume different input precision and display space, but still needs scalable settings.

Documentation outputs

After endorsement, produce or update:

• Game design document or living design wiki.
• Technical design notes.
• Art and asset pipeline guide.
• Production schedule or sprint plan.
• Test plan and quality criteria.
• Risk register and issue backlog.
• Version control and build process notes.

Example

A Cairns team developing a 3-D reef exploration game uses the endorsed prototype to plan a vertical slice. The roadmap prioritises swimming controls, reef asset pipeline, low-end laptop performance and educational objective UI before adding more species. This aligns creative, technical and production requirements.

Common mistakes

Avoid planning only content creation while ignoring tools, testing and optimisation. Also avoid changing engine versions mid-production without a strong reason and rollback plan. Engine upgrades can fix issues but may break assets, plugins or scripts.

Endorsement is a starting point, not the end

After endorsement, development continues to involve evaluation. The endorsed prototype becomes a baseline for the complete product. The team should preserve what was approved while making planned improvements. If major changes alter the creative core, target user, platform or scope, you may need renewed approval from required personnel.

Maintain endorsement by tracking:

• Conditions attached to approval.
• Required changes not yet completed.
• New risks discovered during production.
• Scope changes and their impact.
• Test results and user trial findings.
• Technical debt reduction.
• Asset integration and performance status.

Regular reporting helps stakeholders trust the process. Reports do not need to be long, but they should show progress against milestones, open blockers and decisions needed. In online teams, written updates are especially important because informal studio conversations do not happen naturally.

Validate against the prototype promise

As production expands, a game can drift away from what made the prototype successful. New features, content and polish may add complexity that harms user-friendliness or performance. Keep asking:

• Does the complete product still deliver the creative hook that was endorsed?
• Are new systems supporting or distracting from the core loop?
• Is the product still user-friendly for the intended players?
• Are hardware constraints still being met?
• Has the asset pipeline remained manageable?
• Do user trials continue to support the direction?

Change control

Use a change control process for major shifts. A change request should describe the proposed change, reason, evidence, impact, risks and approval needed. This prevents uncontrolled scope creep. For example, adding online co-op to a single-player prototype is not a minor feature; it affects networking, UI, save data, testing, performance, schedule and possibly classification or platform requirements.

Legislative and industry considerations

As the product becomes complete, compliance responsibilities increase. Continue respecting software licences and asset licences. If the game collects player data, analytics or accounts, privacy obligations must be assessed. If the game will be distributed in Australia, classification requirements may apply under the National Classification Scheme. Accessibility, user safety, content warnings and platform policies should be considered early rather than after content is complete.

Example

A Melbourne studio endorsed a prototype because players loved fast movement through vertical 3-D spaces. During production, the team adds crafting, dialogue and inventory management. Later tests show the game has become slower and less readable. The producer uses the endorsement baseline to refocus scope: crafting is simplified, movement challenges return to the centre, and stakeholders approve the revised direction.

Common mistakes

Do not treat endorsement as permission to build anything. It is permission to develop the agreed product direction. Also do not wait until final submission to reveal major risks. Required personnel need timely information to make decisions.