Polygon Pi

Last year, before I started working on my Frozen game, I started with something a bit simpler for my then-3 year old – a 2D Little Mermaid game. I wanted to make something very simple to teach basic 2D pad controls with minimal buttons required. On the plus side, no UI or text was required as she can’t read. Ariel is my daughter’s original favourite character, and some kind of swimming game sounded like a good idea. Also I hadn’t tried tilemaps in Unity before, and this was a good excuse to investigate. Here’s the end result:

The initial idea was to help a mermaid find her children who were hiding in a little maze, and bring them back to her. I’d picked up one of the Humble Bundles for creators that had some basic tile sets in, so I thought this would be easy. Unfortunately when I actually looked at the tileset it was completely useless – most of the tiles weren’t even square! Long story short, I eventually hopped into GIMP and drew my own, hence they don’t look very good!

But after making a simple maze, chucking in a parallax underwater background and adding a few simple fish sprites that moved back and forwards, it actually looked OK and I excitedly showed my daughter.

She takes the pad, goes straight up to the roof of the cave and says “Daddy, I want to go to the surface and see Prince Eric”. Except there isn’t a surface, or Prince Eric. But she does have a bit of fun swimming around looking for mermaids.

A couple of days later I’ve added some scrolling waves, some sky, and Prince Eric standing on the shore. “Daddy, I want Ariel to turn into a human and go into Eric’s castle.”

This game is going to be a little more involved that I’d anticipated. Oh well, it give me some direction, and it’s not like I’m not used to the whims of demanding designers.

Soon it had escalated. “Daddy, put in a giant penguin that goes up and down and has water spraying out of its head. And some monsters.” But finally I called it a day – after rescuing the mermaids you retrieve Eric’s castle key, do a little bit of platforming inside to grab your luggage, find the keys to chests containing other vital supplies, and then you sail off with Eric on a boat. Phew.

It’s not a technically great game by any stretch, I was just hacking stuff in quick. But it was pretty fun to make, and it was great for my daughter to see it being made (we mostly played it together in the editor, chucking sprites in and moving things around – she was obsessed with making the seagulls huge and green at one point). The only thing I’ve changed since is the music it originally had – after hearing the same jingly song from the musical on loop for hours on end, I just had to replace it with some generic background music.

I bought a bunch of the popular Unity landscape tools recently, namely Gaia Pro, Vegetation Studio Pro, Complete Terrain Shader and River Auto Material. I also picked up a couple of the Nature Manufacture asset packs.

Here’s a little video of using the tools to quickly create a landscape. Note that I have spent a decent amount of time setting up the biomes and rules first so there’s work to be done after acquiring the tools, but once that’s done it’s super quick to create landscapes!

Gaia Pro

Gaia Pro from Procedural Worlds is primarily a tool for creating terrain heightmaps. It includes a wide range of ‘stamps’ (predefined heightmaps) which you can move, scale and rotate, and then apply to your terrain. There are loads of modes for applying stamps – add, subtract, blend, or apply effects like erosion, steps or peak enhancement. Stamps can be further combined with distance masks or other heightmaps for plenty of control. There’s a nice preview visualiser so you can see more or less what it’s going to do to your terrain before you apply.

Gaia Pro has loads of other features bundled in. You can set up texturing rules based on angle and height to automatically texture your terrain, as well as add rule-based spawners to add trees, rocks and buildings. Also bundled in are other asset sample, such as water, environmental audio, post-processing control, and a selection of trees, rocks and building assets.

This was the first tool I bought, and it’s a good all-in-one package to get started with. The terrain editing bit is great, but personally I don’t used the texturing and spawning controls – I find that Vegetation Studio Pro does that better.

Vegetation Studio Pro

Vegetation Studio Pro from Awesome Technologies is a must-have if you’re making large outdoor terrains. It takes a bit of setup, but afterwards you can author whole terrains in minutes.

You set up a series of biomes, each of which consists of terrain texturing rules and vegetation placement rules. The terrain texturing is similar to Gaia. You defines rules for each texture based on height and slope, convex or concave terrain, and Perlin noise, and they’re all combined to get the final texture. Vegetation follows similar rules – drop in your prefabs and set up similar rules for each based on height and slope, underlying texture, and density.

One massive bonus of the Pro version is that it supports multiple biomes types simultaneously. You define a default biome and can then drop other biomes into the scene and define their extents. The highest priority biome at each point is the one used, and there are cross-fade rules and curves to blend textures and reduce vegetation density or scale across the border.

In my game I have a default grass biome. I’ve defined a couple of different forest biomes so I can drop them into the level, mark the borders and you’ve got instant forests. And it uses its own batching and rending system so everything draws super fast! It’s the most expensive tool I’ve bought but definitely worth it.

Complete Terrain Shader (CTS)

Complete Terrain Shader is also from Procedural Worlds. It replaces the default Unity terrain shader with a more advanced one with more options. I think it has two main uses – the simple one is to add interest to distant terrain and break up the tiling, and the second is to use height maps for each terrain textures to completely change how textures are blended together.

The standard shader variant adds ambient occlusion, low frequency detail normal maps, height-based geological banding and snow, lower frequency tiling on distant terrain, and a few other features. These tweaks will make your distant terrain more visually interesting and less flat. Whether it’s worth it probably depends how much stuff you have in your world – if there’s a lot of detail and objects over your distant terrain it might not be so noticeable.

There’s an advanced shader variant that uses per-texture heightmaps, combined with the standard texture blending, to determine which texture to use per-pixel. I’ve not looked into this too far, but done well it can give far higher resolution, sharper texture blending.

River Auto Material (R.A.M.)

River Auto Material is a tool for creating river, lake and road geometry. You just click to add river spline nodes, set the scale and rotation of each node, apply a material preset, and paint transparency for blending. Fast and slow water effects are applied automatically based on the river gradient, or you can paint them yourself.

You can also simulate river flow, which I use a lot. Drop in the start point, hit the Simulate button and it’ll generate a river that flows downhill. Then there’s a terrain carving tool – draw the river bed profile in the graph editor, hit the Carve button and it’ll reshape the terrain around the river and blend it in to the existing terrain.

The other great feature is Vegetation Studio Pro integration. For each river preset you can define an associate biome type. Simply set the desired biome width, press a button and it’ll automatically generate a matching biome mask around your river. This makes it really easy to blend your rivers into your scene – the sand and rocks in the screenshot above were added like this.

I’ve not dived too far into the possibilities yet, but it’s a fun tool to use and I like the results a lot.

This is part 2 of how my spaceship building/fighting game is structured. Find part 1 here.

Space network synchronisation

Each player’s ship consists of a parent object with a PlayerShip script and a Rigidbody 2D, and a bunch of children (one for each attached ship module). I very much like the fact that you can just add a selection of children with box colliders (i.e. the modules) to an object with a Rigidbody and the physics interactions Just Work (certainly well enough for my purposes).

With that in mind, the only objects created with a Network.Instantiate() are the parent ship objects, one for each player. The server owns all network-instantiated objects, and nothing is network-instantiated on a client. The server keeps track of which object belongs to which player.

The clients have already been told which modules make up all the ships, so they create them all locally and attach them as children of the ships. The parent PlayerShips are the only things in the game that use the NetworkView state synchronisation (which automatically updates position and rotation 15 times/second). This is very efficient as there is only one synchronised object per player.

Prediction and interpolation

The ships use some simple prediction to minimise the effects of lag. I’ve seen a few people asking about how this works, so here’s the serialisation code:

void OnSerializeNetworkView(BitStream stream, NetworkMessageInfo info)
{
  if (stream.isWriting)
  {
    Vector3 position = rigidbody2D.position;
    Vector3 velocity = rigidbody2D.velocity;
    float rotation = rigidbody2D.rotation;
    float rotSpeed = rigidbody2D.angularVelocity;

    stream.Serialize(ref position);
    stream.Serialize(ref velocity);
    stream.Serialize(ref rotation);
    stream.Serialize(ref rotSpeed);
  }
  else
  {
    stream.Serialize(ref syncPosition);
    stream.Serialize(ref syncVelocity);
    stream.Serialize(ref syncRotation);
    stream.Serialize(ref syncRotSpeed);

    syncPositionFrom = transform.position;
    syncRotationFrom = transform.rotation.eulerAngles.z;
    syncBlendTime = 0.0f;
  }
}

And here’s the update code to calculate the transform every frame:

void Update()
{
  if (!Network.isServer)
  {
    syncBlendTime += Time.deltaTime;
    float blend = Mathf.Min(1.0f, syncBlendTime / blendTimeMax);
    transform.position = Vector3.Lerp(syncPositionFrom, syncPosition, blend);

    float newRot = Mathf.LerpAngle(syncRotationFrom, syncRotation, blend);
    transform.rotation = Quaternion.Euler(0.0f, 0.0f, newRot);

    // Update the from and to values by velocity.
    syncPositionFrom += syncVelocity * Time.deltaTime;
    syncPosition += syncVelocity * Time.deltaTime;
    syncRotationFrom += syncRotSpeed * Time.deltaTime;
    syncRotation += syncRotSpeed * Time.deltaTime;
  }
}

This will predict the position/rotation in the frames following an update, and blend out previous prediction errors over blendTimeMax (set it the same as your time between updates). This will fix all positional discontinuities (nothing will pop to a new position) but there will still be first-order discontinuities (velocity will pop).

That’s not a problem at all for the other ships, as it’s not noticeable in a game like this with slow controls. The only issue is if the camera is fixed relative to your ship (which it currently the case), because a tiny change in the ship rotation leads to a large movement of the background at the edge of the screen. It’s still barely noticeable, but ideally the camera position/rotation needs to be slightly elastic.

Controlling the ship

The Space scene contains a PlayerControls script which takes input from the keyboard and sends it to the server. You have controls for applying thrust in four directions (forwards, backwards, left and right), firing in each of the for directions, and steering left and right. The PlayerControls sends an RPC to the server whenever any of the inputs change (e.g. started or stopped steering) to minimise server calls. On the server, the inputs are passed to the PlayerShip owned by that player.

Ships are controlled by applying physics forces to the Rigidbody. Every FixedUpdate(), the PlayerShip uses GetComponentsInChildren() to find all the Engine components (scripts attached to the engine module prefabs) and send them the net horizontal and vertical thrust. If the engine is facing the right way is applies a force to the parent Rigidbody with AddForceAtPosition().

Applying the force at the actual engine location results is wild spinning for even slightly unbalanced ships, so I blend the position nearly all the way back towards the centre of mass to make is more controllable (97% of the way in this case, and even then it’s hard to drive with off-centre engines).

Steering simply uses AddTorque() to rotate the ship.

Weapons

Weapons are fired in a slightly different way to engines. Because there are a variety of weapons systems, I use BroadcastMessage() to call a function on every child script that responds to it (scripts are added to each weapon module). Each weapon script keeps track of its own cooldown and fires if it can.

Firing weapons creates Projectile objects. Each weapon module prefab has a Projectile prefab referenced in it, and each Projectile can have different graphics, speed, lifetime, damage and particle effects. The projectile is created on all clients by doing a Network.Instantiate().

Because projectiles go in straight lines there is no need to synchronise the transforms over the network. The initial position and velocity are set precisely the same as on the server, and the parent ship velocity is added immediately after creation with an RPC (use the new object’s networkView.viewID to identify it on the client). The projectile can then move itself locally and be in exactly the right place.

Impacts and damage are all calculated on the server. OnTriggerEnter2D() is used to detect when a ShipModule has been hit. Network.Destroy() is called on the projectile, a particle effect is instantiated on all clients, and damage is applied to the ShipModule.

If the ShipModule has been destroyed it informs the parent PlayerShip which checks if any other components are no longer connect. RPCs are then used to tell clients to destroy the relevant modules. If the red central component is destroyed then you’re out of the game.

No physics calculations or collisions are processed on the clients at all. The game is entirely server-authoritative to minimise cheating possibilities – the clients simply sends off inputs and receive updates. Overall I’m pretty happy with how it all works, and very happy that the entire game comes in at under 3000 lines of code (total, including comments and blank space)!

Next it needs a load of polish – better graphics, add some sounds, a building tutorial etc, but it’s a decent start.