4.3 Test and run game prototype as a presentation and confirm sequences meet creative, production and technical requirements

What a prototype presentation must prove

Testing and running a prototype as a presentation means showing the intended gameplay sequence in a controlled, reviewable form. The goal is not to pretend the game is finished. The goal is to demonstrate that the current prototype meets agreed creative, production and technical requirements well enough for decision-making.

A presentation may be delivered to a client, assessor, producer, creative director, publisher, playtest group or internal team. In an online course, it may involve a screen recording, live screen share, packaged build or submitted playable file. Whatever the format, the sequence must be prepared and checked.

Define the presentation sequence

A sequence is the ordered flow of events you expect the reviewer to see. For example:

1. Main menu or start screen loads.
2. Player spawns in the test level.
3. Player learns movement and camera.
4. Player collects first item.
5. Objective UI updates.
6. Player avoids hazard.
7. Player unlocks exit door.
8. Completion screen appears.

Write this sequence before the presentation. It becomes the basis for testing. It also helps you identify critical path elements: if the collectible counter fails, the exit door cannot be shown; if the player spawn is wrong, the whole demonstration starts badly.

Preparing the prototype

Use this preparation procedure:

1. Select the correct scene or level. Remove old test scenes from the presentation path unless they are needed.
2. Set a reliable start state. Confirm spawn position, camera, player health, inventory, objectives and UI.
3. Check required assets are included. Missing materials, audio, fonts or shaders can appear only in a build if references are wrong.
4. Remove disruptive debug content. Keep useful diagnostic overlays only if the review requires them.
5. Confirm input mappings. Test the actual keyboard, mouse, controller or other hardware to be used.
6. Check quality settings and resolution. Use settings appropriate for the target hardware and presentation context.
7. Run from start to finish. Do not test only isolated sections.
8. Package or record correctly. If submitting online, follow LMS file size, format and naming requirements.

Presentation-ready is not the same as finished

A prototype may contain placeholder art, incomplete menus or limited content and still be presentation-ready if those limitations are known and do not block the sequence. However, avoid presenting random editor clutter, broken console errors, missing references or untested controls. A rough but stable prototype is more useful than an ambitious but unreliable one.

Workplace example

A Gold Coast studio prepares a vertical slice prototype for a publisher meeting. The creative goal is to show traversal and environmental puzzle solving. The production goal is to secure feedback before further funding. The technical goal is a Windows laptop build with controller support.

The team creates a locked presentation path: spawn, tutorial prompt, climb section, pressure plate puzzle, door open, vista reveal. They test the sequence on the actual laptop used in the meeting, not only on the development workstation. They also prepare a short gameplay video as backup in case hardware or screen-sharing fails.

Risk controls and contingencies

Presentation risk is real production risk. Controls include:

• keeping a known-good build archived;
• rehearsing the sequence;
• having a backup input device;
• preparing a video capture if live play fails;
• documenting known issues before the review;
• avoiding last-minute untested changes;
• checking audio levels and screen capture settings for online delivery.

For WHS, do not create rushed all-night build sessions as a normal practice. Fatigue increases errors and can create unsafe work habits. Good scheduling and earlier testing are safer and more professional.

Editor testing versus build testing

Game engines support quick in-editor testing, such as Play mode in Unity or Play In Editor in Unreal. This is essential for iteration. You can adjust values, inspect objects, read console output and quickly retry.

However, editor testing is not enough for presentation validation. The editor includes tools, debug systems and resources that may hide build problems. A packaged build may use different quality settings, file paths, input handling, shader compilation, scene inclusion, permissions or performance characteristics.

For performance criterion 4.3, you must test and run the prototype as a presentation. That means checking both the development environment and the presentation form.

A practical testing pass

Use this sequence:

1. Clear known compile errors. A prototype with script compilation errors is not ready for presentation.
2. Run in editor from the intended start point. Check core sequence and console warnings.
3. Fix blocking defects. Prioritise defects that stop the sequence or misrepresent the creative goal.
4. Create a packaged build or approved presentation output. Include required scenes and assets.
5. Run the packaged build on target or comparable hardware. Do not assume your development machine represents the review environment.
6. Complete the full sequence without developer shortcuts. Use normal player input, not editor object dragging or inspector changes.
7. Record results. Note pass, fail, known issues and build version.
8. Repeat after changes. Any fix can introduce regression.

What to watch for

During a run, check:

