This is part three of a multi-part series on focus in game design, using examples primarily from Knockabout Games.  The first post can be found here.

I’ve designed a lot of computer pinball games.  My first one, “3D Pinball For Windows“, has the odd claim to fame of being seen by pretty much anyone who ever owned a PC.  Back in 1994, when I started working on that game, I wasn’t asking myself “what is the game about”.  I just went and made a pinball game (one that was about as kitchen sink a design as you can imagine).  It wasn’t great, but it was entertaining and acceptable for the time.

So when I sat down to make a computer pinball game for a mobile phone in 2003, I really wanted to get to the underlying core of what pinball was about.  At a minimum, I wanted to identify a key element a mobile pinball game could be built around that wouldn’t be crippled by the device.

What I settled on was “motion”.  Pinball is all about sending the ball careening around the playfield.  Unimpeded motion is far more appealing than obstacles;  and any motion that ends with a reaction (e.g. a target drops or a spinner turns) is better than one that ends with nothing happening at all.

Some of the things we did to reinforce motion in the game:

• Every possible angle away from the flippers resulted in a target being hit or, more often, the ball gliding gracefully up a ramp or through an arcing channel.
• We changed the underlying collision detection to be different than the visual, narrowing things like posts and the ends of walls so that the ball was more likely to glide past and into a lane or ramp than bounce back.
• Lights were laid down in all channels and ramps that would light up briefly as the ball went past, adding to and enhancing the motion.
• We made the game easy.  There were lots of reasons to do this, but more fundamentally, one ball in play for a long time is more continuous motion without interruption.

Reviewers and players loved the game, although it fared poorly as a commercial title (it only appeared on three handsets, limiting its distribution).  It did very well in OEM, which was oddly appropriate given how most folks discovered “3D Pinball For Windows” a decade earlier.

Next week:  Dodgeball

This is part two of a multi-part series on focus in game design, using examples primarily from Knockabout Games.  The first post can be found here.

In 2004 JAMDAT (now EA Mobile) contracted us to build an NFL-licensed title with full teams and rosters for a mobile phone.  Devices were pretty limited back then — the first real color handsets had only been out a year and the iPhone was a long way off.   Football games to that point were fairly primitive affairs with limited graphics.

Professional sports is well tread territory on other platforms.  Our thematic answer to the question “what is the game about” came with the license — this was “NFL football”, real as can be given the constraints of the platform, and all the expectations that come with that:  play calling, recognizable players and teams, season long play, etc.

But there were many options open to us on the functional side:  should it be about passing?   scoring?  play calling?  We ultimately settled on a very basic idea:  football was about “contact”.

Why contact?  Because it is what defines the real football experience and distinguishes it from other sports, and it happens on every single play.  It is the essence of football, and since we couldn’t replicate Madden on a 1′ x 1′ screen, we had to go to the roots of the game and build it up again from there.

In practical terms, here’s what that meant:

• Tackling was not binary.  Every single tackle, once started, took time to resolve.  You’d push a player back, or you’d drag (or be dragged) another yard or two.  Sometimes you’d break free.  On rare occasions you and the defender would bounce off each other and fly 10 yards through the air.  But the guiding principle was that you always kept moving when tackled, and the play wasn’t over when the tackle began.
• We tied phone vibration to tackling.  We didn’t use it for anything else, so the association was very clear in the player’s head (vibration means I’m being tackled, it’s not some UI feedback in the game).  And of course, vibration really does feel like contact, so the more we extended tackling, the more this feature enhanced the game.
• Because tackling was no longer an instantaneous affair, things like horrible keypad latencies could be hidden by the tackle.  It’s frustrating to press a button on a phone and not have the screen update your action in time.  In this case, even if you were late on the keypress and got tackled, you could still, say, change direction and keep moving (the player couldn’t tell if they started moving a different way before or after the tackle, since they were able to continue).

We were the top rated football game for mobile for two years, and the game sold well for JAMDAT (although sports and mobile were not what we expected overall).  We got a lot of favorable comments about play balance and graphics and such, but I believe the thing that made it work was the underlying focus on football as “contact”.

Next week:  Precision Pinball

This is part one of a multi-part series on focus in game design, using examples primarily from Knockabout Games.

One of the first things you should ask when designing a game is “what is the game about?”.  This is an old notion, and it’s not original to me.  The purpose is to focus the project and establish criteria against which to measure ideas and features.

This question should really be asked twice, once about gameplay (functionality) and again about context (theme).  Some functional examples might be “territorial acquisition”, “exploration”, or “physical contact”.  Thematic ones could be, say,  “19th century imperialism”, “street football” or “gumdrops”.

In either case, it’s important that there be only one answer.  That doesn’t mean you have to throw out your kitchen sink list of cool features you’d like to implement, but the question you have to ask of each one is simply “how does this feature support the core idea, and if it doesn’t then how can it (or should it be dropped)?”.

I should note that it’s possible during development for all this to change.  Sometimes a supporting feature unexpectedly emerges as the core element that makes everything tick, and by extension, the core focus of the product changes too.  Given the thought put into the relationship between the original core and different game features, that can be ok;  moving the new element into the primary role probably won’t be too hard (but you will have to re-think how, and if, other features still apply).

