No Time To Play

Encounter-based game design

by on Jun.15, 2017, under Case study, Gamedev

Perhaps the most infamous feature of roleplaying games, computer and tabletop alike, is the random encounter. Dreaded by players, panned by reviewers, it’s nevertheless been a constant presence in the genre, ever since its original appearance in Dungeons & Dragons. It made sense in the latter, which was always at least partly a resource management game, but few modern RPGs preserve that aspect (except for roguelikes). And in a game that tries to tell a story, random encounters are just an annoyance, regularly getting in the way for no good reason.

Which is a shame, because encounters have been the basic unit of storytelling since ancient times. What else is a fairy tale than a string of encounters the protagonist runs into along a linear road?

(And the protagonist’s journey in a fairy tale is linear. Plotted on a map, it may well meander all over, but it must still be followed strictly from end to end. Straying from the path always leads into trouble, and turning back is the worst sort of failure.)

Having recognized this basic truth, about a year ago (as of June 2017) I started thinking how to take advantage of it in game design, because unless open-ended exploration is part of a game’s appeal, the map can turn into a dead weight. Players can easily tell when they’re being presented with false choice. Making good maps is hard; can you afford to waste time and effort only to have the results rejected for being pointless?

My first go at the concept, codenamed The Unmapped Tale, fizzled out early. The main problem was not having a good mental model of how each encounter was going to play out and connect with the others. It didn’t help that I kept thinking the player should at times skip ahead or go back, like in a glorified Snakes and Ladders; that’s how strongly we’ve been conditioned to think game stories have to be non-linear!

This concept did end up as a more conventional adventure made in Twine, which also ground to a halt for unrelated reasons. All I got out of it was a nice stylesheet for browser games, reused on multiple occasions since.

The intervening summer saw the long-awaited public release of Texture, a visual tool for authoring interactive fiction. Texture sports many compelling innovations, but one in particular is relevant: story games made with it are structured into pages, each a self-contained minigame if you ignore the global game state. This is true of competing tools as well, but here it’s very explicit.

I soon used it to port one of my text adventures, which worked out really well except for having to cut a bunch of text for lack of screen space. It still didn’t quite fit my newfound vision. While boolean values (true/false) are enough to encode many conditions, they’re not enough for an RPG-like experience. There’s a reason why both Roman and Kanji numerals invent distinct symbols for numbers larger than three!

Fast forward nine months, when participation in a game jam pushed me to dig up my old books of BASIC type-ins from 25 years ago. Imagine my surprise when a game I’d forgotten all about turned out to suffer from the exact same problems that made me abandon a design document earlier this year! To wit: when you abstract the map to such a degree that every tile becomes nothing more than a blank space for random encounters to happen in, you might as well do away with it entirely.

Once this revelation struck, it was a matter of days to cobble together a silly little game to test the concept. I named it Lost in the Jungle:

Health: 3 Bullets: 6 Time: 7h
You cross shafts of sunlight.
Around you, the jungle looms.

What do you do?
1) Walk 2) Rest

You rest and heal a little.
However, while you slept...
Screaming monkeys harass you!

What do you do?
1) Shoot one
2) Look scary
3) Run away

You shout and wave a branch.
Argh! It rains kicks and bites!
The monkeys scatter, shrieking.
(Press a key.)

The above text is an actual except from the game, where you can see me having a close shave with death after making good progress in the first few turns. Note how brief it is: not for the first time, the limitations of a literal 8-bit computer forced me to boil a game design down to its very essence, and get it done for a change. Endless frills can be added once a solid foundation is in place.

It’s otherwise exactly as I imagined.

You’re on a trail, implied by a (hidden) number that counts down the distance to safety. You get a chance to make progress towards the goal every turn when nothing else happens — and stuff happens often enough. Sometimes you get a chance to progress faster, but usually it’s an obstacle to overcome, or a way to gamble one resource for another. Yes, luck is a factor, but then you can say the same of any RPG out there.

Rest assured that strategy is still paramount.

Mind, that’s not very obvious right now. Overly terse messages imposed by limited screen space make it hard to be clear. Worse, the game as it stands is repetitive. But there are ways to get around the latter issue:

  • Add more encounters. Lost in the Jungle has seven; if it had seventy, you’d need several playthroughs to see all of them.
  • Make encounters dynamic. A little random variation in the text of some encounters would go a long way, even if it’s just cosmetic.
  • Give players more to do. Encounters leading to various minigames such as RPG combat, instead of simple choices, would be good for variety.

A delicate issue is lining up encounters. Making them completely random would make for a terrible game, but how else? The card deck model is an obvious alternative, but maybe too predictable after a while, if you always go through the whole deck before reshuffling. So I tried something different.

Specifically, Lost in the Jungle attaches a probability to each encounter, that starts at zero and increases by five percent when one of them isn’t chosen by the dice. But whenever it is chosen, its associated probability is divided by five. And they still come thick and fast, with few breaks. Clearly the game requires a higher proportion of “relaxed” encounters that allow the player to breathe and/or move closer to the end goal.

Other possibilities include a separate roll of the dice for whether to have an encounter in the first place, and attaching conditions to some or all of them so that the eligible set changes from turn to turn. If the premise of your game allows it, you could even let the player choose which of a few encounters to have next — think leads to follow in a detective game. But then it becomes all the more important for each of them to have an impact on how you must handle the others. That’s one of the big problems with Fallen London, the highly acclaimed MMO from Failbetter Games: individual storylets (their term for what I call encounters) feel not only disjoint for the most part but also like a grind. Failing a challenge doesn’t change how you approach the next one, whether it’s different or the same again. And that’s bad.

What happens here, in my opinion, is that Fallen London‘s biggest selling point also becomes its undoing: the game tracks dozens, if not hundreds of so-called qualities. They can make for an impressive, even overwhelming character sheet, but it’s no wonder that most of them end up single-purpose. By way of contrast, Lost in the Jungle only tracks six variables, half of them hidden, which limits decisions. The ideal amount of complexity would then be somewhere in the middle: half a dozen attributes, half a dozen derived scores, a dozen or so skills… in other words, on the level of a typical RPG.

And so we come full circle.

I won’t discuss how to weave a story throughout this kind of structure. It would be more urgent to point out that if you wanted to make your own, the aforementioned Twine is more than capable of handling a game like this with minimal coding. So is Ren’Py, though in the latter case you’ll be expected to add pictures and sound — something you might want anyway for added appeal. Either way, the tech level required is on par with that of interactive fiction, except with much more replay potential. So you can experiment with little risk on pretty much any game development platform. And ways to make bigger, richer games more easily are exactly what we need these days.

Creative Commons License
Encounter-based game design by Felix Pleşoianu is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

:, ,

1 Trackback or Pingback for this entry

Leave a Reply

Posts by date

June 2017
M T W T F S S
« May   Jul »
 1234
567891011
12131415161718
19202122232425
2627282930  

Posts by month