I've had a few tests of my cooperative game, Sympolis, over the last month or so and am now pretty comfortable with the overall shape of the game, but of course, the devil is in the detail and now I am trying to get that devil pinned down.
So here's the thing: if you make a competitive game, the players provide a lot of the balance; in a cooperative game, the game systems have to do all the work. I'll unpack that a bit. If I want a cooperative game to feel challenging to experienced players as well as newbies, the mechanisms, set-up parameters, etc. need to provide that challenge and have a way to scale and adapt. With a competitive game, an experienced player can usually get more challenge by playing against other experienced players.
 |
| One of my traditional blurry photos of a recent playtest of Sympolis. |
The last few playtests of Sympolis have all been won by the players fairly easily, with a period of perceived pressure mid-game, followed by that pressure easing off until we reached a relatively straightforward final round that felt more like a victory lap than a finale. The level of that feeling has reduced as I have tweaked settings, but it hasn't gone away. One of the focuses of the game is the pair of "wrath tracks" for each player, which indicates the level of trouble you are getting from the gods and the people of your city respectively. If either track gets too high, your city falls and everyone loses the game. In recent iterations, if the tracks go too low, you gain complications due to the people being too lazy and hubristic, or the gods getting jealous of the pampered people. It turns out that the "high wrath" situation is currently too easily managed, which reduces pressure far too much.
In essence, the game asks players to walk a tightrope, but that tightrope is more of a footbridge, with handrails that look insubstantial, but are actually pretty solid when you test them.
And that's what I'm trying to deal with now. My usual approach of making games is to just make general guesses about numbers, quantities, and so on, and then revise as I get a feeling for how a game plays out. I think that in this game, I may have got to the limit of how far I can go by doing that - or at least, further progress will be slowed massively unless I adapt.
So that's what I am attempting to do at the moment. I have a spreadsheet page counting up numbers from my main card data source, which is another page in the same document that I use as an input into a nanDECK script in order to build my card decks. This is giving me a decent view on the state of my card decks, but there are things that aren't easy to capture automatically, like figuring out the number of dice that are likely to be required to complete any given challenge card, or even group of cards.
I think that a potential approach would be to come up with a system to provide a rating for each challenge card, working initially on the expected number of dice needed to complete it, maybe boosting it a bit if there is some complicating factor like requiring precise numbers. In fact, I could extend this and rate the production use of each card also, maybe with production of a die giving 1 point, and provision of some die or card manipulation ability having probably some fraction of a point. Then I should be able to analyse the likely production rating at any given time and compare it with the likely challenge rating on a given turn. Once I have that information I will be better placed to tweak numbers to get the game to the challenge level I am looking for.
