How to build your own programming puzzle

After having solved many programming puzzles, have you ever thought about creating your own puzzle? You’re not sure where to start? Or do you think you’re not up to the task? Here are 5 easy steps that should help you create your own coding puzzle.

1/ Pick a theme

You create a puzzle for other developers to solve it. They solve puzzles for several reasons, one of them being entertainment. Your first job is to entertain the solver. The theme won’t make it all but without a theme you surely won’t have a great puzzle.
Preferably choose a theme you like. It will be easier to create a top-notch puzzle.
Now that you have a theme, you can find an idea of puzzle more easily, or adapt the idea you already had to the theme.
You should also think about the originality of your puzzle/theme. Try to avoid classic topics of programming puzzles (like Ascii Art).

Ex: I’m fond of tennis, the goal of my puzzle will be to compute a tennis score from the chronological list of points.

2/ Write tests

You’ve got the idea of the puzzle: there should be a goal and some rules to achieve it. Make sure to define clear rules.
How will you check that a code has solved your problem? If it passes the tests you’ve created for it.
Simply write all the conditions a solution should respect to be valid and make a test for each one of them*.
If it’s a scaling problem, you’ll have to write tests of simple scenarios and at least one test for a larger scenario, so a brute force solution would fail this test (ie timeout).

Ex: My tests should verify that a solution correctly computes the score of a game and set, handles deuce and tie break...

3/ Write the solution of your puzzle

This part helps you assess the difficulty of your problem. A too hard puzzle might deter some developers from solving it. On the other hand a too easy puzzle won’t be challenging for advanced developers. You can tweak the rules (and obviously modify the corresponding tests and validators) to modify the difficulty.
Even if you know the solution to your puzzle**, it might be a good idea to check on the internet for similar problems. Maybe you’ve missed a trivial solution or forgotten a specific test case.

Ex: I found a StackExchange topic about my problem which makes me realize my puzzle may be too simple. To make it more tricky, I could decide to add incomplete inputs…

4/ Present your puzzle

This could be a boring part but this is highly important. The problem/puzzle might be familiar to you, but developers will just discover it.
A complete statement usually contains: a small story, the description of the problem (goal and rules), the description of the inputs and expected output along with an example. All of it must be very clear and simple to understand, else developers might not even try to solve it. The story shouldn’t be too long. It is used to create a fun atmosphere around the programming puzzle.
Title is also important, make it sexy! However it should not misleading.

Ex: Instead of "tennis scoring system", I could call the puzzle "Game, Set & Match". To be sure the description is clear, I would choose wordings from the related wikipedia article.

5/ Ask friends for review

You could think your job is finished at this step. It is not. You need to have someone review your puzzle. Don’t explain anything about your puzzle, just give to your reviewers the puzzle and ask them to solve it. There will be remarks for sure. Or proposals for better wordings. Maybe you made a typo. Or even a mistake in the test cases.
In any case, the quality of your contribution can just increase after this process.

The tennis puzzle is obviously incomplete but you can still give your opinion on it. If the global feedback is positive, I might even take the time to really create the puzzle :)

If you’ve followed these 5 steps thoroughly, you’re ready to share your puzzle with the world and become famous. This is what happened to SamSi whose puzzle “Heart of the City” got featured as Puzzle of the Week on CodinGame. 

Here is his story:

Careful, if you have not solved his puzzle yet, there are spoilers below

“My college is in a military area, so we have sort of pine trees all over. My friend and I were just roaming around. I was wondering if there existed any sort of pattern as to how many trees are visible if we are surrounded by them and they have equal spacing.

At first I thought that there was a pattern to it, I derived an equation from it and checked it against my bruteforce solution. It failed.

Later on, I realized that this problem is nothing but counting the number of co-prime pairs so I tried to find some related algorithms and I discovered Euler totient theorem.

So I decided to create a puzzle. I did several mistakes but my friend and the CodinGame community (MadKnight, Kyran…) were very helpful and told me what could be improved.

My piece of advice for creating a nice puzzle would be the following: 

  • it should be easy to understand
  • it should be challenging
  • it’s better if it’s related to nature or things people are familiar with”
Thank you SamSi and congratulations for your puzzle!

* On CodinGame, the tests will be visible, so you’ll have to write another set of tests (validators) to prevent hard-coded solutions. These validators need to validate a code the same way tests do.
** On CodinGame, your own solution is a proof that your puzzle is valid, it is now mandatory.

Artificial Intelligence: dive right in and give it a shot

You know that fun is at the heart of the platform. As much as we want players to improve their programming skills, we want them to have fun doing so. We've discussed with Mikkanu from Illinois in the US and he agreed to share his experience on AI programming for fun.

CG: Hi Mikkanu, first tell us a bit about yourself :)

Mikkanu: I've been programming one way or another for more than 20 years. I've started on a Commodore with a BASIC interpreter. Now I work with big data for Amazon AWS. A few years ago I ran a start-up company with a focus on helping less software-oriented companies. 

Programming is for me both a job and a hobby. I enjoy spending my free time on platforms like CodinGame, HackerRank, or answering questions on StackOverflow because it's fun and it helps me flex muscles I don't get to use in my day to day work.

CG: You've tried AI games on CodinGame, how was your experience?

