The Forge Reference Project

 

Topic: [Illumination!] Session closure procedure problems
Started by: Filip Luszczyk
Started on: 1/6/2009
Board: Playtesting


On 1/6/2009 at 7:05pm, Filip Luszczyk wrote:
[Illumination!] Session closure procedure problems

I'm in the middle of writing the new playtest version of my game. I'm stuck.

There's this "what if" thing that bugs me. It's something that cropped up in my attempt to fix a problem identified in the recent playtest. This issue didn't come up in an actual playtest yet, but it's painfully obvious to me that it's there and it's going to require a solution sooner or later.

It's a problem of how the otherwise ideal session closure procedure affects the optimal strategy. I've spent the last few weeks trying to work it out, but neither I nor my immediate feedback group is able to produce a good solution at this point.

The game uses a board, cards and tokens. Players place cards on the board and move them around like game pieces. The content and alignment of cards define the characters' enviroment and circumstances, and also determine available interaction options. Interaction is fueled by tokens, which then move from pool to pool, depending on the specific procedure invoked. There's a single communal pool and two private pools per player (different pools fuel different interactions), and each pool can contain a mix of three types of tokens (these affect the scale of the interaction and its consequences). Interaction shifts the alignment of cards on the board and the distribution of tokens, changing both the in-fiction and strategic circumstances.

So, basically there are two resources: cards and tokens. Each player starts with a single card on the board, adding and losing cards throughout the game. As for the tokens, there's a fixed number of them in the economy, distributed among various pools. Before you are able to achieve your session-scale in-fiction goals, you need to go through a period of build-up, accumulating cards and tokens, trying to align cards on the board the right way and so on. My assumption is that any legal strategy is a perfectly allowed strategy.

Now, in the current version of the rules, at the end of the session the board and pools reset. Players discard all their cards but the starting one, because various design factors require the cards to be periodically discarded and this is the most convenient moment to do that. All tokens go back to the communal pool, because this prevents hoarding resources and just seems right given that with the cards discarded, the next session is a fresh start.

All in all, it's very practical to reset resources at the end of the session. That way, every player can gather the toys and go home with no need for long-term bookkeeping. I did consider doing it with no reset, but such a solution does not appeal to me and I'd prefer to avoid it. Unless the group plays using a Vassal module*, which makes it easy to save the state of the game, it would require everyone to keep track of card placement and spend some time counting the tokens of each type in a couple of pools. Seems like a rather bothersome perspective to me.

And here's my issue. Resetting resources actually adds another, unwanted resource to the equation: TIME.

This will mess the strategy up. The optimal strategy will have to include time management. The closure of the session will be a critical point, and it will force the players to rush their build-up phase, and rushing it will hurt the entire experience. Other than that, there will be problems with players asking to play "just ten minutes more", while the rest of the group wants to wrap things up. There will be problems with players who want to close the session to block the plans of the others. There will be problems with those who just have to finish, because the last train won't wait for them. There will be all sorts of problems that I don't want. They might not arise every time or in every group, but the game will be prone to them. And if a game is prone to a problem, the problem will arise.

Well, I could instruct the players not to rush things despite the clock ticking. It certainly would be some solution, but it feels sort of lame to me. Especially that I make no similar assumptions when it comes to the management of other resources.

Is there any other way I can have the resetting of resources with the closure of the session, but with no addition of the unwanted time resource and also no need to "save the state of the game"?

I'm aware that going the bookkeeping route is the easiest solution, but I'd really prefer to avoid it, if at all possible.

* The Vassal module might as well be the default, but I want the game to be fully playable with no computer aids as well.

Message 27418#259054

Previous & subsequent topics...
...started by Filip Luszczyk
...in which Filip Luszczyk participated
...in Playtesting
...including keyword:

 (leave blank for none)
...from around 1/6/2009




On 1/14/2009 at 4:07am, Noon wrote:
Re: [Illumination!] Session closure procedure problems

Hi Filip,

How long is a session? It isn't a fixed time span?

In other games you've played with your group, did players enter into time management?

Can they actually win this game? I'm rather sceptical (read: incredibly sceptical) there is an optimal strategy to acheive a win status, when there is no win status.

And if they would define their own win statuses and rush to achieve them, then that seems to be how they play. Perhaps they don't care for an unrushed game, to begin with?

Message 27418#259359

Previous & subsequent topics...
...started by Noon
...in which Noon participated
...in Playtesting
...including keyword:

 (leave blank for none)
...from around 1/14/2009




On 1/15/2009 at 2:25am, Filip Luszczyk wrote:
RE: Re: [Illumination!] Session closure procedure problems

There is no fixed time span for a session, and there is no fixed number of sessions.

In other games I've played with my group, there was occasionally some mild time management (of the "let's cut the crap here and move to the next scene, there's still just enough time left to finish it this session"). However, I can't remember playing under this sort of conditions, i.e. a mechanical restart after each session in a multi-session game.

The closest is probably PTA, where the resetting of Budget, Audience Pool and Trait uses sometimes affected our mechanical choices, especially near the expected end of the session. However, it was largely inconsequential there, in the long run (i.e. we could still request the scenes we wanted to the next time, and our mechanical effectiveness hardly mattered, as we usually negotiated stakes till a win-win situation was reached).

As for the win condition, there is no default one, and the game is intended for sandbox-ish play. The players need to decide on their own objectives within the fiction, consequently, and it's very likely that achieving a given objective would require triggering certain conditions mechanically. Now, the real "juice" of the game comes from interacting with the game on the level of specific instances of resolution, and broader objectives are secondary to that. There are certain aesthetic considerations here, and I expect too much rush to be destructive in this regard. So basically, not caring for an unrushed game is essentially not caring for the "juice", i.e. the main reason to play the game in the first place.

I expect the problem to start when the players have to choose between the "juice" and those secondary session-scale goals they might have. So perhaps eliminating those goals alltogether could be the way to solve the problem.

But then, now that I think about it, it's not only about player goals. The in-fiction results of mechanical options that require the build-up also fuel the non-mechanical aspects of resolution, on a campaign scale. It's convenient that those are tied to achieving potential player-dependent goals, as it prompts players to activate them. With the resetting of tokens, those effects won't occur reliably, as whether the players strive to accumulate the right tokens or not, there might often not be enough time for the accumulation cycle to complete.

Hmm, unless Dissonance (the single private pool responsible for this accumulation) does not reset, but the remaining pools do so. This would require some bookkeeping, but still considerably less than with a full "game save". There would still be a problem with the discarding of cards, though. While I already have an idea for speeding up cards recovery, starting a session with tokens in Dissonance and no cards on the board makes all players particularly vulnerable to potentially unwanted Dissonance effects. This means that near the end of the session there could be a rush to bleed off Dissonance anyway, or the beginning of a session could suffer from a fortification panic.

I'm seriously wondering whether I have any options for mitigating time management at all, without rewriting the entire game one more time. If no, then the "save game" option is probably the more sensible way to go.

Message 27418#259388

Previous & subsequent topics...
...started by Filip Luszczyk
...in which Filip Luszczyk participated
...in Playtesting
...including keyword:

 (leave blank for none)
...from around 1/15/2009




On 2/6/2009 at 1:17am, Spooky Fanboy wrote:
RE: Re: [Illumination!] Session closure procedure problems

How have you solved this dilemma, if indeed you have?

Message 27418#260126

Previous & subsequent topics...
...started by Spooky Fanboy
...in which Spooky Fanboy participated
...in Playtesting
...including keyword:

 (leave blank for none)
...from around 2/6/2009




On 2/10/2009 at 12:31am, JoyWriter wrote:
RE: Re: [Illumination!] Session closure procedure problems

Even if you can't get "ending time" out of the strategic setup, which may be inevitable given the build-up mechanics you seem to have, you can still balance it by adding disadvantages to playing for longer to offset the advantages. Now how possible this is will depend on how universal an advantage it is to keep going; if it only effects a few corner cases, then you may be able to find a corrective rule for that situation, but as often happens, that might lead to unintended consequences of it's own. Well you never know unless you try!

If it does effect a large swathe of different goals, then you may have to accept it as a feature of this game, and not use it near the end of a session; setting a set time scale with an error margin, and shifting to some lighter game before people leave.

Message 27418#260222

Previous & subsequent topics...
...started by JoyWriter
...in which JoyWriter participated
...in Playtesting
...including keyword:

 (leave blank for none)
...from around 2/10/2009




On 2/10/2009 at 2:40am, Filip Luszczyk wrote:
RE: Re: [Illumination!] Session closure procedure problems

How have you solved this dilemma, if indeed you have?


I think I solved it just yesterday, or at least I've made a very concrete step towards solving it.

Essentially, I divorced most of those secondary session-scale goals and long-term feedback stuff from non-immediate mechanical choices.

There was that class of medium-term resolution/fallout-type actions that required the build-up of Dissonance. I removed it, and attached some of the effects to easily triggered procedures, making others automatic in certain time-independent circumstances. Dissonance has an ongoing impact on play, but only a single option (changing the board/human consciousness/the world at large) requires its build-up now. This doesn't eliminate the time factor entirely, but it's much more easily manageable now, and I can adjust the required amount of Dissonance so that it was always realistically achievable to trigger that option at least once per, say, three hours of play with no need for excessive rush.

Removing the medium-term resolution actions, at the same time, streamlines the strategy greatly, leaving only essential mechanical choices there. There were some issues with too large number of them in the last version we playtested anyway, and I reduced the number from over ten to six - but now, I found a potentially painless way to get rid of a whole segment of rules (about 1/3 of the previous "source code" text). Also, there was this whole associated layer of potential strategy that we just didn't tap into in the last playtest. It might have been due to the learning curve involved, but really, I'm no longer convinced the game needed it in the first place. Its removal also reduces the competitive aspect, which might additionally help in mitigating those time factor issues.

Playtesting will tell how well those new solutions work, but at the very least, I think I reduced the number of potentially troublesome areas to that single world changing thing.

(As a side note, I find it interesting that I keep making such development leaps in roughly 2-3 months intervals, and usually after spending some time working on another, completely unrelated project.)

Message 27418#260226

Previous & subsequent topics...
...started by Filip Luszczyk
...in which Filip Luszczyk participated
...in Playtesting
...including keyword:

 (leave blank for none)
...from around 2/10/2009