3D Game Development

3D game development is where the technical demands climb – rendering, physics, performance budgets, and asset pipelines all have to hold together at frame rate. Software Splash builds 3D games and experiences in Unity and Unreal Engine, from stylized mobile 3D to high-fidelity PC and console.

Performance Is a Design Constraint

A 3D game that looks great in the editor and stutters on the target device is a common failure. We set performance budgets early – poly counts, draw calls, memory – and design art and systems to live within them on the hardware your players actually own, not on a development workstation.

What We Build

  • 3D gameplay, physics, camera, and control systems that feel right
  • Asset pipelines: models, materials, animation, and level tooling
  • Optimization for the target platform, including mobile and VR
  • Multiplayer, backends, and live operations where the game needs them

Unsure whether your concept needs full 3D or works better in 2D? Describe it and your target platforms – we will advise and prototype before committing to production.

Art Direction Is a Performance Decision

Stylized art holds a budget better than realism. A stylized target permits deliberate simplification everywhere, meaning fewer materials, smaller textures, simpler lighting, and lower geometric detail, and the result still reads as intentional. Photoreal sets a bar you then have to hold across every asset, every environment, and every device you ship on, and one asset that misses it is far more visible than it would be in a stylized game.

It also affects how forgiving the pipeline can be about art produced by different hands, and how the game looks a few years after release. That makes art direction one of the earliest technical decisions on a 3D project, even though it arrives looking like a purely creative one.

Animation Is Usually Underestimated

Characters need rigs, a naming and retargeting convention, blend trees, transition logic, root motion decisions, and inverse kinematics for foot placement and hand contact. Motion capture produces volume quickly and then needs cleanup and retargeting. Hand keyed animation gives precise control and takes time per clip.

Either way, the animation system is a real engineering component with its own performance profile and its own tooling needs. Deciding on it late tends to force rework through gameplay code, because movement, combat, and interaction all read from it.

The Camera Is a Gameplay System

Player frustration in 3D often traces back to the camera. It clips through geometry, loses the player behind a wall, fights the input, or swings in a way that makes people uncomfortable. Camera collision, framing, look ahead, and behavior during combat or fast movement all need tuning against real level geometry.

Level design and camera design therefore have to progress together. A level built without the camera in mind produces problems that no amount of camera code resolves cleanly, and the fix at that point is usually to rebuild the space.

Build Tools When Content Volume Justifies Them

Custom level tools, procedural placement, and validation scripts pay off when there is a lot of content and a team producing it. For a short experience or a single training scenario, tooling is overhead that delays the thing you are trying to make.

The signal to watch for is repetition with error. When someone is performing the same manual setup over and over and getting it slightly wrong each time, that is the moment to build the tool, and not before.

Where 3D Effort Concentrates

Content production, usually. Modeling, texturing, animation, level construction, and lighting are the long poles on a 3D schedule, while engineering is often waiting on content or building tools to produce it faster. Planning as though programming were the bottleneck is a reliable way to miss a date.

If the concept works flat, 2D Game Development explains why that is a legitimate choice in its own right.

Engine Choice Constrains Everything Downstream

Choosing between Unity and Unreal is not like choosing a library, because almost nothing crosses the boundary afterwards. FBX meshes, textures, and audio move. Scenes, prefabs, Blueprints, material graphs, animation state machines, physics setup, and gameplay code do not. A port is close to a rebuild with the art already made, and the rebuild lands on exactly the systems that took longest to tune the first time.

