Random

Lately, I've been tuning the "Drop-Rate" of pickups in Scooter Boy.  It's actually a lot like handing out candy at Halloween.

Allow me to use this handy diagram to explain:

Too little Candy	Too much Candy
Not enough candy to go 'round - some people walk away empty handed.	Everyone is all full of sugary goodness, and they don't want any more.

But that's not actually what I wanted to talk about today.

I wanted to talk about Pigeons.

The Pigeon Food Dance

There was a famous set of experiments back in the '30s that revolved around withholding candyfood from pigeons.  In one of these experiments, the amount of time between successive drops was random. It turns out that each of the pigeons developed a (unique) ritualistic food dance. In happy pigeon land, it was the completion of the dance which caused the food to appear.

Now the curious thing was, the time it took for the pigeon to complete the dance was slightly longer than the average time between drops.

So when the pigeon completed the dance, there was a better than 50/50 chance of getting food.  And if not, well repeating the dance a second time would surely do it!

(Have you ever timed how long it takes to reboot your computer when you've got Tech Support on the phone?) 

Random Drop Rates

For most of Scooter Boy's development,  I've been using random drop rates.  Power ups would appear, seemingly at random.  Sometimes you'd get lots, and sometimes you'd go ages without seeing any.

Worse still, changing the drop rate, by changing the percentage of a drop, was very clumsy. You'd double or quadruple the drop rate, play the game, and the results would be... well ... random... There was no way to tell if your change was making the game better.

In short, random drops, just aren't fun!

A Drop Rate Schedule

I'm in the process of changing all those drop-rate percentages into times. 30±10 seconds between drops.  Or 120±60.  It's so much more measurable. And it turns out, it's a lot more fun too.  As a player, it feels like the powerups are rewarding your effort.

So down with Mathematical Randomness! Lets make the game match the player's expectations. Lets put the fun first!

Analytics

If you happen to live in a certain North European Country, in the wee hours of this morning, ScooterBoy went live!!

That's right, you can now download ScooterBoy, for free!!  (with certain geographical restrictions.)

"But why can't I download it??!" I hear you ask.

Well, you see, it works like this :

We want to make the best release possible in the largest market.

 ➡  The best way to do that is to use feedback from real live customers to improve the game.

 ➡  Where best to get those customers? Yes! From a certain Northern European Country!

Analytics

Now our analytics takes over.  How many downloads will we get? How long will players play? Which level and characters do they play the most? How quickly do they earn currency? What's their favorite IAP (In-App Purchase). What does our retention look like? Where does the game crash?

We can turn all these questions into metrics, then apply those metrics to our game.

We will compare our numbers to our expectations, and then see which numbers we want to improve.

What If?

The next step is to play the "What-if" game.  For example, suppose we make the decision we want to increase player retention:

• What if we had more characters?
• What if we had more levels?
• What if the game were harder? easier?
• What if we gave a bonus for playing every day?
• What if we had daily challenges?
• What if we highlight the leaderboard?

Soft Launch

Exciting times for ScooterBoy!  And lots of geek-out points writing queries in SQL to try and turn a mountain of data into usable information.

We can't wait to make ScooterBoy even bigger and release in more markets!

...watch this space...

Easy Mode Unlocked

One of the hardest thing to do when making a game, is to balance the difficulty.

Of course, at the start, you want your game to be as accessible as possible.  Then, over time, as the player progresses, you smoothly ramp up the difficulty to keep the player engaged.

Today I wanted to focus on the beginning of that : Just how easy is easy?

Easy for Me

The natural instinct of the indie developer is to make the first level really easy for themselves.  It turns out that's not a fair test.  You've been playing the game for a while now and you know all the controls and every obstacle.  You need to look elsewhere, to someone who's never played the game before.

Easy for You

The next step is to focus test.  Find everyone you know, especially your friends, who don't play games that much.  And then make it easy for them.  As you go through this process you'll find your game becomes more and more accessible and the learning curve becomes more and more navigable.

Easy for Everyone

But can we do even better than that?

If you watch young kids playing games on a tablet, you'll know how engaging they can be.  And frustrating too, with the constant restarts, and the accidental taps on adverts and in-game consumables.

Zen Arcade

In keeping with this spirit, this morning I added a special "Zen Arcade" mode to my next game:

There's no enemies or time pressure.  There's no way to lose.  It's just a calming, peaceful experience that anyone can play and enjoy.

I even made the pause button a little smaller to avoid accidental clicks, and removed the options to use the power ups.

What tips and tricks do you use to increase accessibility of your game?  Why not let me know in the comments below!

Don't Repeat Yourself

When making Indie games, there's a mantra that bears repeating over, again and again:

“Don't Repeat Yourself”

It's actually a corruption of a much deeper truth. If software development excites you, I urge you to read all the gory details about that deeper truth over on wikipedia. (If you want to go read it now, I'll still be here when you get back.)