Mikkanu: I've had a great experience on CodinGame - right from the beginning. I think the first game I played was the drone multi-player game and then Tron. And after that it was likely the Terminator single player game. It was not my first time trying AI programming. Before starting my professional career I spent a few years working on games. 
But that was many years ago and since then I recall having tried some platforms such as .NET Terrarium (around 2004) and Fighting Code but those other platforms didn't captivate my attention.

CG: To what extend did playing AI games on CodinGame help you improve your bot programming skills?

Mikkanu: Playing games on CG is not just fun. It's helped me keep my skills sharp working with graphs and trees. Building and traversing graphs is a pretty much required skill to solve most of the CG games. Path finding algorithms like BFS, DFS, A* search or Dijkstra are also very useful. 
I can't say that I've learned new algorithms from other players on CG but I've definitely sharpened my skills and yes, I've benefited from studying strategies of other players on multi-player games. 

As a professional with a family I wish I had more time to dedicate to multi-player games, that's why I particularly enjoyed solo contests.

CG: What kind of tips would you give to beginners in AI who hesitate to try? 

Mikkanu: I've actually encouraged a few of my beginner friends to get in on CodinGame. My advise is to dive right in and give it a shot. I think the practice area is a pretty good way to get started but I also feel that it was better before when one could study other players' code if one got stuck. 

I would recommend submitting code often. That is one mistake that people tend to make, especially with multi-player contests in my opinion. I think the sooner you get your code submitted, the sooner you can find out how you're doing and then try to improve your solution.

CodinGame has had a lot of appeal to me because of the solo contests and because of the built-in online platform to write/debug and submit the code. I think it has a lot of potential.

CG: Thank you for the kind words and for your time Mikkanu!

Community Spotlight #3


CodinGame would not be what it is without its community. The platform is yours, and your passion for it makes it alive and helpful. A lot of CodinGamers are presenting great content around CodinGame and we thought it would be very interesting to put them under the spotlight. 
You can find the previous episode here.

Get on TV with Matheu Plouffe and AutomateAllTheThings

If you're lacking determination to finish a puzzle which is giving you a hard time, I invite you to check Matheu Plouffe stream on Twitch: the3rdHunter. The amount of determination he shows to land on Mars using C# is incredible. Definitely inspirational.

"I am a huge fan of the platform you've developed! I'm currently in the middle of doing an IT degree that has a very strong emphasis on job readiness, and doesn't do nearly enough with algorithms and things like that, so CodinGame gives me a chance to work on those skills in a super fun way"

Thank you Matheu Plouffe!

Link to the Twitter of Matheu Plouffe
Link to the Twitch tv of The3rdHunter
Link to the replay of his last stream

AutomateAllTheThings has been streaming his Clash of Code sessions on Twitch for about a month. He has been playing private clashes with his audience for hours. And even sometimes, here at CodinGame we wanted to be part of it so we joined some clashes... It has been a blast! Really fun!

[CG]VonRickroll reaction on one of our Slack channels (after submitting his solution indeed)
"Totally in love with codingame, #gamification of #coding is wonderful"

Thank you AutomateAllTheThings!

Link to the Twitter of AutomateAllTheThings
Link to the Twitch tv of AutomateAllTheThings
Link to the last session of Clash of Code

Optimize your rank with Royale's and Magus' tools

Ever wanted to know on which game you should focus to quickly improve your multiplayer ranking? This is now possible thanks to Royale who presented his tool on the forum last month. Yes you have most probably heard the name before: he is the one with Magus competing for the top place in the multiplayer ranking.
With your profile handle (the code that you find in the url on your profile page after ""), you can discover the amount of coding points you have for each multiplayer and optimization games and how much you can get.

Thank you Royale!

Link to the forum topic
Link to the tool results with my profile as an example (yes there is room for improvement :p )

Once you're in an arena game, you probably spend a lot of times on the tab "Last Battles" to analyse how your AI behaves. Magus has made your life easier by creating a tool to get statistics on your fights. He shared it last month on the forum.
You just have to input your username, choose the game on which you want to have some statistics. It will give you the win/defeat ratio of your AI against specific players. It can help you to identify bugs or specific flaws in your strategy.

Thank you Magus!

