Working title: Double Double One

Author: Florian Graf | Published: 2019-07-20

Green Motherboard by Pixabay on Pexels CC0

The work on my game has been slowly going along, but so far I haven’t talked about it at all. And if I want to publish updates about the development of my game, I first will have to tell you where I’m at. This posts is about the state of the game development. From the title you can also get the current name of the game: Double Double One. I’ll also provide an explanation for this name.


Double Double One is a turn-based strategy game with a major focus on resource management. Every player has to conquer, produce and manage resources. The conquest part of the game will be mostly automated and only very simple orders can be given.

It is turn based to give every player enough time to think about their resource management. The game thus will not be about who was first or the fastest but who made the right and best decisions. To reduce the waiting time a turn is played in parallel. More on this in a later chapter.

The resources to manage will be computer resources. Thus the resources will be the amount of processing, memory, storage, bandwidth, etc. Also possible resources might be energy, cooling or simplified construction material. The setting of the game is a computer network. The player is a rogue artificial intelligence that has to take over the network and competes against other artificial intelligences. Since the player is a computer program himself, they will have to allocate resources for every action they want to execute as well.

The working title is a simplification of the address for localhost in IPv6. The localhost address in IPv6 is ::1. Perhaps that is how an artificial intelligence would refer to itself.


The graphics at the moment should be understood as debugging help. They currently only have a very limited association with what should be in the end product. The plan is to improve them over time via an iterative process. But at the moment they just don’t have a high priority in the overall development.

The end goal is to have low poly 3D graphics. The theme probably will be rather dark but brightened up by the simplicity or even by a comic style. But the game is currently nowhere near that concept.

Just keep in mind that whenever you see any graphics of the game, it is by far not the end result.


The play field is a hexagon grid map. The basic data structures have been implemented for this. The implementation allows for dynamic maps, they can grow at runtime and also have gaps.

Path finding and other crucial algorithms have been implemented for the map. A great resource for the implementation of such algorithms can be found at the blog of Red Blob Games. Another helpful tool for hexagonal grids can be found at Gridzzly. It lets you create different type of grid paper including hexagon grid paper. You then can print it and use it for prototyping or just visualize ideas on paper.

Every cell can be owned by a player. The cell themselves have health points that can be built up through defenses or lowered through attacks. If the health is low enough the cell can be taken over by another player.

It is also possible to build buildings on the cell. The buildings can create resources that will be mentioned in a later chapter. Buildings are destroyed when the cell is changing owner. In the future I plan to have possibilities to take over buildings as well with special types of attack.

Three types of buildings are currently in the game. The operation core from where you issue your actions on the map. This building has to be defended or you’ll loose. At the moment only one core is available but the game has been implemented in a way to allow multiple cores per player. The processor buildings produces the resource processing. More on that resource later. The last building currently available is a general attack and defense building. This building will later be split up in more specific ones and is currently mostly used as a proof of concept. It will probably be removed in later revisions of the game.


Multiplayer support has been implemented. The entire game architecture is built in a way that singleplayer is just a special case of multiplayer. At the moment dedicated servers are not possible. The server is running on the machine of the player hosting the game.

To support multiplayer several libraries have been reviewed. The initial plan was to go with the native Unity Multiplayer (UNet). While learning about UNet it was announced by Unity that this library will be deprecated and replaced in the future. Also several people pointed out that UNet is very buggy and unreliable.

There are several other networking libraries for Unity from third party vendors. The major problem with them are their prices that are obviously not made for smaller studios. Also a lot of them provide the servers and have a software as a service (SaaS) concept. Meaning that the players don’t have control over the server. This becomes especially a problem in the future, in case the development or future support of this game would stop. Using a software as a service multiplayer solution would made it impossible to use the game from this point. I personally don’t like this and don’t want this for my future customers.

There are also a few open-source libraries with at time questionable quality and/or implementation details. Also they seem to come and go and long-term support is at best questionable.

To be as free as possible, the decision was made, to introduce a simple abstraction layer that could be used to switch between different multiplayer solutions. Since this is a turn-based strategy game the multiplayer code isn’t so complicated in comparison to a real-time game. A simple solution can already go a long way.


The library Pulsar is a small abstraction library developed to give the freedom to use whatever network connection library necessary or wanted. The name Pulsar was chosen from the communication link in Star Trek Voyager where Earth used a pulsar to create a communication link between the Voyager and Earth.

The Pulsar library is setup very simplistic. It’s main functionality is based around two interfaces: NetworkTransport and NetworkListener. Every possible communication has just to provide implementations for those two interfaces. The library itself is asynchronous and uses the Task based programming of DotNet.

