Faith Forge LabsGame development

Questions about commissioning game development

Is a design document enough to start?

Yes. Describe the intended player, main action, target setting, and uncertainty. We can discuss a prototype before a full design exists. The initial scope should say what the experiment will let people try and which decision the result will support.

Will a prototype become the final game?

Sometimes parts can be reused, but that should be assessed. Code or assets made to test one question may not suit a longer production. The handover identifies temporary behavior, shortcuts, and what would need rebuilding before expansion.

Can you work on another developer's project?

We can assess available source, builds, dependencies, and documentation with appropriate permission. A playable download alone does not provide the materials needed to modify it. The review establishes access gaps and whether a bounded change is feasible.

Which engine should we use?

That depends on the project, team, platforms, existing assets, and maintenance plan. An engine's export options are only one consideration; the actual game still needs usable controls, appropriate performance, and a supported build process. We do not promise every engine or platform without assessment.

Is a 2D game necessarily a small project?

No. A 2D game can have complex animation, combat, content, progression, saving, or online systems. Scope follows the behavior and production work, not the number of dimensions. The 2D guide explains how to define a complete section.

What should a first 3D milestone contain?

A representative space and interaction: enough camera, movement, collision, assets, and feedback to expose the difficult relationship. An empty level or cinematic view may not test the intended play. Target-device checks should be included where they affect the production decision.

Can one build serve desktop and phones?

Possibly, but the input, layout, performance, and delivery conditions need review. A precise pointer mechanic may require a different touch interaction. Exporting successfully does not prove the resulting experience is suitable on a physical phone.

Can you add multiplayer later?

It requires a separate assessment. Simultaneous actions, session ownership, disconnections, rejoining, and potentially accounts or moderation change the design and technical responsibilities. A local two-player mode and a public online service are very different scopes.

Do you supply art, music, or writing?

The proposal identifies which materials are supplied, created, adapted, or commissioned and by whom. Editable source, approvals, rights, and integration responsibilities should be explicit. No asset should be treated as cleared for release merely because it appears in a working prototype.

Does testing prove accessibility for everyone?

No single test establishes that. Define relevant input, reading, audio, motion, and recovery needs, then test the implemented experience with suitable methods and participants. Record what was checked and what remains unverified.

Is store publication included?

Only when agreed. Account access, signing, listings, content declarations, privacy information, and review responses need owners. We can scope release preparation, but platform approval and review timing are not guaranteed.

What will we receive at handover?

The agreement specifies source, builds, editable assets where applicable, dependency and rights records, instructions, and test findings. A receiving maintainer should be able to identify and reproduce the accepted version using the agreed materials.

Send a project inquiry or read the planning resources.