2.3 Discuss considerations for selection of game-engine software with required personnel and confirm selection will meet specified outcomes

Who are the required personnel?

Performance Criterion 2.3 requires you to discuss considerations for selection of game-engine software with required personnel and confirm that the selection will meet specified outcomes. Required personnel are the people whose work, approval or expertise is needed for the decision. In a student project this may be a trainer, technical mentor, project lead and team members. In a workplace it may include discipline leads, producer, technical director, art director, QA lead, IT/security staff, publisher representative or client.

Each role looks at engine selection differently:

• Producer/project manager: schedule, budget, staffing, licensing, milestone risk and delivery evidence.
• Technical lead/programmer: architecture, scripting language, performance, debugging, build pipeline and maintainability.
• Design lead: prototyping speed, visual scripting, level editing, iteration and gameplay system flexibility.
• Art lead/technical artist: import pipeline, materials, lighting, animation, VFX and asset optimisation.
• Audio lead: spatial audio, middleware support, mixing and platform output.
• QA/test lead: automation, build stability, bug tracking, platform coverage and profiling.
• IT or systems support: hardware requirements, installation, accounts, storage, backups and security.
• Client/publisher/trainer: specified outcomes, assessment requirements, platform expectations and legal compliance.

Preparing for the discussion

Before meeting, provide a concise evidence pack:

1. game concept and prioritised requirements
2. comparison matrix of candidate engines and tools
3. key risks and assumptions
4. proof-of-concept findings if available
5. cost and licence summary
6. recommended option and alternatives.

This preparation keeps the discussion focused on outcomes rather than opinions. It also lets people prepare questions from their own discipline. For example, an art lead can test an asset import assumption, while the producer can check whether training time has been included in the schedule.

Example

A student team proposes Unity for a 3-D escape-room game because all programmers know C#. The art lead raises concerns about lighting quality and importing assets from Blender. The producer raises a schedule concern about learning Unreal. The trainer asks whether the chosen tools meet the unit requirement for complex 3-D interactivity. The team tests a representative room scene in Unity, documents lighting settings and confirms that the target interactions can be built within the schedule.

Common mistakes

Do not consult only people who agree with your preference. Do not present a decision as final before discussing constraints. Do not overload non-technical stakeholders with raw feature lists; translate capability into production impact. For example, "engine supports behaviour trees" becomes "enemy patrol and alert states can be implemented using built-in visual debugging, reducing AI troubleshooting risk."

Another mistake is treating consultation as a single meeting after all decisions are made. For non-routine 3-D development, consultation is iterative: initial review, risk testing, decision confirmation and later review if requirements change.

What to discuss

A selection discussion should test whether the proposed game-engine software and tools can meet the specified outcomes. The discussion should cover creative, production and technical requirements together because they affect each other.

Key considerations include:

• Creative fit: Does the engine support the visual style, interaction style, camera, animation and world design?
• Technical fit: Can it deliver required gameplay systems, performance, networking, build targets and debugging?
• Production fit: Can the team learn and use it within schedule and budget?
• Asset pipeline: Do DCC, audio and UI tools integrate cleanly?
• Hardware fit: Can development and target devices run the editor and final build?
• Legal/commercial fit: Are licences, asset rights, privacy obligations and distribution terms acceptable?
• Support fit: Are documentation, community, training resources and local expertise sufficient?

Structured discussion agenda

Use a simple agenda to keep the meeting productive:

1. Restate the game concept and specified outcomes.
2. Confirm must-have play requirements and target platforms.
3. Present shortlisted engines and the comparison matrix.
4. Discuss risks by discipline: design, code, art, audio, QA, production and legal.
5. Review proof-of-concept results or decide what prototype evidence is still needed.
6. Agree on decision criteria and weighting.
7. Confirm next actions, owners and deadlines.

Communicating trade-offs

Trade-offs should be framed honestly. For example:

• Unreal may improve high-fidelity rendering and cinematic tools but increase hardware demand and learning overhead.
• Unity may improve team productivity and C# workflow but require more third-party packages for certain high-end visual features.
• Godot may improve openness and lightweight development but require careful validation for complex 3-D production and platform release needs.

Use plain language when discussing trade-offs with non-specialists. "GPU-bound due to dynamic shadows" can be explained as "the visual approach may reduce frame rate on the target laptops unless we simplify lighting or use baked shadows." This helps clients, trainers and producers make informed decisions.

Workplace example

A Gold Coast studio is choosing an engine for a VR safety training game for a mining client. The designer wants high interaction fidelity, the technical lead focuses on VR frame-rate stability, and the client wants deployment on specific headsets. The team discusses Unity and Unreal using prototype tests. They confirm that visual quality is less important than stable VR performance and rapid iteration of training scenarios. This changes the weighting of the decision.

WHS and communication