Inside Unity the same problem repeats one level down. Built-in, URP, and HDRP are not interchangeable. URP is the pipeline Unity targets at mobile and standalone VR hardware, while HDRP targets PC and current console and will not run on a standalone headset. Changing later means remaking every material and rewriting every custom shader, because a shader is written against one pipeline's lighting model and node set.

  • Unity: C# on a runtime that compiles ahead of time through IL2CPP for platforms that forbid JIT, including iOS and the consoles.
  • Unreal: C++ compiled per platform with Blueprints as a visual layer over it, and Nanite and Lumen assume desktop or current console GPUs, so they are normally off in mobile and standalone VR builds.
  • Either engine: scenes and binary assets do not merge the way source files do. Unity can serialize scenes and prefabs as YAML text and ships a merge tool for them, while Unreal assets are binary and the workflow leans on exclusive checkout, which is why Perforce is common there and why two people editing one level has to be scheduled rather than assumed.

Decisions and Inputs That Belong to the Customer

Some decisions belong to the customer because they change the architecture rather than the polish. A minimum device, not a platform name: "Android" is not a target, a specific device tier is, because that device's memory ceiling and GPU class set texture budgets, draw call counts, and how many animated characters can share a screen. Whether the game is single player or server authoritative decides whether there is a backend at all, and adding authority to a client side prototype touches movement, physics, and every system that writes state. The distribution route, whether that is a public store, sideloading, a kiosk build, managed enterprise devices, or the browser, sets build configuration, signing, update mechanism, and what telemetry is permitted at all.

These interact, which is why they are worth answering together rather than one at a time. A minimum device two generations old rules out render features a multiplayer design was quietly assuming. A kiosk deployment drops the store constraints and adds an unattended reliability requirement instead, since nobody is standing there to restart the build. Answering late does not avoid the decision, it means the answer arrives after code has already assumed something else.

  • A target frame rate per platform, stated as a number: 60 fps leaves 16.6 ms of total frame time and 30 fps leaves 33.3 ms, and that gap decides how much animation, physics, and post-processing fit.
  • Reference material for anything that has to match a real object, machine, or building: dimensioned drawings, CAD, or photographs shot for reference rather than for marketing.
  • License terms for any third party asset, motion capture set, font, or audio you want used, including whether the license permits shipping it inside a distributed binary.
  • One person who can settle design questions quickly, because a modeler or animator blocked on an unanswered question stops producing for the day.

Production Order and What the Vertical Slice Settles

The order that survives contact with a 3D project is prototype, vertical slice, then content production. The prototype tests the core loop with gray box geometry and capsule characters, where changing a rule costs an afternoon and no art is at risk. The vertical slice is one level or one scenario taken to shippable quality through the real pipeline and run on the real target device, so the budgets set at the start get checked against measured frame time instead of estimates.

The slice is also where the pipeline itself stops moving: export settings out of the modeling tool, material and shader conventions, LOD generation, lightmap or light probe strategy, collision authoring, and the build and deploy path onto the device. Content produced before those are fixed tends to get produced twice.

  • Units and scale, decided once: Unity treats one unit as one meter and Unreal treats one unit as one centimeter, and an FBX exported at the wrong scale gives you physics that looks nearly right and never behaves right.
  • Asset identity: Unity tracks assets by the GUID in the .meta file beside them, so renaming and moving inside the editor is safe, while doing the same thing in Explorer without the .meta file breaks every reference to that asset.
  • Collision and LODs decided per asset class rather than per asset, so an artist knows which meshes get a generated convex hull and which get hand built simplified shapes before there are a hundred of them.

Telling CPU Cost From GPU Cost

When frame rate drops, the first question is which processor the frame is waiting on, because the two sets of fixes do not overlap. A CPU bound frame usually traces to draw call submission, animation evaluation, physics, or a garbage collection spike, and it responds to batching, instancing, fewer unique materials, and object pooling. A GPU bound frame usually traces to overdraw from stacked transparent surfaces, render resolution and post-processing, shader instruction count, or texture bandwidth, and none of the CPU side fixes touch it. Guessing wrong costs a week of optimization that moves nothing.

