This time, I have 2 post mortem to do: one on creating the game and the second one on playing the game.
On creating the game:
Societe Generale wanted to create a CodinGame challenge to make developers aware of Green IT. The idea was to have a challenge, and then to give the game to the community. When they asked me if I wanted to participate, I couldn’t refuse ^^. There was a game I wanted to add in multiplayer for some time, but I never got the motivation to start coding it. This was a good motivation.
We had 3 months to create the game. So I started by learning java and after one month playing with the SDK, we had a good prototype of a working game. This game was in the usual CodinGame standards, but didn’t meet my company prerequisites: it was too difficult to fit the Green IT theme on this game.
So, we shelved this game (we still hope to release it later) and started again from scratch. We now only had 2 months to code a game, and we didn’t even know which game.
It took us one week to find a game that could fit the theme (a game in which virtuous actions would help the player and bad actions would give him a lot of penalties). It would be the first deckbuilding game on CodinGame and it seemed easy to code (there was only 8 different cards). And to fit with the Green IT theme, we wanted to limit the computing time for one turn to 20ms.
It was in fact much longer and harder to code it. And even harder to test all situations. And we couldn’t even set the time limit so low (the minimum time limit accepted by the SDK is 50ms)
But we managed to release it on time.
Of course, we had a few bugs (I guess we didn’t perform enough tests beforehand), but I believe we were able to fix them quite fast. I hope this didn’t bother you too much and that you enjoyed this game.
If I had to do it again, I would still go for it, but I would follow the following advices.
Advices for the next challenge creators:
Do not wait the last day to write the statements. And make sure to have people who do not know the game at all to read it.
Make sure to have a lot of testers. And to have testers who think differently. This will help you to detect more bugs.
If your game uses random, be sure to use SecureRandom
Be sure to have all the game information visible in the viewer. I forgot about this and I had to fix it during the challenge.
I’m currently upgrading the game for the multiplayer release (adding SecureRandom, fixing the statement for silver/gold/legend leagues, and trying to have a better view of the cards played)
I hope you enjoyed playing this game. I know the random part did not please some of you, but a deckbuilding game is about managing your deck in order to reduce the randomness impact. So we couldn’t remove all the randomness.
On playing the game:
Since I spent so much time fixing the game, monitoring the chat/forum/discord and answering questions, I didn’t have a lot of time to code my bot.
I started by submitting the bot I used to test the wood bosses. This got me in Bronze league.
I had to wait until tuesday to be able to code again. Due to lack of coding time, I decided to go with a simple heuristic.
Here is the algorithm that got me into Gold:
MOVE :
Never move next to the opponent: this will avoid the GIVE phase and youy’ll keep your cards
If I have BONUS cards in hand and no CONTINUOUS_INTEGRATION, I try to get to the CONTINUOUS_INTEGRATION desk.
Otherwise, I move to the next desk that is far enough from the opponent.
GIVE and THROW :
I should have only THROW phases.
If I can release an application, I keep the needed cards on the side.
Then, I throw the cards that are not needed for the release (starting by the BONUS).
If I don’t have anything to throw (in case I put all my cards on the side, I do a RANDOM)
PLAY
If I can release an application, I keep the needed cards on the side and I only play with the other cards in this order:
If I can automate a card, I do it (I prefer to automate the BONUS)
If I have a TRAINING and I have interesting cards to draw, I play it to draw cards
If I have a CODING and I have many interesting cards to play in my hand, I play it to be able to play all my cards
If I have a CODE_REVIEW, I play it to get more BONUS
If I have a REFACTORING and one debt in my hand, I play it to remove the debt
If I have a ARCHITECTURE_STUDY, I play it to draw more cards later.
And that’s all. I do not play any TASK_PRIORITIZATION or DAILY_ROUTINE
RELEASE :
I release the application that will produce the less debt (and I never deliver if I get more than 2 debts)
Once in Gold League, I analyzed the other players games. I tried to use the following pattern:
- DAILY_ROUTINE
- Get 3 CONTINUOUS_INTEGRATION in a row and automate BONUS
- Use TASK_PRIORITIZATION to get the right cards to release applications
But I must have a bug somewhere because it didn’t work as expected
I’ll try to fix it (or to use a small simulation) once the game is back in the multiplayer section