Respectful consultation is part of good workplace practice. Avoid blame-based discussions and unrealistic overtime assumptions. Under WHS duties, workplaces must manage psychosocial and ergonomic risks as far as reasonably practicable. A tool choice that forces chronic crunch, unstable builds or excessive manual rework should be treated as a production risk, not a badge of commitment.

What confirmation means

To confirm selection will meet specified outcomes, you need more than verbal agreement. Confirmation means the required personnel accept, based on evidence, that the chosen engine and tools can support the required game outcomes within known constraints. It may still include risks, but those risks must be understood and managed.

Specified outcomes may come from a client brief, assessment brief, production plan, publisher milestone or internal prototype goal. They might include a playable 3-D level, specified platforms, target visual style, interaction systems, performance expectations, accessibility needs or documentation requirements.

Evidence for confirmation

Useful evidence includes:

• a completed requirements-to-engine mapping
• comparison matrix with weighted scores
• proof-of-concept prototype results
• sample asset import tests
• target hardware performance notes
• licence and cost review
• build/export test
• risk register and mitigation plan
• meeting minutes or approval record.

Proof of concept

A proof of concept should test the riskiest assumptions, not build the whole game. Examples:

• one playable room with final-style lighting and interactable props
• one networked character moving between two clients
• one imported rigged character with animation blend and controller input
• one VR scene running at a stable comfort-focused frame rate on target headset
• one build exported to the required platform.

Acceptance criteria

Define how you will know the engine is acceptable. For example:

• The engine imports the representative character, materials and animations with no blocking defects.
• The greybox level runs on the target laptop without severe stutter during normal play.
• The team can create, commit, pull and resolve changes through version control.
• The engine licence and asset licences allow the planned assessment or release use.
• Required personnel agree that remaining risks have owners and mitigation steps.

Confirmation should also state any conditions. A conditional approval might say the engine is approved only if the project uses a specific render pipeline, avoids unsupported plugins, or limits the first release to Windows. Conditions are not weaknesses; they are controls that keep the selection aligned with outcomes.

Example

A Canberra studio is developing a small 3-D serious game for emergency response training. They prefer Unreal for visual realism. Before confirmation, the QA lead requests a Windows build, the art lead requests an asset import test, and the producer requests a licence and hardware check. The proof of concept shows acceptable performance on the client's machines after disabling expensive lighting features. The team confirms Unreal with a condition: lighting must use the tested scalable settings, not unrestricted cinematic settings.

Common mistakes

Do not treat "we can probably make it work" as confirmation. Do not ignore negative prototype results. If evidence shows the engine struggles with a must-have requirement, either change the engine, change the requirement through approved scope control, or plan a credible mitigation.

Handling conflicting views

Engine selection often creates disagreement because each role values different outcomes. A technical artist may prioritise material workflow, a programmer may prioritise debugging, and a producer may prioritise schedule certainty. Your role is to keep the discussion tied to the specified game outcomes and documented criteria.

Decision techniques

Use structured methods such as:

• Weighted decision matrix: score each engine against agreed criteria, with higher weight for must-have requirements.
• Risk register: record likelihood, impact, mitigation, owner and review date for each risk.
• Decision log: record what was decided, who approved it, evidence used and conditions attached.
• Prototype gate: require a proof of concept before final approval where risk is unresolved.
• Change control: if requirements change after selection, reassess whether the engine still fits.

Example conflict

A small Hobart team is split between Unreal and Unity for a stylised 3-D action game. The artist wants Unreal's lighting and material tools. The programmer wants Unity because the team already knows C#. The producer worries about schedule. The team agrees on weighted criteria: core gameplay implementation 30%, asset pipeline 25%, performance on target laptops 20%, team skill 15%, licensing/cost 10%. A two-day prototype shows Unity can achieve the required stylised look and faster iteration. The team selects Unity, while documenting a risk that advanced VFX may need asset store packages or custom shaders.

Contingencies

If no engine clearly meets all outcomes, you have options:

1. Reduce scope with approval, such as fewer dynamic lights or simpler AI.
2. Add tools or middleware, such as FMOD for audio or a networking solution.
3. Increase schedule or training time if the project can support it.
4. Change target platform or minimum hardware.
5. Select a different engine and accept retraining cost.

Each option must be discussed with required personnel because it changes production commitments. If the change affects a client contract, assessment brief or publisher milestone, it may require formal approval rather than an informal team agreement.

Documentation expectations

For VET assessment and workplace practice, keep evidence of consultation. This may include meeting notes, comments in a shared document, LMS discussion posts, signed-off comparison tables or project management tickets. The aim is not bureaucracy for its own sake. Documentation protects the project by showing why the decision was reasonable at the time.

Common mistakes

Avoid consensus by silence. If an art lead or programmer has not reviewed the decision, do not assume agreement. Also avoid locking the choice permanently when major requirements are still unknown. Complex 3-D games are non-routine projects; good teams make decisions based on current evidence and revisit them when new evidence changes the risk profile.