Beta 0.18.0 released: accounts, frostbite and our rating system

After numerous setbacks and rigorous testing, we finally released Epicinium beta 0.18.0! It features password-protected user accounts, gameplay changes, and RampantRhino, a new AI opponent to play against. RampantRhino is our first AI that utilizes all of the buildings and units (well, nearly - no zeppelins yet). Challenging it should make for some interesting games.


A lot of time was spent to set up the infrastructure for user accounts (MySQL, PHP, Apache, TLS). We feel that having a good accounts system is very important for a multiplayer game. In previous versions, players would pick a username. Behind the scenes, this would generate a "secret" which was used for subsequent logins to the server. It seems easy, but it was a real hassle to use the same username on another installation or machine (you would be informed that the username was already taken, so you'd need to copy the file containing the secret over to the new installation manually).

We've now done this properly: register your account and log in from anywhere using your password. Logging in will generate a session, which is remembered if you enabled "Keep me logged in". As an added bonus, we now have a domain and webpage: Check it out! This also paves the way for us to make things like a leaderboard, so Epicinium ratings will mean more and players can flaunt them. We are working on this for the next update. Go ahead and play some games, you might be on it! We'll talk some more about how the ratings work later in this article.

Gameplay changes: Frostbite

Something we continuously work towards, is making sure the environmental mechanics and weather effects are not just there for their own sake, but that they actively influence the player's decision making. If players cannot respond to an effect in a meaningful way because it occurs regardless of their actions, the effect does not really add any value to the gameplay other than aesthetics. A major design goal going forward is to ensure that the weather effects improve the strategy and fun, instead of the game being fun in spite of them.

As an example, in version 0.18.0 we changed Frostbite to only apply to open fields (grass, dirt, desert, crops etcetera) and to deal damage instead of lowering hitpoints. This forces players to make sure their riflemen seek shelter in nearby cities, forests of trenches, whereas tanks can freely go wherever they please. In response, a player could use this knowledge to predict where the enemy units will go and attempt to occupy or bombard those spaces. We hope these changes create more strategic opportunities and make Frostbite more interesting to interact with overall.


Because our game changes almost every week and our playerbase is still growing, we wanted a rating system that is simple and also quite loose; a player should be able to win just one or two games and immediately see a change in their rating. Also, the rating system must reflect not just whether they won or lost, but also the score the player obtains after every match. The winner of a match is awarded between 0 and 100 points based on how well they did in keeping the map intact, whereas defeated players always get 0 points. As we both studied mathematics before diving into game development, it would be tempting to spend three months coming up with a mathematically ideal system, but we knew that we needed something that was easy to implement and easy to iterate on.

The easiest rating system would be to average the scores of all games played so far. This has an immediate downside: if a player loses the first ten games they play, their rating will forever be dragged down. Even worse, after playing a hundred games each subsequent game could alter their rating by at most 1%, making real progression impossible. 

To resolve this problem, we could take a running average of the last ten games played. This would be sufficiently loose: even if a player had lost a hundred games, winning ten games in a row would skyrocket their rating. However this system could end up stifling players who keep track of their wins and losses. Suppose in the last ten games a player played they received 100, 0, 60, 0, 0, 0, 20, 40, 80 and 0 points respectively, for an average of 30. Winning a game with a score of 60 should increase their rating, but their last-10 average would drop to 26 (note that the corresponding line actually drops in the following image, despite the win).

And there lies the crux: we want a simple rating system that increases when you score higher than your current rating and decreases otherwise. We can achieve this by having an iterated function whose fixed point is your average score. We settled upon: R' = 0.9 * R + 0.1 * S, i.e. your next rating is 90% of your current rating and 10% of the score you obtained at the end of the match. If your current rating is 30 and you score 60 points, your next rating will be 30 - 3 + 6 = 33. This gives the players that want to climb a clear objective during each game: obtain a score that is higher than your current average.

There are still some issues with this system, and we will likely change it in the future once we reach a larger playerbase. For matchmaking purposes, we might switch to a variant of the ELO rating system, but we would first need to come up with a way of incorporating the score. So we might end up quenching our mathematical thirst after all...

Leave a comment

Log in with to leave a comment.