Doing More With Less: Short Videogame Design

Aug 17, 2010

Rapid advances in computing, design community discourse, and demographic variation continues to make game development and distribution easier each year, prompting a tidal wave of new games. Although console manufacturers historically limited the number of annual releases, the internet and smartphone app spaces have no such restrictions.

Videogames used to be light on content due to limitations of technology. Then they ran into limitations of budget. The latest and increasingly dominant limitation now seems to be consumer time and attention within an ecosystem of constantly improving free/cheap entertainment alternatives. Not only is each game competing with the flood of other quality games, either – it also battles for attention against the internet in general and pirated media.

Justifiable time and cost, for both developers and consumers, are on the way down.

This has prompted unexpected moves like GameStop purchasing Kongregate, and Electronic Arts buying Playfish. Like it or not – and I certainly have mixed feelings about this – the future of the game industry may look more like The Fancy Pants Adventures than Mass Effect. Even iPhone app budgets are shrinking rapidly, and they were comparatively bite-sized projects to begin with.

As developers, then, it is increasingly worthwhile to strategize about being resourceful – cleverly finding ways to do more with less, until we discover ways to make what we want while spending next to (or ideally) nothing.

In the material that follows I will mostly keep to examples from my projects – not because they show the best ways to deal with minimal resources, but because they show the best ways that I know firsthand. If I knew the design or development of anyone else’s projects nearly so well as I know my own, I could focus more on those, instead. (I will, nevertheless, try to reference at least a few outside games to highlight variations and counterexamples.)

Challenging Ending for Systems Games

Topple (iPhone) was not a long game. It has 10 levels, each of which can be played in 1 minute each. 10 minute game, right?

When the game was released – the publisher ngmoco may have adjusted the difficulty since – it took 40-90 minutes of play to complete, due to a mix of luck, strategy, and skill required to advance. In particular the first 6 levels were designed to be a bit easier, with 7-10 being much more challenging.

In a story game, that difficulty spike would be substantially more frustrating. It would create the impression that there’s content being kept away from the user. A person buying a DVD expects to be able to see and hear everything from it, and a lot of larger games strive to be associated with film, resulting in an expectation that the user bought and thus deserves to watch all content included. Since Topple is about systems, rather than story content, replaying a level isn’t keeping the player from seeing the ending – it’s simply playing the game.

Toy Without Objective

Burnit (iPhone) / FireWriter (web) isn’t a “game” – there’s no score, points, or goal. Instead, it’s just a way to draw with gunpowder, then light it (optionally, in Burnit, over a photograph). There’s no level 2, there’s no plot, there’s no expectation set that it needs more depth or functionality.

Tumult (video of iPad/iPhone app) is a similar example. Relative to most iPad apps, there’s virtually no content – no animations, no music, no story… Users aren’t complaining about its length, though. People like it.

We expect songs to be 3-5 minutes long, movies to be 90-120 minutes long, and television shows to be 22-45 minutes – whether we get them from the bargain bin, pay full price, or watch/listen for free. We similarly expect videogames to be [whatever length] regardless of price. Tumult avoids looking like it’s trying to be a videogame, avoiding those expectations.

Those two are not videogame-like. That’s ok, if our goal is to entertain, rather than to make a game. However a toy can be like a videogame. An example: A-10 Thunderbolt II (web)

Meaning Outlasting the Game

Transcend (iPhone/iPad) can be completed in 15 minutes. It has roughly the same replay value as a book – it’s there for review at any time, but won’t behave differently than it did the time before. In spite of this, user reviews recommend it.

Rather than focusing on the time spent playing the game in this case, the emphasis is offloaded on making a memorable impression. Unusual presentation, unusual design approach, and a few dozen highlights pulled from over 15 hours of text read from an influential book in the public domain (Walden). It ends with a short “song” juxtaposing half of the game’s excerpts over a catchy tune.

My interest was not how the user would think about Transcend while using it, or how long it would take, but rather how and how long the user may think about Transcend after.

See also: A-10 Thunderbolt II: Costs

Meaning doesn’t have to be dense to outlast the game. Especially if the game is short. This is how I got away with Candy (web). This strategy also seems to central to Ian Bogost’s satire game Cow Clicker (Facebook).

Stretching Out Relatively Little Content

Alice in Bomberland (iPhone) is a hybrid literature/action mash-up, and partly designed around theories about educational interactivity atoms. It’s a dodging game with 7 types of weapon behaviors to avoid, in front of 8 different backgrounds – yet the game lasts roughly 3 hours.

