I’m up to prototype #6 for Scandinavia and the World and one of them has lead me into some interesting design terrain that I’d not been thinking about explicitly before: If a game relies on limited information, how should that information be controlled? What are the minimums and maximums of information that it is okay to release? What is the relative value of obtaining information to the player?
The problems that I’m running in to can all be related back to the goal of ensuring that a player can make interesting decisions. In order to do that they need three things:
- Multiple options…
- …which have a impact on the outcome of the game…
- …which can be somewhat predicted by the player.
That third point is critical. If the player can’t predict the results of their choices at all then the choice isn’t interesting and they’ll take it randomly. If they can predict it completely then the choice isn’t interesting and they’ll take it automatically. The sweet spot lies in the middle ground, where a player will be able to exercise their judgement to try to suss out the best option.
Bringing it back to hidden information, if I have a game in which a lot is obfuscated and players can expend actions or resources in order to obtain more information, then the band of information that they might have is quite wide. That makes it tougher to satisfy the third criteria, because ideally the entire band will lie within the area of that sweet spot.
This is all rather abstract, let’s put it in the context of an existing game: Hanabi. In that game you are trying to play cards in the correct order, but the cards that you have is hidden information (to you at least). On your turn you have the option to either have a chance of furthering your goal (by playing a card) or to increase the odds of future attempts to further your goal being successful (by revealing hidden information to another player).
If perfect information were possible Hanabi would quickly become boring. Imagine a version of the game with no limitation on the number of hints that could be given out – players would simply provide information for several passes around the table and then make perfect plays. Dull!
If no information were possible it’d be equally rubbish. Imagine a version of the game in which hint tokens could not be refreshed. Owing to the ratio’s of cards in the deck the vast majority of plays would be made completely randomly, with the outcome depending on sheer chance rather than the player’s choices. Dull and frustrating.
At the moment I feel like #5 (Unlike my previous prototypes the SatW prototypes just have numbers, I’m finding it less confusing since some of them occupy a similar thematic space) has a lot of potential but isn’t reaching it because I need to get a better grip on information rationing. It feels like a Hanabi without a working hint mechanic: Disappointing to play because it feels unfulfilling but also gives the impression that it’s just a couple of small tweaks away from being something much better than it is now.
So, how does a designer go about understanding something like this? I’ve no idea if I’m typical, but this is what I’m up to at the moment:
An obvious step is to play more games that operate in this domain. If you can think of any games that are primarily about information, please let me know in the comments! I don’t love this approach because I always end up feeling like I can’t use ideas I see in other games this way without feeling like I’m cheating, but it’s good for building general understanding.
Another is to study simple scenarios. For instance imagine a game in which cards numbered 1-10 are placed face down on the table. On your turn you can either take a card or look at a card. Once you take a card you’re done. Once everyone’s done the highest score wins. Your score is the value on your card minus the number of times you decided to peek.
Intuitively what’s the optimal number of peeks? Mathematically what is it? Why is there a difference and how big is it? Does the decision to look or take feel interesting? Could it be made to feel interesting if combined with another mechanic? A deep understanding of a simple system can help to develop intuition about how to tune a more complex one.
Also I’m continuing to develop the prototype and play games with it. Playtesting is always the magic bullet of game design and no game is complete without a huge amount of it, but I’m wary of using it too heavily in this way. If I tinker with numbers and rules until I get something that works in practice, I don’t really have a deep understanding of why it works.
That could be dangerous in a project in which the IP owner has indicated that they’d like their fans to be able to submit card ideas and similar. I’ve run Kickstarters with a “design a thingy” level before, so I know that it’s really important to be able to guide that process. The essence of the backer’s idea must be preserved, but tempered such that it contributes positively to the overall play experience. That tempering process relies on an understanding of “I implemented this system in this way for this reason” rather than “I monkeyed with the numbers until people were smiling”.
So yeah, playtesting is part of the toolkit, but it needs to be a very specific type based on different versions of the game generated to test different hypothesise about information rationing rather than simply tuning towards good feedback.
Hopefully that gives a bit of an insight into how I approach a design problem when I find one, I’ll try to follow up on this post in a month or so with the conclusions I reach about this aspect of design. Also whether #5 winds up being developed into a published game or whether one of the other ideas beats it out and how this process interacted with that decision.
Until next time 🙂