3
\$\begingroup\$

I am designing a level-based game where the user completes the level 1, then 2, 3 and so on. There are 200 levels and each is rather short: 60-ish seconds.

I am tracking

  • Each played, completed (cleared for the first time), failed and cleared level
  • Milestones: number of players to reach level 1, 5, 10, etc. Also for number of failed and played levels.
  • Separate new players from returning ones.

However, I still find it difficult to get a clear picture of what is going on from the stats. So what are the best practices for determining where I am losing players?

\$\endgroup\$

2 Answers 2

3
\$\begingroup\$

you are asking probably one of the hardest questions - you will find that a lot of data being collected, by a lot of companies, is not used because no one knows how to undersand it. its a full time job that few small studios / startups can invest in (althought they should, lol!)

I suggest, you start by collecing very little data at the begining - pick a few points that YOU think are important in the game. look at the data DAILY or in general regularly and look for patterns. Add more datapoints as you realize you want more insight into some part.

example - start by collecting - did player complete a level or not. look for patters - where are most ppl dropping off. then start breaking the leveldown further

Collecting too much data is the first step to being discouraged and not using any of it :)

Also, i suggest A/B testing. If you think some change you will make a difference, never, ever make the change for all players and try to read the data. Always change the game for 1/2 of the player (A group) and the other half continues to play as before (b group).

then compare the groups

good luck!

\$\endgroup\$
1
  • \$\begingroup\$ A/B testing may be hard to set up in real life. \$\endgroup\$ Oct 27, 2012 at 14:37
0
\$\begingroup\$

You say that you separate new players from returning ones. It may be possible on some platforms, but usually not because of privacy issues. And so cookies may be cleared, IP changed, Flash Shared Object flushed together with browser's history etc. In the end some of players that are supposed to be 'new' will really be old, returning players with changed identity, making some of your stats misleading.

I suggest that you track not places that players get to, but where they quit the game - generate random unique ID at start of the game, and save in stats new lastPosition for this ID every time the player gets to some checkpoint. Additionally, if you get some event like onExit or onUnload, you could use it to log soft quits. In the end you would have data of either

  • User quits "soft" way exactly at point X
  • User quits in hard way (disconnect/hard reboot/bug) between checkpoints A and B

You could also ask players for opinions on soft quits, or upload your game to a service with comments like Kongregate.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .