Demon Pit

This is a fun little game I’ve been working on part-time with friend and local artist Paul Conway (see DoomCube and The Darkside Detective), with audio provided by Thomas O’Boyle (see Thomas’ Website). The seeds of the game actually came from a GameJam-winning game I made with Paul over a weekend last November.

Demon Pit is a hardcore first person shooter (FPS) of the “Arena Shooter” sub-genre – essentially, an oldschool arcade game where it’s all about skill, reflexes, and learning the pre-scripted enemy patterns. We’ve been making great progress over the summer since we’ve been co-locating one day a week to work on this. Paul has a detailed eye for this game genre (it’s one he’s into), as well as for all things artistic, so this translates to precise instructions for me to implement.

I’ve been using Unity3D for a few years now (and lecturing it to my 3rd year undergrads since last year), so I’m quite adept at structuring things and I’ve learned what to do and what not to do. I’ve learned to hate the horrible archaic garbage collector which Unity clings to, which turns strings in particular into minefields which can stutter your framerates. But it’s generally an excellent game engine.

Demon Pit adds a couple of new features to the FPS Arena Shooter genre – first, we have walls which move up and down during the game, which creates a constantly changing, small and claustrophobic arena. Second, we have a “grappling hook” mechanic whereby you can transport rapidly between a number of “portals” around the arena. I see this as an equivalent to the “teleport” mechanism which games such as Defender and Asteroids had – basically, an escape/panic-button. The grappling hook is more controlled and subtle than this though, and moving swiftly around between the portals while getting in some crafty mid-air shots is a very useful tactic.

Some of the enemies fly, and we have different behaviours here – some are blocked by the walls while other tend to swoop around and over them, diving at you from above. Other enemies are on foot, and one of the technical things I’m quite pleased with is the A* pathfinding implementation which runs multi-threaded and deals with the constantly changing arena by performing a bunch of raycasts after every arena change. I’ve been teaching the A* algorithm to my 2nd year undergrads for the past few years, and it’s something I’ve also worked on previously (see this blogpost and academic paper from 2011).

Another small feature which I’m pleased with is the enemy deployment patterns. Enemies spawn from the centre of the arena and follow one of several visually-impressive procedurally-generated formations such as “Fountain” or “Vortex”. To get these high-speed formations working precisely, I control the enemies kinematically while they’re in formation, and then switch them to normal physics-engine control when they break rank. While in formation I log their current and previous position, which means when switching to normal physics control I can calculate and apply the correct initial velocity to make the transition seamless.

The audio is coming along nicely too (great work from Thomas), and we’ve put in some play-synchonised music, for example an extra-crunchy guitar track which moves forward in the mix during the spawning of a new wave of enemies.

High performance networking with a ‘web’ of peer-peer connections in Godkin

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).

Godkin: An Online Co-Op Combat RPG

Although we have been prototyping various parts of Godkin since about a year ago, we didn’t tie down most of the details until around June this year. Since then, there’s been a big push on to get the game up to a demonstrable state for Galway Games Gathering (this weekend).

Online Co-Op Combat RPG

The core of Godkin is an online party-based combat RPG, where you play as demi-gods defending procedurally-generated mortal realms that are being invaded by hordes of monsters. As you gain experience, you will learn spells which are aligned with one of 10 different elemental gods. The monsters are also associated with specific elements, and gathering a party with appropriately varied skills will be an important goal with the more difficult game maps. Technically, the online play uses an optimised mix of peer-peer and client-server networking; I’m planning to write a blog post about this quite soon.

Attack and Defend

To win a game of Godkin, your team will have to balance attack and defence. You’ll have to track down and eliminate all of the monster camps on the map, while also overseeing the construction of walls, barricades and towers for the villages. As monsters approach the villages, your role will become that of field-captains: fighting, yes, but also marshalling and instructing the mortal characters who you are trying to save. Working as a team will be critical to achieving all of these simultaneous goals.

Villagers and Followers

The mortal characters in the game take the form of villagers and followers. Followers are essentially combatant villagers who have pledged themselves to your service, and who you can bring with you into different games. They level up and gain skills, leadership ability, and courage; however, they can die (permanently). You issue orders to followers – gathering resources, constructing defences, or joining you on at assault on the monster camps. However, you don’t directly control them – if you push them into too much danger, their courage might break and they will run away. Your followers, in turn, gather together villagers to assist them with their gathering and constructing.

The Map

