Technical constraints

What this is

Technical constraints are the limits and affordances of your platform choices: the hardware players will use, the software and engines you build with, the systems you must integrate with, and the technical knowledge of both your team and your users. Discovery means identifying these constraints before they identify you.

Why it carries values

In serious game development, technology is not neutral — it is an active player in deciding which values you can bring to life. Every technology imposes its own limitations and offers certain options; and it works in both directions, because the values you want to promote steer you towards particular systems and tools. Decisions about hardware and software are never purely technical: they carry accessibility, fairness, immersion, fidelity and learning outcomes with them. Sometimes constraints push you towards decisions that put values front and centre — designing for low-end phones so lower socio-economic groups have access — and sometimes the same decisions compromise values like authenticity.

Patterns from practice

Hardware

Platform choice is a values choice. Several developers chose mobile and tablet precisely because of their near-ubiquity — the early childhood clinical lead directly linked widespread device ownership to accessibility, accepting narrower design options in exchange for broad access and avoiding the exclusivity of high-end PCs or specialty hardware. The social services developer goes further, buying "the cheapest, cheapest phone... 100 bucks" (P10) and making sure the game runs on it, dialling down shaders and features so that low-income players aren't locked out. The fire warden training developer switched from PCs to tablets after discovering many rural volunteer stations had no electricity — trading graphical fidelity for reach.

Hardware can also undermine values. Constant device churn breaks the immutability clinical trials need, making evidence-based treatment harder to sustain. When the physiotherapy company abandoned manufacturing its own balance boards on cost grounds, complexity shifted onto end users, who now juggle "a board and a computer and a smartphone" (P2) — financial feasibility clashing with simplicity for patients and clinicians.

VR concentrates these trade-offs. It offers genuinely valuable immersion for experiential learning, but high-end headsets are expensive, tethered systems are hard to roll out at scale, and at the time roughly five per cent of students got motion sick — leading the driving game team to conclude "if you wanted to make something accessible you can't just make it VR" (P4). VR also can't mimic precise fine motor movement: the medical simulation designer found a basic CPR manikin beats any VR simulator for CPR training, and the mixed-reality headsets that solve this cost over $10,000. Even so, half the studios in the study had shipped at least one VR serious game — the immersion is real, and many of the trade-offs are easing as the technology matures.

Technical knowledge

The know-how of your users and your own team is a constraint too. Babies can't operate software; their parents must — and getting parents to find and install apps was "much more of a battle" (P9) before COVID normalised video calls and lifted baseline digital literacy (though that literacy didn't automatically extend to games). On the team side, the founders of a medical education games company found their own limited technical knowledge made it hard to hire top talent in a specialised field — they couldn't evaluate what they couldn't do, which hindered their ability to deliver high-fidelity, clinically meaningful simulation.

Software

Unity was the most popular engine among the designers interviewed — its low barrier to entry made it the go-to for mobile and tablet work — but it was not a neutral choice. One developer called it one of the biggest determinants of what they could achieve, with a massive impact on what they could implement and which values they could address. Engines nudge teams towards certain interactions and visual styles, sometimes at the cost of more complex simulations or experimental mechanics.

Integration constraints are quieter but just as value-laden. Learning management systems built around "slide shows" and "pass/fail" (P5) can't display the results of a simulation involving intricate decision chains and complex scoring. When institutions are satisfied that pass/fail meets their legal requirements, they won't pay for more — and squeezing a rich simulation into simple completion metrics forces out formative assessment, self-reflection and complex understanding. Converting a web-based fire warden game to tablets created substantial extra work just to get results back to the LMS, especially offline; the difficulty of integration pushes companies towards what's easy to track rather than what produces the better learning outcome.

Questions to ask your team

1. What hardware do our real players actually own — and have we tested on the cheapest device they're likely to have?
2. Which values is our platform choice promoting (reach, access) and which is it sacrificing (fidelity, immersion)?
3. If we're considering VR: is immersion genuinely serving the learning, and who does the headset exclude — by cost, logistics, or motion sickness?
4. What technical knowledge are we assuming in our users, and in the people around them (parents, teachers, clinicians)?
5. Can our own team evaluate the specialist skills this project needs — and if not, who can?
6. How is our engine quietly shaping what we build? What has it already talked us out of?
7. What can the client's LMS or reporting system actually record — and are we letting a pass/fail pipe dictate what the game measures?
8. If devices or platforms change mid-project, what evidence or clinical validity do we lose?