Software Splash builds games, training simulations, and AR/VR experiences — the SoftwareMile specialist practice for interactive development. We prototype the core loop first, prove it plays, then take it to full production.
Game Development
PC, mobile, and browser games across Unity, Unreal Engine, and Godot: gameplay systems, progression and economy design, UI, and platform-compliant builds. We take on full-cycle development and co-development alongside your team.
Multiplayer and Game Backends
Session and persistent multiplayer, matchmaking, leaderboards, player accounts, live-ops tooling, and server infrastructure that scales with your player base.
Serious Games and Training Simulations
Training scenarios for equipment operation, safety procedures, and process walkthroughs — built with measurable learning objectives, scenario branching, and progress reporting. Where the subject is industrial, our sister practice SoftwarePile supplies real building-systems domain knowledge.
AR and VR Applications
Headset VR training and visualization, mobile AR product experiences, and interactive 3D visualization for products, facilities, and data — optimized to hold frame rate on target hardware.
Porting, Optimization, and Live Operations
Cross-platform porting, performance profiling and optimization, game QA, and post-launch content and live-ops support.
How We Start
Every project starts with a playable answer: a prototype of the core loop or training scenario, scoped in weeks. You decide on full production with something real in hand — not a deck.
Tell us about your game or simulation — include target platforms, engine preference if any, multiplayer needs, and your release window.
Related services
- Unity Development Services — Building in Unity? See our Unity development services.
- Unreal Engine Development Services — Building in Unreal? See our Unreal Engine development services.
What a Prototype Can and Cannot Tell You
A prototype answers whether the core interaction is worth repeating. It will show you that the loop is thinner than it read on paper, that the control scheme fights the player, that the central idea needs a second mechanic to hold attention. Those are the expensive things to discover after a year of production.
It will not tell you whether players stay for weeks, whether the economy balances, whether the art direction reads across a full game, or whether your content pipeline can produce enough levels at the quality of the first one. Those need a vertical slice and, for retention, real players over real time. A good prototype is permission to continue, not proof of a hit.
Co-Development Works When the Seams Are Clear
Co-development friction collects at the seams between teams, so define them. Which systems belong to which team, who owns the build machine, whose coding standards apply, where branches cut, how often they merge, and who has the final call on a design disagreement. Write it down before the first sprint and revisit it at each milestone.
The cleanest splits follow system boundaries. We take multiplayer and backend while your team keeps gameplay. We take a platform port while your team continues on the main branch. We build the training scenario layer while your team owns the simulation core. Arrangements built on helping wherever it is busiest produce merge pain and duplicated work, and they get worse as the team grows.
The Feature List Is the Real Risk
Studio leads tend to ask which engine at the start and which features get cut at the end, and the second question is the one that decides the schedule. Unity Development Services and Unreal Engine Development Services set out the differences, and either engine will carry a well scoped project. For a 2D game Godot belongs in that comparison too, and 2D Game Development covers where it fits.
What varies enormously between projects is whether there is a working mechanism for saying no to a feature after production has started. That means a named person with the authority to cut, a cut list kept from day one, and milestones defined by what has to be playable at each gate. A team that can cut will ship something. A team that cannot will keep building.
Certification Is a Schedule Item
Console and store submission is a process with its own calendar and its own reviewers, and it can send you back for things unrelated to whether the game is good: naming conventions, controller disconnect handling, save data behavior, age rating paperwork, accessibility requirements that vary by region. None of it is hard. All of it takes time you have to have planned for.
Read the technical requirements while the game is still malleable, and assume a submission may come back at least once. The Platforms page covers what each target adds to that workload.
A Live Game Is a Standing Cost
Launch is the beginning of a cost line. A live game needs content, moderation, servers someone operates, storefront updates, engine and SDK updates forced on you by platform holders, and a person who answers when the backend has a bad night.
If you do not want that commitment, say so during design. A self contained single player game or an offline training title can be finished and left largely alone in a way a live service cannot, and choosing that shape deliberately is a legitimate strategy.
Frame Budget Is a Hardware Number
A frame rate target converts to a fixed time budget per frame, and that budget, not the engine, is the real constraint on scope. 60 fps leaves 16.7 ms. A 72 Hz headset leaves 13.9 ms. 90 Hz leaves 11.1 ms. Everything fits inside that: gameplay ticks, animation, physics, culling, command submission, shading, and post processing. VR spends part of it twice, once per eye, and reprojection covers head rotation between frames but does not cover a frame that arrives late carrying stale animation and stale physics.
Which hardware sets the number matters more than which engine draws the pixels. A standalone headset runs a mobile class SoC where CPU and GPU share one power and thermal envelope, so under sustained load the device reduces clock speeds, and a scene that holds budget on a cool device can miss it once the device has been running and has warmed up. That is why the profiling that counts happens on the target device, warm, rather than in the editor on a desktop.
When a build misses budget, the useful first question is where the time is going, not which quality setting to lower. Unreal's stat unit command splits frame time into game, draw, and GPU. Unity's profiler separates the same costs and shows per frame spikes rather than averages. A fast check is to drop the render resolution: if frame time falls, the GPU is the limit, and if it barely moves, the cost sits on the CPU and smaller textures will not help. The split worth reading before changing anything is:
- Game thread time covers gameplay code, animation, physics, and anything running per tick, and it comes down by doing less work or by doing it on fewer objects.
- Draw thread time covers building and submitting render commands, and it comes down through batching, instancing, and reducing the number of unique materials.
- GPU time covers rasterization and shading, and it responds to resolution, overdraw, shader complexity, and texture bandwidth.
- Stalls appear as occasional long frames rather than a raised average, and they usually trace to garbage collection, asset loading, or first use shader compilation, which means they have to be found on the frame time graph and not in the mean.
Source Control and the Asset Pipeline
A game repository is mostly binary. Textures, meshes, audio, and compiled assets do not diff, and two people editing the same level or scene produce a conflict that no three way merge resolves. The standard answers are exclusive file locking and splitting content so two people are rarely in the same file. Perforce is common on larger projects because locking is native to it. Git handles large binaries through LFS and supports lockable file attributes, and Unity scenes and prefabs are YAML that UnityYAMLMerge can reconcile in simple cases, but locking a shared level is still safer than merging one.
Almost none of this matters during a prototype. A small team on a lightweight repository moves faster without locking rules, and standing up a full asset pipeline before the loop is proven is effort spent on a project that may not continue.
It stops being optional as the file count and the import cost grow. Reimporting a project from a cold cache, or recompiling shader variants after a change to a shared shader or material, is slow enough on a large project that teams run a shared cache, Unity Accelerator or an Unreal derived data cache, so one machine pays that cost and the rest pull the result. Generated folders should not be versioned at all, since Library, Temp, Intermediate, Saved, DerivedDataCache, and build output are all reproducible from source. The decisions worth settling before the file count grows are:
- Whether the repository holds art source files or only game ready exports, and if source lives elsewhere, where that is and who backs it up.
- Which folders are generated and excluded, and whether the project is large enough to justify a shared import or derived data cache.
- What the locking policy is for scenes, levels, prefabs, and blueprints, and how content is split so two people are rarely in the same file.
- Who holds a license for each piece of middleware, and which machines have each platform SDK installed, since a build machine that cannot compile a target blocks everything downstream of it.
- How a clean checkout becomes a running build, written down and kept current, so a new machine can produce one without asking anyone.
Preparing Existing 3D and CAD Assets
Models built for engineering or offline rendering are not game ready, and converting them is a step of its own rather than an import. CAD and BIM geometry is built for accuracy: dense tessellation, no UV layout, a material per face, and often the whole assembly placed at true survey coordinates far from the origin, which shows up as floating point jitter once it is in an engine. Real time use needs decimated or retopologized meshes, a UV layout, atlased textures, LODs, and materials rebuilt against the target engine's shading model.
Characters and animated assets from an offline pipeline carry constraints, drivers, and deformation rigs that do not transfer. Skeletons and blend shapes are normally rebuilt into a game rig with a bone count and per vertex influence limit the target platform can skin at frame rate.
FBX and glTF are the usual handoff formats, and it helps to send the original source files as well, since an exported mesh is much harder to correct than the file it came from. The questions worth answering at handoff are:
- What application authored the source, since a CAD or BIM export and a DCC export from Blender, Maya, or 3ds Max take different conversion paths.
- What units and up axis the source uses, and whether the geometry sits far from the origin.
- Which parts of the model a user will actually get close to, because that decides where the polygon and texture budget is spent.
- Whether the model has to stay dimensionally accurate, which limits how far the geometry can be simplified.
- What license covers purchased models, textures, and audio, and whether it permits redistribution inside a shipped application.
What a Training Simulation Needs Beyond the Simulation
The scenario logic is usually the smaller half of the work. A training simulation encodes one specific correct sequence, and a scenario that teaches the wrong order is worse than no simulation, so it needs a subject matter expert who can walk the procedure and review builds on a repeating cadence rather than once at the end. That person also decides what counts as a failure state, which is the part that turns a walkthrough into an assessment.
Name the learning management system and the identity source early, because they change what gets built. SCORM 1.2 and 2004 packages are launched by the LMS inside a browser frame and report a small set of values, mainly completion, score, and time. xAPI sends statements to a Learning Record Store and can record granular events such as which step was missed and on which attempt, which is usually what a branching scenario is worth building for, and cmi5 is the packaging spec that lets an LMS launch xAPI content. A headset build cannot be a SCORM package, since SCORM assumes browser hosted content in a window the LMS controls, so headset results reach a reporting system through xAPI or through a service you own.
Enterprise headsets also need a deployment story before there is any content to deploy: enrollment in a device management service, kiosk or single app mode so learners cannot browse out of the app, a way to push builds without a consumer store review, network provisioning for whatever Wi-Fi the training room uses, and a person who charges, updates, and sanitizes the devices between sessions. That is IT work rather than development work, which is exactly why it needs a named owner instead of being assumed.
When a Game Engine Is Not the Right Tool
If the requirement is watch and recall rather than do and be assessed, a video or a slide based module carries it, and it stays cheap to maintain because it does not have to be rebuilt when an engine or a platform SDK changes. If the deliverable is a fixed camera path over a building or a product with no branching and no user input, that is a rendered animation, and rendering it offline gives better image quality than any real time build of the same scene.
For a small 3D configurator or product viewer embedded in a web page, a WebGL library such as three.js or Babylon.js is often a closer match than an engine web export. An engine web build ships a runtime that has to download and initialize before the first frame appears, memory ceilings are tighter in mobile browsers than on desktop, and multithreading through SharedArrayBuffer requires the page to be cross origin isolated, which means the host has to send COOP and COEP headers on the document and matching CORP or CORS headers on every asset it loads. Those are hosting constraints, and they are much cheaper to check before a web target is chosen than after.
The dividing line is interaction. If a user has to make decisions inside the scene and the system has to respond to them, score them, and branch on them, an engine earns its overhead. If the user watches, reads, or clicks through a fixed sequence, lighter tools finish sooner and cost less to keep running afterward.
Frequently Asked Questions
Can you take over an existing game project, and what do you need to do that?
Yes, and what it requires is access rather than polish. That means the repository including history, a license for every piece of middleware the project links against, access to the platform SDKs the targets need, and a written path from a clean checkout to a running build on a machine that has never seen the project. If that path exists only in one person's head, or depends on files kept outside version control, it has to be reconstructed before feature work can start. It also matters which engine version the project is pinned to, because moving versions is a separate piece of work rather than part of the handover.
What has to be decided before multiplayer work can start?
Two decisions set the shape of everything else: whether the server is authoritative, and whether sessions are short matches or a persistent world. An authoritative server means clients predict locally and then reconcile against server state, which changes how movement, hit detection, and inventory are written, and retrofitting it onto code that trusts the client is close to a rewrite. Persistent state brings a database, durable account identity, and a migration for every schema change, none of which a match based game needs. If player accounts already exist in another system, say so early, since the multiplayer layer normally authenticates against that rather than creating a second identity source.
How is the engine version chosen, and can it change mid project?
Pin one version at the start and treat any move as a scheduled task rather than a routine update. Unity and Unreal both publish long term support or stable branches, and staying on one avoids the plugin breakage and deprecated API churn that comes with tracking the newest release. Upgrades still happen, sometimes because a platform holder requires a newer SDK that only ships in a later engine version, and the cost lands on third party plugins, any custom engine changes, and content that has to be revalidated afterward. Godot is a similar case, where moving between major versions is closer to a port than an upgrade.
Can one project ship to PC, mobile, and a headset?
One codebase can hold several targets, but they are not the same product. Input differs, UI has to be re authored for touch and again for a headset where there is no cursor and text entry is slow, and each target usually needs its own content quality tier. Pick the weakest target before the art is made, because adding a lower spec platform later means re authoring assets rather than changing a setting. A shared project also does not mean a shared build, since each target keeps its own configuration, plugin set, and testing pass.
What do we have to provide for console or store submission?
The developer account has to be yours. Console developer programs approve a company rather than a contractor, and dev kits, store listings, and submissions all attach to that approved account, and the same holds for Apple and Google developer accounts, which own the signing identities a build is signed with. You also answer the content rating questionnaires, since rating bodies such as ESRB and PEGI and the IARC questionnaire used by several storefronts ask the publisher to declare what is in the game. Privacy disclosures work the same way, because the data safety and privacy label forms on mobile stores are declarations about your product and your data handling. We can prepare the builds and supply the technical answers, but the entity that publishes has to hold the account and sign the declarations.
Should an AR product experience be an app or a web page?
Decide install versus link first, because that choice picks the toolchain. A native build through ARKit or ARCore, both of which Unity and Unreal target, gives the most stable tracking along with plane detection, image and object tracking, and depth occlusion, at the cost of a store install and a store review for every update. WebXR runs from a link with no install and updates the moment you deploy, but its feature set is narrower and availability varies by browser and operating system. iPhone Safari does not expose WebXR AR sessions, so link based AR on iOS is commonly done with AR Quick Look and a USDZ file, which places a model in the room but is not an interactive application.