While this game turned out much longer than the other “short games” on this list, it does not have proportionally larger asset requirements. A few design tricks were used here to squeeze the most out of what’s there:

  • Only 1 animated character (Alice). All others are presented as paintings holding weapons during story sequences, which interact with gameplay via attacks fired from off screen.
  • Recolored backgrounds. Each of the 8 background images, in addition to appearing in its full color version, also appears in dark (challenging), blue-tint (even harder), and red (final version, most difficult). These required very little programming time to create, but added significantly to the variety in visuals throughout the game while giving an extra sense of proximity to the end.
  • Lots of power-up types. Every 1-2 levels, a new item is introduced to the game. Programming the effects for these items was fairly straightforward, and their graphical requirements were also very simple. This spreads out novelty over all levels in the game.
  • Unpredictable ordering of level patterns. There are 6 level difficulties for each of the 8 level/character types, creating a total of 48 levels. Rather than putting level/character types in repeating order like A, B, C, D, A, B, C, D, A, B, C, D (i.e. always putting a Caterpillar stage immediately after each White Rabbit stage)… I instead ordered as A, B, A, C, B, A, D, B, C, D, C (like the distribution of grassy/rails/caves/water stages in Super Mario World)… this allowed me to save certain types until later in the game, include early types throughout until the very end, and avoids a sense of monotonous routine. Different players have different level types they prefer or hate, leading to surprise “Finally! Another Hatter level!” or “Ooo, a Cheshire Cat level this time” like a mini-lottery after every win.
  • While a lot of writing work still had to go into selecting, editing, and ordering excerpts from Alice’s Adventures in Wonderland, as with Walden for Transcend, the core of the writing already existed and had passed the test of time, saving a considerable amount of time and energy. (In both cases, the copyright on the book text in question expired long ago.)

High Replay Value

feelforit (iPhone/iPad) is an artsy project, but mechanically it’s built around a novel interactivity concept rather than a sequence of content. By presenting a repeated, randomly new situation each round, rather than having levels, the game cannot be “completed”. Each time it’s as good as new.

It’s a skill to be mastered, rather than an obstacle course to be completed. It doesn’t translate naturally into challenges of different difficulty – they’re all equally hard until the skill is learned, and they’re all equally decently engaging once the skill is learned. A bit like juggling 3 balls. Had I added 2-3 “levels” to it, the game would be completable or “digestible”.

(I think this particular distinction, on a massively different scale, was one of the design faults in Spore that previous games from Will Wright didn’t suffer from. In SimCity, the player is fundamentally always doing the same thing, even if at different scales, making there no end to what’s there; in Spore there were – necessarily – a discrete number of different gameplay modes, such that by the time the player was “trained” in all of them, the game felt completed.)

With Varied Content, Unlock Everything

This is a theory of what I should have done, based on what happened. iZombie Death March (iPhone) has 6 level scenarios – each plays differently, with unique weapons, in a distinct setting, and different features. Because the game had a (textual) story, I locked the levels into an order: level 1 must be completed before playing level 2, 2 before 3, up to 6. Each level only lasts a few minutes, during which time a random quantity and ordering of zombies attack, of varying types depending upon the level, and in different speed/quantity depending upon difficulty selected.

All 6 levels, therefore, can be completed in order relatively quickly. In that time, players may not even come to appreciate the differences between the levels, weapons, lighting, perma-gore feature, etc.

If, instead, all 6 levels were made available immediately after download, and instead of being a 6-level linear game it was a random zombie shooter with “6 ways to play!” or “6 Zombie Minigames” I don’t think I would have received as many criticisms about the game being too short.

Just a theory.

Other Indies on Short Games

We’ve coordinated to write perspectives and experiences! Dislike my suggestions? Compare to what peers in the indie development community have to say about game length:

Ron Carmel of 2DBoy

Jonathan Blow

Jamie Cheng of Klei Entertainment

Dave Gilbert of Wadjet Eye Games

Matt Gilgenbach of 24 Caret Games

Noel Llopis

Cliff Harris of Positech Games

Martin Pichlmair of Broken Rules

Scott Macmillan of Macguffin Games

Peter Jones of Retro Affect

Lau Korsgaard

Eitan Glinert of Fire Hose Games

Chris Hecker

Jeffrey Rosen of Wolfire

Greg Wohlwend

Michael Todd

Alex Amsel of Tuna

Anthony Flack

Steve Swink of Enemy Airship

Rob Jagnow of Lazy 8 Studios

Jamie Fristrom

Sean Murray

Hank Whitson

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.