Dice, spinners, playing cards, and board games

Apr 29, 2009

“Imitating paper on a computer screen is like tearing the wings off a 747 and using it as a bus on the highway.”

-Ted Nelson

There’s a pervading notion in videogame design courses, lectures, books, conference workshops, and online discussion forums that the best way to understand and plan videogame design is through a deep analysis of dice, spinners, playing cards, board games, and the like.

If our daytime work was with Milton Bradley or Parker Brothers, this would be a worthwhile use of time. For the more than 40,000 of us in the USA working on real-time electronic videogames, I think that most of the analysis in analog space is an inefficient way of highlighting some vague commonalities at best, and more often than not, a dangerously sneaky way to get sidetracked.

The thinking is that videogames are games, those other things are games, so the study of them must be relevant. The problem is that videogames are not a subset of paper and board games, it’s the other way around. With hundreds of millions of calculations happening per second, we can fully simulate paper and board games on a computer; with a hand-manageable amount of limited, visible states and a few state changes every few seconds, we absolutely, positively, cannot meaningfully simulate real-time videogames off a computer.

Nothing about the paper model side of the field relates to what worked about Pong, Warlords, Asteroids, Pac-Man, Tetris, Bubble Bobble, Donkey Kong, Castlevania, Blaster Master, Paperboy, Mega Man, Ninja Gaiden, F-Zero, Goldeneye 64, Quake, Resident Evil, Wipeout XL, Street Fighter 2, Snood, Soul Calibur, Smash Brothers, or Metal Gear Solid. For electronic dungeons and dragons games, or electronic versions of chess, or electronic versions of poker, obviously those paper models and topics apply, insofar as they are the directly emulated material.

That random numbers are involved does not mean dice and spinners are useful, unless your game runs at 1 frame per 30 seconds, because the hundreds of random numbers come out in the wash compared to factors that challenge cognitive perception and reaction, such as rapidly changing spatial relationships, event timing in relation to on-screen cues, learning patterns, and rapidly adapting heuristic judgment. And unless you’re playing a turn-based multiplayer game where you’re all in the same room, the dominant factor from Poker and many paper prototypes – reading tells – goes out the window.

We can learn things from other mediums, sure. We can compare some aspects of board game playing, or a game of basketball, to what goes on in a videogame. I can also make a comparison to washing dishes, cutting hair, rolling down a hill, running a company, picking a movie at the theater, or doing the Macarana. That does not mean that we should devote every page of every game design book, every hour of class lecture, or every workshop at every conference to these things which have a few relevant parallels to videogame design and playing.

Don’t get me wrong – paper is useful. So are whiteboards. Sketching is useful. A programmer is wise to figure out certain things on paper before writing code, and a designer is likewise wise to do some sketching before fiddling around with the level editor. There is a world of difference though between using paper to sketch spaces while considering line-of-sight and navigability vs. using paper to play out elaborately structured rule sets in search of understanding a videogame’s “core compulsions.”

How it behaves on-device, how everything fits together, is the relevant space. And just as porting a videogame designed for a TV console videogame system to a handheld device or vice-versa may require a total redesign to match the input and hardware constraints to meet platform expectations, you can bet there’s a tremendous amount of redesign work to port to/from “hardware” with no processor clock, unlimited display space, fully articulated speed/bodily input, and “RAM” that’s limited to a spinner’s current position, a boardgame’s piece layout, and a few piles of cards. You wind up porting a gameplay scenario that was designed to work for a narrowly constrained 500-year-old game system.

I’ve heard arguments from academics that this is what they resort to for game design classes because the designers can’t program. However it will help electronic media designers tremendously if they can pick up some simple programming, even if they’re writing unshippably hacky code, just to gain a conceptual understanding of how to work with-the-grain of a logic-driven machine to communicate via interactivity. Secondly, if someone absolutely, positively must have a programming-free videogame design assignment, consider trying a project to:

  1. Make playable content with a level editor for an existing engine, justifying their layout decisions to the group or instructor in a formal crit
  2. Tune unit stats in an RTS game to balance teams where different armies have different unit types available, explaining their considerations, methods, and guiding principles used to arrive at a solution
  3. Give them a non-layout mission/level to design, such as planning the order and pattern of incoming ships in a side-view shooter, or setting shape probability and fall speed for multiple levels in an action puzzle game
  4. Give them a multiplayer mod for a deathmatch game that has the weapons deliberately unbalanced; challenge them to adjust the variables related to weapons and projectiles until none of the weapons go neglected
  5. Prepare a study of trends in videogame characters, settings, and other reoccuring themes in videogame history (ex. #101 – Zombies and Robots are indifferent to death, unaffected by minor injury, tireless, expected to make stupid decisions, and morally unobjectionable to slaughter)
  6. Analyze the subtle differences in timing, affordance, interface, interactions, and presentation between successful and unsuccessful games in the same genre; have them summarize this analysis into a list of concrete, actionable suggestions on how the less successful games in the genre could “feel” better to play with just a little attention to the right areas

Exercises like this will do a poor job of preparing them to design new board games, but is there even still much of an industry of people trying to dethrone Chess, Go, or Monopoly? Very few people have those sort of projects in mind when they speak of becoming a game designer.

I’ve seen massive commercial projects and student indie projects alike wallow uselessly in paper prototyping for months, nearly a year in at least one case, designing board and card games to “discover the mechanics”, only to start from scratch the second they switched to digital, because none of that learning was relevant. Companies lose money over this. People lose jobs over this. Students lose hope in their dreams over this. If this was just people arguing about outdated philosophies it’d be one thing, but it’s potentially ruining tomorrow’s games, hurting today’s companies, and derailing yesterday’s careers.

I am not saying that real-time videogames cannot be designed by starting with paper prototypes and principles derived from analyzing board/paper/card games. I am saying that doing so is like trying to design a military jet fighter based on the how a paper airplane works. I am saying that videogames resulting from that process will, generally speaking, not come out as well, except to whatever degree they get a complete overhaul after being adapted to a playable electronic platform.

(Originally posted as GameDevLessons.com Vol. 1 Sec. 4)

Este artículo está disponible en español. Traducción por cortesía de Andrés de Pedro.

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!

One Comment

  1. […] Vol 1 Spx – Dice, Spinners, Cards, and Board Games […]

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.