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!

Test Anims

Here's some initial test animations:

More coming soon!

A new project?

Something pretty awesome is taking shape on my development computer at the moment.


These are the first public pics.


More updates coming soon!

Beta

In the world of stuff, there's things that you know, and things that you don't know.  It can sometimes feel like all of us are simply questing to try and know more and more stuff.

But there's another way of looking at the world of stuff.  We can also split stuff into the things that other people know, and also things that other people don't know.  It can sometimes be confusing thinking about what other people know.  Fortunately we live in a social world so we should all be good at it.

In any case, Mathematicians, like me, sometimes like to use Venn Diagrams to describe these kinds of relations:

We can then build fun subcategories, like "Secrets", which contains all the stuff that we know, but that noone else does.

Or "The unknown" - that's all the stuff that noone knows about.  Yet.

But there's another interesting subcategory that I wanted to talk about today.  I'm sure there's a great German word for this category, but I don't think it has a name in English. It's that category of stuff that other people know (about us), but that we don't know about ourselves.  It's all the stuff like:

• What does the back of my head look like?
• What was everyone laughing about just before I walked in to the room?
• Why do I always struggle to open doors?

And the all-consuming:

• Does this pair of jeans make my anorak look out of proportion?

Even in principle, this stuff is unknowable to us. Why? Because even if we were to ask a trusted friend, there's a complex web of social contracts which ensures the information they relay to us be 100% believable, yet have no basis whatsoever in reality.

Beta Testing

When we're making video games, there's a number of tools we can use to improve the quality of the game prior to launch.  One of the most useful is Beta Testing.  Of course, we do all manner of testing when making video games, but Beta Testing is the one which can really make or break a game.

In a true Beta-Test, all of the intended features are actually present in the game in a playable state.  It might even be one of the first builds where this is true.  The game is then played by people who are outside of the development team.

In a (true) Beta-Test, it's the development team looking for feedback about all the stuff that other people know.


So if you're ever asked to Beta Test some software, what does that look like?


Well first things first, remember the social contract?  That's not what a Beta Test is about.  The dev team isn't looking for praise or apologies, they want solid, genuine feedback about the features in the game. Be that an emotional response ("it felt great when..."), or something actionable ("I couldn't reach the exit because...")

Naturally they're looking for confirmation about the stuff they (think they) already know, so be sure to include some high level comments about the stuff that seems obvious to you, the stuff that "...everybody knows...."

More valuable to the dev team is going to be feedback about stuff they don't know.  Try and tell them about the bugs that only you encountered.  Try and share anecdotes that are relevant, but that will be unknown to the dev team.  Try and give them access to the areas they can't otherwise see.

The Beta Blog Post

So all of this is stuff that I know, and after reading though, now it's stuff that you know too.  I happen to think this is important stuff that everyone should know, but I may be in the minority on that one.

However, there is a chance that this blog post contains serious defects.  For example, I know that this post still has lots of room for improvements.

For that reason, I'm officially declaring this blog posting to be a "Beta Blog Post".  What that means is, I think it contains most of the good ideas, but there might be stuff about this topic that I don't know (yet) or haven't covered adequately.

Why not help me out and use the comments section below to give me some feedback, maybe an emotional response, or even something actionable?   ;)

The Big Picture

"It's just behind that one over there!"

I always have this kind of mental picture in my head about all the things that need to happen before I can launch a game.

It's filled with lots of tiny little things :

• Putting in a 'squish' sound when you press a button on the main menu. (5 minutes)
• Re-export a piece of artwork with different quality settings. (10 minutes)
• Building out the website with a FAQ section. (15 minutes)

For each one of those little user stories, I'm thinking : "Oh, I can do that, that's easy."

There's also a whole bunch of medium sized things :

• Make the draw routines faster so it doesn't skip quite so much. (1 hour)
• Add a 'Load' screen to, umm, cover the loading. (1.5 hours)
• Make the 'Undo' button work properly. (2 hours)

I guess if I had to, I could cut those user stories, but in the back of my head I'm thinking, "Oh, I know how to do that too, it's not that hard..."


Of course, there's a whole bunch of difficult things to do too, but even those I'm not too worried about.  I know in principle that they're solvable, and I've solved similar tricky problems in the past.

The problem comes when I try and find all the things that need to happen before I can launch a game, and then add up how much time it is going to take to get all of those things done.  It's a huge chunk of time. It can be a little daunting.

The Plan

My original plan was to have an app out on the appstore by now.  So I guess that didn't happen :)

But I hope you'll allow me the indulgence of quoting former US president, Dwight D. Eisenhower:

         "Plans are worthless, but planning is everything."

The easy thing to do right now would be to just keep chipping away at the original plan.  I am making good progress after all, even if there has been considerable discovered work.  It definitely feels like I'm getting closer to something.

"... That one over there looks easier to get to..."

But maybe there's a smarter way through here.  Maybe I can find a smaller game to make.  One that I can launch sooner.  Something to at least establish a presence, and then use that as a base to launch bigger games.

...hmmmm...

What would you do in this situation? Any advice? What do you think I should do?

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

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.