# When to Abstract

5 replies [Last post]
Kreitler
Offline
Joined: 12/31/1969

[Note: This is actually a continuation of a thread that disappeared during the "Great Forum Hack of '05".]

When designing games that simulate "real world" events, we must choose how far to abstract our mechanics from reality. For example, in Tikal, you restore ruins by placing workers on the site. The more workers you place, the more you can restore. This is a fairly "realistic" (i.e., concrete) simulation. As another example, consider Settlers, in which you generate resources by a pure die role. This is fairly abstract.

My question to the community is this: when do you choose to abstract a mechanic as opposed to going "purely concrete"? I'm not so much looking for "always do it when condition 'a' occurs" as I am for anecdotes: "I was making game 'x' and encountered problem 'y', which I eliminated with abstraction 'z'.

I'll go first in my next post.

K.

Kreitler
Offline
Joined: 12/31/1969
Re: When to Abstract

Kreitler wrote:
My question to the community is this: when do you choose to abstract a mechanic as opposed to going "purely concrete"? I'm not so much looking for "always do it when condition 'a' occurs" as I am for anecdotes: "I was making game 'x' and encountered problem 'y', which I eliminated with abstraction 'z'.

Recently, Challengers and I discussed a board version of a computerized space-conquest game in which you ordered fleets to conquer distant worlds. We tossed around ways to record the destination of fleets and the number of turns they traveled. Most of the ideas involved straight-up record keeping:

1) Record the size of a fleet.
2) Record its destination.
3) Compute the number of turns to reach the destination.
4) Write all this down.
5) When the fleet arrives, reveal the information.

When a fleet arrived at a planet, it would fight any existing fleets and the winner would occupy the world.

This was a very concrete simulation.

I liked the easy-to-understand rules, but I wanted to seriously streamline the record keeping process. I also wanted to showcase the game's central mechanic: a dicing system that would allow multiple fleets at a single location to simultaneously fight each other.

I struggled for weeks with these constraints. Finally, this week, a light bulb went on: since simultaneous combat is the star of the show, my orders-and-flight mechanics should encourage such encounters. I thought of a way to abstract the space travel into a fuel bidding" system that would allow players to arrive at most locations within 1 or two turns. This would tend to result in more simultaneous arrivals. It also eliminated the need for complex record keeping.

So, in my case, the question "When should you abstract a game system," has two answers:
1) When the concrete system introduces undesirable complexity,
and
2) When the concrete system has undesirable side-effects (in my case, discourages use of an interesting mechanic).

K.

Scurra
Offline
Joined: 09/11/2008
Re: When to Abstract

Kreitler wrote:
For example, in Tikal, you restore ruins by placing workers on the site. The more workers you place, the more you can restore. This is a fairly "realistic" (i.e., concrete) simulation.

Although (as Jeff would also point out :-), the fact that the player decides where the ruins are actually going to be renders such a "concrete" element entirely laughable...

Quote:
My question to the community is this: when do you choose to abstract a mechanic as opposed to going "purely concrete"? I'm not so much looking for "always do it when condition 'a' occurs" as I am for anecdotes: "I was making game 'x' and encountered problem 'y', which I eliminated with abstraction 'z'.

Well, to preempt Seth bringing it up, let me cite the combat mechanic in All for One. This is a game themed around the Three Musketeers, so most players are expecting some sort of sword-fighting mechanism (despite the fact that in the books there aren't very many at all - I blame the movies!)
Now, I'd already established a basic model for the game which was that players would have cards with missions on them, and by having multiple cards they always had a choice of things to do. The logical extension was to add a card-driven sword-fighting mechanic to the game so that the cards could do "double-duty".
I tried a number of approaches in which two players used cards in a more complex RPS system*. There was certainly a good concrete element to all of them (players would cut - parry - riposte - swing - hit etc.) but it churned through cards too quickly and, crucially, only involved two of the players.
Once Seth joined the project, we started experimenting with much more group-based systems. Ultimately, we have ended up with an extremely abstract mechanic (that feels more like "voting" for the winner), but still contains enough of the thematic elements of sword-fighting that it's probably OK.

I guess the point of this rambling is to say that you can get so attached to something that you spend more time than is reasonable to get it working within your existing framework. Whether or not it is "concrete" or "abstract" sometimes doesn't enter into it!

(*not exactly an original approach, but the mechanic has subsequently led to two entirely different games, so at least the work doesn't feel wasted :-)

Kreitler
Offline
Joined: 12/31/1969
Re: When to Abstract

Scurra wrote:
I guess the point of this rambling is to say that you can get so attached to something that you spend more time than is reasonable to get it working within your existing framework. Whether or not it is "concrete" or "abstract" sometimes doesn't enter into it!

Yes, excellent point -- and an excellent example as well.

So let me rephrase the question in light of it, for anyone else who cares to reply:

"What are some examples of 'letting go' of a mechanic -- what made you realize it was time to say 'uncle' and how did what you ended up with fix your problem?"

K.

Rick-Holzgrafe
Offline
Joined: 07/22/2008
When to Abstract

I created a two-player card game a couple of years ago, Thrust and Parry, which simulates an Olympic foil-fencing match. To score a hit, you must usually play a footwork card to get close to your opponent along with a bladework card to launch an attack. I had a "turtling" problem: players would reach a state where neither could get close enough to attack in the current turn. But if either player came closer without attacking, the opponent would then be able to counter-attack in his next turn.

I spent weeks adjusting the deck, looking for a magic balance of footwork cards to solve the problem, but it couldn't be solved that way. Finally I saw the light, and allowed each player a free step forward at the start of his turn instead of requiring that all motion come from footwork cards. Players could smoothly and quickly step forward to attack from nearly any distance. The urge to "turtle" vanished, and play became very lively.

If you want a little more detail, see the rules and especially the design discussion.

Challengers
Offline
Joined: 12/31/1969
When to Abstract

The abstraction point = the distraction point.

I developed a gem-collecting game that involved a global Exchange for the players to sell and trade their gems. Initially, I set out to faithfully reproduce a commodities market mechanic, with charts and event-driven market changes. The target audience for this game, my kids, quickly became bored with it (except for my oldest, who is weird like me, and who kept suggesting even more detail).

So, I went back to the drawing board, asking them what part they liked best. While they agreed that the market was useful, they really liked the opportunity to make a killing in the market (we are all veterans of the commercial game, Bull Market). This caused me to throw out the realism and devise a simplistic exchange that still managed to capture the flavor of rare gems having a higher intrinsic value than common gems.
This mechanic is so simple, I'll post it here:
Gold is the rarest gem and is represented in the Gem Exchange by four yellow six-sided dice.
Emeralds are next, with three green dice.
Sapphires are next, with two blue dice.
Rubies are most common, with one red die.

At the beginning of the game, all ten dice are rolled. This sets the opening price for each gem. The maximum value of Gold, therefore, is 24 and the maximum value of rubies is 6.

There are only four events that trigger adjustments in one or more of the ten dice:

a BEAR market event causes every 6 to be rerolled;
a BULL market affects all 1's;
a market CORRECTION affects all 4's;
a RUN on the market allows a player to dump a minimum of 1,000 gems of one type at once, causing downward pressure on the price.
Like real commodities, sometimes you want to hold a lot of a particular gem in the hopes that its price will rise. Other times, you'll need to dump as many as you can to "get out of the market" and into cash.
Success depends on players' ability to "buy low" and sell high.

All without charts, to boot.

Mitch

[/]