The leaderboard adds a whole new dimension to your video game. It’s a means of building rivalry between players and deepening their engagement with the game – and with the community built around the game. Leaderboards are a great way of touching a live nerve with your Killers and Achievers, and incentivizing your Socializers and Explorers. But, like most things in gaming, building a leaderboard comes with its own technical challenges.
We sat down with Ronny López, our Backend Technical Lead, to ask him how we deliver leaderboards to Social Point games. Here’s what he told us…
Ronny, tell us about leaderboards. What are they, what do they do?
Leaderboards are an effective way to show a user quickly where they currently stand within a gamified system. Also, it can be a great social connection tool. Generally there are two types of leaderboards: absolute leaderboard and relative leaderboards.
Ronny in Backend action at Social Point HQ!
Absolute leaderboards display the top X number of players. This is great for people who are visible on the leaderboard as it can give them a feeling of achievement and status. However, it can be very de-motivational for those at the bottom or even not on the leaderboard at all. If you’re at the bottom rung, the top spot can look like an unachievable goal. For some, this may be a great challenge, but others will disengage from the game. And that’s something we want to avoid. This is where the relative leaderboard comes in. We use the relative leaderboard to show user positions which are relative to others of a similar rank. So, whilst you may be 9000th out of 10000, you only see the 10 people above and below you on the leaderboard. This way your player doesn’t lose hope and disengage from the game.
So what are the major challenges you face when building a leaderboard?
Size. In a game with several million users, implementing a leaderboard in an effective, scalable and optimal way is a big challenge. We’re constantly looking for ways to implement our leaderboards in an scalable and optimal way. You need to bear in mind that implementation often goes beyond the simple leaderboard with individuals scores. We’ve implemented complex leaderboards, including user friends, weekly and monthly rankings and so on to enhance the gameplay. This is part of the challenge. To date we’ve tried out several, different approaches, and the solution that best fits our needs has been using a Redis database.
Essentially for speed. In a high load environment we can’t afford to talk to other kinds of databases directly. We use Redis to do things that were just too slow or impossible to do with our existing databases. Redis is different to other database solutions in many ways: it uses memory as main storage and can be configured to preserve and also to disk. Another advantage is its unique data structures, which allow us to do some amazing things while still benefitting from being in-memory.
How does it work?
In order to achieve its outstanding performance, Redis works with an in-memory dataset. Depending on the use case, data can be preserved by dumping the dataset to disk every once in a while, or by appending each command to a log.
Those look suspiciously like ping pong rackets. It’s not all work and no play at Social Point.
Redis also supports easy-to-set up master-slave replication, with very fast non-blocking first synchronization, auto-reconnection on net split and so forth.
Have you experienced any major crashes or problems using it?
We started 18 months ago and now we have dozens of Redis servers in production which we use for several distinct functions; from leaderboards to primary data stores. So far we haven’t experienced any major downtime or crashes.
However for other kinds of applications Redis may not be the right database. If you choose it to implement a feature where an in-memory database is not appropriate, you could face unexpected problems. For instance a Redis data set can’t be bigger than available memory. So if you have some “big data” application where the data set can grow in an uncontrolled way, Redis is not the right choice.
What tips or advice would you share with other backend developers?
We didn’t decide to start using Redis and get rid of our other databases. We just added it to our stack and started using it for small features until we started to feel sure about it. I suggest you follow the advice of Salvatore Sanfilippo, the creator of Redis, and start off with Redis simply, adding it to your current software stack, and see how it goes.
Monitor and measure everything: memory usage, clients connections, operations per second, CPU usage … everything!
In the spirit of sharing the love, Ronny has put together this slideshare which covers how we have implemented leaderboards using Redis in more technical detail. Please feel free to download the slideshare. And if you have a question for Ronny and our team, why not leave us a comment?