Link to the forum topic
Link to the tool results with my bot in Codebusters as an example (yes I'm not Gold... yet ;) )
Link to the GitHub project

Watch ElanVB Codebusters time-lapse

There are almost no words to describe what ElanVB did, it's just nice. 
So he managed to get in gold league of Codebusters contest, and then decided to start again and do a time-lapse of the process. At the end he reached the 290th place!
It's really interesting to see him comment properly his code, use a separate document to type out his ideas and remarks and finally see him use the CodinGame beta sync app. Enjoy!

"I just wanted to start off with thanks for the great site and competitions. I have gotten a lot of joy out of this community. That said I would like to try give back a bit. I don’t have much to offer but I did take a time lapse of how I programmed and tested my code for the CodeBusters competition."

Thank you ElanVB!

Link to the CodinGame beta sync app

Anyone can be a hero

You too are doing something special around CodinGame and would like to share it with the community? Don't hesitate to share your story with us at!

The best strategies for Codebusters

Codebusters game has come back on the AI page. The game is a bit different from the contest one since two rules will be added in silver and gold leagues, but it will still stay quite the same. We're putting a highlight on the strategies from players which reached the top 10 of the contest leaderboard. For those who didn't have the time to participate in the contest, this is the opportunity to learn more and dive in.

You can find a lot more strategies in this forum topic from which the following was taken.

Romka (5th, C++)

Eventually I ended up 5th despite being 1st first half of the contest. I think the reason is that I didn't pay enough attention to the small details and didn't believe in herding. I spent about 25 hours in total on coding and watching the replays, 10 hours of these 25 were spent during the Saturday, one day before the contest has ended.


I coded my exploration algorithm in the first hour after the contest has started and didn't change it during the whole contest. I consider a grid on the playing area with step = 100. I have a set of "unseen" nodes of this grid which I update every turn. When my buster wants to pick up new target to go to, he selects the closest node from this set, but adding to all distances random number from 0 to 3000. I could not decide what is better: to explore large area with all busters walking alone, or to explore small parts of the map with the group of busters in order to defend against opponent and to catch found ghosts faster, so this random change of the distance could lead to either of these scenarios.


I had two modes: "usual" and "careful". If I see half or more of enemy busters near my base or if there is one ghost left for my victory, I get in mode "careful". In this mode the whole team works as a support for the buster who is carrying the ghost. If my buster who is carrying a ghost finds himself significantly closer to base than its support guys, he waits for them.

Stealing ghosts

I didn't try to steal ghost by sneaking at the opponent base, because I've found it boring. But I did try to intercept enemies going to their base assuming they will use a straight path, so I could not intercept busters of Khao (8th, Javascript) that moved along the walls.


I didn't come to the idea of chain zapping used by Hohol as I am not a Dota player. Still, if I need to choose between stunning enemy busters with stun cooldowns equal to 0 and 5 for example, I will choose the one with cooldown=5, as buster with zero cooldown will use his stun anyway.


I had absolutely no time to code during last Sunday. When I woke up in the morning, I saw matches vs Recar who proved that herding can be done efficiently. I tried to implement something similar, that I ended to code in my friend's car and submitted when we arrived to our picnic location. After a few hours I decided to check how it's doing and found some bugs that I fixed while my friends were playing Frisbee.

Some words about code organization

I had a base class for Entity and two derived classes for Ghost and Buster. All game information such as arrays of busters, ghosts, base locations was stored in a class Game. It could read information about a new turn and update corresponding fields. I also had one class GameAI which possessed tactical information such as a behavior mode, a list of moving targets, a list of enemy busters to intercept and so on. There was one main method named "makeDecisions" that subsequently called methods dedicated to one particular activity. Part of it was as follows:

for (int index : movingToBase)

Each method considered only busters that weren't used in the previous methods (with a few exceptions, like for herding). Last one was the most useful method, of course :)

I didn't use any unit tests as I'm totally fine with controlling code of this small size (1.5k lines of code, including empty lines -- about 50kb in total). I had a bunch of asserts here and there, though. Asserts are a great way to prevent using some methods in the way you didn't suppose to use them earlier. So for those of you who think that unit tests take too much time to write I suggest you to try asserts. Nevertheless, I liked the way Hohol organized his testing, maybe I'll try his recipe in the future.

I can answer any question that you may have about some details of my implementation.

I enjoyed this contest a lot because I like to write team-oriented AI very much. This kind of games always include at least two levels of AI: high-level AI to determine current mode and goals for each unit and low-level AI which makes unit to achieve its goal in some optimal way. I hope similar contests will be conducted in the future.

Hohol (2nd, Java)

This contest was similar to Russian AI Cup 201317 contest, in which I was quite successful as well. They both featured turn-based games on rectangular field, squad of a few units under your control, fog of war and lots of fighting. So it was just my cup of tea.


The first feature is unit-testing. I'm quite proud of it. It allowed me to create some rather complex logic without fear to get lost in bugs.
About a half of my strategy features are mentioned in these tests.
You can notice that all numbers used in tests are quite small, less than 100. How's that possible if distances used in game are much greater? That's because I use separate set of game parameters for unit-tests and for real runs.

public static GameParameters createTestGameParameters() {
GameParameters r = new GameParameters();
r.W = 51;
r.H = 51;
r.FOG_RANGE = 7;
return r;

It allows me to use more convenient numbers in tests, easier calculations, and exact (without any scaling) schemes on checkered paper.

Some may say that writing such tests slows down development. For me, it's the thing that speeds up development. When you implement a feature, you test it anyways. If you don't have tests, you upload a new version and watch replays. Writing test for a feature takes the same time as watching a replay (if you already have reasonably good testing framework). But test will stay with you, and will be run dozens of times later.
So, are unit-tests always such a great idea?
Unit-tests make you sure that your code does what you want it to do. But it can't check if what you want is the good thing. If you have some nice, but risky idea, only real matches can show if this idea is good. But if you are confident in your idea, you can start with unit-test for it right away.
So happened, that this specific contest was full of such obviously good heuristics.

The other case when unit-testing is not so good is when game rules are just too complex. If the world state contains many parameters, it'll be hard to set them up for a test. If game events require some complex calculations (physics simulation, for example), it may be too hard to find the right answer for your test manually.
And again, this specific contest had small game state and simple rules. It was easy to set up tests and simulate game events manually.


My bot relies heavily on fighting. Very much effort was invested to discover and implement useful fighting heuristics. So busters are quite confident in their fighting abilities and rush for a battle whenever possible.
All fights can be divided into 3 groups.
  • Chasing enemy courier. 
To prevent courier from running away on unpredictable trajectory, try to always keep him in sight. 
If some of your allies is going to stun the courier, try to be in right bust range from courier, to be able to bust dropped ghost right away.
If you expect that courier is going to use stun, try to be in bust range again for the same reason.
Take into account the fact that if stunned courier drops the ghost inside his base, ghost is scored to that base.
If you stun the courier and lose vision over him, create imaginary ghost in his expected position.
  • Escorting your courier. 
Courier should avoid getting stunned, if his stun is on cooldown (yeah, sometimes my courier carries his ghost right to enemy base this way, even in final version).
If courier is going to use stun or get stunned, be in bust range from expected dropped ghost position.
Don't escort when I think there's enough escorts already, i.e. when number of escorts >=  number of chasing enemies.
Escort is needed in the following cases:
    • when the enemy is in stun range from courier right now 
    • when there is enemy closer to your base than the courier 
    • when enemy can get in stun range to next courier position on way to base in one move 

  • Fighting for ghost with positive stamina. 
If there is a fight for a ghost anywhere on the map, all my busters charge into the battle. I suppose that there is battle for ghost each time there is both my and enemy busters in it's bust range. To avoid false positives, I ignore ghosts with 40 stamina. But ghosts with 39 stamina are already worth a fight!
If there is more enemies than allies near the ghost, don't bust it. Just stun enemies, bait for their stuns, and wait for assistance.

And few more features not specific to any of fight type:
If your stun is on low cooldown, try to not get stunned. If you got stunned just before ending of your cooldown, it's quite a pity.

Here's the riddle. There are two enemies near you. One has stun ready, and one has stun on cooldown. Who you gonna stun? Codebusters! At first sight, you should stun the one with stun ready since he's more dangerous. But that's a terrible mistake! He will use his stun anyways, because moves are simultaneous. After few moves cooldown of the second one ends and some of your busters get stunned again. You'd better stun the guy with stun on cooldown right now.

The idea of chain-stun was super obvious to me since I'm a Dota player. You'd better overlap your stuns a little, so enemy can't instantly cast some of his spells between your stuns.

Enemy cooldowns

Hmm... Did I mention that you have to know enemy cooldowns to do all of the above?
I detect which enemy stunned me and remember on what move it happened.
To do so, I check all possible things: whether enemy is stunned, carrying a ghost, moving, busting, his previously known cooldown...
I use previous game state to detect who could stun me, and current game state to cut off who could not stun me.
But couldn't these cooldowns just be available in the API? Why should we use such sophisticated logic to have such basic thing? Is it fun at all? Well, it was fun for me for some weird reason, I admit it. But I don't like when game rules are inconsistent with setting. A guy stuns you with proton beam. Which is sparkling and loud. You see it. Your teammates see it. And still, one tick later no one can remember what just happened. You only see that your guy is stunned. And you need to run a whole investigation do detect what exactly happened. It feels wrong.
Though, if you were shot by invisible sniper somewhere in the forest instead, then lack of this information would be reasonable.

Some random features

When you have already collected half of ghosts, focus on the last one - it will secure you the victory. If you see few ghosts, bust only nearest to your base. If you carry ghost to base, everyone should escort the courier.
Use knowledge of total number of ghosts (ghostCnt in input) and map symmetry to detect that you have already seen all possible ghost types on the map. It helps to proceed to busting fat ghosts earlier without excessive exploring.

That's all folks!

Thanks to CG team, it was very fun and high-quality contest.

csj (3rd, Scala)

I finished 3rd place and here is a breakdown of my strategy.


At the start of the game (first 30 turns), scout aggressively -- the targets are hardcoded. Do not engage any ground ghosts until you've reached your scouting assignment. After that, still within the first 30 turns, only engage a ghost that is downfield (i.e. further than our base than you are). Rationale: I'm likely to end up getting easy targets on my half of the map anyway, and early action on the opponent end of the field will cause ghosts to gravitate towards my base naturally. Map position is extremely important for times when the midgame/endgame turns into a race. I have found that I begin most games behind by 1-2 points, but that I make it back up over time as the map advantage is in my favour.


Every turn, a collection of interesting targets is tabulated, consisting of:
  • Visible ghosts on the ground
  • Visible enemies carrying a ghost -- only if any of our busters will be able to intercept him in time, considering their current stunned status and stun cooldown, otherwise ignore that enemy completely -- no sense wasting valuable effort on him!
  • Last observed locations of ghosts (taking care to account for the fact that ghosts may float away)
  • Friendly busters carrying a ghost, if they are not safe (using the same calculation as above, in reverse -- not perfect since we don't know where all enemy busters are, but good enough)


Initially I adopted a very liberal stance regarding weapons: if able to use them, use them. I found that I was losing a lot of shoot-outs with higher ranked AIs, and I decided to be more conservative regarding my use of zaps. Now, I never zap any opponent unless there's a valuable target on the map somewhere: a <10 HP ghost (including one carried by an opponent or a vulnerable friend). In other words, if there are only big ghosts on the field, conserve those zaps; otherwise, weapons free. I've found that I come away victorious in a lot of zap battles simply because I was on stun cooldown less often when it mattered.

Buster behaviour

In general, busters act completely independently. For each buster, the set of available targets is filtered by viability (for example, if a buster can't reach a ground ghost before it burns down and we're the only ones burning it down, don't bother). Then, whichever applies first:
  • If there's an enemy to shoot (and we're weapons free), shoot (only if he hasn't already been shot this turn -- this is the full extent of buster cooperation). Note: a buster will shoot even if currently carrying a ghost.
  • If carrying a ghost, dive-bomb for home in a straight line. I didn't do any avoiding techniques because I had faith in my battling abilities :) UNLESS it's near the end of the game and we won't make it back in time to have a material impact on the rest of the game anyway, in which case hide in a corner and avoid enemies
  • Pick a viable target based on the number of turns needed to burn it down completely: divide distance by speed (turns to get there) and then divide ghost health by number of busters adding myself if not already there (turns to burn the ghost down). Remember that this can include enemy-carried ghosts or friendly-carried ghosts. Select the one with the smallest number of turns and act accordingly (move towards, shoot, escort, etc.). Do not give additional preference for an enemy-carried ghost.
  • If no available targets, go into pre-assigned endgame roles, hardcoded on turn 1: camp enemy base or sweep far sides of the map (targets will likely emerge sooner or later)

By watching countless replays I made minor modifications throughout the contest. I made a few major modifications when I observed some brilliant behaviours from some top AIs.

Chain-zapping (Hohol)

Despite my best efforts, Hohol always seemed to get the best of me during gun battles, and I sought to figure out why. I watched replays frame by frame and observed that in some circumstances, Hohol would zap my buster one turn before I would zap his! I panicked and thought that I was not interpreting the input correctly and that I was misjudging the cooldowns or stun durations by one turn, but it was not so. So what happened? He was actually zapping my guys the turn before they came out of stunned state. This way they would not have a chance to fire upon enemies the turn they woke up. I immediately implemented this idea: when looking for enemies to stun, consider also those who are in Stunned status for 1 more turn.

Herding (Recar)

At 10AM on Sunday (4 hours before the contest ended), I noticed a new leader, Recar, and immediately started studying replays against him. While carrying a ghost (even sometimes when not carrying a ghost!) his guys would gently shepherd ground ghosts towards his base! This struck me as brilliant - while there would be a cost of doing this (ghosts float half as fast), the dividends would show: better map position for the mid/end game and fewer running costs later on (not to mention return safety). I set to work on this immediately and within a few attempts I got it working. This was submitted with around 2 hours remaining.


I learned Scala on the job and have been using it for about 8 months. This is my first contest attempt using Scala and I can confidently say it will not be my last. Scala is such an expressive language that makes it extremely easy to communicate intent -- not once during this contest (at least that I noticed) did I discover a careless error in my code. Errors are extremely difficult to track down in a contest like this -- without a debugger you're reduced to writing a lot of console entries to diagnose the problems, and this takes up a lot of time -- time that could be spent watching replays and studying top opponents. This time I was able to focus my attention where it mattered and it showed on the scoreboard.

A small piece of feedback

The zap cooldown of friendly and enemy busters was not available. This meant it had to be manually tracked for friendly busters -- difficult for newcomers. It would have been very valuable to have this information for enemy busters as well: it could be used to prioritize enemy targets when considering whom to zap. Maybe some of the top AIs tracked this as well somehow? Otherwise an excellent contest, beautiful visuals, superb execution as always and a great pleasure to participate in!

Are you ready for Codebusters AI game now? Don't hesitate to share with us your new strategies!

Codebusters Contest Report


A week ago, you were still working actively on your bot on the Codebusters contest. You had 8 days to code the smartest AI to handle a team of busters and make them explore the map and catpure more ghosts than the enemy team. Let's come back on this crazy week.

The game

There were several parts in the Codebusters game. You had to manage a team of busters: from 2 to 5 starting from your base which was a corner of a rectangular map. Ghosts were spread on the map, but their positions were not known at the beginning of the game, because they were out of sight of the busters. As the enemy team was. This is called a "fog of war" and it changed everything.
So the first thing to do was to make the busters move on the map to explore it and discover ghosts. Once ghosts were found, the busters could "bust" them to capture them. Once captured, a ghost would be carried back to base by a buster with classic movement actions. Once in the base, busters had to release it, to mark definitely one point. These were the simple commands you needed to assign to your busters in Wood 2.


As in Smash The Code, the game was split in several leagues: from Wood 2 to Legend. To be promoted to a league above, one AI had to be better placed than the boss of the league, a predefined AI chosen by us. It does not mean your AI had to beat the boss in a PvP match, but that it had to beat his score after all matches were computed.

Additional Rules

At the beginning of the contest, only three leagues were open: Wood 2, Wood 1 and Bronze.
After players reached Wood 1, they could use the "stun" command. Each buster could stun an opponent for 10 turns. Each buster could use it any number of times but with a 20 turns cool-down. This new rule brought fights in the arena between the teams. Indeed if a buster carrying a ghost was stunned, the ghost would be released.
Bronze league brought "stamina" to the ghosts. It worked as "health points". It just meant that it needed several turns to get captured through the "bust" command. After that, there were no more rule changes, and the other leagues were opened every 2 days.

The results

The strategies

There is a forum topic where some players have already shared their strategy. It is super interesting, so I recommend you to have a look. You can also find the strategies of the winner and the third in the same topic.


This has been handled most of the times by a predefined set of coordinates in the map to check. A lot of players also took advantage of the symmetry of the map (at the beginning only, since ghosts move away from busters) to guess where ghosts could be.


It began clear for players during the contest that a valid strategy was to take care of ghosts with less stamina first. Indeed they take less time to bust so you can score points quicker. I actually happened to add the following strategy in my code <ignore ghosts with more than 25 stamina> which enabled me to gain around 500 places in the ranking and get to gold in a single shot.

Stun fights

An easy strategy was to stun an enemy at range as soon as a buster could use his stun. But it could prevent the same buster to use it at a more important moment later. So be more efficient the AI had to decide which was the best moment to use it. And it was not easy, considering all the different configurations.


The easiest (and most used) strategy was to go back to base in a straight line once you had captured a ghost. It led to the "camping" strategy, that is to wait near the enemy base for busters to come back with ghosts, stun them and steal their ghosts. One strategy used by the best players to counter it was to escort the buster carrying a ghost with one or more busters.

Some key points

Based on the feedback we received on the chat, by mail, on the forum or by the survey, here's a brief idea of the goods and not-so-goods.

What can we improve?

  1. There has been several complaints about performance of the site during Codebusters. And indeed, we had memory leak issues. It has been fixed now. Also we're trying continuously to improve the global performance of the site.
  2. The AI we chose to become the Silver league boss was probably not strong enough, as a lot of players stacked in Gold league at the end of the contest. It's not so easy for us to evaluate which AI should be chosen considering the constant improvement of AIs during the week, but we'll try to be more careful.
  3. The barrier entry at the beginning of the contest was higher than usual. It was not too difficult, but quite a bunch of lines were necessary to start competing.

What went well?

  1. The game was fun. Watching replays was really entertaining. A lot of players loved the graphics.
  2. Some didn't like it, but overall, the different kind of contest, more focused on game logic and less on simulation, pleased a lot of CodinGamers. Don't worry, it doesn't mean we'll prepare exclusively this kind of contest from now on.
  3. You've welcomed well the league system on Smash The Code. It's confirmed now with Codebusters that you like it. And we'll continue to tweak it and improve it!

The replays

After three days in the contest, we decided to launch a replay contest with CodinGame T-Shirts as prizes. Here are the three winner replays:
  1. Wobble dance by Husenap
  2. Emoji time by pcruiher08
  3. Chicken dance by OMGJebz
There is no secret that Husenap's replay has been a true success. Here, on the chat, on Twitter, he received a lot of praises. So he decided to strike again!

Here's another replay he has done to thank everyone who helped him win the T-Shirt: Thank you replay by Husenap.

And he didn't stop there, he took the time to explain what he did for Codebusters in this nice blog article. Also if you want to know how he created the two replays, he explains it in this other article.

Congratulations to him for this amazing content.

Codebusters will be back!

As usual, the contest game will be back in the AI games section soon. We'll add a few rules to the game but it's a secret for now!
Prepare your busters to be ready on next Wednesday!

Your reactions about Codebusters


5 days have passed since the beginning of Codebusters* and players are still joining the competition. If you're hesitating to participate in the contest, these players' reactions could help you take the leap! 
Also if you're interested in knowing what happened during all the contest, you can read Codebusters logbook here.

*For those who don't know the game: it's a multiplayer league contest of AIs where you have to handle a team of busters, make them explore a map and capture more ghosts than the enemy team.

1) What do you like about this contest?

What I love about this contest is the different take most people have had. In the past, we've witnessed a race to get the best genetic algorithms or heuristics of some sort. Codebusters is taking a really interesting different route from that, and a lot of people have had to adapt to a different style of thinking to get some good teamwork with busters!
Thanks for the absolutely awesome contest. It's been my favorite so far and I'm very excited for future ones too. I know a lot of people for who this is the first contest and I'd love to set up a CodingHub in the UK for the next one.

I love the reference to Ghostbuster. The PvP system is quite original, but I have to admit that each time I have difficulties to understand all rules, and debugging my code has not been an easy task.

This is my first contest. I didn't dare trying the others before as there's a lot of AI experts around. I find the contest quite good, because you can go far with just heuristics. However I have the feeling that in this one specifically you have to code a bunch of things before being able to see anything.

I like the contest because I (and probably many other people) don't need to use brute force algorithm as in the previous one (Smash the Code).

This contest is my favorite (and I've participated in most of the previous ones)! I like the fog of war as it adds an exploration strategy to the problem. I also prefer PvP contests.

Like most contests on this site, it gets gradually more difficult, so it's easy to start with something basic and iterate on it.

2) What part of your code/strategy are you proud of and why?

I'm particularly proud of the flow of my code this time. I made some effort to avoid ad-hoc solutions and tried to keep things neat, and went for a command queue design pattern that's let me easily tweak different behaviors of the busters with little impact on the other behaviors.

At the beginning, I was very proud of my strategy of map exploration. Then I saw the "camping" strategy... The latter has actually helped me reach silver.

Well, I'm proud that my strategy works. I think it doesn't have anything special in comparison with other strategies though.

The part which handles exploration: it keeps track of what I saw or guessed. I have the feeling that often my AI has a better strategic vision. I also like the way my busters regroup as a battering ram to force the passage through campers. For once, my code is not too ugly, my methods have less than 10 lines. I've managed to force myself to refactor.

Probably the code to get my busters to wait around the enemy base and stun ones that come back with ghosts so I can try and steal them. Although as I'm getting higher up in the rankings that strategy isn't paying off as much as it once was.

3) What are you planning to do next to improve your code?

Next I'm planning on making my exploration strategy a bit more sophisticated. I think it's time to shake of the rand() and start hunting for those ghosts who've hidden away in corners ;)
I'm also going to be working on different strategies depending on the number of busters available, because I think many people might not expect that.

I have to work on my exploring function to be able to detect more ghosts.

I'm going to fix all the bugs that I did in rush. :)

I really have to improve some tactical decisions, in particular not helping ennemies to bust ghosts I will not be able to capture. And if possible I have to organize my algorithm to take more collective decisions for my busters. Except the stuns, each buster chooses alone what to do. 
Unfortunately I won't be able to devote so much time to this until Sunday, I'm going to be overtaken...

Right now I think the weakest link is my ghost searching/path finding choice, so I'll most likely be focusing on what my busters should be doing if they aren't actively busting or stunning.

4) What language do you use and why?

I use C++, partly because it's what I use the most for my own projects but I also really have never been able to shake off using pointers. I find it handy in contests like this for which OOP works nicely, and I think my command queue wouldn't have worked out as well in many other languages. I've seen some very clever Python & Java CodinGamers around too though!

I use Javascript, because Glorious Javascript Master Race.

Python, I already have some things coded like a state machine. Plus it's kind of a flexible language.

I use C# basically because I know the language pretty well.

Woah, I could talk about this for hours because I love this language. After having personally tried about fifteen languages (including basic, pascal, C, C++, eiffel, camel, php, python, groovy...) and spent about 10 years using Java for work, I've discovered scala by chance.

It's an extremely expressive language. The collection APIs are very rich, it helps me save a lot of time on puzzles and contests. The compiler has a very advanced type system and can detect a lot of issues at compilation time.
Finally it runs on the JVM so you can reuse any library and framework from Java if needed.

On other contests, I've had difficulties compared to C/C++ users for optimizing critical parts (when you have to calculate possible plays on a tree and evaluate positions) but anyway it's not my cup of tea. And for Codebusters, my algorithm doesn't loop on futur so no regret this time!

I'm using PHP on this, I used to use it a lot, but haven't touched it in a few years and wanted to brush the rust off. Thought something like this would be a great way to get back into the swing of things.

5) If you had to give a piece of advice to a new player of Codebusters without much time in front of him/her, what would it be?

