The nice thing about working with a bunch of friendly and clever folk at Braintree is that they are always willing to brainstorm on better ways of building software. “Clans” is no exception, and within 20 minutes of posting Part I we¹ had come up with a simpler way to build it.

In our last thrilling installment…

I left off in Part I talking about running Unity on the server. It consisted of two parts:

1. Clients (our players) submit orders to the server that represent what they wanted to do on their turn.
2. When the server has all orders for all players, it processes those orders on the server and sends back to clients the new game state that results from it.

Turns out that Step #2 is overkill². Instead, once we have all players’ orders, we just have to send back to each client that collection of all players’ orders and let each client simulate what happened. As long as the simulation is deterministic, clients should end up with the same game state that the server would have generated. This avoids any kind of Unity/Mono running on the server at all.

This introduces the possibility of clients accidentally generating different ideas of the “current state” of the game and getting out-of-sync from one another. This is hardly a novel problem or indeed solution. The original Warcraft used a similar scheme in multiplayer albeit to solve very different problems than what I’m solving. There is a fascinating analysis of the Warcraft out-of-sync problem and its solution by one of Warcraft’s creators, Patrick Wyatt.

My solution will be a slight variation on the first step above. When clients send the server their orders, they’ll also send their understanding of the current game state. Specifically, each client will serialize the current state of the game as they understand it and produce an MD5 sum of the result. If any client sends an MD5 sum that differs from the others, the game is out-of-sync and is dealt with³.

The New Plan ⁴

1. Clients (our players) submit orders to the server that represent what they want to do on their turn. In addition they submit an MD5 checksum of the current game state.
2. When the server has all orders for all players, it verifies all clients had the same game state. It then sends back to clients all other clients’ orders.
3. Each client verifies and simulates orders on their own to determine the next game state.

Next Time, on “Clans!”

Scott outlines how the server will work, something he promised to do in Part I! Enriquela discovers a terrible secret about sharks! Captain Boontz makes a decision that will change OMEGA GOGO SQUADRON forever.

TUNE IN NEXT TIME!

SP

In my previous post on my next game project “Clans” I outlined the kind of asynchronous turn-based strategy game I want to make. I didn’t discuss the implementation details though.

An asynchronous game implies there are persistent servers available to coordinate game state between players. I want to leave the option of an offline mode available, and I also need to make this easy to develop without having to run a server locally.

I experimented with a few options but it came down to two: build my game logic in a separate assembly and reference that from Unity, or take the compiled DLLs Unity creates of my custom code and find a way to run them without most of Unity.

Option 1: Separate Project

While building my game logic as a separate assembly is more logical and definitely cleaner, I ran into a few issues. While I don’t need most of what Unity provides in classes like MonoBehavior for my game logic, the utility classes around math and vectors would be a big help. Furthermore, Unity periodically likes to rebuild your solution files which forces me to periodically re-add my GameLogic project.

Option 2: Headless Unity

When you build & run your Unity game, Unity compiles all of the custom code you’ve written for your game into a DLL named “Assembly-.dll" (in my case, Assembly-CSharp.dll). This won't work on it's own though - you'll need to pull in a few additional DLLs from core Unity to make it work.

After I tracked down those DLLs though, I was able to make a simple command-line application that used those DLLs to process some simple game logic. I’ll have to be diligent in separating my logic code from anything that requires Unity’s “MonoBehavior” components as anything that references any of their event lifecycle hooks like Start() and Update() won’t work. This shouldn’t be a problem for turn-based strategy games, as they shouldn’t be making use of Unity’s game physics or other logical components for any important bits of game state.

In the next installment I’ll show how all of this is going to come together. I may even make a diagram! GET READY

After a period of game-making hibernation, today I found the time to get back into shape. Previously I had teased about a strategy game called MUTANT OVERLORDS. As my design doc hit the 4,500th word for that game, I realized that perhaps it was beyond the scope of my current skills. I’d like to tackle it someday, but it’s prudent to start on something less ambitious.

“Clans” (very much a working title) is a simple asynchronous turn-based strategy game of hidden information. Drawing inspiration from the board game Sekigahara, victory in “Clans” will be achieved by surprising your enemy by your unit composition and choosing the right time to play “tactics” cards that can change the nature of battles:

Armies are composed of stacks of units and used to take key parts of a point-to-point map. On your turn, you’ll queue up movement orders for your armies. When you opponent has done the same, the orders will be resolved simultaneously.

Choosing and ordering the individual units of an army is the key mechanic of “Clans.” While your opponent will see your armies and the number of units in them at all times, they won’t know the composition of your army. Perhaps you’ve filled it with a number of cheap, fast units to give the impression of strength where there is none. Perhaps you have an elite few heavy hitters. Perhaps you have a mix:

Each type of unit will have an ability it grants to its army when it is the topmost “lead” unit in the army. In the above screenshot, a “shield” unit is atop the army which makes it both harder to kill and harder to move.

I have some further ideas on how this mechanic will work to offset the obvious “kitchen sink” army composition strategy that this otherwise lends itself to. I don’t want to say too much more until I have more than a simple mockup though.

The New York Times is reporting this morning that a settlement is close in the class-action lawsuit brought against Google, Apple, Intel, and Adobe for their discriminatory and illegal no-hire, no-solicit agreements amongst one another.

For those who haven’t been watching this case, those four companies (and previously also Intuit, Lucasfilm, Pixar, and eBay, who have since settled for pittances) have been accused by potential employees as having an agreement not to hire employees from the other companies. The proceedings have already led to the discovery of numerous emails documenting the process

I’d be very sorry to see this settled rather than set a precedent. I am fanatic about retaining employee mobility as society transitions further towards employees as disposable, transient resources. With the high-profile companies involved, this was a fantastic opportunity to clearly make this an illegal act for others considering the same.

This isn’t just theoretical either - I was nearly the victim of such an agreement back in 2009. A number of CEOs from bootstrapped Chicago companies and consultancies formed a networking group. The cost to entry was, amongst other things, an agreement not to solicit employees from any of the members of this group. When I reached out to Obtiva to work there in 2009, I was unlucky enough to work for one of the other members of this group.

I may have been rejected outright if it weren’t for the fact I found out about this and had a very lively conversation with my soon-to-be former employer. I was one of the fortunate ones though - I learned this was happening. Usually this unfair labor practice manifests itself in the form rejection letter, the unanswered email, or the strangely reticent recruiter. This isn’t even to mention the other victims like the Google recruiter that Steve Jobs had fired for daring to do his job in the face of these illegal agreements.

I’ll be crossing my fingers that this article is inaccurate, but I suspect not with the number of other companies that have already settled similar claims. It’s a shame - when a case like this settles for such small amounts, the only legal precedent becomes “don’t get caught.”

(On a side note - The New York Times has been fantastic in covering this case - virtually every meaningful update has been on page one of either their National or Business section. If you care about these things too, you might consider throwing them a few nickels)

It pleases me immensely that GATTACA has aged like a fine wine.