Scope Creep Studios

We removed ads and made it a dollar instead. Go get it!

‎You Can’t Win on the App Store

The TL;DR is that ads bum us out and were ineffective at generating revenue. We made a grand total of $9.34 from ads and $4.95 from people paying to not see ads. Rather than chasing ad views we’d like to let you play the game without distraction. After all, it’s impossible to win the game but we still think you’re a good person.

The longer version

You Can’t Win But You’re Still A Good Person was designed to be played in short bursts here and there. Ads ended up just not being a good fit for that kind of game. We made $9.34 from showing (as near as I can tell) around 2000 video ads over two years. Five people opted to pay to remove ads at $.99. (I think two of them might have been us.) Our thinking was that if we made the game free and offered that remove ads in-app purchase that more people would go for it.

Extremely narrator voice: they didn't.

I don't blame anyone for putting up with them either! Ads are easy to ignore and comparatively in-app purchases are hard to make.

We could have leaned harder on psychological levers to claw people into coming back to the game to maximize the number of ads they see...but, honestly? We’d rather make a solid experience and let you just play the thing.

The lesson in all of this is that you should have your monetization model decided before you begin coding. We waffled on that and it hurt the game experience. I’m sorry for that although while removing them I remembered that the game is a fun app to fire up and play now and then!

Long term

The fun side of game dev: took some time with the team to get Shedwarf into a proper version control system. If you’re curious--and who wouldn’t be when talking about such a fun thing as version control--we’ll be using git and bitbucket. 

Unity plays decently well with that setup, but a gitignore is a must. Stackoverflow, as always, has a great quickstart guide:

I always look forward to the moment when it’s time to add sound to our games. Accompanied with music and sound design, even simple prototypes can suddenly become immersive, and the road to a finished product no longer seems so long.

Early on in the development of our latest iOS game, You Can’t Win But You Are A Good Person (referred henceforth by its nickname and hashtag, YouAreGood), I knew sound and music had to play a larger role than usual. What I didn’t realize initially is that they would influence the design of the game in subtle but important ways.

From simple beginnings

The concept was fairly basic: the screen is divided into four tiles. Each tile changes at different rates from black to white. Tapping a square resets it to black. If a square reaches 100% white, it’s game over.

To complement this mechanical simplicity, we decided to go with a minimal graphical style. Besides aesthetics, this choice had the benefit of limiting the scope of the project. With team members grappling with new jobs, new babies, and new cities, we needed to make the game as simple as possible if we wanted a chance of completing it.

The minimal graphical approach seemed to fit with the gameplay, and we hoped it would come across as a stylistic decision rather than an excuse to do less work (I’m of the mind that both things can be true at once). That said, the problem with a game that features four black and white tiles and nothing else is that it isn’t incredibly immersive. The basic mechanics were fun, for sure, but there was something missing.

Discovering what the game was all about

As I played our early prototype, I learned what made the game special. I found that I could play nearly indefinitely as long as I kept a relaxed but unwavering concentration on the gameplay. The moment I became slightly distracted, however, I lost. It’s almost as if my ultimate score reflected my current level of mental clarity. Maybe people could actually use this game to meditate. I decided to take this idea and underline it with an ambient soundtrack that would hopefully imbue the gameplay with a zen-like aura.

I’m a big Brian Eno fan and particularly enjoyed his (and Peter Chilvers’) early iOS app, Bloom. If you’re unfamiliar with Bloom, it’s essentially an interactive composition that lets you add notes by casually tapping here and there. It’s not a game so much as a sonic playground.

With YouAreGood, I wanted bring a similar level of interactivity to the soundtrack. In addition to the relaxing music, I thought each tap should contribute to the melody, a la Bloom. By virtue of playing the game, players would create beautiful melodies that never repeated. Each game would be its own unique composition.

This musical concept would provide the immersion the game needed, but it also influenced aspects of the game’s design.

A bit about scoring

We knew that we wanted YouAreGood to have a “press your luck” element with regards to the scoring system. In other words, we wanted to incentivize the player to score as close to 100 as possible, risking the game for a big reward.

In the first iteration of YouAreGood, the player scored the same amount of points as the current number on the tile. So, if the tile was at 78 when the player tapped, the player earned 78 points. If the tile was at 2, the player earned 2 points. This had the benefit of being simple, but also gave players an easy and risk-free way of earning a high score. Simply tapping continuously would be a slow but sure way to grind one’s way to the top of the leaderboard.

We went back to the drawing board, and created the following conditions:

Players don’t score anything if they press a tile under 50

Tiles from 50-70 give you 1x your score (i.e. 50 x 1 = 50 points)

Tiles from 70-90 give you 2x your score (i.e. 70 x 2 = 140 points)

Tiles from 90-100 give you 3x your score (i.e. 90 x 3 = 270 points)

The point system was basic, but it rewarded pressing your luck and discouraged mindless tapping. It wasn’t until I implemented the music that I felt that something was still off.

The interplay between music and game design