• startup time and whether the correct scene loads;
• screen resolution, aspect ratio and UI layout;
• mouse capture, controller recognition and input prompts;
• missing assets, pink materials, silent audio or wrong animations;
• collisions, triggers and physics sequence reliability;
• save, reset, checkpoint or restart behaviour;
• console errors, warnings or log spam;
• frame drops during the planned presentation moments;
• end state, completion screen or transition.

In Unity, simple diagnostic messages can be sent to the Console during Play mode, and many engines provide equivalent logging. Use logs to confirm event order, but remove excessive debug output before formal presentation unless it is needed for technical review.

Hardware and software product features

The hardware and software products used for gameplay affect test outcomes. A keyboard-and-mouse PC game may depend on cursor lock, key rollover, mouse sensitivity and display resolution. A controller game depends on button mapping, analogue stick dead zones, vibration support and platform driver recognition. VR or AR projects add headset tracking, motion controllers, comfort and safety considerations.

Software features also matter: operating system, graphics API, engine version, render pipeline, installed redistributables, browser support for WebGL/WebGPU builds, and audio device selection. Always test the presentation setup, not just the project file.

Workplace example

A Newcastle team prepares an online assessment prototype for a 3-D puzzle game. In editor mode, the prototype works. In the packaged build, the second level does not load because it was not included in build settings. The UI also scales poorly on a laptop screen.

The team updates the build scene list, tests UI anchors at the target resolution, creates Build 0.4, and records the fix in the development log. This confirms that the sequence meets technical requirements in the actual presentation form.

Common mistakes

Do not make a build for the first time on submission day. Build errors, missing scenes and platform settings are normal development issues. Do not test with cheats or editor-only shortcuts unless the presentation explicitly includes a debug demonstration. Do not ignore warnings that appear repeatedly; log spam can hide important errors and reduce performance.

If the build fails close to presentation, use a planned fallback. This may be an archived stable build, a recorded video, or a reduced sequence that still demonstrates the core mechanic. Record what changed and what remains unresolved.

Confirming the creative sequence

A prototype sequence should communicate the intended experience. Creative confirmation asks: does the run show the game idea clearly?

For a stealth prototype, the sequence might need to show hiding, enemy awareness, sound distraction and escape. For a puzzle prototype, it might need to show rule discovery, experimentation, consequence and success. For a training simulation, it might need to show the correct workplace decision and feedback.

Check the sequence against creative requirements:

• Is the player goal clear at the right time?
• Do camera, lighting, audio and UI support the intended mood?
• Are interactions readable before the player commits to them?
• Is feedback immediate enough to feel responsive?
• Does the challenge level match the prototype purpose?
• Does the sequence avoid confusing or misleading content?

A prototype can fail creatively even if it is technically functional. For example, if the player cannot see the required lever because lighting is too dark, the puzzle is not communicating properly.

Confirming production requirements

Production confirmation asks whether the sequence is suitable for the milestone. It includes scope, schedule, asset status, team responsibilities and review purpose.

Before presentation, confirm:

• which features are included, excluded or placeholder;
• whether the sequence fits the allocated review time;
• whether known issues are acceptable or must be fixed;
• whether required assets are final, temporary or third-party;
• whether the build or recording is named and versioned correctly;
• whether review notes, controls and instructions are ready.

Use plain, professional language. Instead of saying “the AI is broken”, say “Enemy patrol has placeholder pathing; current review focus is player interaction and objective flow.” This helps stakeholders judge the prototype fairly.

Evaluating pacing and clarity

Run the sequence as a player, not as the developer who already knows every shortcut. Ask:

1. Can a first-time player identify where to go?
2. Does each event occur in a logical order?
3. Are objectives updated after actions?
4. Are failure states explained?
5. Is the camera helping or fighting the player?
6. Are there long dead periods without purpose?
7. Does the ending of the sequence feel complete enough for review?

Where possible, ask another person to play or watch. In an online course, this could be a peer review session or recorded playthrough with timestamped comments. Fresh eyes reveal assumptions that developers miss.

Workplace example

A Darwin studio is building a 3-D cyclone preparedness serious game. The prototype sequence requires the player to secure outdoor items, check a radio and move indoors. Technically, the interactions work. Creatively, the first playtest shows learners do not realise loose items are clickable.

The team adds outline feedback, a short objective prompt and a sound cue when hovering over interactive objects. They also shorten a walking section that delayed the learning point. The revised sequence better meets the creative requirement: teach preparation actions clearly and efficiently.