Try some of the puzzles first and just get used to writing in a single file. If you can, make use of the CodinGame IDE plugin, it has really helped me keep track of my code this time. Also, debug mode is a lifesaver this time around!

Well I started the contest yesterday, so I'm kind of a new player. I'd advise to check the chat, it's quite easy to find tips there.

Do not rush, otherwise you'll get a buggy strategy. Measure twice and cut once. 

Code very quickly (in a matter of minutes) a first version of an AI and test against the boss to get feedback on what is not working well.
Do a list of improvement ideas and write it on paper. Prioritize approximately to begin with the most easy and promising ones.
Improve your IA in a few minutes and iterate.
On Codebusters specifically: move diagonally, capture the closest ghost, and bring it back to base. This is quite fast to code.
Then: better explore (following borders but not too closely, spreading busters...), capture the ghost with less stamina (bronze league), stun an enemy as soon as it is within range (wood 1 league)...
In the first leagues, I think you have to focus on an efficient map exploration.
Starting bronze, you have to handle campers.

Focus on one thing to code and don't worry about anything fancy. Once you can get your busters to find a ghost and retrieve it, then you should start worrying about doing things in a more efficient manner.

6) If there's something strange in the IDE, who you gonna call?

GHOST-BUSTERS!....or probably [CG]VonRickroll if that doesn't work...




CodeBusters? My memories of the movie are quite blurry...

Bram Moolenaar

Thank you Wando, KingdonHS, Zexion, olsh, tyrcho and gragatrim for taking the time to answer my questions and good luck for the rest of the contest!

Codebusters logbook: daily updates

A multiplayer online contest is a special event.  For more than a week, a lot of things happen and most of the times you have no idea about it. For Codebusters this will change! Here's the logbook of the event, as it happens. We'll update this blog post regularly during the week. Stay tuned!

Saturday 25, 16:37. Stay Calm and Join Codebusters

One hour and a half before the beginning of the contest, it's still calm here. The calm before the storm? Some of us (like me) are experiencing for the first time this special atmosphere of a Saturday afternoon at the office. Everyone is slowly getting excited. Now that we've fixed last typos (and a null pointer exception :p), we are ready to launch the contest and welcome fellow CodinGamers for the CodingHub!
Time to have fun! Beers are cooling in the fridge, some of us are warming up at the table football (hey we cannot lose against CodingHubers), Ray Parker Jr. is about to run in loop in the hi-fi...

And you, how are you getting ready for Codebusters?

We're counting on you to send us photos of you coding, replays of your crazy matches, anything! ;)

Don't hesitate to follow #Codebusters on Facebook and Twitter!