When making Indie Games, however, “Don't Repeat Yourself” means something different. It's rooted in the notion that (calender) time is the most precious resource. It's the free variable with the highest opportunity cost. The longer amount of time it takes you to do something directly translates into a lesser amount of time you could be working on your next goal.

So what happens if you have to repeat a previous step? Replace an image that's no longer working? Change a sound effect? Rebuild a level? What happens when you have to repeat yourself?

For every repeat, the time you wisely invested into the previous version of that asset is effectively wasted.

You would have been better off using that initial time reading game development blogs. Or meditating. Or playing Dino Switch II.

So what does "Don't Repeat Yourself" really mean? It means that as an Indie, (almost) every piece of content you put time into, needs to ship at some point in the future. It means that each time you touch an asset, you should treat it as the last time you'll touch it before it ships.

Your asset pipeline (as an Indie) needs to go :

Concept -> Placeholder -> Shippable Asset

Cappucino

Contrast that with the apocryphal AAA game producer, “Make three cappucinos... then bring me the best one!”

Of course, what he really means is “Have three baristas separately make three different cappuccinos... then discard the two which aren't as good.”

So here's a Pop-Quiz, are those two discarded cappuccinos wasted?

Some would say “Yes”, referring to the ingredients and skill which went into the preparation of content which will never be consumed.

Others would say “No”, because the producer couldn't know ahead of time which barista would prepare the best coffee. Three times the amount of resources have gone into the production, in exchange for an improvement in quality and a substantially reduced chance (risk) of getting a bad coffee.

Don't Repeat Yourself

As an Indie, where (calendar) time is the most precious resource, “Don't Repeat Yourself” means shipping every piece of content you produce. If you somehow find yourself with 3 cappuccinos, then you're going to be drinking them all!

But does that also mean you need to ship the pieces which didn't work out? Not at all. Because the overarching process goes like this:

• Get placeholder assets for everything into the game

• Without repeating yourself, systematically lift every asset in the game up to shippable quality.
  (Upon completion, your game as a whole ought to be shippable)

• Do a polish pass where you replace only the assets which are (a) quick to improve, (b) have a big impact on quality

• Ship it

And that's indie game development...

I Make Video Games

For me, it all started back in 1985 with the Commodore Vic-20.  I'd while away the hours typing in games from the magazines and storing them on magnetic tape.

Fast-forward to 1995 and the Amiga.  Me and some buddies launched Super Skidmarks to outstanding critical acclaim.

I love the process of making video games.  It's a series of puzzles.  Solving each puzzle unlocks even more puzzles.  As you get deeper and deeper, the puzzles get more and more intricate, and it becomes harder and harder to distinguish the best solution amongst all the correct solutions.  Always the fascination remains.

I love making games for gamers. I love passing the gamepad over to a gamer - passing the gamepad over to you - to see how you'll react.  There's this one moment that I really love in game development.  It's that moment when I try to probe you for feedback on my game, but you're so engrossed in the gameplay, you're physically unable to stop playing long enough to engage in meaningful conversation.

In 2005, I launched Black&White 2 with Lionhead Studios on the PC.  The game was a technical masterpiece and wildly ambitious.

Over the last few years, I've worked on many, many, many, many unreleased projects.  Those are the projects during which you grow the most.

I've been incredibly fortunate to work with, and learn from, so many amazingly talented people.  From programmers and artists, from QA and production.  Gifted musicians and mocap performers.  Everyone.  Thank you so much!  It's from you I learned everything.

Most recently I've been fortunate enough to work on the Mass Effect franchise with BioWare and on the Rainbow 6 franchise with Ubisoft.

Also the surprise hit at this year's E3, Watch Dogs.

 

But when I sit back and reflect, it feels like I've been working on increasingly smaller and smaller pieces (with ever increasing detail) of increasingly larger and larger games.  I'm always truly excited to be a part of a AAA blockbuster... but I miss that visceral connection with the gamer that comes with smaller teams and shorter development cycles.

It's taken me a while to realize, but the thing I love the most about video games, the reason I got into all of this in the first place, is when your delicate, fragile little game, (or big game!) that you've put so much effort into, finally makes it out to the gamers - to you.   Well... that's why I Make Video Games.

And while I never stopped making mini-games (and playful spaces) along the way, almost all of them I've been prevented from finishing because of contractual obligations.

That's why, as of today, I've returned to Indie Game Development.  To make video games in their entirety.  To make every little piece, from top to bottom, everything custom crafted with gamers in mind.  To make the best games for gamers.

To make video games, for you.