Writing for Seltani: Aspel Post-mortem Part 2

This is Part 2 of a post-mortem series about my multiplayer Seltani game Aspel. Part 1 talked about things I omitted entirely from the design, and some things that I put in that didn’t work quite right. Part 2 talks about things that did work, and things that started out not working but that I think I improved over the iterations between tours.

These discussions are sort of implicitly a bit spoilery. You can decide how much that bothers you.

Things that did work (I think?):

1. Puzzles with informal “stations” of operation. Think of the bridge of the Enterprise: in theory anyone could man any of the stations, but in practice it would just be easier if certain people helmed certain controls. The first scene and puzzle includes this feature, and it was common for groups to appoint one person to handle the navigation cords, another to mess with the colors, and so on. This seemed to work fine for parties of up to 6 or 7; more than that and it got chaotic, but >7 is definitely outside the design parameters for the realm.

2. Debriefing room. Storygames often need a debriefing period; I felt like Aspel should have one too, a space after the major action was over where the participants could hang out, with a few minor actions available, and discuss what had just happened. I think this was straightforwardly a good idea and successful.

3. Modeling that added effects as player properties. Seltani doesn’t make inventory easy, but it does allow you to attach properties to particular players. This is how I modeled character memories and expertise. I had to rig something up to reset those properties if a new player entered the world (so if you play multiple times you’re not stuck with whatever choice you made the first time), but this seemed to work all right.

Things I modified during running:

1. random success/failure in a few cases to spin out an exchange.

Initially I had things set up so that if you tried fishing with the rod, you had a 50% chance of landing a fish. My thinking was that a team didn’t need all that many fish, so adding the randomness would make it so that (on average) multiple people would wind up getting to fish before the need for fish was satisfied.

In practice, this was stupid and exasperating. On one occasion players had such bad luck that they began to think that an area wasn’t fishable when it was. Even when things were behaving a bit more normally, in practice most of the players wanted to try the fish, and there was baiting the wicker cage to take care of as well, so fishing just slowed things down without meaningfully extending anyone’s experience of involvement. After the first tours I deactivated this and made fishing work 100% of the time.

2. inconsistency about indicating which links were going to lead to actions and which were essentially examining actions. This is an issue with Twine as well: some hyperlinks do something, some just give information, and it’s not immediately obvious which is which. I reasoned initially that with Seltani it didn’t really matter as long as big actions (such as traveling from room to room) were clearly signaled as such; and there didn’t seem to be a prevailing convention about this so far as I could see.

But in practice that was a bad idea. In the first room description in its initial edit there were interspersed actions that brought up a description and other actions that took effect immediately in some way. People had no way of knowing which was which, and this affected the communal experience because the world-model-changing actions could interfere with what others were doing or print output that made the chat stream noisy for everyone. It wasn’t possible for some participants in a large group to explore “quietly” while others explored more loudly.

3. decisions with asymmetrical information. This was one of my big ideas for this game: your team has multiple people with different specialties, and people with different specialties see different things. Specialties can be chosen at a bunch of different points during the story, so you get voluntary rather than mandatory player role assignment — something Seltani can handle.

People who’ve seen different things can then discuss what they’ve seen and how they interpret it before making final decisions.

For the first two teams, this didn’t work as well as I might have hoped, though it was not totally ineffective. In team one, there were just too many people, which meant too much happening. With so many events going on constantly, the room text was scrolling really fast. Seltani offers little scrollback, and people lost information they might have wanted to tell one another. Also, because it wasn’t always obvious what people’s motives were supposed to be, it was hard, sometimes, for people to know what they should be sharing and what they might want to keep to themselves.

Likewise, sometimes it wasn’t obvious to people when there was only one of an information-giving resource, and sometimes a single resource would be consumed when not everyone was there to see it. I’d sort of assumed that players would move in packs to explore the space, but this turned out to be false. This did lead to some entertaining moments, as when, in the first playthrough, Hernshaw tried to get everyone’s attention to explain that he’d eaten a piece of dead king, and no one was really listening…

