(TL;DR: We got the first version of multiplayer working. Skip to the end of the post if you want to read more about that.)

Our debug model placer interface would like to tell you about the fine qualities of The Monarchy.

My time right now on CE is evenly divided between three things: the completion of new features (finishing the dynamics system, at present); revival of old features which stopped working due to bit rot at various points in development (animals, steps leading into buildings, etc.), or moving the pre-alpha from “let’s get it running on computers” to “let’s get it playable on computers where everybody actually moves, and does their jobs under real world conditions.” Hooray! Bug busting.

I like to think of this as making the game less sticky. Basically, what the last part means is this: sometimes, in the current build, people may never pick up a job, or may stop working altogether. Sometimes, under rare circumstances, the game will crash. (this has now been fixed.) Less damning problems include things like misbehaving UI widgets – things that don’t work correctly, things that accept mouse clicks that they shouldn’t (buttons in the UI accepting clicks from scroll bars, etc.) to latency. It is very much like somebody has dumped an enormous jar of honey into your video game, and you need to remove it all – ergo, stickiness. As you may imagine, chasing these through a game with the complexity of Clockwork Empires is quite a mess. Right now, for instance, I am working on the cheerful problem of ensuring people do not get trapped in modules when they are built, which means that before building a building characters must wait for all characters to leave the build zone before they actually go ahead and change the obstruction layer. The problem, of course, is that the builder is also a character – and he’s in the build zone, waiting for everyone else to leave – which means I need to calculate a list of all the squares next to a building or module that are next to it (so the character can build), but not in it (so that the character gets trapped).

“Go! My place is here now, embedded for all my days in the floor of the carpentry shop I myself built. Alas, but for what cruel irony was wrought by these, mine hands.”

These are all easy things, but annoying, and a lot of them have been fixed. Highlights include: not using a destroyed item as a building material for another building (crashes the game); ensuring that if your job item is destroyed, your job cancels correctly (people would get stuck); ensuring that, if your job got cancelled, you started at the start of the next job and not half-way through it (random things, breaking, forever); etc., etc. This is all standard bug hunting, but it’s the difference between a sort of wobbly tech demo and something people can actually play. I’m happy to report we’re grinding our way through it at a good speed, so it’s feeling more and more like a game every day. I know I keep saying that, but it’s true!

What is more interesting, though, is networking.

The half-eaten tub of chili in the middle of this photo really sells it. In other, related, news Nicholas is never allowed to take pictures of anything for Gaslamp Games ever again.

So – way back when we announced this game in 2012, we mentioned support for two types of multiplayer gameplay. The first, round-robin gameplay, provides a way to share worlds automatically between players for Boatmurdered-style hijinks. (This is totally not done yet.) The second mode we talked up was the ability to play online, with up to four of your friends.

This is now working: we can have two to four players connect to each other in an exciting game of networked Clockwork Empires. Well, it’s not very exciting yet – you basically run the same colony, “cooperatively”, and there’s no real notion of “your characters” versus “your friends’ characters” – this is all fairly easy stuff to put in. The hard part – taking an extremely complicated, multi-character simulation and getting it to work over a network? That’s done.

So how do you take a game where you may have two hundred characters, and get it working over a network? Answer: we cheat. Instead of sending either a) the game state, or b) “the parts of the game state that have changed” over the network (usually called deltas, after the fraternity), we run a deterministic copy of Clockwork Empires on each machine in the network game. By determinism, this means that “each person, playing the game with the same set of commands, will get exactly the same output.” In practice, this is very fussy – for instance, we can’t use floating point math, because floating point math may, in very rare cases, do totally different and wacky things on different machines that will throw off the determinism. Therefore we go through Great Pains to ensure everything we do is deterministic; our worlds are generated using old-fashioned fixed point arithmetic, just like we used to do Back In The Day before the original Pentium chip came out, and we had to do 3D on a 486DX/33. (Okay, I’m showing how long I’ve been doing this here.) We have to make sure that everything is sorted by consistent game IDs, and referenced by consistent game IDs; one of the last bugs causing this to blow up was caused by a linked list class sorting things by their location in memory as opposed to their game ID, which is a no-no. Anyhow, it all works, and two copies of Clockwork Empires running with the same random seeds for terrain and simulation generation will run in perfect sync.

Pictured: Micah furiously sending gamestate update packets via the heliograph.

In fact, there’s even more fakery going on. Despite the fact that Clockwork Empires looks like everybody’s smoothly moving from place to place, and dodging around each other, internally Clockwork Empires is discretized and everybody is on a fixed grid – to make the obvious comparison, it’s *exactly* like Dwarf Fortress. We just use colossal amounts of fakery to disguise this important fact from you. A cool bonus feature coming soon from all this work is debug logging. Since the simulation is deterministic, our testers can send very small logs back to us so that we can figure out why their game crashed or did Something Weird – which will, in turn, help remove stickiness.

Most of the work on networking was done by Micah and Ryan. (I just sat in the back of the car and gave incomprehensible directions.)

Imagine an image of UI annotated with a numbered list of everything you have to do stamping on a human face — forever. This is Nicholas’ life.

There’s a lot of work to be done here, of course. Daniel and David have both written an enormous list of tickets related to UI concerns and gameplay concerns, which I had to promise to do before I complete this bug post. More problematic for me is making the networking feel solid, and to give users the ability to automatically set up games despite being behind firewalls and routers. This is called NAT punching; the Steam API provides one solution, but we need to come up with something for users who do not have, or do not want to use, Steam for this purpose. Indie games traditionally do a poor job of this, probably because NAT punching is a pain in the neck.

There is also the longer, more interesting problem of game play. Right now, everybody plays in the same colony, in an anarchic free-for-all. At some point, we will need to address the issue of team-based gameplay: multiple players, on multiple teams, competing for the Glory of the Empire. With this, there are questions about balance and the Regulation of Gameplay. How sandboxy will the game be? How do multiple players colonize and fight on the same map? Is siccing the fishpeople on your opponent a viable strategy? (Yes. -ed)

What does a multiplayer simulation of a hundred or more discrete, interesting characters look like?

What is the gameplay here?

I don’t know, but I’m very excited to find out.