Documentation for presentation

Prepare a short presentation note or build readme containing:

• build version and date;
• engine version;
• controls;
• intended sequence;
• creative goal;
• technical target;
• known issues;
• assets or licences that require attribution;
• contact or submission details.

This is especially important for online delivery because the assessor or stakeholder may run the prototype without you present.

Common mistakes

Do not hide known limitations. Stakeholders can make better decisions when they know what is placeholder, blocked or out of scope. Do not over-explain the design during the run to compensate for unclear gameplay; the prototype should communicate core actions through its own feedback where possible.

Also avoid making major creative changes immediately before presentation unless they are necessary. Last-minute changes can break sequence reliability. If a change is important but risky, record it as a recommendation for the next iteration.

Technical readiness for presentation

Technical confirmation asks whether the prototype runs reliably enough in the required presentation environment. It does not require commercial polish, but it does require controlled evidence that the sequence works.

Check technical requirements such as:

• engine version and project dependencies;
• target operating system or platform;
• minimum expected hardware for the cohort or client;
• required input devices;
• resolution, aspect ratio and UI scaling;
• audio output and volume balance;
• asset formats and included files;
• performance during key moments;
• build settings, scene list and quality settings;
• accessibility or usability requirements stated in the brief.

If the brief includes accessibility expectations, treat them as real requirements. Examples may include readable text size, remappable controls, captions for essential audio, colour-independent feedback or reduced motion options. Do not invent requirements, but do not ignore those supplied by the client, assessor or studio.

Defect triage before presentation

You will rarely have time to fix every issue. Use triage:

• Blocker: prevents the presentation sequence from running. Fix or use fallback.
• Critical: seriously misrepresents gameplay or causes frequent failure. Fix if at all possible.
• Major: affects quality or clarity but has a workaround. Fix if time allows.
• Minor: cosmetic or low-impact. Record for later.

Priority depends on the presentation goal. A missing final texture may be minor in a mechanics review but major in an art direction review. A small input bug may be critical if the stakeholder will play live.

Build freeze and change control

Before the final presentation, set a build freeze point. After this time, only approved fixes should enter the presentation build. This reduces the risk of last-minute regressions.

A practical build freeze process:

1. Create a release candidate build.
2. Run the full sequence test.
3. Record pass/fail results.
4. Fix only approved blockers or critical defects.
5. Rebuild and retest affected sequence areas.
6. Label the final build clearly, such as `Prototype_Warehouse_v0.5_Presentation`.
7. Archive the build, test notes and source commit or project backup.

This is a scaled-down version of industry release management and is appropriate even for student prototypes.

Evidence of testing

For assessment and workplace accountability, keep evidence. This may include:

• completed test checklist;
• issue tracker export or screenshots;
• build version notes;
• profiler screenshots;
• screen recording of the successful sequence;
• source control commit ID;
• peer review feedback;
• list of known limitations.

Evidence is useful if a stakeholder reports a later problem. It shows what was tested, on what version and under what conditions.

Australian workplace and legal context

For a presentation build, compliance still matters. Ensure you have the right to distribute any included third-party assets, even to a small review group. Check software licence terms for engine plugins and marketplace content. If the prototype collects player data during testing, privacy obligations may apply; in Australia, organisations covered by the Privacy Act 1988 must handle personal information appropriately. For most student prototypes, the safest approach is to avoid collecting personal data unless the assessment specifically requires it and approved processes are in place.

WHS also applies to presentation sessions. If testing VR or motion-heavy content, consider physical space, trip hazards, motion sickness and supervision. For standard desktop work, manage screen time, posture and fatigue.

Workplace example

A Launceston game team prepares a 3-D controller-based prototype for an investor demo. The final test finds a major issue: if the controller disconnects, the game cannot return to keyboard input. Because the investor will play with a controller, the team treats it as critical. They add a simple input reconnection prompt, retest the sequence, and freeze the build. A lower-priority texture seam is recorded but not fixed before the demo.

This shows professional prioritisation: the team protects the presentation sequence and technical requirement rather than chasing every visible imperfection.

Common mistakes

Do not submit an unversioned folder called “FinalFinal2”. Do not rely on cloud sync as your only backup minutes before submission. Do not change engine versions immediately before a presentation unless required; upgrades can alter packages, rendering, physics or script behaviour. Do not delete old stable builds until the new build has been tested.