Praise the Fire Fighter, Damn the Safety Inspector

There's a sickness eating our industry.  It's a culture of Macho Programming.  In it's simplest form, it's the idea that if we just push harder, longer, stronger, then we will win.  Yet time and time again, experience shows that the way to win is by working smarter.

Side-effects

I was once working on a particular AAA title.  The game was running late.  We were in crunch, and had been for a while.  There was no end in sight.  I came across the following code:⁽¹⁾

bool DetectCollision(Vector3 location, float radius){
  ...
  radius * 1.2f;
  ...
}

So that line of code makes the collisions a bit fatter.  It's what we call a 'Fudge Factor' - we don't know why a problem is occurring, so we fudge the numbers a little until it works.

But take a closer look.  The statement as written has no side-effects.  It doesn't actually modify the value of radius.  When the programmer wrote:

  radius * 1.2f;

they intended to write:

  radius *= 1.2f;

Let's review the facts:

• It's the wrong fix to begin with (fudge factors are generally a bad idea)

• It doesn't actually change the behaviour of the running program

• The programmer didn't verify that their "fix" worked

And we can safely assume that the programmer didn't verify the original bug in the first place.

Compound Fail

It gets worse.  In this late stage of crunch, there were so many easily avoidable bugs coming in to the code, that the production team mandated every changelist required a second programmer to sign off.

That's right, not one, but two programmers, working together, managed to convince each other that this placebo changelist actually improved the game.  Together, they marked the bug as fixed and sent it back to QA, fully confident they had made the game better.

What other trivial mistakes did those programmers make that night?

What a colossal waste of time and resources, simply because those two programmers had inadequate sleep.  The project would have been much better off if those two programmers had just gone home at 18:00.  Or 17:00.  Or even 14:00.

[Edit: I just wanted to add, these are actually two really good programmers! I'd jump at the chance to have them on my team again.  The equation here is crunch + good programmers = too many careless mistakes.]

Praise The Fire Fighter ...

When you're deep in crunch, it's easy to see the heroic efforts, the mountains of caffeinated beverages, the change logs at 4am.  It's easy to point to the person who's working the hardest and say "We all need to be more like that guy."  Because when it's all falling apart, you need to do something.

(Hint: That something we need to do is to get more sleep.)

... Damn the Safety Inspector

And when you're at the beginning of the project, and the Safety Inspector is telling you that what you're building isn't up to code, that the schedules are unrealistic and will lead to crunch, slipped deadlines, hard-to-find bugs and adds unacceptable levels of risk to the project...  Well they're easy to dismiss "We're trying to build something here! Why are you trying to stop us?"

(Hint: The Safety Inspector is probably right.)

Macho Programming

As an industry, we should be working smarter than that. We should be rewarding measurable results and hard evidence, rather than effort and posturing.

To me, Macho Programming, is blundering onward in whichever way you possibly can, without regard to what's best for the project or the team, simply for the appearance of getting something done.

I think we can do better than that.  In the true Agile sense, as a team, we need to make the best decisions based on the best information we have, right now, and move forward in the best direction we can.

Who's with me?




⁽¹⁾ Some details have been changed to preserve anonymity.

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...

Finding The Fun

When making a game, one of the things I like to do early, and often, is 'finding the fun'.  It's the process where you take a long hard look at your game to answer one simple question:

"What makes it fun?"

What is fun? How do we know when we've found it? I struggle with these kinds of questions because I don't play games the same way gamers do.  I'm a deconstructivist.  I tear games apart trying to understand how they were made, what were their authors motivations, what choices and alternatives did they shy away from?  That's fun for me, but I don't think that's much fun for you.

So instead, I hand a prototype of my game over to a gamer, and I watch them play. Mostly I'm looking for facial expressions - joy, wonder. But also their comments. What do they keep coming back to? If I'm trying to 'find the fun', I pretty much ignore all negative feedback, and just focus on the good.

One question I ask a lot is, "How could I make that part better?"  When I ask that question, what I'm really asking is, "What part of that do you want more of?"  If I hear multiple people want more of one thing, then I'll go and brainstorm about how to add more of that thing, using the actual gamers suggestions as a starting point for the brainstorm.

A Quick Note On Design Styles

If you've been reading this blog for a while, you'll know I'm a pretty hard-core programmer that's been fortunate enough to work with a great many super talented designers.  I've found they tend to have different styles and approaches.  Some, like me, are obsessed with finding the fun.  Others are much more interested in telling a story, or bringing the player along an emotional path.  Still others want to make elaborate systems for the player to explore, requiring a delicate zen moment on the player's behalf to catch glimpses of it's beauty.

And many others besides.

It's convenient for me to split designers into two camps - those who try to find the fun earlier, and those who are confident with their tools and process, and know the fun will come later.

Take a character designer for example, often in the second camp.  Someone who is building up the backstory for a character, figuring out their traits and abilities in-game.  Where they got that scar, and who was their childhood friends, and how all of that will affect their interactions with the player.  In isolation, these choices might seem meaningless and trivial, but when woven into a broader narrative, this minutiae can become intensely compelling and enjoyable.

Now, I'm not saying either camp is more or less effective. There's definitely room for both.  I'm just saying I find it more comfortable to follow along with the first camp as I find reassurance in their processes' measurability measurableness ability to be measured.

Which is important, because as a programmer, when I'm designing, I'm constantly have to ask myself, "What would [censored] choose in this situation?"

One advantage from working closely with so many designers, is the freedom to design in the style of those great designers.  I'm not stuck in any one particular school or with any baggage.

And now that I'm Indie, when I don't know the answer, I can just call them up on the phone and ask.

Before the Prototype

The approach above works fine when you have a prototype.  But what do you do before that?

Cardboard is great for this.

Scribble on cardboard, chop it up into pieces and move it around a page.

Make flowcharts, roll dice.  Get some trusted friends over and say "Hey, let's pretend we're playing a video game right now."  And you go through the exact same (watching) process outlined above, but without the actual prototype.

Before the Cardboard

Well that may be fine if you know what game you want to make, but what do you do before that?
Here's where you have to use the power of imagination.

 That's where I'm at right now.

I'm imagining what it would be like for my trusted friends to be playing a cardboard cutout of a prototype of a final game.  And then asking my imaginary designer buddies in my head :

"What makes it fun?"