Spilt Milk on: Designing mechanics in a system that lacks constraints.



Spilt Milk Studios are currently working with Improbable’s SpatialOS to create Lazarus, a top-down multiplayer shooter set in a universe that can be developed, built up and then resets every week. Andrew Smith is their Creative Director.

All games, and specifically all genres, were born of constraints mixed with imagination. It seems obvious to say, but it’s worth remembering – every single game you’ve ever loved was impacted by memory limitations, colour palettes, sound chips and the like. And despite the fact that we can make incredible things with modern computers and consoles, the relatively small steps taken in the power increase of CPU / RAM / GPU gave plenty of extra wiggle room for designers and coders.

Every few years a relatively substantial step was taken. I’ll never forget how sprinting around the alien world of Doom first felt. That first foray into the 3D playground world of Mario 64, too. For some games, these advances are obvious because they are presentational, but for other games the forward march of tech had less extrinsic meaning.

Systemic games like the Civilization, Tycoon or the X-COM series were particularly limited by computing power in their earliest incarnations, and yet benefitted the most from tech advances. The same computational advances that led to better graphics or 3D worlds in other games meant that Civilization could, to boil it down, respond satisfyingly to far more varied and numerous player decisions.

Unlimited Promise

Looked at through that lens, the promise of SpatialOS is therefore a sea-change, perhaps even bigger than the traditional jump between console generations. It’s more like the change in thought that comes with new hardware – like sound cards, large storage of CD drives, floppies, the advent of GPUs. All these are substantial resource availability changes, and the story of game development has long been about fights over resources between different areas and how programmers work with that. How do you design when those tired old resource limits aren’t in place any more, but other hidden limits are?

Our design process was iterative and always open to change – it’s how we roll at Spilt Milk Studios – but we were not fully prepared for what we saw with SpatialOS. Starting from the bare bones idea of ‘MMO Asteroids’, we knew our first steps would be wrong, at least in the sense of taking best advantage of this new tech. Yet embracing and planning for failure is the best way to learn, so we refused to get down about it.

This was an opportunity to test our methods against a technology not a lot of people had even been exposed to – but we found it was also (and perhaps more importantly) an opportunity to test our ‘thought chain’. That phrase might be a potential candidate for Nu Speak Phrase of the Year 2017 I realise (and it’s only February), but regardless we have a certain practical ‘cost effective and achievable means to a playable end’ way of thinking about things (which a lot of game devs share.) The core of the challenge here pretty much boiled down to how well we were thinking about the opportunities that were now available – what we called the ‘thought chain’.

Purple Diamonds game screenshot

Limit Break

That meant our new core limitation was actually design time. We knew the top-down shooter was understood and were confident it was a solved problem, so we tackled the larger simulation as a separate challenge. Even though we’d planned for failure, we bounced off this more times than we expected.

That’s because the shooter level and the larger simulation are are intertwined. Each time we iterated, we brainstormed, then we checked the idea for realism and workload, before asking ourselves ‘was it taking advantage of the tech?’

But do you worry about the player’s interactions first, or the world they interact with? Of course it’s never that black and white, but this is especially true when applied to a living world – a game as a simulation (or should that be a simulation as a game?) As a small team we’re acutely aware of the scope of our abilities and reach, and that may have been a further limitation on the ambition required to really push as hard as we needed to on Lazarus.

Unshackling yourself from your normal modes of thinking takes some effort, pain and time.

The SpatialOS “thoughtchain”

Unexpected constraints are a part of everyday life as a game developer, but over time you get to thinking you know most of them, and if you don’t you can probably predict where they’ll come from. Stating the obvious, normally you only have to think about the cost of a call to the CPU, GPU, system memory and the like.

But everything in SpatialOS has a deployment cost, which is something you don’t have to think about for most games, other than MMOs. With SpatialOS, you have to consider workers, how you spread the load, how efficient you make the calls to them, the density of them in a typical play session, what happens with an ideal player count, or what occurs if nobody’s around…? You’re building an ecosystem of interrelated components.

Light explosion game screenshot

With Lazarus, we’ve taken that to heart and built an ecosystem of mechanics too. As I touched on above, we had to make a design choice between an ecology with the player cast in the role as just another agent (albeit a way less predictable and far more powerful one) or giving players actions to build that world, that ecology around through play. The point when we decided this was the point at which Lazarus truly stopped being ‘just’ MMO Asteroids.

We settled on the ecosystem first, although we arrived at that via a period of iterative play with systems built to give the player interesting choice, which themselves then fed back to the ingredients we’re giving the ecosystem… you can see how much of a twist you can get yourself in. And so the challenge moves away from ‘what to build and how?’ and towards ‘how on earth do we make sure the player knows what’s going on, has the information to figure out what they can do to mess with the system, and has the confidence to go ahead and try?’

Every player action has some effect, but unless the player is told, then it’s a waste of time e.g. choosing to shoot an asteroid versus mining it. Picking up a resource versus leaving it to time out. Killing an AI you come across versus leaving it be. We have to think, and encourage the players to think, like economists at both a macro and a micro level. That’s a tall call for a 2D shooter!

Mining in Lazarus

A Spatial thoughtchain example: mining in Lazarus.

Picking on the mining vs shooting example specifically, this is the core of what we’re about in Lazarus. One choice is to explosively, destructively, messily interject yourself as a player into the status of resources – that is to shoot the asteroid, watch it blow up, miss some of the pickups that it drops, and move on. The other choice is to move close to a ‘roid, make sure not to bump into it, mine it with your mining tool, and suck it dry – this leaves nothing to chance and no resources left ‘in the field’.

This movement of energy around the ecosystem is how the player can play, but it’s also how the AI can play. Depending on the circumstances the world, this might result in the birth of a new Xenotaph, the death of one, the mutation of a Queen, and countless other consequences both big and small. We’re building Lazarus’ world as a closed loop, one that absorbs any lost resources back into itself, one that is in a constant state of moving those resources or energy into different containers – some of those containers move around aimlessly, while some of them will fight you on sight.

SpatialOS offers you the chance to think differently, to design differently, and to do so without worrying about the restrictions you’d normally expect, while at the same time unshackling yourself from your normal modes of thinking takes some effort, pain and time. We can’t wait to see how this percolates down into Lazarus and how players have fun inside its rules!

Update – we have announced new Unreal and Unity game developer kits (GDKs) as improved versions of our SDKs. Find out more about the Unity GDK and Unreal GDK.

More solutions. More possibilities.

Explore all IMS solutions