Get SpatialOS

SpatialOS

Company

Careers

Sites

Prepare for entropy

Get started on your own SpatialOS game development with our free SDK.


Gabriel Gambetta is Tech Lead/Manager of the SpatialOS Community team at Improbable.

It turns out the old nemesis entropy is as prevalent in simulated worlds as in the real one. All return to the dust.

How do you maintain a dynamic and interesting world that is always on? This is a question that we think about a lot here at Improbable.

In games, designers will go to great lengths to carefully craft an environment for the player that is not only beautiful, but which casts aspects of the gameplay in sharp relief. If one of these gameplay aspects is the destruction of the environment, we have a problem.

One way around this problem is to be limited to an environment that can be only partially destroyed. The main structure of the world is static and immutable, it is indestructible and can’t be interacted with by players. Small aesthetic details or companion pieces may be added that are destructible. These pieces will typically regenerate over time.

An alternative approach would be to have a world that can be completely destroyed, but that only exists for a brief time before it is reset back to its original state. This what we see in first person shooters where gameplay occurs during carefully controlled, time limited rounds. This is also popular in open world survival games, which regularly wipe the map and restart, cleaning up the destruction, but also erasing players’ hard-earned progress.

The longer you run a simulation in a highly dynamic world, the more that world will degrade until it bears little resemblance to the initial state. Physically simulated entities will fall down into their lowest energy configuration and any structure that existed in the world when it launched will be lost.

It turns out the old nemesis entropy is as prevalent in simulated worlds as in the real one. All return to the dust.

In the real world, we are locked in a constant battle with entropy. We mow our lawns to hold back nature, repave crumbling roads and build new structures over ruins of the old. What if we used this idea to maintain our persistent, always on worlds? What if there was an agent within the simulation responsible for maintaining the world?

Introducing the Towers Demo

In Towers, there are three kinds of entity: Cubes, Trucks and Builds. These entities interact in a meaningful way to populate the world with interesting structures.

Towers world

Here are the rules for the simulation:

  • Each Truck is assigned one of two teams: Red or Blue.
  • A Truck will subscribe to the nearest Build with the same team.
  • A Truck with a Build will undergo a random walk until it finds a Cube.
  • When a Truck finds a Cube it will beeline straight to it.
  • When a Truck is close to a Cube, it will pick up the Cube and return it to its Build and drop its Cube on arrival.
  • When a Truck which is subscribed to a Build has been unable to find a Cube for a number of seconds it will charge straight for the centre of the rival team’s Build.
  • Builds belonging to Red Team organise Cubes into a square-base cuboid.
  • Builds belonging to Blue Team organise Cubes into a circle-base cylinder.
  • When a Build discovers a Cube nearby it will use the Cube as the next piece in the current build.

Importantly, each Build is informed when one or more of its Cubes is out of place. In these circumstances, a Build will destroy itself, releasing all constituent Cubes and subscribed Trucks back into the wild:

If a Truck is unable to find a Build within a fixed time, it has the ability to create one. Indeed, this behaviour is relied upon at the beginning of the simulation as no Builds are created on start.

With just these simple behaviours, we can see how each instance develops a unique history in both time and space. This history is not static, rather it is live and evolving.

Finally, not only is the history of the simulated world live and evolving, it is even interactive!

We could not resist adding the ability to blow up stuff! In the demo the user can click on a cube to turn it into a timed explosive. This feature is perfect for knocking down the tallest towers.

explosive demolishing tower

The pièce de résistance however is the Tornado. The user can click drag on the ground to mark out a path to be followed by a physically simulated Tornado. The Tornado will pick up any cubes or trucks that enter its domain and spin them violently around the centre of the vortex.

Tornado heading towards tower

Your World Here

It is already interesting to imagine playing a deathmatch with first person player characters in a world such as this, using the built and broken towers as cover. We are excited to see how far this kind approach will take future users of our technology.

It is hopefully not too difficult to see how this approach could be adapted to build different and more varied structures. In a real game, each artist designed buildable asset could have intermediate stages from unbuilt to built and agents could deliver the different pieces needed to complete the build in the order in which they are needed.

Each buildable asset could just be a single piece, but equally it could be one template taken from a library of templates of gameplay showcases that, in covering a small area, are intended to be repeated throughout the world at appropriate intervals.

You can find the source code for the Towers Demo, as well as our other demos, on our GitHub.