Hernshaw says, “Everyone, perhaps it was ill-advised, but I ate a ruler.”
…
(no one really reacts, until the group gets onto the subject of the courtyard cannons)
…
Hernshaw says, “The former I (the king I ate) made them non-lethal on purpose.”
Lalswing asks, “You ate a king?”
Laura asks, “You ate the king?”
…
Hernshaw says, “Sorry to hog all the king, everyone.”

…but this was nonetheless plainly not ideal.

The first modification I made was to go through and italicize all descriptions that were specialist information. My goal here was to help people understand more clearly how their role choices were affecting play.

The second was to add a memory feature so that certain important pieces of information could be electively reviewed by the players who had first seen them.

As far as I can tell, those were helpful improvements.

4. Withheld information about how players accomplished something. In the first room, there was originally a piece of machinery which, when used, would report to onlookers, “$name does something you can’t quite see, and (thing results).” I did this because I liked the idea of variable expertise, of some players knowing the machines better than others. In practice, this was just confusing. It telegraphed to onlookers “something happened that you don’t understand,” but they had no way of finding out what it was other than asking the player who’d just taken action; which, with a smallish or slow-acting group, is more or less fine, but it is a lot more problematic with a large group in which people’s queries to one another could get lost in the noise.

It was just needlessly coy, so I changed it.

5. Lots of scenery in the final, dialogue-driven encounter with an NPC. In the original design, I tried to make it clear through the writing that the NPC could not hear (or would choose not to hear) what players said to one another; also that conversation with the NPC would result in a major decision. I envisaged that the players would all take their time looking around and discuss what they noticed about the character.

In practice, what happened was that some players started talking to the NPC while others were still laboriously working through all the scenery material, with the result that there was too much input for slower readers to be able to follow the scene at all. People with a deep-exploration approach rather than an action-first approach (relative to their co-players) were pretty much shafted by this scene design.

To somewhat streamline this, I took out a lot of the scenery so that there was way less to get hung up on. That extra imagery was interesting but it wasn’t as important as the conversation, so having it there just got in the way.

6. Fixed-length timer in the final, dialogue-driven encounter with an NPC. I originally set things up so that the NPC would make a decision after four pieces of information had been submitted. That was what had felt about right when I was playing through solo. The problem is, the more people you have, the fewer get a chance to say anything in this scenario.

To address this, I made the NPC’s readiness to make a decision depend on the total number of players in the realm. This is meant to give players in the room a chance to have a say; it’s also meant to make it less likely for one player to be able to get to the NPC’s chambers before everyone else and speed through the conversation while a large number of fellow-players remain behind.

7. Relying on players to inform each other when something interesting happened. In the first tour session, this didn’t happen very effectively at all. In the second, I told people in advance that there was a /yell command allowing them to communicate across rooms — which would have been more helpful if I’d remembered it was actually /shout — but we got this sorted out and people did shout about their discoveries some of the time. Nonetheless, even in the second session there was a fair amount of confusion from players who happened not to be around when a key discovery occurred.

For the last tour, I added a collective journal in which key events would be recorded as they happened. Output looks a bit like this:

Full team linked in from base camp; arrived with balloon platform intact. Aolius steered the platform to approach remains of a castle courtyard in the northeast corner of the survey area, but was knocked back by air cannon. Aolius navigated the balloon platform over the courtyard. Belford consumed a quantity of leather and revisited the life of a cow.

This seems to have made things quite a bit less confusing, though the third tour also did relatively little conversation among themselves. Did having the journal make it too easy to forego discussion? I’m not sure. Which leads us to…

Things affecting the multiplayer experience that the author cannot control:

Players, man.

Different tours played very differently because the players treated them differently. Sometimes the group stuck together, sometimes they split up. Sometimes they role-played and sometimes they talked exclusively out-of-character. Sometimes they shouted to one another to share information across the realm, and sometimes they didn’t. I think these choices strongly affected the experiences of the players.

There’s only so much an author can do about this, but I could have done more to set up expectations… if I’d had a clearer idea myself about the “ideal” way to experience something like this. It’s an area where I think solutions are still emerging.

I’m very grateful to those who played during tours, since it’s otherwise a lot harder to learn how the dynamics are working.