The interface NetworkListener is there to listen for incoming connections and create NetworkTransport objects for those connections. The basic interface looks like this:

public interface NetworkListener
  NetworkListenerOptions Options { get; set; }
  void Startup();
  void Shutdown();
  Task<NetworkTransport> WaitForTransportAsync();

The interface NetworkTransport is there to send and receive blobs of data asynchronously. It also provides the possibility to connect and disconnect the communication.

public interface NetworkTransport
  NetworkTransportOptions Options { get; set; }

  Task<int> ReadDataIntoAsync(MemoryStream buffer);

  Task SendDataAsync(MemoryStream buffer);

  Task ConnectAsync(TimeSpan timeout);

  void Disconnect();

If you have knowledge on how a TCP connection is established, you can easily see that this maps nearly one-to-one to it. The NetworkListener interface can easily be implemented with the DotNet TcpListener class and the NetworkTransport interface can be implemented with the DotNet TcpClient. But this abstractions allows other network connections as well. It could be implemented with UDP, WebSockets, SOCKS, etc.

Next to the implementation via TCP a second implementation is already in use. An InternalNetworkListener and InternalNetworkTransport has been created that provide in-process communications. An InternalNetworkTransport just has an inbox and is connected to another InternalNetworkTransport. When sending data it is just sent to the other InternalNetworkTransport inbox. The data from the inbox is retrieved when receiving. This gives the possibility to have a fast connection for locally connected players like a computer enemy or for the player playing on the same machine as the server. But they still go through the same network interface as externally connected players. This simplifies the overall design of the code.

In addition Pulsar provides a very basic serialization capability. It allows registering serialization contracts for types. Thus allowing the conversion of C# objects into blobs and blobs back into C# objects. The process is parallelized and memory optimized via the Task programming of DotNet.


Resources are available via producers and consumed by consumers. Consumers and producers are at the moment buildings but there are plans for resource production by cells on the map as well. Producers are connected to consumers. The consumers then request resources to perform an action with.

A producer can be attached to multiple consumers. Currently the implementation is a first come first serve. A more complex system is planned to be implemented. Fine-tuning this relationship and thus resource distribution will be a central part of the game.

The connection will be made visible on the map and initial work on that has started. Currently this is visualized as small flying packets (cubes). At the moment they can’t be well distinguished on what they represent exactly. This will be worked on in the future. Actually quite a lot might still change in this regard.

The further away a producer is located the less efficient can it deliver its resources to the consumer. This is currently implemented and named latency. It is a constraint for larger networks and creates the need for additional management of the resources.

At the moment only two resources are in the game. Processing is the first and major resources. It is processing time that is needed by every building to perform any action. Processing is made available via processor buildings.

The second resource is action points. Action points is the resource that the player needs to perform any kind of action. Actions are always executed from the core of the network. Thus more action points are needed to perform actions further away since there is latency costs. Reducing the production of action costs means the player has more resources available for his conquest but also means he can make less decisions. If a conquest is set and planned this can be useful. Increasing the production of action points can give more flexibility and the possibility to change on-going projects.

There are a lot of additional resources planned. To mention some:

  • Memory
  • Storage
  • Write/Read speeds
  • Energy/Electricity
  • Cooling
  • Building materials


As already mentioned the game is turn-based. A common problem of turn based strategy games is the rather long waiting time until a player can play again. To minimize this problem a turn is split into two phases. The first phase is called the planing phase and that is where the player is actually playing the game and giving his inputs. In this phase the player plans the next actions and tells the game this. He allocates his resources and plans the future buildings and expansions. This is done in parallel by all players and is possible since there are no conflicting changes on the map between the players.

The second phase is automated and applies and executes the planned actions of the players. Since this entire phase happens automatically it can run much faster and give back the controls to the players as quickly as possible. Thus reducing the waiting time for each player.

This takes also focus away from micromanaging small aspects and gives much more focus on the bigger strategy and planing of the game. The focus of the game is about planning and managing the resources. Everyone should be able to take their time to plan and execute their strategies. Since the planning is happening in parallel there should be less pressure by the peers in a multiplayer game to finish your turn so the next player can play.

Currently the game supports multiple players per client. Since no split screen is implemented at the moment, those players will still play one after another. But this scenario is not very common and can easily be resolved with split screens in the future.


This blog entry is already again behind the current development. But I wanted to finally get it out to start to write on smaller entries about changes introduced into the game. There are still many features missing and a lot of work is left to be done. Stay tuned for further updates. I’ll soon publish new possibilities to follow along the development and get notified about updates.