I could give some interpretations of existing games on the market and what I think they’re “about”, but this is backward looking and not terribly helpful.  Instead, in the next series of posts I’m going to talk about games I’ve actually worked on and how we answered that question at the beginning of the project (and to what extent it held true to the end).   These are all from Knockabout Games, a mobile game development shop I founded and ran from 2002 to 2006.

Next week, the first example:  JAMDAT NFL

This multi-part series examines the history of Knockabout Games, a mobile games startup I co-founded in 2002, near the start of the pre-iPhone “first wave of mobile gaming”.  The start of the series can be found here, and last week’s post on Knockabout’s demise can be found here.

I wouldn’t feel too sorry for Knockabout, by the way.  We shut the company down cleanly, without debt.  Everyone found work quickly.  Our publishing partners still talk fondly of the titles we created for them.  And something odd happened after we closed the doors.

Early in Knockabout’s existence we did a deal with Motorola to OEM our pinball game on some of their handsets.   It was a colossal waste of time and money that we never thought we’d recoup (our max upside projection was about 10k– we did it mostly for the relationship).  We’d only ever seen one royalty report, and it was so small as to be inconsequential.  We had written the whole thing off.

Except that, three months after Knockabout’s end, we started getting checks from Motorola.  Checks that were large enough that we could have saved the business if we still had staff or an office or anything.  But we didn’t.  So we distributed the money to the shareholders.  We had no way to project how much would come in or for how long, but every quarter a new statement and royalty check would arrive in the mail.  For two years, money came in and went right back out.

On top of all that we got inquiries from both Microsoft and Sony about the pinball game, and ultimately licensed it to both of them.

Was all that enough to make up for the cash we sunk into the business?  No.  But it did soften the blow substantially.  Monty and I often joke that we should have made pinball and immediately shut the company down.  The real lesson, perhaps, is that we should have put more faith in our own IP and focused on that with a smaller staff.  We didn’t need to build the shop like our past businesses — a few guys would have been sufficient to achieve sustainability and from there we could have scaled up as appropriate.

The larger observation is that speed isn’t always as critical as it appears.  Any time you enter a new, emerging space, there’s a tendency to view the window of opportunity as small.   You have to move fast, grow quickly, establish a foothold before the value chain ossifies and fills up with established players.  To some extent that’s true.  But I think there may be a case for being patient and growing organically, not worrying about the timeline and just adapting as you go.  If you’re small, really small, you’re actually pretty nimble — large tectonic shifts in the space don’t kill you.

That wraps up the series on Knockabout Games.  The entire sequence is below:

Before The Start

Product Strategy

Business Strategy

Funding, Equity And Staffing

What Actually Happened

Where We Failed

Knockabout’s Demise

An Epilogue

This multi-part series examines the history of Knockabout Games, a mobile games startup I co-founded in 2002, near the start of the pre-iPhone “first wave of mobile gaming”.  The start of the series can be found here, and last week’s post on how Knockabout’s strategy failed can be found here.

In the end, Knockabout got caught in the typical developer trap, going from project to project, always in danger of missing payroll should a milestone slip.   We reached a point where we couldn’t sustain the business and had to shut it down.  Rather than conceal this from our staff and business partners til the last possible moment, we took a gamble on a better (and I would argue more ethical) approach:

• When we first saw things starting to crack, we informed everyone that we were at risk.  We didn’t know if we were going to have to close our doors, but we didn’t want anyone to be caught by surprise.  This was risky– our staff could start jumping ship and our publishers could cancel projects.  But none of them did.  We talked about options and scenarios, but mostly we worked hard to keep revenue flowing.
• A month later we revisited the situation and made the decision to wrap up the business (for reasons I’ll outline shortly).  Again, we told everyone.  Because we had titles under development, we told our publishers we would do our best to complete them, but it would likely cost more than they had budgeted.  All but one decided to continue.  We then asked our staff to stay on until their respective titles were done.  That meant as much as two more months of work.  We also said we’d help them find work if they needed it, and we’d give them severance if they stayed to the end.  All but two stuck it out.  I’d like to think being open and honest with everyone — publishers and our developers — compelled them to stick with us, but I can’t say for sure.

Not everyone understood.  One publisher initially agreed, but was baffled when I asked for more money to complete their project.  He told me I shouldn’t pay my staff unless they meet their milestones.  I explained that every one of my engineers already had jobs lined up with better salaries than what I was paying them.  They were there out of loyalty — he was welcome to not pay, but the project wasn’t going to finish.

Why did we close our doors?  Why not raise money, borrow from the bank, or scale back operations?  That may have been an option.  Indeed, we had deals on the table for another round of products.  But they all looked like the last round of projects, which meant we’d have a hard time surviving unless we were perfect on delivery (and we clearly didn’t have a track record to support achieving that).

We also looked ahead and didn’t see an exit.  Our strategy didn’t produce value in the space the way it had in the pc and console sectors.  And we didn’t have the capital — or the time to raise capital — to change the nature of our business.  So we moved on.

Many of our colleagues faulted the space — it was hard on developers, market conditions were tough, very few survived.  But if you’re running a business you can’t ever point to external factors.  Every problem is ultimately a problem of execution.  If you don’t see the changes happening around you, or you fail to adapt, the only one you can blame is yourself.

Next time:  An epilogue of sorts.