New roadmap after finishing multiplayer

I now have a working implementation for a multiplayer server that allows for running a game across separate machines that can run both the JavaScript and the JVM version (link to demo). It’s too slow to be really usable yet, but all the core algorithms are in place. Multiplayer was the last difficult technical problems that I wanted to tackle, so from now on I intend to focus mostly on improving existing features and getting the word out about CodeCraft. For this post, I have compiled an overview of what I want to do on the technical side of things over the next few weeks. If you have any feedback or suggestions, let me know in the comments or on twitter.

Open source the code: Long overdue, really.

Gameplay: I want to eliminate the “refinery” module, which doesn’t really serve an important purpose and adds unnecessary complexity. I will also change the map, and maybe the mechanics of resource collection, to speed up the game and make it more action packed. I’ll also investigate adding some additional modules that might offer interesting strategic possibilities, like a jump/teleportation module and maybe a second weapon type.

Website: I think it would be good to have some kind of a live demo on the website, similar to Also good would be a carefully compiled video that gives a quick overview of the game, but that will take a more effort to create. In the JavaScript tutorial I want to detect when a task has been solved correctly and give some visual indication, I think this will give valuable feedback and additional motivation to progress through the tutorial. And then there is some other tidying up to do, like integrating the Scala tutorial that currently resides on github and adding a page about the game mechanics.


Ever since I began working on CodeCraft, I wanted to implement a multiplayer mode which would allow players anywhere in the world to pit their AIs against each other. With most other parts of CodeCraft taking shape, I now spent some time working on that aspect of the game. In this post I want to talk about some of the design challenges and outline my plans for multiplayer.

The core problem one needs to solve to implement multiplayer is to devise a protocol that synchronizes the game state across different machines. My initial approach to this was to distribute the initial world state to all clients at the start of the game and then, on each turn, sync the commands executed by each player. All clients can then individually compute the game state resulting from the commands, just as if they were running a single player game. The appealing property of this protocol is that only a small number of commands have to be send across the network. This minimizes bandwidth requirements and gives conceptual simplicity. For these reasons, this is the protocol of choice for most RTS games.

To make this work, the simulation of the game mechanics must be completely deterministic. If at any point there is as much as a difference in the least significant bit of one of the unit positions, the simulations might diverge over time. Until now I had been assuming I could achieve this level of determinism. After some research, I have come to the conclusion that this is actually a hard problem when you target different platforms. The issue is that the IEEE 754 floating point standard allows some freedom in the precision that intermediary results are stored in. It is also necessary to have full control over the values of various flags that affect floating point behaviour. In C/C++ it is possible (with some effort) to produce binaries that will be deterministic across different machines and in Java, the strictfp keyword seems to allow this as well. However, as far as I can tell there is no way to do this in JavaScript (and, by extension, Scala.js). So that would make multiplayer (or even just viewing replays) impossible in the JavaScript version. This is not a limitation that I want to impose, which is why I have been thinking about alternative ways to implement multiplayer.

(If you want to find out more about floating point determinism, these are some sources I have found particularly useful: What Every Computer Scientist Should Know About Floating-Point Random ASCII on floating-point determinismFloating-point determinism in JavaScript)

Option 1

Why go through all the effort of synchronizing state between machines at all? In JavaScript you could just download someone’s source code and run it locally on your machines. Of course this means only one person can actually view the match, it only works for JavaScript, and there are some security concerns. On the other hand, the players don’t need to be online at the same time and it is actually fairly easy to implement. I expect to roll out this feature as early as next week.

Option 2

Instead of transferring commands, sync the entire world state after every simulation step. For most RTS games, this would be infeasible due to bandwidth constraints. Fortunately, CodeCraft operates under slightly different conditions: First, the number of objects in CodeCraft is reasonably small. Second, there is no need to let the AI logic run on every simulation step. I suspect even something on the order of 2 times per second would still be quite acceptable. The clients can still simulate the ticks in between to keep the graphics running smoothly, but now divergence won’t matter since everything gets synced before any new commands are run. If it was a human playing the game, the resulting lag would be annoying, but your AI won’t care.

Implementing this will be a bit more difficult than my initial plan, since I now need to identify and sync a lot of different sources of state rather than rely on a small and well defined set of commands. So it will take longer than I had hoped, but I will still get there eventually.

CodeCraft.js demo

There is now a working Javascript/WebGL version of CodeCraft, go check it out:

Getting this to work was surprisingly easy, mad props to everyone behind Scala.js for creating such an awesome piece of technology.

I will now be adding a Javascript API and an in-browser editor and command line and use that to create an interactive tutorial. So there is still some work to be done, but I expect to have most of this up and running by early August.

Some thoughts post-launch

More than a hundred people clicked through to the CodeCraft tutorial over the last few days, which is a nice start. I don’t have any other statistics though, so I have very little visibility into how many of those are actually using CodeCraft, or don’t know/like Scala/Java, or think the idea or implementation suck, or don’t have the time/patience to perform all of the setup and go thought the tutorial. If you have any thoughts on CodeCraft, do share them, it really helps me figure what I need to be working on!

Looking forward, I think at this stage there is not much point to improve the actual game. My main focus will now shift to growing the user base and gaining more insight into what people are looking for. I have two main projects to that effect: The first is to set up an actual website which can serve as a platform to promote CodeCraft and gather some statistics. The second one is to use Scala.js to create an interactive Javascript version of the game that runs right in your browser. This will eliminate the need to perform any setup and make CodeCraft accessible to a much larger audience. As always, I will keep you informed of any progress.

CodeCraft alpha launch

Today, I am releasing the alpha version of the real-time strategy programming game CodeCraft. (previously called CodingGame, but I want to avoid confusion with This is the first public release, so there will be various bugs, rough edges and missing features, but all the core functionality is there now. There will be regular releases from now on to incorporate your feedback.

I put up a tutorial and overview of the API on github, so if you want to give it a try go on and head over there. Currently, CodeCraft can be used with both Scala and Java. Happy coding!