10 Game Design Lessons Learned This Year

It’s been a crazy year!

Lots of projects. Late nights.  

A windy path from ideas to reality…

Here’s 10 game design lessons learned this year:

1/ If in doubt, take it out.

A few months ago we had a game prototype with some half-finished features. One was a Gallery to help players savour past adventures. When push came to shove we removed it from the alpha - after much hand wringing and a tinge of guilt.

So what was the impact of the removal? Not much.

The fun factor remained almost identical without it.

We freed up cycles to improve the core gameplay, with a much better game as a result (one that still doesn’t include the Gallery… but we’re fine with that)

Early on, less is more.

2/ Context, child.

In that same project we had an item discovery mechanic we named the “Shop”. In focus group after focus group players told us they felt frustrated and confused.

At one point I questioned whether the mechanic would work, and considered a switch back to something less risky.

In the end, the fix was simple: don’t call it a “Shop” (doh!)

Once we switched the name, expectations changed and a under-performing feature turned into something fun.

3/ UI  =  "Ultra Important"

One stuff up this year was an RPG, an early project we had to reboot.

The mistake?

Designing a deep game that seemed fun in a GDD, but couldn’t work in an actual phone UI.

I had designed the specs on paper, our devs implemented much of the systems before reality dawned - we couldn’t fit it all on the screen without greatly confusing players.

And by that time mechanics were too heavily linked, making it much harder to remove individual parts.

Ever since, we’ve had UI mockups in lockstep with game designs and prototypes. More up front work but far less pain down the line…

4/ Don’t balance bottom up

It’s not much fun to build a fun prototype and see players blow through the content too quickly. Or discover there aren’t enough quests to fill out mid-level progression.

The big picture lets you set your anchors in days, weeks, months and years, and guides you on how much to fill in the day-to-day path.

5/ Dialogs deserve prototypes too!

Raise your hand if you had to rewrite or throw file away thousands of lines of text. Perhaps twice?

*sheepishly raises hand*

Why?

We started text “production” before we’d set the right story form and function to fit the game and UI.  And in another case because the mechanics changed and made the original text redundant.

It’s much better to test a small amount of text first and then write the rest once later on, once it’s all locked in.

6/ Don’t bumble the bundle

In a recent beta we had to delay to optimize the initial download to under 50MB. This required dropping assets to later bundles and adjusting tutorial, thankfully not too bad as we have a streaming asset system, but still a last minute scramble.

And no, you can’t really “cheat” and just put overflow into an initial download on first run.  We’ve seen 40%+ dropoff rates with even as small as a 30MB download after first launch.

Thinking through the initial asset budget in more detail saves headaches down the line.

7/ Plant your story in a big pot

We discovered that our first game continues to have a much longer lifespan than expected, with many players playing now for over a year.

At the time of launch, we hadn’t thought through the story expansion, and had to twist together a second act that resulted in some inconsistencies we had to iron out later (the game now is more than double the original in length)

These days we imagine a launch version is just the first part of at least a trilogy worth of content that we have thought through (at least at a high level), to make sure we have plenty of space for expansion.

8/ Programmatic trumps manual balancing

Well strictly speaking, that’s not always true.

There are always some parameters better hand crafted, particularly in the NUX.

But as a game designer you only have so much time in the day, and you can’t spend them hand crafting prices for thousands of items, or manually pick rewards for hundreds of levels.

We switched the bulk of balancing for new projects to formula bases.

A bit of extra work up front for the coders now results in many benefits:

- much faster tweaking of difficulty and progression
- lets us goal seek the parameters to meet overall balancing goals 
- enables us to run much easier A/B experiments 
- more sleep

9/ Polish can wait.

Similar to premature production of text, creating near polished UIs and icons for a system that ultimately had to be changed…

I find now it’s much better to stick generic all the way through the prototyping and alpha, and then start real art production and polish at the last step.

This has had an extra benefit of helping concentrate on core gameplay early on, rather than what shade of purple to use for that Settings icon.

If a temporary “wireframe” UI can house a fun game, it’s a great sign for later when the real art and polish is added.

10/ New location for new inspiration

It’s funny how a change of environment, even for a few hours can spur new thinking.

Exotic subreddits, watching TED talks or reading books are fine, but there’s something fresh about time away from the office.

One of our new game designs was conceived during a weekend startup hackathon, in a big theatre amongst lots of great startup energy.

Another idea I’m in love with came from chatting to some young hippies in San Francisco (yes, the world deserves a basket-weaving game!***)

Summary 

Like most endeavours in life, learning to make great games is a journey, and the wins but also missteps have lots to teach.  

Thank you 2013, you’ve been great.

What lessons do you have? or , would love to hear.

*** well not that idea, though it could be pretty fun….