Game Development

Game development at Software Splash runs the full arc: prototype the core loop, prove it is fun, then build, ship, and operate. We work across Unity, Unreal Engine, and Godot, on full-cycle projects and as co-development alongside your studio.

Prototype First, Always

The most expensive game is the one built for months before anyone checks whether it plays. We start with a prototype of the core loop – the thing the player does over and over – and you decide on full production with something playable in hand, not a design document.

What We Handle

  • Gameplay systems, progression, economy, and balancing built for retention
  • Multiplayer, matchmaking, and game backends that scale with your players
  • Art integration and platform-compliant builds for PC, mobile, and console
  • Porting, optimization, QA, and post-launch live operations

Not entertainment? We also build training simulations and serious games with the same engines. Tell us your concept, target platforms, and engine preference – and your release window.

Choosing an Engine, and When to Switch

If you already have an engine, or your team has standardized on one for reasons that sit outside this project, that is the starting point and the work happens there. When the choice is genuinely open, a short set of constraints narrows it faster than a feature comparison does, because the differences that decide a project are rarely the ones the engines advertise.

Switching engines partway through is a rewrite of everything except art source files, audio, and design intent. It is worth considering in a narrow set of cases: the current engine cannot reach a platform you have committed to shipping on, or a core requirement such as deterministic networking, a large streaming world, or a specific rendering feature has turned out to be something you fight the engine for rather than configure. Discomfort with the tools, or a preference picked up on a different project, does not survive that arithmetic. If the doubt appears during the prototype, that is the cheap moment to test the alternative; if it appears once content production is underway, the realistic options are usually to finish and reconsider for the next title.

  • The platforms you have committed to, and how each one is actually reached. A platform you must ship on and cannot reach well is a hard constraint, and it often settles the question by itself.
  • What the scene has to do per frame, at the frame rate you need, on the weakest device in your support list. A stylized 2D project and a large streaming 3D world do not have the same shortlist.
  • Who maintains the codebase after launch. If your own engineers take it over, an engine they can hire for and already read is worth more than a technical edge they cannot staff.
  • How engine licensing and source access interact with how you distribute. Enterprise deployments, kiosk installs, and anything not sold through a consumer store have different terms to read than a retail title does.
  • The tools and middleware you already depend on. Art pipelines, networking libraries, and analytics SDKs are not equally supported everywhere, and replacing one is a real cost that belongs in the comparison.

The Vertical Slice and What Comes After

A prototype answers one question and deliberately omits everything else: placeholder art, no save system, one input scheme, no store plumbing, no localization. That omission is what makes it fast, and it is also why a prototype that plays well still tells you almost nothing about what the rest of the project costs. The step in between is a vertical slice: one level, mission, or lesson finished to shippable quality through the real art pipeline, with the real build process, on the real target device. The slice is where you learn what a minute of finished content costs in effort and where the pipeline breaks, and it is far cheaper to learn that once than to discover it across a full content set.

The phases on either side of the slice each have a specific job:

Scope changes are cheapest before the slice and most expensive once content production is running, because by then every change has to be applied to content that already exists. Builds also belong on the actual target device from the first milestone rather than at the end, since performance problems found late are usually structural and not something a settings pass will fix.

  • Prototype: one question, placeholder everything. It is written to be discarded or rebuilt, which is what keeps it quick. Treating prototype code as the foundation of production is a common and expensive mistake.
  • Production: content and systems built against the pipeline the slice proved. Progression, economy, and balance get tuned against recorded playtime rather than in isolation, which means the telemetry to record it has to exist before anyone needs it.
  • Release preparation: platform holders review submissions against their own requirements and ratings bodies work to their own schedules. This phase consumes calendar time that adding people does not shorten.
  • Live operation: patches, server operation, and content updates are a standing commitment, not the tail end of production. Staffing for it should be decided before launch, because a game with servers has an operating burden that continues whether or not anyone is adding features.

Simulation and VR: Judged on Transfer, Not on Fun

A training simulation is judged on whether the behavior transfers to the real task. That is a different standard from the one a game is held to, and it changes where the money should go. Fidelity is worth paying for exactly where the task lives: the correct sequence of actions, realistic consequences for the wrong one, and controls laid out the way the real equipment is laid out. Environment detail beyond what the task requires is the most common way a simulation budget disappears without the training getting better.

Two things have to be settled on your side before the build is worth starting, and neither is a technical question. Someone with real authority over the procedure has to define what correct performance is and stand behind it, or the simulation quietly encodes a developer's guess. Separately, someone has to decide what is scored, what a pass looks like, and who reads the results afterward. Without that second decision the sim gets built as an experience rather than an instrument, and the training organization has no way to show it changed anything.

For headset work, comfort and session length are design constraints rather than polish items. Locomotion style, seated versus room scale, and how long a trainee is expected to stay in the headset shape the content itself, and all three are cheap to change before content exists and expensive afterward. The physical room matters as much: floor space, supervision, and turnaround between one trainee and the next. AR carries its own dependency, since the experience is anchored to a real environment and behaves differently in a space it was not authored against, which is why it has to be tested in the actual space and not in a model of it.

When a Game Engine Is the Wrong Tool

A game engine is a heavy dependency, and it earns its place when the product is genuinely real time, interactive, and spatial. Several requests that arrive described as games are better served by something lighter, and saying so early costs less than proving it with a prototype.

The test is straightforward. If what you are teaching or selling has to be judged in motion, in three dimensions, or under time pressure, an engine is the right tool. If a user could reach the same result from a form and a diagram, it is not.

  • An interactive configurator, a dashboard, or a 3D viewer embedded in a website. A web stack with a 3D library builds faster, opens in a browser with no install, and is cheaper to keep running when the only annual change is new models.
  • Linear content. If the deliverable is a video, produce a video. Rendering it out of an engine still means paying for a build pipeline and people who can operate it.
  • Knowledge and recall training. When the subject is policy, terminology, or a decision tree rather than a physical procedure or spatial judgment, conventional e-learning does the job for less, and headsets add hardware logistics without adding transfer.
  • Gamified business applications. Points, streaks, and leaderboards inside a workflow tool belong in the application stack your IT group already supports, not in an engine build they cannot maintain.

Frequently Asked Questions

What does this service cover, and what is it not?

We are a development partner, not a publisher. We do not fund development, hold the storefront relationship, or run marketing and user acquisition; the title, the store accounts, and the commercial decisions stay with you. We can prepare submission builds and the materials a submission requires, but the account they go out from is yours. Co-development also does not mean we take over the project: in that mode we work inside your pipeline, your conventions, and your review process.

Can we require a specific engine, or do you decide?

You can require one. If your team already works in an engine, or you have standardized on one across other projects, we build in it. Where something in your concept is awkward in that engine, we will say so early and describe the workaround and what it costs, but the decision stays with you.

What has to exist on our side before work can start?

A concept specific enough to name what the player or trainee actually does, the platforms you intend to ship on, an engine if you have a preference, the release window you are working toward, and one person who can settle design questions without convening a committee. That last item matters more than it sounds, because prototypes stall on unanswered questions far more often than on technical problems. You do not need a finished specification, and waiting to write one usually delays the prototype that would have tested the idea.

How does a project actually proceed, in order?

Assuming the prototype has answered the question it was built for, the next step is the vertical slice, and production content does not begin until that slice's pipeline holds. Before the slice, the plumbing gets set up: source control that handles large binaries, a build machine that produces installable builds without anyone's laptop being involved, and asset naming and import conventions everyone follows. Production then runs in milestones, each ending in a build you can play rather than a status report. Release preparation is its own phase and starts before content is finished, not after.

What does the game connect to, and what has to already be running in our organization?

On the build side: a source control host with large file support, somewhere automated builds can run, and developer accounts on the platforms you plan to ship to. Developer program membership and console development hardware are issued to the company the platform holder approved, so those stay with you and we work through them. On the runtime side, the usual integrations are identity or player accounts, in-app purchase and entitlements from the store you ship on, analytics, crash reporting, and for training deployments a learning management system that expects results in a particular format. If any of those already exist in your organization, say so before the slice: integrating an existing identity or reporting system is a design constraint, not a feature to bolt on later.

How does a VR build get onto headsets?

Standalone headset builds are installed through whatever device management your organization already uses for those headsets, and that path is worth testing with a single device before content is finished, because enrollment, distribution policy, and account requirements are where rollouts stall rather than in the build itself. PC-tethered VR is a normal desktop install with a runtime dependency, which moves the problem to machine specification and driver state. For training deployments, decide early who owns the headsets, who charges and updates them, and who is in the room when a trainee has trouble. None of that is engine work, and all of it decides whether the simulation gets used.

Who owns the code and assets, and where does player data live?

Ownership and license terms are set in the agreement you sign, so treat that document as the authority rather than this page. The way engagements are normally structured, the source and assets produced for your project are handed over to you, and the licenses an operator of a live product has to hold, engine terms and store agreements among them, sit in your name. Player data and telemetry belong in accounts you control: services deployed into your cloud tenancy, analytics under your keys, and repository access granted to named people and revoked when the engagement ends. Where our team needs production access to operate a live service, it should be scoped to that purpose and logged, and third party middleware and marketplace assets are worth auditing at the slice stage while swapping a dependency is still cheap.

Delivery is remote and hybrid, so how does testing on our target hardware work?

Which hardware sits where is decided at the start of the engagement rather than assumed. Phones, tablets, and headsets can sit with either team, and builds reach whoever holds them through the same distribution path the real release will use, which has the useful side effect of exercising that path early. Console development kits are tied to your platform accounts, so those normally stay at your site and your testers run the build, with defect reports and profiling captures coming back to us. Hybrid engagements exist for the stretches where the work is hardware-bound, submission passes and headset comfort testing among them, and being in the same room beats shipping devices back and forth.