Commissioning an Engine game is a production decision: choose a studio that can turn the same brief into a mathematical model, a playable client and a documented delivery. A polished animation reel is useful evidence of visual craft; it does not establish the whole delivery scope.
For a publisher or studio building an original title, the first useful conversation is about the work, the assets you already have and the decisions that remain open. A project-specific quote becomes meaningful once those inputs can be compared.
Start with the game and the work you are commissioning
Write a short brief explaining the theme, core loop and target platform. Name Engine, often still searched for as Stake Engine, if that is your intended route. If distribution is undecided, say so: the integration and approval requirements must be assessed before they become a delivery promise.
State whether you need a whole original game, a team to complete an existing build or capacity for a content roadmap. List what already exists: a game design document, math model, artwork, source files or a playable prototype. Separate material you own from references you admire. A reference is a way to explain a goal, not permission to reproduce another game.
Ask for comparable work and the studio’s exact role
For each relevant example, ask which disciplines the studio supplied. Art direction, animation, mathematics, client engineering and integration are different contributions. Ask to see the states that matter to your project: a cascade resolving, a bonus transition, a narrow-screen layout or the player information around a feature.
A demo can help you assess a particular build. A launch claim requires separate platform evidence. Do not assume that a studio’s whole catalogue has passed the same review or that a demo’s mathematics is the model intended for your commission. Our game-development catalogue is a starting point for discussing comparable work.
Define animation as a list of deliverables
“High-end animation” is a direction, not an acceptance criterion. Name the characters, symbol states, reel transitions, feature introductions, win sequences and interface feedback that must be produced. Agree which source files, exports and integration work are included.
Spine 2D, prerendered 3D and real-time 3D need different production and testing plans. Ask the studio to explain the chosen pipeline in relation to the visual goal and intended devices. Compare representative sequences at the size and speed at which players will actually see them; a full-screen showreel hides interface legibility problems.
Make custom mechanics reviewable before polishing them
Cascading reels and bonus modes connect design, mathematics and presentation. The brief should describe the state transitions, trigger conditions, end conditions and information the player needs. For each mode, agree which math outputs the frontend consumes and how the final outcome is communicated.
A useful design review follows one complete round through those states. It asks what happens after a reconnect, how the result is replayed and where the rules explain the feature. The aim is a testable mechanic and a clear client, rather than a longer feature list.
Compare proposals on scope, not a headline figure
A quote is easier to compare when the same responsibilities appear in each proposal:
| Decision | What the written scope should settle |
|---|---|
| Original production | Supplied versus newly created art, math, audio, code and documentation |
| Animation | Named sequences, source deliverables, exports and revision rounds |
| Engineering | Target platform, supported devices, localization and integration dependencies |
| Acceptance | Milestones, reviewable builds, QA evidence and who signs each stage off |
| Ownership | Game-specific work, reusable tools, third-party licences and publisher-account responsibilities |
| Review support | Submission package, in-scope corrections, response process and change requests |
| After delivery | Support period, maintenance and the treatment of future feature changes |
You can share a budget privately to discuss tradeoffs without expecting a fixed public package. An unexplained low quote may omit work; a higher quote may include responsibilities you do not need. Clarify the difference before choosing.
Specify the review handoff and its limits
Ask for the versions, rules, media, math evidence and QA records that will form the delivery package, with a named owner for review feedback. Agree how an implementation defect differs from a changed feature request. The current Engine submission checklist is the platform reference; the studio’s contract should explain its contribution to that process.
Engine retains the publication decision under its approval requirements. Platform approval, independent certification and permission to operate in a particular market are different questions. A production promise should identify the work and support the studio controls without guaranteeing the decisions of other parties.
Prepare the first conversation
Bring the concept, two or three useful references, the target platform, existing assets and your intended milestone. Identify who can decide the brief and who will own the publisher relationship. Mark unresolved questions clearly; they are inputs to discovery, not details to conceal until production.
Wizards’ Engine game-development service brings these workstreams into a project-specific scope. Request a project quote with what you have, what you want to create and the decisions you need help resolving.
