Skip to Content

How to present aspects of a game, component wise

2 replies [Last post]
Anonymous

In games, mechanics that use some sort of resource or values you have to administrate somehow are very common.

Component heavy games has much less chance at hitting tha market, because of the extra cost included. Publishers want to take the less risk possible, and an invidual person rarely has the resources to provide components for a larger print run by themselves.

But there are situation when simplifing a component heavy element hinders the gameplay and thus reduces the fun. A designer has to hit the best middle ground whenever possible.

I wan't to start a discusson about the different methods a designer can use to represent accumulatable values and other things.

These examples are from games I know, or currently designing.

1. Representing the levels of a 'tech tree'

The player use resources to gather a kind of score. When that score exceeds a given value, the player has completed a level, his score is reduced to zero.

a.) you could use cards, that a player recieves when completes a level
b.) you could use a track and a pawn

2. Handling large amount of resources

a.) counters, tokens

Obvious, but expensive, if you have to include over 200 bits just for this. You can make this less by introducing change into the system, but in my experience change could become an annoyance, when a player requires to give away little amounts of money to many seperate places

b.) track and pawn

Very, very cheap, but has biig drawbacks, like:

easy to cheat (oops, it fell over. now where was it? here? or here?)
accidents may happen (oops, it fell over. now where was it?)
perhaps a bit too dry

c.) cards

perhaps the best choice. It acts as counters but large enough to make changes easy, and has greater possibilites, since you can implement other mechanics due to the information you can include on each card

drawbacks: wear, vulnerable

I'd like to hear what to you think about this.

Hedge-o-Matic
Hedge-o-Matic's picture
Offline
Joined: 07/30/2008
How to present aspects of a game, component wise

I, too find getting the balance of components one of the more interesting parts of design. Since I've been doing mostly abstracts for the past two years, this wasn't really a problem. But now that I'm designing more themed boardgames again, I find I'm struggling with these same age-old questions.

Let me use my current project, Tel Dan, as an example. First, I was originally trying to conserve componants by using resource token cubes for toher things. First off, there were limited numbers of each: a dozen white, gray, or black cubes. A very limited bank that players could attempt to strangle, if they desired. But City Watch pieces were represented by white tokens, and Criminals were represented by black pieces. Thus, if you had a lot of crime, the most valuable commodity, the black resource tokens, would become less available. Meanwhile, in order to clean up the town, you need to lower the amount of white tokens available, since they represent the Watch. an interesting game mechanic that also conserves bits.

As for victory points, I originally have three tracks of different lengths, representing the three ways to win. To mark these paths, players must use the same flags they use to reserve use of new buildings for themselves. since they only have threee of these flags, players will likely start with one track and stick with it. If they have to begina second out of desperation, they'll sacrifice a flag from the board to do it. This is another dual-use mechanism that impacts play.

I considered using straight VPs, with each step on a given track giving a set number of VPs instead, but this eliminates the dual use, as well as making mixed-track victories have no downsides, since the flags wouldn't be used. the game would devolve to whatever was expedient to win. But I could later introduce other methods of getting irregular VP mounts, which would increase flexability.

Then there's the personal stash of building supplies every player has. In total, with the common pool, there ins't enough space on the board for all these buildings, so why include it? These wooden cubes will increase production cost as well as shipping weight. But the players control just enough to offset the ease with which they could squander the common resources as soon as they were ahead. The game has just enough pieces for the game to run smoothly, and not any more.

Still, it's a heavy one. If it sees distribution, bits-lovers will like it, I think. Of course, each bit is a simple wooden shape, which is an aethetic choice on my part which has handy cost-saving features!

Still, I fully agree that the choice of bits is important in all phases of play, and sometimes a redesign of even one bit is a headache.

As an example of this, one of the standard pieces is a sort of wooden dome. The idea was that this piece could be placed dome-side up, or flat-side up, serving two functions with the same piece. but in practice, the whisper of doubt that using domes would be a problem turned out to be true. Nothing will sit nicely on those domes, obviously. I'm racking my brains to find a piece that seves the same function, but is flat, and not a simple disc. Bit troubles! Gotta love 'em!

lordpog
Offline
Joined: 12/31/1969
How to present aspects of a game, component wise

trapezium?

Syndicate content


forum | by Dr. Radut