Analytics and Post-Mortem
, Ludum Dare, Post-Mortem, The One Road, Analytics
A long post lies ahead! My game is The One Road, which I wrote in JavaScript for the 48 hour compo.
Analytics
My game is played in the browser so I can just look at web server access logs. No special logging, I’m just looking at which resources were downloaded.
111 unique visitors. This counts anyone who loaded the background for the battle screen. 38% had referers, with 6% of those coming from Facebook and the rest coming from Ludum Dare.
89% of visitors requested at least one audio file. This means that audio is broken for 11% of visitors. That’s huge! I could figure out no rhyme or reason to the visitors without audio: they used different browsers (Chrome, Firefox, Safari, and Internet Explorer) and different operating systems (Windows or OS X).
There are three background music tracks. Each correspond to a different point in the game. For those with audio, 100% played track 1, 40% played track 2, and 29% played track 3. So under 30% of those who play my game got to the end. Is that a big number? Small?
48% of visitors with audio played the “you died” music, so maybe 52% gave up without dying. Well, it is possible they faced an unbeatable battle: the first gremlin. I’ll talk about that later. Actually, three visitors got to the end without playing the “you died” music. Congratulations to the seasoned RPG veterans out there (or cheaters).
Only 54% of visitors with audio ever bought something (sword, potion, etc.) at the town store. I think the store was not obvious enough, or people tried to get too far in the game without visiting the store. You can’t beat the game without going to the store, it’s simply not possible.
Browsers: 65% Chrome or Chromium, 27% Firefox, 5% Safari, 2% MSIE, 2% other. One visitor claimed to be using Safari on Android. Huh. People generally used up to date versions of Chrome and Firefox: there was a Chrome 18 user and a Firefox 14 user, but almost everyone used either Chrome 26 or Firefox 20: those two specific versions account for 80% of all users. All that time I spent testing on Firefox 10 (yes, seriously) was a waste.
Platforms: 57% Windows, 28% OS X, 12% Linux (except Android), 2% iOS, 2% Android. My game shouldn’t work on iOS or Android, but I want to make it work. Again, this only counts users who got to the battle screen. Windows XP was the oldest with 6% of Windows users and OS X 10.6 had 16% of OS X users.
Gameplay
I focused on the core mechanics of turn-based RPGs: start at a town, go through the overworld, and end at the final dungeon. Defeat monsters to gain XP and gold to buy better equipment. This focus worked well, but…
Balancing the game was tough and took too much time. I expected “Impossible” difficulty to be literally impossible, or at least extremely tedious, but it turns out that it just requires a little grinding, a lot of caution, and some luck at the very beginning. “Easy” should be very easy, but if there’s one thing I learned about Ludum Dare game balance, you should err on the side of making your game easier. If you make it too hard, people won’t see most of it.
The major problem with gameplay is that stupid gremlin you fight on the other side of the bridge. The gremlin has a defense rating of 3, so you can’t harm it unless you buy a sword at the shop in town. Worse yet, if you decide to buy chainmail but no sword, the gremlin can’t damage you either. Oops. I suspect a number of people stopped playing here. I should have made the shop more obvious or reduced the gremlin’s defense rating on Easy.
One user complained that potatoes are overpowered in the game. They actually fill a specific need: they cut short any encounter you’ve already faced, so backtracking is less tiresome.
Coding
Two hours in, I switched from C++ and OpenGL to JavaScript and Canvas. That worked out surprisingly well. I did web searches for “how to make a simple HTML5 canvas game”, followed some tutorials, and expanded until I had a game.
I found the core UI in an RPG like this is the menu system. The game used a stack of menus, where hitting escape would pop the top menu off the stack and return to the previous. I didn’t realize how critical it was until I had reimplemented it in four or five places.
The other fundamental piece of code is the tables used to drive the game. There are tables for monsters, encounters, swords, armor, items, spells, and difficulty levels. The rest of the code only has a couple special cases, mostly revolving around the potato.
I also like the battle animation system, which runs a bunch of callback functions in sequence or in parallel to adjust the position of sprites on the screen. For example, one function will generate a tween callback, another function will cycle through sprite frames, and the two of them in parallel make the “sparkle” animation when you drink a potion.
Media
Not much to say: I didn’t want to SFXR everything but recording sound effects was tough. However, the music came out well. I scrapped plans to draw and paint because I suck at that, and ended up pushing pixels in GIMP.
Summary
An extra hour or two might have made worlds of difference for game balance. It’s just too tempting to add features right until the last minute, next time I’ll try to save a little bit of time to play before release. Next time, I’d also like to add a little extra analytics code: I want to know how long people play, how far they get, and what strategies they use.
Looking forward to doing this again in August… or even sooner!