Introduction

Godkin is an in-development multiplayer co-op combat RPG, with a maximum of 4-5 players per session, and with high numbers of moving entities (4-5 players each with several AI-controlled followers; several villagers; and potentially 100s of monsters and 10s of defensive towers, missiles and spells active at a time). In order to handle the high amount of network traffic, I have developed an infrastructure involving, at its core, a direct peer-peer connection between each pair of players in a game session.

Peer-Peer Direct Connections

The main motivations behind a peer-peer approach are (i) low latency, and (ii) low server costs. Using peer-peer means that a hosted server is not needed apart from initial handshaking and NAT punchthrough. With 5-10 movement packets per second, per entity, per connected client, the amount of network traffic (and potential server CPU load) can grow alarmingly.

In my ‘web of direct connections’ approach, the player who starts up a game session listens for incoming connections. The second player to join connects to the 1st player and then itself listens for incoming connections. This procedure continues: each player who joins connects to each existing player’s connections, and then opens its own connection for use by subsequent players. This model means that each player can send and receive data directly with each other player (a traditional client-server setup would of course mean data between players would have to be relayed via the server, i.e. 2 hops rather than 1). Latency is minimised.

In Godkin, we’re using WebRTC data channels for both unreliable data (i.e. entity movement updates) and reliable data (i.e. game/entity states and event data).

Client-Server Fallback

The trickiest thing about peer-peer networking on the public internet is the fact that each client will be sitting behind a router which will probably not allow unsolicited incoming traffic, and in any case without manual configuration will not know where to route that traffic to, in its private network. The solution is NAT punchthrough which involves both clients connecting to a publicly-addressable server, and then (via data from the server) negotiating connections directly to each other through the same port that the other client just opened to the server. It’s a somewhat messy process and a small fraction of routers pretty much refuse to do it. Therefore, a fallback is needed whereby clients who have failed to achieve peer-peer connection will relay data to each other via a traditional server. In Godkin, we use UDP (for unreliable data) and Websockets (for reliable data) as a fallback. The exception is the game’s public hub where there can be larger numbers of clients, with players joining/leaving at a high rate: here, we use server-relaying all the time.

Scoping

The idea behind scoping is that certain data is less relevant to a player if it related to a game entity that is far away from their camera. The main data that can be culled through scoping is position updates (which are also overwhelmingly the most frequently sent types of data). Since Godkin is a 2D topdown/isometric game, it’s easy to decide whether a particular world position is visible to other players or not, assuming you know where their camera is located. If a packet is defined as ‘scopeable’, the sending client will typically only send it to other clients for whom it is in-scope. Every 25th packet is sent to everyone, regardless of scope. The exception is data related to Player characters, which is sent without scoping, since everyone needs to accurately know where everyone else’s camera is.

Distributed Control

One further system in Godkin which I have implemented for efficiency reasons is distributed control, by which I pass control of AI entities between clients based on whoever is closest to them. This means that both CPU and network loads are balanced between clients, rather than the game having a heavy reliance on the power and connectivity of the 1st player. In fact, distributed control is also a requirement in order to support scoping: we need to make sure that each client is controlling interactions between entities that are ‘in scope’ for it, i.e. it knows their positions accurately. Since Godkin is a co-op game, we’re not overly concerned about security (although, I have implemented some anti-cheating measures).

Unity3D Implementation

Godkin is being developed using the Unity3D engine, and I was initially developing the networking infrastructure using the excellent Bolt plug-in. Last year, however, the company Photon bought Bolt, and implemented a punitive per-seat cost which is the same as the per-seat cost of their client-server solution, despite the fact that server overhead in a peer-peer situation is a tiny fraction of that in a client-server situation. Unhappy with this, I explored other possibilities and eventually picked a really nice, bare-bones WebRTC plug-in. One of the benefits of moving to a simpler, low-level solution was also that I was able to fairly easily construct the ‘web of connections’ approach as described above, rather than treating the 1st player as a server (which is what Bolt does).

For the past few months, I have been working on Godkin, a pixel-art online co-op combat RPG. This is a collaboration between Psychic Software and Goblin Portal (our second collaboration, in fact, following up on last year’s release Goblins & Grottos).

Godkin takes a “faked 3D” view (this style is often referred to as isometric, although actually we’re not adhering correctly to the strict viewpoint that would make the game isometric.) Getting the lighting and shadows looking good in this style is somewhat challenging, since there’s no real 3D geometry for the game engine to work with. I’m having a lot of fun programming this game in Unity (it’s my first Unity game) and figured a blog post about shadows and lights was in order!

At the core of my shadowing system are the FakeShadowCaster and LightAnimator components.

LightAnimator

A LightAnimator component is attached to any objects that have lights – camp fires, torches, explosions, etc. These search for nearby objects which have FakeShadowCaster components, and register with them. They also notify the FakeShadowCaster objects whenever changes happen (e.g. the light moving, flickering, brightening, dimming, turning off).

FakeShadowCaster

A FakeShadowCaster component is attached to any objects that we need to cast shadows – basically, anything that should appear to have some 3D ‘height’ – characters, monsters, rocks, trees. This component maintains a list of nearby light sources, and creates a fake shadow sprite to associate with each of them. Whenever a light notifies a change, or if the FakeShadowCaster itself moves, its list of shadows are re-calculated. Each shadow is rotated to face away from the associated light source, and its opacity is set based on distance from the light (plus other variables). I also wrote a ‘shadow skew’ shader which spreads apart the vertices of the shadow sprite which are further away from the light source – with a stronger effect the closer it is to the light; this adds quite well to the overall feeling of 3D. Another nice touch is that we can use whatever sprites we like for the shadows – so trees, for example, can have their shape baked into their file.

‘3D’ Object Shader

The standard Unity sprite shaders look great for terrain, and sprites which don’t have much ‘height’ – however, since the amount that each of their pixels is lit is simply based on the distance they are from light sources, this starts to look strange for objects that are supposed to be tall. The problem is that the top pixels and bottom pixels of the object will be at quite a different distance from the light – but to look like a proper object with height, the vertical position of all pixels should be considered the same, for lighting purposes. So here we have a shader that attentuates light to all pixels based on the position of the vertically lowest ones. This shader also reduces the brightness of any object which is in front of lights (since in this case the majority of the light should be cast on the non-visible ‘back’ of the objects).

If you’d like to follow the progress of Godkin’s development, here’s our blog. Or why not join us for a chat in Discord?