For example, in my first published title, Terra Prime, I began with a "great" idea for a supply/demand mechanism for the value of resources you deliver. Based on Power Grid's fuel market, you would get paid more for delivering Bluium if there hadn't been any delivered yet than you would if there were already some Bluium sitting there on the ships, ready to send back to Earth. Every once in a while, the ships would take off, and the resources on them would clear off, resetting the demand (and therefore the price). Each resource was supposed to have a different curve - maybe Yellium was worth 7 the first time it's delivered, then 4, then 1... so it's super valuable, but goes down fast. On the contrary, maybe Bluium would range from 5 down to 3, and be a lot more steady:
In the end I (thankfully) decided to replace the whole thing with a Demand Tile mechanism. Much more simply, each resource had a price, and tiles indicated how many were required. Once all the blue spaces were filled, the demand for Bluium dries up, no more can be delivered. As soon as one of the tiles fills up, it goes away and a new one comes up, which may bring back some demand for Bluium.
This worked a LOT better, and I'm happy that's how I ended up going in that game.
The point of that story is to show how a major mechanism that I really liked ended up changing because it wasn't right for the game. Recently, that dynamic has showed up again on one of my current active designs: Apotheosis.
One of the instigating ideas for Apotheosis was that your workers would level up when played, like the cards in Solforge. The crux of the game was intended to be whether you play out all of your workers before recalling, and leveling up your entire workforce evenly, versus playing just a couple of workers then recalling them and playing them again, and ending up with a few high level workers while the rest remain at low level. That idea being the whole point, survived the first several revisions, and many playtests. However, as of last week, I tried a new version -- instead of leveling up every worker you have played when you recall them, we said you could only level up one worker.
I was hesitant to try this, but I was hopeful it would fix certain issues I was having with the game. As we began the first game with that rule, I missed being able to play an extra worker before recalling in order to level them up, but pretty quickly I could see how certain aspects of the game seemed to be tighter and work better. All told, you're still choosing whether to recall early to level more often, or play more workers first for their effects.
One concern with only leveling one worker at a time was that it slowed things down, but that's just a matter of balancing costs, and could be easily fixed. However, in an effort to try something in between "level one worker" and "level all workers," we tried something that amounted to "level some workers." I had expected that to be better, with some of the benefits of the restricted leveling, and some of the benefits of the original idea. But in practice I found that it didn't really work as well, and it became clear that just leveling once per recall (and maybe a few special rewards for things could get you an extra level-up) is the way to go.
So there you go -- once again I've had to "kill a darling," so to speak, and remove or significantly change an instigating mechanism for a game.
As a side note on this topic, my friend Gil Hova (of Formal Ferret games) has a particularly aggressive auction mechanism from an old, unpublished game of his called Wag The Wolf (one which I thought was good!) that he keeps designing games around. He used it in Battle Merchants, but in the end cut the mechanism. He used it again in The Networks, and again cut the mechanism before the game was finished. And I believe he started his latest game, High Rise, with that mechanism, and eventually cut it from that game too!
No hay comentarios:
Publicar un comentario