Game Prototyping & Proofs of Concept

XGameDev builds game prototypes and interactive proofs of concept in Unity, HTML5 and Construct. A prototype should answer a specific question before you fund the larger build: whether an interaction is understandable, a mechanic is worth developing or a technical approach works on the intended device.

We agree the question, the playable scope and the evidence you need at the end. Budget and timing follow from that scope; a short 2D mechanic and a connected AR experiment need different work.

Choose the kind of prototype

Gameplay prototype: test controls, rules, feedback and the core loop using a small amount of content. The aim is to make the interaction assessable without first producing every level and final asset.

Technical proof of concept: test a difficult dependency such as an AR interaction, browser build, external API or multiplayer connection on the relevant platform. A working test should record its device, assumptions and limitations.

Presentation or vertical slice: demonstrate a selected part of the intended finished experience, including agreed artwork and polish. This usually requires more production work than a rough mechanic test and needs a clear boundary.

A project example

For Guac-n-Roll, XGameDev and Knobby explored three prototype concepts before selecting the browser game's final direction. The chosen concept became a Construct 3 campaign game using Knobby's artwork and PlayFab leaderboards.

That case demonstrates concept exploration inside a delivered project. It does not establish a general market-validation result or promise that a prototype will attract funding, sales or a particular number of players.

What we agree before building

• The main question and the person responsible for the next decision.
• A small list of included interactions, screens and representative content.
• The target device, browser or build platform.
• Supplied assets, source code and any third-party licences or access needed.
• Who will test the build and whether participant recruitment is in scope.
• The review method: observation, technical measurements, feedback or an agreed combination.
• Deliverables, review points, budget and the boundary between prototype and production.

For a playtest, decide what to observe. Can a first-time player understand the task? Where do they need help? Does an interaction work with touch controls? For a technical test, define the relevant loading, frame-rate or integration requirement and the environment in which it must hold.

Handover and the next decision

The scope can include the playable build, agreed source files, build instructions, test observations, known limitations and options for further work. Identify temporary code and placeholder assets so they are not mistaken for production-ready systems.

A prototype may lead to a revised design, a further test or a production estimate. Those are separate decisions. Accounts, accessibility requirements, complete content, operational security, device coverage and release support often need more work before public launch.

If you already have a troubled production project, technical consulting is the route for a codebase review or recovery plan. If the scope is known and your team needs a defined feature delivered, see Unity co-development. For a new concept, use our project brief guide to describe the first question you want a build to answer.