Two measurement habits keep that diagnosis honest. Profile a development build running on the device rather than in the editor, since the editor runs inspection and asset handling code the shipped build does not. And on phones and standalone headsets, run long: thermal throttling appears as a slow settle to a lower clock after several minutes, not as a spike, so a two minute test on a cool device reports a frame rate the player never sees.

  • Unreal: stat unit splits the frame into Game, Draw, GPU, and RHI thread time, which names the bottleneck before any deeper tool is opened, with stat gpu and Unreal Insights for the level below that.
  • Unity: the Profiler attached to a device build, plus the Frame Debugger to see the actual draw call list and why batches broke apart.
  • When the engine tools stop being specific, a RenderDoc frame capture or the vendor tools, Xcode Instruments and Android GPU Inspector, read the hardware counters directly.

Frequently Asked Questions

Does 3D work have to run in a game engine?

Not always, though usually. A three.js or Babylon.js scene in the browser is a reasonable fit for a product configurator or a small model viewer, where install friction matters more than fidelity and the content is a handful of assets. Once there is physics, animation state, level content, and a frame budget on a named device, the engine tooling is the cheaper path rather than the heavier one. Unity and Unreal can also build into an existing native app as an embedded view rather than the whole application, at the cost of binary size and a lifecycle boundary the host app has to manage.

Which headsets and AR devices can a 3D project target?

Standalone Android based headsets, PC tethered headsets, and phone based AR through ARKit and ARCore. Unity and Unreal reach them through OpenXR, which standardizes device discovery, input actions, and the stereo render loop, so one codebase can address several headsets. Vendor SDKs are still needed for what OpenXR leaves to extensions or does not cover, including store entitlements, hand tracking specifics, passthrough, and platform social features. A standalone headset is mobile class hardware rendering two eyes at a fixed refresh rate, so its budget is tighter than a phone game's, not looser.

We already have models from CAD or another project. Can they be used?

Sometimes, and the amount of rework depends entirely on where they came from. CAD data from SolidWorks, STEP, or IGES is surface data that has to be tessellated into triangles and then retopologized, because a direct tessellation produces enormous triangle counts, no usable UV layout, and no LODs. Scanned and photogrammetry meshes have the same problem plus lighting baked into the textures. Game ready means clean topology, a UV layout, a triangle count inside the budget, LODs, and collision, and existing models are worth auditing against that list before anyone plans a schedule around reusing them.

When do you need decisions from us?

Before the vertical slice, since that is the build where they get committed to code. The architecture level choices are set out above; the one that is easy to forget is the input scheme, because gamepad, touch, mouse and keyboard, and motion controllers each imply different camera behavior, UI scale and hit target size, and control mapping. Adding a second scheme after those systems are tuned means retuning all of them.

What accounts and platform access do we have to provide?

Store and platform developer accounts, created in your own name and owned by you from the start. Apple Developer, Google Play Console, Steam, and headset store accounts hold the app identity, the signing keys, and the financial relationship, and transferring a published app between accounts is a manual process with eligibility conditions on both major stores. Where a transfer is not possible, the fallback is a new listing that starts over on ratings and install base. You also answer what nobody else can answer for you: age rating questionnaires, privacy and data collection declarations, and export compliance.

How does a training simulation differ from a game build?

The rendering, animation, camera, and interaction work is the same; the requirements around it are not. A training build usually needs scoring, session telemetry, an instructor or after action review view, often an LMS integration over SCORM or xAPI, and deployment to managed devices rather than a public store. Fidelity is judged differently too, since procedural accuracy outranks visual realism, and someone with the domain knowledge has to be available to validate each procedure and correct it. That availability is a scheduling dependency more than a technical one, and it is the usual reason a simulation slips.

What does a 3D game need after launch, if we add no new content?

There is a maintenance floor regardless. The platforms move underneath the build: Google Play raises the required target API level on an annual schedule, Apple requires submissions built against a recent SDK, and headset stores deprecate device generations and SDK versions. Engine and third party plugin upgrades are the other half, and they are far cheaper taken in small steps than skipped for two years and then forced by a store deadline that has a date on it.