Game Flow: Stats Tracking
While I was developing Re-Spawn (not that I have stopped, but that is beside the point) I started coming across various needs for the game that were not necessarily covered by the game engine itself. Things like master servers, license keys, achievements, and other standard game features; obviously the game engine is there to help you make a game and I wouldn't expect the game engine to provide me with these and so I started working on my own services that would eventually become Game Flow.
Game Flow is a technology stack that provides game developers with functions and features that include but are not limited to the ones listed below:
* Scalable, Robust, and Lightweight Master Server
* Scalable, Robust, and Lightweight Game Update Server
* Scalable, Robust, and Lightweight Achievements and Statistics Server
* Secure Encrypted Communication between the Interconnected Services
* Secure Server License for Official Servers
* Secure Player Profile Storage on Client Machines
* Secure Player Storage and Allocation of Achievements and Statistics
* Web Based Server Control Panel (Game Changer)
* Web Based Game GUI that is Theme-able and Supports Internationalisation (Ditributed UI)
* and many more...
In my previous Game Flow blog (Game Flow: Distributed UI), I talked about the Distributed UI aspect of the system. In this blog I am going to discuss the stats tracking and how this is allowing me to draw metrics on my maps to help with the game play and combat flow.
How did the concept come about?
One of the primary goals for Re-Spawn has always been to make the game a competitive FPS and overlay that with tournaments, achievements, and leaderboards. I don't like using the term e-Sports, but ultimately I want Re-Spawn to be focussed on e-Sports and hopefully when the player base gets strong enough, Gobbo Games (or other sponsors) will be able to host international tournaments.
Obviously I am under no illusions that this game will be an overnight success or will gain the player traction that I hope it will ... but regardless, implementing these features ensures that I am ready if it does happen and allows me to test the Game Flow technology stack more thoroughly.
First came the Leaderboard
The first step in this process was to get the leaderboard working. This didn't prove too difficult and after some tweaking and a minimalistic database design, I had a working leaderboard.
The leaderboard concept is quite simple, use Kill/Death ratios to dictate who is ranked higher. We use two different Kill/Death ratios to decide on the rank of the leaderboard, this are listed below in higher priority:
* Player Kills vs Player Deaths (i.e. you killing other players or being killed by other players)
* Bot Kills vs Bot Deaths (i.e. you killing bots or being killed by bots)
Then we added Stats
So after we had the leaderboard system and it was working, we made some modifications to the database and tweaked the stats tracking system to include more details.
This allowed me to create the stats pages, currently they just give an indication of weapon used and the standard kills versus deaths for both players and bots, but these will eventually be expanded to include favourite weapon, favourite map, favourite victim, and most killed by player, weapon, and map.
The stats system will be expanded on and features will be added as we identify more metrics that players would like to see tracked and displayed.
All this information ... now what?
While I was writing the stats system and going through the data that I wanted to or needed to have tracked, I realised that there was huge potential here to help me with my map design.
I am already tracking when a player or bot gets killed, why not add the position of the kill as well. I then wrote a process to draw this out of the database and plot this on the map, below are some screenshots. Yellow spheres are Player Kills. Red spheres are Bot Kills. Green spheres are Player Suicides.
I will add the images for the Factory map in due course.
So how do the above images actually help me, well by studying the placement of spheres, I can immediately see some trends.
In image 1 above, these is a large concentration of Yellow spheres (Player Kills) and an unusual amount of Green spheres (Player Suicides). This coupled with the information that this is the spawn point for the Ender (Rocket Launcher), I can surmise that players will run to this location and camp it. Players will also typically do long range rocket shots towards the large platform in the middle.
Armed with this information, I need to make it not so advantageous to camp here ... maybe put some obstacles to the line of site down to the centre platform ... or move the spawn entirely.
It is armed with these metrics that I will be able to better balance my maps and hopefully enhance the player experience and game play.
What other metrics?
At the moment I am storing and processing the following stats:
* Hit Locations - Kills and Deaths for Head and Torso
* Maps - Kills, Deaths, KD Ratios for Bots and Players grouped by Map and Player
* Weapons - Kills, Deaths, KD Ratios for Bots and Players grouped by Weapon and Player
As we identify more stats and metrics that need to be tracked, we will add them and then make them available to the players.
How does it work?
Quite simply, when a player or bot is killed, we fire off a message to the stats server with the relevant data. This is stored as a unprocessed base stat.
Every 15 minutes, we have a procedure that processes the first next 100 unprocessed stats and generates the various metrics that we need.
Every 60 minutes, we have a procedure that updates the leaderboard based on any new metrics as may be required.
We are pretty scalable on this process and if we see we are getting excessive load we will move the whole process across to a Message Queuing System like ActiveMQ instead ... but for now we will continue to use once off messages without a queue.
Where to from here?
Re-Spawn was recently released on v1.0.0.5 (Release Notes) and although there have been a few hiccups, the release has gone pretty well. I am not getting the player traction that I was hoping for, but I am forging ahead with our awareness and player attraction plans that we have come up with.
We are listed on Indie DB now and I am closely monitoring the process:
We have done a new website for the game and will be adding more information to it:
http://respawn.gobbogames.co/
The wiki is up and running and we are adding more information to it:
http://respawn.gobbogamessa.com/wiki/
We are now getting the 1.0.0.6 release prepared for release and this will include two new maps and a few extra features to the base game. We are aiming for a 2 to 3 week release cycle per release and are confident that we can hit this milestone effectively.
In the next update, I will talk about the Master Server.
Gobbo Games Marketing:
Website
Facebook
Google+ (WIP)
Twitter
Skype: gobbogamessa
G-Talk: webmaster@gobbogames.co
E-mail: [email]webmaster@gobbogames.co[/email]
Re-Spawn Marketing:
Website
Forums
Blogs
Facebook
Google+
Twitter
Skype: ggrespawn
G-Talk: respawn@gobbogames.co
E-mail: [email]respawn@gobbogames.co[/email]
Game Flow is a technology stack that provides game developers with functions and features that include but are not limited to the ones listed below:
* Scalable, Robust, and Lightweight Master Server
* Scalable, Robust, and Lightweight Game Update Server
* Scalable, Robust, and Lightweight Achievements and Statistics Server
* Secure Encrypted Communication between the Interconnected Services
* Secure Server License for Official Servers
* Secure Player Profile Storage on Client Machines
* Secure Player Storage and Allocation of Achievements and Statistics
* Web Based Server Control Panel (Game Changer)
* Web Based Game GUI that is Theme-able and Supports Internationalisation (Ditributed UI)
* and many more...
In my previous Game Flow blog (Game Flow: Distributed UI), I talked about the Distributed UI aspect of the system. In this blog I am going to discuss the stats tracking and how this is allowing me to draw metrics on my maps to help with the game play and combat flow.
How did the concept come about?
One of the primary goals for Re-Spawn has always been to make the game a competitive FPS and overlay that with tournaments, achievements, and leaderboards. I don't like using the term e-Sports, but ultimately I want Re-Spawn to be focussed on e-Sports and hopefully when the player base gets strong enough, Gobbo Games (or other sponsors) will be able to host international tournaments.
Obviously I am under no illusions that this game will be an overnight success or will gain the player traction that I hope it will ... but regardless, implementing these features ensures that I am ready if it does happen and allows me to test the Game Flow technology stack more thoroughly.
First came the Leaderboard
The first step in this process was to get the leaderboard working. This didn't prove too difficult and after some tweaking and a minimalistic database design, I had a working leaderboard.
The leaderboard concept is quite simple, use Kill/Death ratios to dictate who is ranked higher. We use two different Kill/Death ratios to decide on the rank of the leaderboard, this are listed below in higher priority:
* Player Kills vs Player Deaths (i.e. you killing other players or being killed by other players)
* Bot Kills vs Bot Deaths (i.e. you killing bots or being killed by bots)
Then we added Stats
So after we had the leaderboard system and it was working, we made some modifications to the database and tweaked the stats tracking system to include more details.
This allowed me to create the stats pages, currently they just give an indication of weapon used and the standard kills versus deaths for both players and bots, but these will eventually be expanded to include favourite weapon, favourite map, favourite victim, and most killed by player, weapon, and map.
The stats system will be expanded on and features will be added as we identify more metrics that players would like to see tracked and displayed.
All this information ... now what?
While I was writing the stats system and going through the data that I wanted to or needed to have tracked, I realised that there was huge potential here to help me with my map design.
I am already tracking when a player or bot gets killed, why not add the position of the kill as well. I then wrote a process to draw this out of the database and plot this on the map, below are some screenshots. Yellow spheres are Player Kills. Red spheres are Bot Kills. Green spheres are Player Suicides.
I will add the images for the Factory map in due course.
So how do the above images actually help me, well by studying the placement of spheres, I can immediately see some trends.
In image 1 above, these is a large concentration of Yellow spheres (Player Kills) and an unusual amount of Green spheres (Player Suicides). This coupled with the information that this is the spawn point for the Ender (Rocket Launcher), I can surmise that players will run to this location and camp it. Players will also typically do long range rocket shots towards the large platform in the middle.
Armed with this information, I need to make it not so advantageous to camp here ... maybe put some obstacles to the line of site down to the centre platform ... or move the spawn entirely.
It is armed with these metrics that I will be able to better balance my maps and hopefully enhance the player experience and game play.
What other metrics?
At the moment I am storing and processing the following stats:
* Hit Locations - Kills and Deaths for Head and Torso
* Maps - Kills, Deaths, KD Ratios for Bots and Players grouped by Map and Player
* Weapons - Kills, Deaths, KD Ratios for Bots and Players grouped by Weapon and Player
As we identify more stats and metrics that need to be tracked, we will add them and then make them available to the players.
How does it work?
Quite simply, when a player or bot is killed, we fire off a message to the stats server with the relevant data. This is stored as a unprocessed base stat.
Every 15 minutes, we have a procedure that processes the first next 100 unprocessed stats and generates the various metrics that we need.
Every 60 minutes, we have a procedure that updates the leaderboard based on any new metrics as may be required.
We are pretty scalable on this process and if we see we are getting excessive load we will move the whole process across to a Message Queuing System like ActiveMQ instead ... but for now we will continue to use once off messages without a queue.
Where to from here?
Re-Spawn was recently released on v1.0.0.5 (Release Notes) and although there have been a few hiccups, the release has gone pretty well. I am not getting the player traction that I was hoping for, but I am forging ahead with our awareness and player attraction plans that we have come up with.
We are listed on Indie DB now and I am closely monitoring the process:
We have done a new website for the game and will be adding more information to it:
http://respawn.gobbogames.co/
The wiki is up and running and we are adding more information to it:
http://respawn.gobbogamessa.com/wiki/
We are now getting the 1.0.0.6 release prepared for release and this will include two new maps and a few extra features to the base game. We are aiming for a 2 to 3 week release cycle per release and are confident that we can hit this milestone effectively.
In the next update, I will talk about the Master Server.
Gobbo Games Marketing:
Website
Google+ (WIP)
Skype: gobbogamessa
G-Talk: webmaster@gobbogames.co
E-mail: [email]webmaster@gobbogames.co[/email]
Re-Spawn Marketing:
Website
Forums
Blogs
Google+
Skype: ggrespawn
G-Talk: respawn@gobbogames.co
E-mail: [email]respawn@gobbogames.co[/email]