The Breadboard Metaphor

The dungeon is a breadboard all wired up. Plug a monster in here and a player in there, and see what signals they can send each other: if they’re adjacent, they can talk about melee; if they’re in bowshot they can talk about arrows; if they’re in disjoint rooms they can, at best, talk about telepathy. (This can be taken as another way of looking at whitespace reasoning.)

Two kinds of problems succumb to this view. It’s a really practical way to understand how players will experience a new game component, since you can run down a mental list of relevant arrangements and work out which ones are covered; you can also identify arrangements that nothing really interacts with in an interesting way. But it can also help you settle on an architecture that’s appropriate for your game design, and since it does that in a way that lines up with your game design, it’s really good news.

The breadboard clearly doesn’t contribute anything (formally) that thinking about graphs won’t. But it can help limit some of the flexibility of nodes and edges and make it a little more obvious what kinds of additions you can make to your game. You can either add new things that communicate or new edges for them to communicate over. Most of your edges are spatial, but you’ll find it really useful to think of stats and resources as channels of communication, too; which components in your game communicate via hp? Which communicate via the burning status? These aren’t dependent on the shape of the dungeon for their wiring, although the ability to reach into them clearly depends on it (losing hp through melee communicated over adjacency, or being set on fire by standing in a burning cell.)

One failure of the metaphor is that we can simultaneously think of our mobs as the things doing the communication and as messages in their own right, an absurdity in the physical world. No matter. Where practice diverges from the image of a breadboard we can calmly point it out and get on with thinking about our designs.

Resources (channels without location)

If you have lots of special purpose channels, it gets to be pretty easy for players to figure out what’s going to happen in the long term. You won’t see them making lots of interesting tradeoffs. A general purpose channel, like the money in your wallet or hp you can spend in battle, is subject to a kind of interference: once used for one exchange it’s unavailable for another. Instead of thinking about resources concretely and spread across time, then, you can think of them statically in terms of what they’re wired up to; what feeds into the resource, what draws from it, what’s limited by it? Most important, why is the player going to have fun managing it?

It’s often useful to look at one resource as a buffer against overruns in another. I’m particularly fond of treating hp this way; instead of seeing resources as a way of saving health, health is a way of saving resources for later. The player’s job is to cut corners as tight as possible, but no tighter, by engaging in melee whenever health can be spared. The core game, though, consists in tactical positioning and the expenditure of more specific resources.

(Channels meant as buffers fail when the player can successfully fill them forever. An absolute cap, like 100% health, a full stomach, or a packed bag, is the simplest fix. A soft cap, like decay, is a little more complicated for design and play alike. Balancing it only against the availability of a resource in the world is, in all cases, the most difficult and the most elegant protection. Games with money traditionally have too much of it, inviting this mode of failure.)

Brogue’s food clock converts food into health (through regeneration), uses health as a buffer against resource use, and puts food in the inventory along side other resources to protect against a kind of hoarding and misinterpretation of the game’s intent. These channels of communication then interact with spatial nodes by, for instance, the positioning of food in the dungeon (which can be seen through fov, detected indirectly by monster movement with telepathy, and so forth.)

A dataflow implementation

The other lovely application of the breadboard metaphor (as limited as it is) is in the way we structure our code. The general notion is that our game components (player, monsters, dungeon features, and items) merely ‘register’ themselves in the locations that interest them, and are otherwise positionless entities. A more thorough treatment will have to wait for a dedicated technical post.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">