2.4 Select game-engine software and development tools

What it means to select software and tools

Performance Criterion 2.4 requires you to select game-engine software and development tools. Selection is the formal outcome of the review, assessment and consultation process. It should identify the engine, version, supporting tools and any required conditions for use.

A complete selection statement includes:

• selected game engine and version or version range
• scripting language or workflow, such as C#, C++, Blueprint or GDScript
• DCC tools for models, textures, animation, UI and audio
• version control and repository structure
• build, profiling and testing tools
• required plugins, packages or middleware
• target platforms and build method
• licence conditions and asset-use rules
• hardware assumptions for development and testing
• risks, mitigations and decision owners.

Step-by-step selection process

1. Confirm the specified outcomes and must-have requirements.
2. Review shortlisted engine and tool evidence.
3. Confirm consultation with required personnel.
4. Check licence, cost, hardware and platform constraints.
5. Select the engine and tools that best meet outcomes with acceptable risk.
6. Record the rationale and rejected alternatives.
7. Define setup tasks, repository rules and onboarding resources.
8. Schedule the first technical validation milestone after setup.

Example selection statement

"The project will use Unity LTS with C# for a stylised first-person 3-D museum exploration game targeting Windows PC. Blender will be used for modelling, Substance Painter for textures, Reaper for audio, Git LFS for version control and Trello for task tracking. Unity is selected because it supports the required first-person interaction, asset pipeline, Windows builds and team C# capability within the assessment schedule. Risks include lighting quality and binary asset management; mitigations are a tested URP lighting style guide and Git LFS file-size monitoring."

A strong selection statement also names rejected alternatives. For example, "Unreal was rejected for this version because the visual benefits did not offset hardware demand and training time; Godot was rejected because the team had not validated the required 3-D asset pipeline." This shows the decision was comparative, not automatic.

Common mistakes

Do not write "we chose Unity" or "we chose Unreal" without version, tools and rationale. Do not select tools that team members cannot legally access. Do not ignore setup time; installing SDKs, configuring version control and importing packages can take significant effort. Do not select every attractive plugin. Each dependency adds maintenance, compatibility and licensing risk.

Workplace context

In an Australian workplace, the selected software must be used according to licence terms, copyright obligations and organisational IT/security policies. If tools require accounts, cloud services or telemetry, check whether personal or client data is handled appropriately. Selection should enable safe, lawful and efficient production.

The balanced selection principle

Knowledge Evidence requires understanding the creative, production and technical requirements of creating 3-D games. Final selection should balance all three. A technically powerful engine that the team cannot use effectively may be worse than a simpler engine that reliably delivers the intended play experience. Conversely, a familiar engine may be unsuitable if it cannot meet a must-have technical requirement.

Creative requirements

Creative requirements include visual style, mood, animation feel, camera language, world scale, interaction feedback, audio atmosphere and player accessibility. If the game relies on cinematic realism, advanced lighting and large environments, Unreal may be a strong candidate. If the game relies on stylised visuals, rapid iteration and broad platform output, Unity may be strong. If the game prioritises openness, simple tools and lightweight development, Godot may be appropriate if 3-D requirements are validated.

Production requirements

Production requirements include team skills, schedule, budget, remote collaboration, training resources, asset pipeline and testing effort. For an online cohort, a tool that runs acceptably on student-supplied hardware and has accessible learning resources is critical. For a studio, contractor availability and existing pipeline may matter more.

Technical requirements

Technical requirements include rendering, physics, AI, animation, networking, build targets, profiling, memory management, asset streaming and platform SDK support. Selection must also consider how hardware constraints affect these systems. If the game targets VR, stable performance and input support may outweigh maximum visual fidelity. If it targets mobile, build size, thermal load and scalable quality settings are central.

Use a minimum viable fidelity mindset. Choose the level of visual and technical ambition required to satisfy the player experience, not the highest fidelity the engine can theoretically produce. This protects production time and leaves capacity for testing, accessibility, polish and bug fixing.

Applied example

A Darwin-based education studio is making a 3-D interactive cultural heritage experience for schools. The creative goal is respectful, stylised exploration rather than photorealism. Production constraints include a small team and school laptop hardware. Technical needs include first-person navigation, hotspot interaction, narration audio and Windows/browser-friendly deployment. The team selects Unity with a lightweight render pipeline after consultation. Unreal's high-end visuals are rejected because they do not justify the hardware and training cost for this outcome.

Common mistakes

A common error is feature chasing: selecting the engine with the most impressive renderer even when the game requires simple interaction and reliable deployment. Another is comfort bias: selecting the engine the developer already knows without checking whether it supports the required assets, platforms or performance. A defensible selection explains why the chosen balance is right for this game.

Selecting asset tools and formats

Final selection must include development tools that support asset creation and integration. For complex 3-D games, the asset pipeline often determines whether production is smooth or chaotic. You should select not only the DCC tools but also formats, settings and workflow rules.

What to specify

Include decisions such as:

• modelling tool: Blender, Maya or another approved DCC tool
• texture tools and texture resolution limits
• animation source and export method
• preferred interchange format, such as FBX for skeletal animation or glTF for selected static assets where suitable
• audio format for source files and engine import
• naming conventions for meshes, materials, textures, animations and prefabs/blueprints
• folder structure inside the engine project
• import presets and scale settings
• LOD, collision and lightmap requirements
• version control treatment for large binary assets.

Version control selection

Game projects contain many binary files that do not merge like text code. Git can work for small teams if combined with Git LFS and clear locking rules. Perforce is common in larger studios because it handles large binary assets and file locking well. Unity Version Control may suit Unity-focused teams. Select based on team size, asset volume, hosting cost, learner access and technical support.

Asset integration example

A Newcastle student team selects Unreal for a 3-D boss arena. Their toolchain includes Blender for meshes, Mixamo only for prototype animations where licence terms permit, Substance Painter for final textures, WAV source audio, and Perforce for version control. They specify centimetre scale, FBX export settings, a naming convention such as SM_ for static meshes and SK_ for skeletal meshes, and a rule that marketplace assets must have licence notes stored in a Documentation folder.

Common mistakes

Do not leave each artist to choose arbitrary export settings. Inconsistent scale, pivots and material names create rework. Do not store only final engine assets and lose source files. Do not use compressed audio or texture formats as your only masters; keep editable source where practical. Do not ignore asset provenance. If you cannot prove you have rights to use an asset, do not include it in a project intended for assessment, portfolio or release.

Contingency planning

If integration tests reveal problems, adjust early. You might change export format, standardise on one DCC version, reduce texture sizes, simplify rigs, introduce import presets or select a different version control system. The aim is to prevent asset pipeline failures from appearing late in production.

For assessment evidence, keep screenshots or notes from import tests, including problems found and settings chosen. This proves that your selected tools were tested against the actual game asset needs rather than assumed to work.

Final documentation

A selected engine and toolchain should be documented so the team can implement it consistently. This documentation also provides evidence for assessment. It should be concise but complete enough that another team member can set up the same environment and understand the rationale.

Your final selection document should include:

1. Project summary: game concept, target platforms and specified outcomes.
2. Selected software: engine, version, tools, plugins and services.
3. Rationale: how the selection meets creative, production and technical requirements.
4. Evidence: comparison matrix, consultation records and prototype results.
5. Constraints: hardware assumptions, licences, platform limits and asset rules.
6. Workflow setup: repository, folder structure, naming conventions and build process.
7. Risks and mitigations: remaining concerns, owners and review dates.
8. Approval: who confirmed the decision and any conditions.

Environment setup

After selection, prepare a repeatable setup:

• install the agreed engine version and required modules
• install DCC and code tools under valid licences
• configure version control and ignore files
• create the project repository and folder structure
• add required packages or plugins carefully
• create a basic build and run it on target hardware
• document onboarding steps for new team members.

Validation milestone

Schedule an early milestone to prove the environment works. For example, by the end of week one the team must commit a greybox level, import one representative asset, implement one interaction, make a Windows build and record performance notes. This protects the project from discovering setup failures too late.

Example

An online learner selects Godot for a stylised 3-D puzzle prototype because it is open-source, lightweight and suitable for their hardware. Their documentation confirms GDScript, Blender, Krita, Audacity, Git and Git LFS. They also document a risk: Godot's advanced 3-D ecosystem is less mature than Unity or Unreal for some effects. Their mitigation is to use a simple stylised art direction, avoid complex shaders and prototype the largest puzzle room early.

Common mistakes

Do not change engine versions mid-project casually. Updates can break plugins, asset import settings or build behaviour. Do not rely on undocumented local settings; if only one computer can build the project, the environment is fragile. Do not forget backups. Tool selection should lead into disciplined production practice, not just installation.

Review triggers

Selection is not an excuse to ignore new evidence. Reassess the toolchain if the target platform changes, the client adds multiplayer, the team loses a key specialist, performance testing fails, a required plugin becomes unsupported, or licence terms change. The review should be controlled and documented so the project does not drift into unplanned tool changes.