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!

May Progress Update

Edit: Didn’t quite manage to finish everything today, so release will be tomorrow (Friday), or on Monday at the latest.

The game mechanics, API and graphics for CodingGame are starting to look decent, and I am now ramping up for an alpha release on June 11. Until then, I will be tying up various loose ends and complete the following remaining tasks:

  • Replays: I want to add functionality for automatically saving all the commands issued to the game units to a file. These can then be replayed later to perfectly recreate the game. Among other uses, this will be invaluable for bug reports.
  • Community: I want to set up one or more mechanisms to allow for submission of bug reports, discussion of the game mechanics, sharing of replays etc. I am thinking something like a google group, but I’ll have to do some research to see whether there aren’t any better options. If you have any suggestion, let me know.
  • Documentation: There probably should be at least some description of the game mechanics and API.

What happens after the release depends a bit on how many people actually try out the alpha version, but the basic idea is to go through several iterations of receiving feedback and improving the gameplay. In parallel to that, I will be able to start work on setting up a website with tutorials and documentation and implementing multiplayer.

The graphic design for CodingGame

In this post, I will go into some more detail about the graphics in CodingGame.

In my opinion, the main purpose of the graphics is to make it as easy as possible to see what’s going on in the game. I want the graphics to be a one-to-one reflection of the game state. All game objects and their attributes have a graphical representation and all world state transitions are highlighted by an animation. The amount of graphical elements that do not serve a function in the game and convey no useful information is minimized.

At least in principle, this should make it possible to get a feel for the game and even infer all of the game mechanics just from watching the game, making it unnecessary to consult pages and pages of documentation. It should also make the game more fun to watch for people who don’t already have intricate knowledge of the game mechanics.

In accordance with this goal, I am using an abstract/minimalist design where all the game objects are composed from simple geometric shapes. This also allows me to generate all of the graphics programatically, which plays to my strengths and gives a lot of flexibility. In terms of the art style, I am aiming for a sci-fi/space theme that features mostly dark colors with a few very bright elements.

Anyway, I promised screenshots, so let’s get to it!
The game units come in different sizes, their body is simply represented by a regular polygon:


These are then filled with all the modules equipped by the unit.

Here are all current module graphics (all inside a size 1 unit):



Shield generator


Empty storage


Storage with mineral crystal


Storage with energy globes






A larger unit with several modules:


Some additional objects:

Mineral crystals


Laser missiles


A screenshot with a larger scene (very large image, click through for zoom):


In other news, the collision detection and physics for CodingGame is now really solid, and I have made a lot of progress on integrating all the components and implementing the game mechanics and API. I can’t promise anything for sure, but if things keep going smoothly I should be able to release an alpha version in about a month. Before then, I plan to write another blogpost to describe my ideas for the game mechanics in some more detail.

CodingGame – An idea for a real time strategy game for programmers

I am currently working on a real time strategy coding game where players develop an artificial intelligence (AI) and can compete against the AIs written by other programmers. It is intended on one hand for beginner/intermediate level programmers who already know most of the basics and are looking for a fun and engaging way to gain further practice, but also for anyone else who enjoys coding and is interested in gaming or AI. There are a lot of great programming games out there already, but I haven’t found one which quite does everything I want. Specifically, I have the following goals:

  1. Easy to get started with: Writing a simple but fully functioning AI should require only basic programming skills and a few dozen lines of code.
  2. Stimulate creativity: Rather presenting the player with restrictive goals that allow only very specific solutions, there should be many different ways to improve your AI and advance to the next level. It should also be possible to make a lot of progress without the application of deep mathematics or complicated algorithms.
  3. Strategic depth: While I want the game rules to be relatively simple, they should still allow for varied and complex strategies that make the game itself appealing and interesting in the long term.

The game will feature game mechanics similar to RTS games such as StarCraft. The players spawn in a 2D world with some initial amount of resources, which can be used to construct new units. Those units may collect additional resources, fight your opponent or perform some other supporting function. Each unit will be composed of several modules. Each module will equip the unit with some specific attribute or skill. The initial design will include modules for firing projectiles, transporting resources, building new units, boosting unit speed and absorbing enemy projectiles. This will still change as I test out different ideas and get feedback from users. The main goal is to find minimal set of modules that gives a simple API and still allows for many meaningfully different units and rich strategies.

The players will interact with the game by writing a program that uses a high level API. All in game units can be controlled by giving them commands such as moving to a certain position, firing weapons at a target, harvesting a resource etc. The game will execute all the commands and then send messages on all events that occurred during that timestep (i.e. some object enters the sight radius, a unit is hit/dies). My implementation uses Scala, so the API will initially be for Scala/Java only, but I want it to be possible to write wrappers for other languages as well.

The game will include a succession of levels, each of which features an increasingly sophisticated AI as an opponent. I am also planning to have a multiplayer mode, where you can compete against the AIs of any other players. The players will run their AIs locally without modification, but the commands will automatically be sent to a server which maintains the world state and sends events back to the players.

So far I have been working mainly on the game graphics, which are based on OpenGL. That part is already largely finished, and will be presented in my next post. Expect to see a large number of screenshots!