Game engine & software

What this element is

This element covers the game engine and the surrounding software your game must live with — physics, networking, customisation, asset ecosystems, and integrations such as Learning Management Systems (LMSs). Flanagan and Nissenbaum note that the engine and other software used to develop a game can influence what is included in it at all.

Why it carries values

Engine and software choices dictate which design ideas are possible, efficient and aesthetically achievable — and can steer the values your game represents. They also determine who on your team gets to contribute. Almost every developer described their engine choice as pragmatic; almost every developer's own account showed the engine shaping what they could actually put into practice.

Patterns from practice

Unity

Unity was the pragmatic choice across agriculture, medical training, disability support, early childhood intervention and physiotherapy — it matched the skills of available staff and the demands of mobile platforms, letting small teams do more with limited resources. But "pragmatic" doesn't mean value-neutral. The environmental developer admitted that "things that are easier to do in Unity, we would lean more towards (it), because it means that we can accomplish them in less time," and that "the specific look of the game is definitely influenced by us using Unity" (P7). Reaching for existing assets and packages isn't just optimisation — it shapes which mechanics and aesthetics get picked, and therefore which values get foregrounded. The same developer drew the line explicitly: "Unity is probably the biggest influencer of the scope of what we can accomplish, which definitely influences what we can actually implement and what values we can actually address" (P7). Unity expands breadth and iteration speed while quietly constraining visual fidelity and customisation.

Unreal Engine

Unreal was chosen for collaboration and creative control. The space game's creative director picked it for the Blueprint system — "essentially a programming language, but one that can be used by designers and artists without, you know, five to eight years of computer science training in C++" (P6). That redistributes power inside the team: designers and artists can build interaction systems and technical art tools themselves. Blueprints bridge the gap where "designers talk in abstract concepts, programmers talk in functions" (P6), giving the team a common space to exchange functional proofs of concept — which is what made nuanced systems like depth-accurate water shaders feasible under real production constraints. There's a warning in this case too: the studio built a Kinect plugin specifically for Unreal, and once that pipeline existed, later design decisions oriented around showcasing the plugin's strengths — technological innovation and showcaseability quietly outranking portability.

Custom engines

Custom engines are increasingly rare but still matter in specialised simulation. The driving game developer: "we used our own engine, our own technology, which meant that we had really detailed physics already" (P4). That foundation enabled non-scripted vehicle AI and accurate physics for the player's car and traffic, so lessons are "never the same thing, because of AI, there is always some randomness to it" (P4). The custom engine's early investment in physics and AI steered the game towards emergent, unpredictable play — the developer was clear the game would have been quite different on an off-the-shelf engine. Pre-existing tech and leftovers from earlier projects quietly shape what a studio comes to value.

Constraints: LMS integration and clinical protocols

The software around your game can bind harder than the engine inside it. The agricultural and biosecurity developer hit a wall integrating with existing LMSs: standard dashboards built for "presentation, click through slideshows" are "not... suitable to display simulation training results" (P5) involving complex decision sequences. The choice becomes "simplify down to really dumb numbers" (P5) or invest in custom dashboards. Generic LMS tooling biases serious games toward reductionism and quantification, at the expense of nuanced assessment and meaningful feedback.

In early childhood intervention, clinical and research protocols outweighed the engine entirely. To maintain research and clinical integrity, games had to stay very similar to previous iterations: "the science behind it... impacted them more than the architecture and game engines that we're using" (P9). Evidence-based practice and comparability limited how far developers could "flex their muscles" (P9) — even when the engine could support more engaging mechanics, the protocol said no.

Questions to ask your team

1. Did we choose this engine, or did our existing skills and leftover tech choose it for us? What has that decision already ruled out?
2. Which features are we leaning towards simply because they're easy in our engine — and are they the features the learning actually needs?
3. Who on the team can build and change game systems? Does our toolchain concentrate that power in programmers, or share it?
4. Are we designing around a pet technology or in-house plugin? Whose interests does that serve?
5. If our results must flow into an LMS, will its dashboard flatten our rich assessment into "really dumb numbers"? What's our plan — custom reporting, or accepting the loss?
6. Do clinical, research or regulatory protocols freeze parts of this design? Have we mapped exactly what we're allowed to change?
7. If we switched engines tomorrow, which of our game's values would survive the move?