Now several weeks into our pre-title-screen optimization efforts, One would expect a visible improvement to our Life’s a Beach traffic numbers.
Alas, it is not yet the case. Here’s a quick recap–
- Light Blue : This topmost line represents the number of people who visit LifesABeach.io, where the game is played.
- Green : This nearly-topmost line represents the number of people who stick around until the Unity WebGL player launches. This tends to take 3-8 seconds depending on your internet connection and CPU.
- Dark Blue : This bottom-most line represents the number of people who reach the title screen.
This is the single most important graph for this game right now, as no matter how much we invest in gameplay, menus, characters, narrative, etc, nothing matters if players don’t reach the title screen. Getting this dark blue line up is also a pre-requisite for heavy advertising– why advertise when we know 80+% of the users we “buy” won’t make it past the loading screen?
So our weekly recurring struggle is…
- Look at the numbers and perform a rough analysis (confounded by low sample size and natural variance)
- Generate several hypotheses on what could be causing players to churn before the title screen.
- Add analytics to support or weaken each hypothesis.
- Invest in experiments that change the game according to our most-likely hypothesis.
- Wait for next week’s numbers
This is essentially the Iterative Design Process as applied to a web game landing page–
Taken from Jeremy Bond’s fantastic book, Introduction to Game Design, prototyping, and Development
The iterative design process is a high-level approach to optimizing a creative endeavor. In the context of game design, one designs something (“Design”), implements that design via code, paper, etc (“Implementation”), tests that design with players (“Testing”), analyzes the results of those tests (“Analysis”), and then uses this analyzed data to inform more design changes. The process repeats to optimize for something, whether it be engagement, fear (horror game), conversion (mobile F2P game), or something else. In our case, we’re optimizing for “likeliness that someone engages long enough to reach the title screen”.
As depressing as the results of this A/B-lite iteration process has been in the last couple weeks (that stubborn dark blue line!), there have been a few nice bits–
- The game and its initial UX is noticeably improved in several objective ways, from art to landing page functionality to loading times. While these improvements may not reflect clearly in the dark blue line, these are wins that may help us down the line, or on future games that use this technology.
- In order to generate new ideas / hypotheses for iterating and experimenting, I have been forced to step out of my normal introverted ways and reach out to fresh playtesters– often old friends with a game development background– and have had the absolute joy of learning about their lives, successed, and impact. As draining as it can be to socialize, there is a warm satisfaction to knowing my friends are doing well and making change in their local communities, companies, and teams.
And as depressing as the results can be at the end of each week, seeing data and coming up with / implementing hypotheses fills me once more with energy, hope, and anticipation– when I’ve implemented something that is just sure to fix our numbers, tommorrow (and a new batch of data and ideas and changes) can’t come soon enough!
A fresh perspective : “What kind of game is this anyway”?
Give the current iteration of Life’s a Beach a quick play through. You may do so here.
If you’re visiting this devblog for the first time, or playing Life’s a Beach for the first time, you probably spent a good deal of time wondering “what exactly is this game, beyond being beach-y?”.
While the question seems obvious if you’ve been reading these blog posts (or developing the game, or playtesting it for me), it is far from obvious when you first arrive at LifesABeach.io (from a google or facebook ad). The game’s landing page doesn’t even hint at the Tower Defense genre, nor does it show any gameplay until…
- The unity canvas loads (2-6 seconds)
- The game itself finishes loading (15-30 seconds)
- You click past the title screen
- You click past the mode select
- You click through the intro cutscene
- You click through the story dialogue
- You click through the stage select
- You wait through the stage-intro cutscene.
My god– it is far worse on paper than it was in my head! Even if we only care about our pre-title-screen sequence right now, that is still 20-40 seconds of playerd not knowing what you’re in for. It is easy to imagine a player arriving the the web page after seeing (and liking) Sam Olson’s beautiful artwork used in our ads, only to spend 20-40 seconds wondering what on earth this game is. From the quality of the artwork, it isn’t unreasonable to think the game might be a narrative / graphic novel game! A big thanks to Tom Olson for pointing out this possibility during his first, fresh playtest.
Understanding ASAP : A pre-title-screen gameplay preview
Now that we have a hypothesis (“Players churn because they don’t know what kind of game they’re playing for the first 20-40 seconds”), we can make a series of experimental changes to see if any impact is had on our numbers.
For reference, here’s what the pre-loading experience used to look like for players–
The first change was quick-and-sloppy (put together in time to get feedback for a weekly business-gamedev meeting). Can you spot the difference in the gif below?
The only change is the pre-load image (the image that appears behind the circle loading icon).
During the pre-load (when the unity webgl canvas is trying to launch), we now have a darkened screenshot of gameplay behind the loading circle, instead of a piece of concept art. The screenshot chosen isn’t the best (it’s what I had time to take), but it now stands as the earliest-possible look at gameplay, and it’s a look at gameplay that players are likely to notice.
When a player looks at this screenshot, what are they likely to think?
- Will they see the towers and conclude this game is a tower defense?
- Will they see the small heart health bars on the right and assume this is some sort of weird RPG/RTS/dating sim?
- Will they see the HUD elements think this all looks sloppy, and churn right away?
I think it behooves me to use some of our budget and hire someone to take some half-decent gifs of gameplay. We could play these gifs behind the loading icon instead, making it all (hopefully) look more enticing, as this game looks far better in motion than it does in gameplay screenshots.
While this week’s focus will be helping players understand what the game is ASAP, there are some other things to think about for future changes–
- Unity effectively stops executing when a player switches to another tab (thank you for the notice Josh!). This is unfortunate, as it is reasonable to guess that a player could (1) Load up the page and see the loading screen, (2) tab away to watch a video or read an article, (3) come back 10 minutes later to see that the loading bar hasn’t progressed, since unity doesn’t execute when it is in a non-visible tab. I have since “told” unity to keep executing, even when non-focused, but it is limited to 1 frame per second when in a non-visible tab, so it is likely the player will still have this poor experience. It may be possible to optimize the loading process to work at 1fps, but will require more investment. Analytics have been added so that we can gauge how typical it is for a player to tab-away during the loading process.
- While our artwork is attracting a pretty good click-through rate on ads, it may be possible that we are attracting the wrong people. Users who see the artwork and click may not be users who are looking to play a game, or specifically play a tower defense game. Adjusting the keywords and target demographics of google and facebook ads could help deliver users who are more likely to hang around and reach the title screen.