To complement YouAreGood’s gentle, synth-driven soundtrack, I decided to use a chime sound that I sculpted with my trusty Nord Lead 4 synthesizer. I wanted each tap to be harmonious, so I came up with a scale that worked well with the chords in the soundtrack. For the range of taps that scored points (50-99), I ended up recording 16 ascending chimes, with the highest point range triggering a chord with the high tonic note on top (the resolution note of the scale). 

As soon as we played the game with the new chimes, we noticed an incongruity between the way the points were totaled and the way the chimes made you feel. For example, if I were to tap a tile at 71 and then at 89, my score multiplier would be the same for both scores (2x), but the chimes told a different story. The joyous chime at 89 made it sound like my score was a lot better than the score I earned at 71, even though this wasn’t actually the case.

To fix this mismatch between expectation and reality, we did away with the tiered point system and instead used an exponential growth function as the basis for the code that determined the amount of points earned.

Before the change (tiered point system): Tapped at 71 = 142 points (2x) Tapped at 89 = 178 points (2x)

After the change (using exponential growth function): Tapped at 71 = 213 points (3x) Tapped at 89 = 623 points (7x)

The player would now earn huge multipliers by waiting until the last moment. After making this change, tapping a tile at 99 was finally as triumphant as it sounded (15x, or 1,485 points, compared to just 297 before!).

Music and game design: better together

Music and sound design can be more than just window dressing on a game. They can help define and emphasize what makes a game worth playing. At times, like with YouAreGood, they can even help expose the inconsistencies and gaps in a game’s design.

-----

Programming! 

Unity will run through a loop on a single frame if it encounters it. The downside to that is if you want to do anything like a smooth movement over the course of several frames you have to interject with timing logic to slow down how it is processing things. We reworked She Dwarf’s movement code heavily in the past day. Before we were using a series of boolean flags and timers within Update(). Now we’re using coroutines. Practically speaking the result is almost exactly the same, but everything is much clearer in the code and this sets the stage for more complicated behaviors in the future.

Before if a movement started there was all these flags that flipped around and timers started and Update() was starting to get unwieldily. Lots and lots of If statements checking boolean values for whatever current action was happening. Essentially relying on the fact that Update runs every frame and then using timers to make sure that it advanced things at the pace we wanted. 

The following is some vastly simplified code for how we were handling moving her from one point to another after hitting the appropriate key:

//Timer Information public float timerStart; public float timerSpeed = 5f; //Action is currently running public bool action = false; //Positional variables public Vector3 startPosition; public Vector3 endPosition; void Update() { if(!action && Input.GetKeyDown(KeyCode.A)) { startAction (); } if(action) { gameObject.transform.position = Vector3.Lerp(startPosition, endPosition, (Time.time - timerStart) * timerSpeed); } //Stop action when we've reached the end position if(action && gameObject.transform.position == endPosition) { action = false; } }
 //Use this to kick off the Action public void startAction() { action = true; timerStart = Time.time; startPosition = gameObject.transform.position; endPosition = gameObject.transform.position + new Vector3(-32,0,0); }


The result looks like this:

http://blog.scopecreepstudios.com/post/144983794346/she-dwarf-moving-without-a-coroutine

It works and we’ve used this method in other games. Yes, it could be refactored to be cleaner, I know. However, no amount of refactoring is going to get around the fact that it’s ugly and the logic is difficult to track. This was fine. It was totally fine.

Coroutines

Coroutines, on the other hand can be thought of as a function that running in parallel to the rest of the script. When you use the return type of IEnumerator Unity let’s you do some special stuff with a “yield” statement. It more or less allows you to “pause” whatever the coroutine is doing on one frame and then the game will return back to the same spot that you paused on the next frame. Cool, so what? Well, throw the yield statement in a loop and it’s like magic.

Suddenly you can do things over the course of many frames with a whole lot less code. I was able to move variables into a much better scope and generally clean up our core Update() loop significantly. Here’s the above rewritten to use a coroutine instead:

public bool action; void Update() { if(!action && Input.GetKeyDown(KeyCode.A)) { StartCoroutine(startAction(gameObject.transform.position, (gameObject.transform.position + new Vector3(-32,0,0)))); } }
 //Use this to kick off the Action IEnumerator startAction(Vector3 startPosition, Vector3 endPosition) { //Disallow other actions action = true; //Start up the timer float timerStart = Time.time; float timerSpeed = 5f; //Core loop for the coroutine while(gameObject.transform.position != endPosition) { gameObject.transform.position = Vector3.Lerp(startPosition, endPosition, (Time.time - timerStart) * timerSpeed);
 //yield statement "pauses" until next frame yield return null;
 }
 //Allow further actions action = false; }

That looks like this:

http://blog.scopecreepstudios.com/post/144983819993/she-dwarf-moving-with-a-coroutine

Very similar to the other method, but so much more readable.

The above sets off the coroutine when someone hits the “A” button. Every time action() hits “yield return null” it stops for that frame and then picks back up at that spot the next frame. This returns us back to the bottom of the While loop, which then hits the end and checks itself again to if its condition has been met.

Working on a level editor/builder. Our basic level starts empty aside from Shedwarf:

Then we import a csv like this:

g,,,,,, ,,,,,,g ,,,,au,, p,,au,s,,, ,g,,,,,

And when you load it up it ends up looking like this: