Ship placement and movement, now with friends!

It was certainly longer than expected, but I successfully reached the 0.1.7-alpha milestone which officially adds preliminary multiplayer turn based ship placement and movement.

So what does that look like?


Oh there’s also a shiny new space skybox. These are super easy (and fun!) to render yourself using Spacescape. And to think I almost bought a skybox from the asset store.. ha!

Much has been learned about many different things, I shall touch on a few.

First, I want to talk about the game model. Something I completely missed in my original design was the notion of maintaining a server state  independent of the client game state. This became evident really quickly in two ways; trying to run a game client in the same process as the game server and trying to have a network client submit the turn ahead of the game host submitting the turn. Basically in both cases, the preview functionality was impossible to manage properly as any preview would actually impact the server’s state and trying to reset to the round’s start state was much more difficult than it needed to be. This was resolved pretty easily by maintaining a completely separate server game state that is loaded into the game field only when the server actually needs to process a turn. Then the start state, player orders and end state are all pushed out to the connected clients to enable local playback of the turn results. At the moment this means each client is really just processing the turn again locally and maintaining their own local state, which in some weird situations might actually put a client out of sync with the server, but that sounds like a problem for future Chris!

Another issue that bit me pretty early on was the default UNet channel for network communications is a ReliableSequenced channel. This limits message sizes to the MTU of the network layer. This is typically somewhere around 1500 bytes but can vary. This caused problems in my early testing of the new serialization system. As you can imagine, serializing data objects into JSON to fire across the wire can get pretty verbose. A few turns going across the wire and I was hitting an error about large message sizes. Some googling showed a few similar issues which pointed me in the right direction. I simply changed the channel of my connection to be a ReliableFragmented channel and the problem went away! I’m sure it has created me a new problem, but for now that’s good enough. One thing to keep in mind here is that when you’re mucking about with network channels, make sure your client and server are using the same channel configurations. Trust me on this one, you’ll thank me for it later.

Finally I ran in to some interesting problems with the way my movement code was working. I had originally crafted a simple Coroutine to do the dirty work across multiple frames which saved me the hassle of trying to manage state in update methods. However, when trying to get the server process a turn, I discovered that the server was ending the turn immediately upon starting it and firing off the state back to the client without actually having moved anything. Well as it turns out, I was basically processing the turn orders synchronously without waiting for the asynchronous movement to actually finish first! This turned out to be a pretty easy fix. I updated to the latest version of strangeioc which I knew had support for promises. Documentation on strangeioc promises is a little light at the moment so I’ll leave the link to the blog post about it here. Long story short, I was able to add promise support to my turn processor and it now looks like this:

public override void Execute() {
    Server.GameState.CurrentRound.StartState = new RoundState(Server.GameState.CurrentRound.EndState);


private void FinishUp() {

My movement coroutine now looks something like this:

private IPromise moveToPromise = new Promise();

private IEnumerator moveTo(Vector3 target) {
    var arc = new ArcPathSegment(View.transform.forward, View.transform.position, target, View.transform.up);
    float speed = View.Data.Speed;
    float p = 0f;
    float d = 0f;
    while (p < 1.0f) {
        d = speed * Time.deltaTime / arc.Length;
        p += d ;
        View.transform.forward = arc.GetTangent(View.transform.position);
        View.Data.Position.Position = transform.position;
        View.Data.Position.Rotation = transform.rotation.eulerAngles;
       yield return null;
    View.Data.Position.Position = transform.position;
    View.Data.Position.Rotation = transform.rotation.eulerAngles;

In case you missed it, the magic is that call to moveToPromise.Dispatch() after the coroutine ends. This triggers the fulfillment of the promise acquired in the turn processor which then fires the FinishUp method once all asynchronous movement has completed.

I’ll be honest, I’ve had trouble wrapping my head around exactly where to use promises but this seems like a pretty good fit.

That about wraps up this post. I’m not entirely sure what my next goal is but I definitely want to get working on combat sooner rather than later. That would put me very close to an actual game that could actually start to be playtested! That would be pretty cool. :)

Anyhow, until next time..

My turn (part 2)

I’ve learned much since my last post working with Unity’s new networking layer. I’ve stumbled, I’ve fallen, I’ve picked myself back up only to have UNet push me back down again with its comically over-sized shoe.


The fundamental problem I am facing is that Unity’s high level networking api (HLAPI for short) is designed to make a certain breed of game simpler. Those are any sort of real-time game where players are expected to see the same actions on-screen at the same time. This covers a not insignificant number of game types, but does not cover Altair.

Altair is a turn-based game where each player sees their own unique view of the game state and is free to manipulate it as they see fit to plan out their next move. This could mean they test out several orders and revert them before settling on a decision and submitting their turn for processing or they may issue orders to units that they do not control in an attempt to predict the outcome of a particular tactical maneuver.

Players are also given the opportunity to replay the results of the last round as they see fit. They can watch the action unfold from any angle over and over again to try and determine their opponent’s strategy before planning their next move.

Neither of these two requirements work terribly well with a networking model based around automatically updating the state of shared game objects across multiple players.

So my first hope was to free myself of the majority of networking complexities by leveraging the default NetworkManager where possible and dropping down to a lower level messaging API without having to worry about synchronizing game objects. This basically ends up utilizing Unity’s built in PlayerObject concept which makes things a little bit irritating but theoretically workable.

There are two problems that I ran in to with the baked in PlayerObject. The first is actually caused by my choice of underlying framework. I settled on strangeioc a while back as it promised a beautiful nirvana of event-driven and disconnected game code not unlike some enterprise applications I’ve worked with. The short version here is that strangeioc encourages you to structure your application in a certain way and it just doesn’t fit together nicely with the HLAPI in UNet. There is very little information to be found on this topic at the time of this writing but just know that you’re going to have a heck of a time trying to bring these two things together.

Assuming I could live with the hacks I had to do to get UNet and strange working together, the biggest problem is actually with the PlayerObject itself as it enforces a server authoritative model which comes with a bunch of intentional limitations to funnel communications to the server exclusively through the PlayerObject as Command and ClientRpc calls. I have been playing with this idea for over a week and I thought I was getting somewhere until I tried to actually send data to the server.

As I mentioned in my previous post, Unity only lets you serialize a relatively small subset of what I actually need to be able to serialize. The biggest gotcha is the inability to serialize complex classes of any kind. This was a problem and so I turned to using the built in .NET serializers to instead generate a byte array or some other primitive representation to fire across the wire. That’s when I ran in to the next problem:

SerializationException: Type UnityEngine.Vector3 is not marked as Serializable.

So much for that then. Without having those basic Unity types marked as Serializable, I would need to either create some sort of surrogate data types for serialization or write custom serialization methods all over the place. Not terribly appealing.

For my next and final attempt at this, I decided to go to the Unity community and find a serializer that would actually do what I needed it to do. I toyed around with a couple of options including protobuf but ultimately settled on fullserializer which happens to be supported on every target platform that Unity can publish to; how convenient!

I would love to have a happy ending to be able to wrap this post up with but the reality is that I’m still chipping away at turning this in to a working solution.

My current build does have designated GameServer and GameClient objects that both play nicely with strangeioc and I am able to serialize objects into messages and have handlers process them appropriately on both the server and the client.

There is however still a whole lot of housekeeping that needs to be done like linking a network connection to a player representation and plugging it in to the actual game model.

I suppose I needed something to write about next week anyway..