Building a 3D game

Most of a 3D game arrives by describing it. This page is about what the agent is actually building when you do — enough that you can ask for the right thing, and recognise when something is wrong.

A scene is data, not code

A 3D scene is a file: a list of entities, each with an id, a transform, what it renders, and what it collides with. Nothing about it is buried in game logic, which is why the editor can show it to you and why moving something is a real edit rather than a code change.

Things worth knowing about that file, because they shape what you can ask for:

• Entities have stable ids. Everything — the editor, your save data, behaviour code — refers to an entity by id. Ids do not get regenerated.
• Transforms are relative to the parent. Parent a lamp to a cart and the lamp moves with the cart.
• Assets are referenced by name, not by path, so re-importing art does not break the scene.
• Colliders are explicit and separate from the visible mesh. This is the most common source of a game that is correct and unplayably slow: the detailed shape you see is not the shape physics should use. A crate collides as a box.
• Animations are mapped per model. Every rig names its clips differently, so a model declares "my walk cycle is called Walk_B" once, and the game asks for walk.

If a scene is malformed — two entities with the same id, a missing animation clip, an entity that would render nothing — the game fails loudly at load and says what's wrong, rather than showing you a black screen.

Lighting and camera, said out loud

The two things most likely to make a correct scene look broken. Both are worth being explicit about:

Light it like late afternoon — long shadows from the west, warm.

Camera behind and above the player, following them, and don't let it end up
inside a wall.

If something is invisible or unlit, say exactly that — it is a well-known class of problem and the agent has a checklist for it.

Characters

A character is a rigged model plus a controller. You ask for behaviour in plain terms and the platform owns the hard parts:

The player walks with WASD, runs when Shift is held, jumps with Space, and
climbs low steps without stopping.

Two things the platform gets right so you don't have to think about them:

• Animation follows the character's state, not the keys held. Choosing a clip from input is how you get a character running in mid-air.
• Step climbing, ground snapping and slopes are the controller's job. If a character snags on an edge, sinks, jitters or tunnels through a wall, that is a known family of bug — describe the symptom and it is fixable.

Beyond locomotion, characters have actions — attack, pick up, die. Declaring them matters for another reason: the platform places the on-screen controls. On a phone the player gets a floating stick and a button per declared action; on desktop the same actions are bound to keys. A capability the game never declares is one no player can find.

One body, many characters

A character pack is usually not N finished characters. It is one rigged body plus a stack of textures — so a pack of four bodies and eighty textures is three hundred-odd characters, not eighty-four files.

That means you can ask for variety cheaply:

Make the guards use the blue uniform skin and the bandits the ragged one.

Equipment

Props know where they go. A cap declares that it belongs on a head; a character declares where its head socket is. So dressing a character is naming the props:

Give the hero the iron sword in the right hand and the round shield on the
back.

Both halves are properties of the models, not of your game, which is why a pack you bought works without you writing a lookup table saying a cap is headwear. You can also change equipment in the Inspector, per entity, from dropdowns.

Physics

Rapier, wired for you. What to keep in mind:

• Static versus dynamic is a real decision. The ground, walls and most scenery are static; only things that need to be pushed should be dynamic.
• Gravity belongs to the world. If jumps feel half-height, the scene's gravity and the character's assumptions have probably diverged — say so.
• Never collide against the render mesh for something that moves. Ask for a box or a capsule.

UI and text

A 3D game's interface is DOM, not sprites — a score, a health bar, a menu, an inventory, a dialogue box. It scales properly, it takes real text input, and it handles non-Latin scripts without the font problems a canvas has. That also means the 2D HUD editor does not apply here; you ask for UI in chat.

Audio

Music and sound effects have separate volumes, so a settings dialog with two sliders is one request. The first sound can be silent until the player has touched the page — a browser rule, not ours — so put a title screen in front of the game. See Sound and music.

Props before polish

Every project ships a kit of real models, and a scene built from them reads as a game; a scene built from coloured boxes reads as a prototype no matter how good the lighting is. If a 3D scene of yours looks flat, grey or empty, that is usually the diagnosis — and it is one sentence to fix:

This looks like a prototype. Replace the box scenery with real props from
the kit.

Next steps