We try to see, how you can use your data on different stages of the game’s life, touching on production, operation, monetisation.
If you’ve ever visited any conference or talk at GDC, you know that game developers actually operate with huge quantities of data. It’s not only the marketing people, but developers themselves. Last year technical artist Martin Thorzen (former CD Projekt Red, now Ubisoft) talked about the optimisation of Witcher 3. The team was able to find all the failed asset placement thanks to a very clever data visualisation solution. Allowing them to see where the problem was on the map. It’s a real eye-opener. Be sure to check out his talk here. In this post we try to see how you can use your data on different stages of the game’s life; touching on production, operation, and monetisation.
As you all know games have tons of assets. Teams of hundreds of people are building titles like Assassin’s Creed: Syndicate, Mirror’s Edge, Dark Souls, Witcher 3. It requires thousands of hours to build a believable game world, and fill it with trees, buildings, NPCs and items. The amount of such content in big (and small) games is constantly growing; which poses a huge challenge for the development teams. It seems that keeping everything in check is becoming virtually impossible. However, there is a solution.
Let’s have this hypothetical situation, based on something Martin Thorzen shared. We have a game world filled with different stuff. There are five types of objects we really care about: Doors, Rocks, Trees, Bushes, and Chickens. We divide the map into sectors, with each area having a certain name: A1-10, B1-10 and so on.
We plug in to our database and make a huge spreadsheet with all the objects of the aforementioned type. What’s left to do is upload this data into a visualisation platform. You could simply use Google Sheets, but we choose to use Slemma. It’s free (well, for game developers it’s going to cost like $29 per month, which isn’t that much) and it looks better. And this way we get this fantastic chart.
Here we can instantly see, how various kinds of objects are represented on the world map. Rocks are obviously dominating. This is a bad thing, since rocks also eat a lot of the performance. But the real killer is the amount of bushes area C6. The bushes were seriously influencing the performance, basically killing the optimisation work we did earlier. F2 region is doing horribly, since the artist used too many chickens there. Fact!
This way we can quickly figure out the problems in the world building, performance, gameplay, even before the testing stage begins.
In online projects, where people are providing their own content, testing can become a daunting task. You can’t actually test all the creations in such games as Minecraft (because of the scope of the game). You can’t test all the dungeons provided by players, if you’re working with a relatively small team, like Lord British and his amazing The Shroud of Avatar Project. So how do you fix it all? Especially if you’re constantly facing problems with players dropping out of the game. Check your data.
Let’s take the number of dungeons of the game (we’ll call them levels here). There are two key metrics we want to have here: time spent on the level and number of death. If the player spends too much time on one level it may mean a lot of things: the level is very long, it’s too complicated, it’s very good place to explore or to farm mobs.
Yet, if the player does spend a lot of time on one level and also keeps dying there, it means that the level is too difficult for an average player (or too easy, if the number of death is below average). Again, thanks to data, developers can easily check it all in a couple of clicks.
This isn’t some voodoo secret knowledge here. Mobile developers have been using these techniques for years, but seems like very few indies invest time in doing this small research. While this may not be an obligatory thing to do, it may give you a unique opportunity to find some hidden problems, ultimately making a better, more fluid game.
This is one of those areas, where data is used most often. Big companies are constantly monitoring their sales, average revenue per user, average check and of course – revenue. Money is hard to get, and having all transactions under control is a great way to assess the general performance of the project.
Plus you can easily check the markets and figure out where the game is really booming. For example, you could have a large presence in China but have very little revenue in this country. This might mean a couple of things. There’s the piracy factor, or you could have forgotten to activate the local payment methods in your interface.
Data is not a thing of legends, it’s not a mystical beast only companies like Sega or Crytek really know how to use. Working with data is basically a way to make a better game. If you can share any other way you can use data to build better projects, please share them in the comments section.