Godkin maps are procedurally generated – they include mountains, lakes, seas, forests, and villages – as well as caves and other areas which are not part of the core game win/lose conditions, but where random monsters can be found and rare loot gathered (treasure, magic weapons and armour). The difficulty of the map will be defined in terms of its monsters and resources – and as you get more experienced at the game you’ll unlock more and more challenging maps. We’re also going to include weekly challenge maps and high-scores – so teams can pit themselves against other teams playing the same map. I’m planning to write a blog post fairly soon about the procedural map generation used in Godkin.

Hubs and Lobbies

The Hub (located in the immortal realm) is where you meet other players, chat, and form teams. Lobbies (also in the immortal realm) are private platforms where a team readies itself for combat: choosing map parameters and selecting spells, equipment and followers.

The Development Team

Godkin is being developed by the same team that made Goblins and Grottos, which we released in July 2016.
Game Design: Everyone
Programming: Me
Art: Björn
GUI Design: Jonas
Audio: Ian

Godkin Tech Posts

Faking Shadows and Lights in a 2D Game
Procedural Map Creation in Godkin (coming soon)
The Godkin Networking Infrastructure: mixing peer-peer and client-server (coming soon)

Godkin Links

Godkin on Steam
Godkin on Discord
Godkin on Facebook

Orbs.it — an “agar.io” style game

Agar.io and Orbs.it

A couple of years ago, agar.io was released as a browser game, and caused quite a sensation. It has subsequently spawned an entire genre of games — lightweight, massively multiplayer browser games with simple graphics and gameplay. This type of no-nonsense, easy-access multiplayer game appeals to many people, and naturally suits lone developers (especially when their art skills are not great).

So late last year, and early this year, I developed orbs.it

Orbs is a simple to play game, yet is very skillful. It’s about fast and accurate control of your “guns”. Eight players start the game, and each initially control a single orb which is part of a set of 24 orbs encircling a central “sun”. You shoot from your orbs, and when you hit another orb you take control of it. The winner is whoever is left last in the game. It’s a very satisfying mechanic, especially when you get in the flow and claim orb after orb in rapid succession.

Lots of users

In May I released orbs.it on iogames.space which is the main portal for “agario-style” games. I was pleasantly surprised with the amount of players that clearly seek out this type of game — within a couple of days, my server was starting up 5-10 game sessions per minute, each with typically 4 or 5 humans in (the rest being bots). As of right now, there are nearly 90,000 player accounts in the game’s database.

Server architecture

Orbs proved to be a nice test-bed for the nodejs-based gameserver cluster I had developed. The central masterserver looks after player logins and communicates with gameservers which run the actual game sessions. It monitors the number of games running on each server, and dynamically starts/stops server instances as required, to deal with varying loads. There’s also some interesting requirements around things like gameserver hot-patching, so again this has involved developing useful techniques which I’m sure I will use again. I have done this sort of thing before in Darkwind of course, but the system in Orbs is generally much slicker and didn’t suffer from the horrible nightmares of blocked sockets which afflicted Darkwind on its opening weekend on Steam.

Networking

High-speed networked gaming is always a challenge to develop, and a particular challenge for “agario-style” games is that they are generally limited to using websockets for their communications. Websockets provide really handy bidirectional communication between browser and webserver, so are far better than plain-old Ajax.. however, they are still based on TCP, and that means guaranteed, ordered delivery of packets. This is the main cause of sudden spikes in latency which most Websocket games suffer from. The latency is basically unavoidable – it happens when a packet fails to deliver and has to be re-delivered, and all subsequent packets are cached on the receiver until such time as the missing packet arrives, so that they can be delivered to the receiving application in the correct order. This makes TCP fundamentally unsuitable for fast-moving data, especially when the nature of the data is that late packets are irrelevant. If your application knows where a player’s orb is at time 20 in a game, it really doesn’t care to know where it was at time 19, yet TCP doesn’t allow your application to see the data from time 20 until the data from time 19 is received.

Deterministic positioning of orbs

I wanted orbs.it to be, as far as possible, immune to the latency problems caused by TCP. I didn’t want the field of orbs to jump around and glitch on the screen, like the player-controlled entities in most agario-style game do. The solution was to remove player-control of the orbs altogether – this also fitted the design requirement of simplicity. The orbs move around in orbits, based on elliptical paths with continually changing parameters (and ultimately controlled by Sin and Cos, of course). The real trick is that these paths, although interesting and varied (leading to a continually-shifting playfield) are entirely deterministic. At any specific time after the game has started, the game server and game clients can all calculate and precisely agree on where each orb is. This vastly simplifies things and gets rid of many of the difficulties associated with everything a game client knowing about everyone else being out of date by the time they know it.

If you’re interested to read more about fast-paced multiplayer networking, this is an excellent overview.

You can play orbs straight from your browser here: orbs.it and it’s also available on the Android and iOS app-stores, although has not seen much traction there.