Week 2: Analytics!

A simple pixel-art sunrise.
I made this simple sunrise while playing with the idea of showing a mountain-summit scene in Inner-Tube Climber.


tl;dr: I added some basic analytics, I gave up on implementing a leaderboard, and I thought through my project-management process a bit more.


What happened last week?

Goodbye leaderboard

I started out last week thinking that I'd be implementing a leaderboard. I made a rough proof-of-concept, and designed all the details for a finished product. But I ultimately abandoned my leaderboard dreams once it became clear that there is no good way for me to implement it with the current state of Godot or without it taking me a month to do. If for some reason you're really curious about leaderboards, I wrote a whole extra post on my experiences with that.

Hello analytics

*In a creepy voice* "I'm watching you..."

At the end of the week, I instead implemented some basic data-tracking and analytics.

I'm using Google Analytics for this, since it's free and provides an API through which I can later use to write custom queries to make charts and dashboards. Specifically, I'm using Google's Measurement Protocol to record data, and Google's Reporting API to query data.

Normal developers just use one of Google's convenient client libraries for recording Analytics events from their website or app. But, once again, there is no such library for Godot, so I've re-invented the wheel for this and implemented a library written in GDScript. Fortunately, it's a straightforward API to work with, so I'm relatively confident that what I've created doesn't have any huge bugs.

This should give me some valuable insights into how players use my game. I'm excited to see the data when it comes in!

Aren't analytics creepy? What about my privacy?!

Analytics are usually critical for developers to understand what's working and what isn't in their app—i.e, if you want an app to provide a good user experience, it needs to collect analytics.

I've tried to make sure that I'm not tracking any sort of sensitive information that should be kept private. But I think I'm not legally allowed to describe my data collection as "anonymous" or involving "no personally-identifiable information" (PII). In particular, I think GDPR considers Google Analytics data to be PII.

So, just to be on the safe side, I'm planning to show a privacy agreement screen the first time the player opens the app, telling them that by using the app, they consent to this data collection. And I'll provide links to privacy policy and terms of service documents.

Also, I'm planning to record app runtime logs if the app ever crashes, so I'll need to let the user know about that.

Project-management thoughts

I've been spending a fair amount of time trying to figure out my systems for time management, organizing ideas, prioritizing tasks, and in general making sure that I make the most of my sabbatical!

My goal for this sabbatical is to improve my game-development and art-creation skills. I'm mostly planning to accomplish that by doing lots of little projects, rather than any large-scale projects. But I also need to make sure that each of these projects gives me enough practice with the particular skills that I need to develop.

Back in October, I had imagined Inner-Tube Climber eventually including some levels that showed the climber leaving the crevasse and scaling a mountain side until they reached the summit. I figured this would enable some more challenging levels without the constant walls on either side (which are a bit like bumpers in a bowling alley). Maybe I could then even create a in-the-clouds type of level. And maybe that could transition through a big cloud bank, until the player re-appeared at the bottom of the crevasse to start the climb all over again and let the level loop infinitely. This would require implementing a lot of new art and level-configuration logic.

However, these extra level types are unnecessary and not worth the time! The gameplay can be the same without them, and they make the theme of the game somewhat confusing. I do need a lot more practice creating level art, but I can get that same practice by instead starting on another game.

Fortunately, "project manager Jackie" (aka, my partner) was on hand to tell me that I'm doing the wrong thing! It can be really hard to realize that something isn't a priority and cut scope, especially after you've already made plans around it... I took some convincing, but Jackie's totally right. Of course. Keep it simple—let’s cut scope and just ship it with the one style of level!

I did spend a little time on Thursday thinking about alternate art for these other potential level styles, and came up with the following simple mocks. (But also, I think I ought to include some new art each week in these blog posts!)


A repeating tile texture for an ice wall look.
A repeating tile texture for an ice wall look.


A mockup of what that ice-wall tile would look like in a level.
A mockup of what that ice-wall tile would look like in a level.


A simple pixel-art cloud image.
A happy little cloud. I think Bob Ross would be proud.


What's next?

My goal is to be done with Inner-Tube Climber by the end of the month! I'm going to participate in Global Game Jam with some friends, and I want to start something new after that.

For this week, here's what's next on my list:

  • Implement initial screen describing data collection and privacy policy.
  • Implement some simple score recording in local app state, so that I can start getting base lines for how difficult levels are.
  • I can then use this to give some indication to the player about how well they did on a level.
  • I think I might give some sort of simple bronze, silver, gold rating indicators.
  • Create a screen asking the player to rate the app, and show this after beating the third level.
  • Create a new level-select screen that shows past scores for each level, and whether each level has been unlocked yet.
  • Create a game over screen.


🎉 Cheers!

This is a simple icon representing my sabbatical.

Comments

  1. Great update Levi! I'm always looking for a link back to the game every time I finish reading a blog post. Please add one, unless this is next-level growth hacking to make me bookmark the URL.

    ReplyDelete
    Replies
    1. https://ldjam.com/events/ludum-dare/47/stuck-in-an-inner-tube

      Ahh, good point! But the mobile app I'm currently working on isn't released yet. The much simpler web version from Ludum Dare isn't all that representative of the current stuff I'm talking about any more, so it doesn't seem as relevant to link to from the last couple posts. But here it is!

      Delete
  2. It's a shame you have to roll your own utilities. Any plans to release it as a library that other folk can use? Do most games not use analytics or is everyone just creating their own all the time?

    ReplyDelete
    Replies
    1. :/ Yeah, definitely. I think this is really the main problem with using Godot. It's often missing important support for production-quality features.

      I think most folks using Godot up-till-now have either been not as serious, or have been rolling a lot of their own solutions for missing features.

      I think there's three basic reasons: it's open source, it probably has a smaller dev team, and it's probably newer than its competitors.

      - Because it's open-source, there's just a lot of stuff that the engine can't provide, because of licensing reasons.
      - Because it's newer, and has a smaller market share, third-parties don't write libraries for Godot clients.

      But I think the future is brighter! I think the best practice going forward will be to use Godot's plugin system to wrap native libraries that already exist for stuff like third-party analytics, rather than adding new libraries in GDScript.

      A while back they added much better support for Android plugins, but they haven't added the equivalent support for iOS yet. But it's apparently coming in Godot's next release!

      Godot has always supported creating custom "modules" that extend the actual engine. But that requires downloading the sourcecode and rebuilding your own custom version of the engine, in addition to having the know-how to actually use the relevant C++ APIs for creating your module.

      tl;dr: Until we get the new iOS plugin support, using native mobile libraries is usually more work than recreating your own GDScript version of those libraries.

      Delete
  3. It's a shame you have to roll your own utilities. Any plans to release it as a library that other folk can use? Do most games not use analytics or is everyone just creating their own all the time?

    ReplyDelete

Post a Comment