Enjoy the beginning of the contest, and don't hesitate to reach us for any question.

Saturday 25, 23:45. CodingHub: check

Thank you to those who came for the CodingHub in CodinGame offices! We had a lot fun, it was a pleasure to meet you and discuss with you.
I remind everyone of the two next incoming CodingHubs:
- one in Paris on Tuesday, the 28th of June. Contact Manwe to register.
- one in Lyon on Sunday, the 3rd of July. Contact Momopouccino to register.

Sunday 26, 17:12. Story of a misleading leak

As you might have noticed, we've been very careful about how much information of the game we reveal. For Smash the Code, we released a video of a replay which revealed important parts of the game. The problem is that only a few CodinGamers managed to watch the video before the beginning of the contest. Even if just a few of them started coding in advance, it was not right for the others who couldn't see the video.

On Saturday morning, as many CodinGamers couldn't wait for the start of Codebusters, [CG]Maxime took an opportunity in the chat, and without checking with Maxime, [CG]SaiksyApo followed on with the idea:

[CG]SaiksyApo my AI is bugging when my ghost is splitting in two :/ I don't manage to hide in the building :/ . I can't beat you :(
*_* Wrong chan bro
Here's the leak
It's not much, not enough to begin to code anything
how do we edit?

So for those who haven't tried Codebusters, there is no ghost splitting or building in the game. It was just a fun moment to see that some CodinGamers on chat thought we had accidentally leaked information about the game...

Monday 27, 10:23. Replays of the weekend

Ghosts are scary, even for busters!
Emoji time
There is room for improvement
Why would you bother capturing ghosts when you can just steal them?

Monday 27, 16:30. Quick interview of the leader Romka

What do you enjoy about the contest?
I find the contest great because you have to make an AI for the whole team, not just for one player
If you had a piece of advice for other players, what would it be?
You have to improve parts of your overall strategy step by step. For example, improve the way you explore the map, improve the way you select ghosts to bust. You cannot do everything at the same time!

Tuesday 28, 18:33. Replay contest

After seeing a bunch of replays that were shared on the chat, with strategies beautifully executed and also completely failed AIs (come on, it happens to everyone), we realized there was a possibility for a lot of fun with a team of busters and ghosts. We thus decided to launch a contest to find the most funny replays.

It starts now!
I invite you to send me your replays at, I'll then publish them on Twitter and Facebook with the hashtag #CBFunReplay so you can like the ones you prefer. We'll offer CodinGame T-Shirts to the three CodinGamers who shared the replays with most likes (if you share two replays, we take the one with the most likes into account).

Wednesday 29, 10:20. Ranking calculation updates

Since Smash the Code contest, we've decided to work on our ranking process. FredTreg explains what has changed for Codebusters it in this forum topic.

Wednesday 29, 20:30. Amazing dance

We've received our first #CBFunReplay from @husenap, it's just awesome. Check it out and like it!

Well played @husenap

Thursday 30, 10:05. Photo mosaic

We're building a mosaic of photos of all CodinGamers participating in Codebusters. Here's a start:

Send us your photos at photo@codingame, and we will add you to the mosaic!

Thursday 30, 14:43. Review of the leaderboard

Of course these numbers are changing every minute, but here's to give you an idea of the current size of leagues and used languages for Codebusters:

There are 574 CodinGamers in Gold league, in which Romka (C++) is the leader. In Silver league, Mwalimu (Pyton3) is the first of 311 CodinGamers. We can find 363 players in Bronze league with RXN (C++) on top. In Wood 1 league, there are 315 players with AndrewxD (C++) on top. Finally they are 157 to compete in Wood 1, Sunime (C++) being first of the league.
Legend league will be opened tomorrow, be prepared!

Looking at the languages, we have mostly Java users (378) then C++ (355), C# (249), Python3 (233), Javascript (131), Python (80), PHP (70), C (56), Scala (23), Ruby (22), Go (20), Rust (17), Haskell (13), Swift (13), Lua (12), Groovy (8), Dart (6), F# (6), OCaml (6), VB.NET (5), Pascal (4), Perl (4), Bash (3) and finally ObjectiveC (3).

Thursday 30, 17:05. More fun replays

Like the replays you prefer:

Playing with ghosts by Beard
Playing tennis table by Jeff06
Chicken dance by OMGebz

Don't hesitate to send us more replays or share them directly with #CBFunReplay!

Friday 1, 17:46. Players interviews

I've contacted some players and asked them questions about the contest. As it was quite long, I have put it in its own blog post: your reactions about Codebusters.

Saturday 2, 14:20. Winning T-Shirts

This time, the top 50 players will be awarded a CodinGame T-Shirt. For the previous contests, they were given to the top 10 players only.

As usually, you can also win a T-Shirt by ranking first in your programming language. However, we've noticed that some players took advantage of leagues to change their programming language and submit a poor AI once they achieved Legend. This time we'll be checking this kind of behavior!

Finally, it's possible to win a CodinGame T-Shirt by submitting us a fun replay. There are three T-Shirts to win in this fun replay contest. Fun replays have been shared for now on Twitter with hashtag #CBFunReplay. Like the ones you prefer! I'll add them all on Facebook at the end of the contest.

Sunday 3, 12:24. Last day!

Just a few hours before the end of the contest... we hope you had fun. Don't worry the game will come back in the AI section soon.

There are three more fun replays:
One ghost to rule them all by paladinlll
Emoji style by PabloCRuiz
The ghost is mine by Mgayar

Good luck to Momopouccino for his CodingHub in Lyon today. Have fun!

Have all a nice end of contest!