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:
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.
13 thoughts on “Writing for Seltani: Aspel Post-mortem Part 2”
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.
There was a little more than that: I remember causing the the vehicle to go lurching by pulling a cord when all I was expecting to do was look at the cord. So it wasn’t even a matter of quiet vs. loud, it just literally did an action I didn’t want to do. This has been a problem with adventure games that rely on a one-click system for a long time.
I think some sort of signal of intent of click would be good, like With Those We Love Alive did colors to help discern the effect of the links.
I haven’t encountered any provision for color-changing links built into Seltani, though it’s possible there’s some way of injecting HTML features that just isn’t immediately obvious to me. But in the meantime I think this will have to be done via some more explicit, in-text communication.
I wonder if it means dividing the paragraph up: “You could examine… You can act on…”
And regarding the players staying together, you said there’s hooks to know how many people are in world. I wonder how awkward or rewarding it would be to create crowd-control gates like an amusement park. Say if you have more than five people exploring at once, a gate at the beginning will hold new players in a lobby and entertain them with a safety video, and the exploring party must all pass through a one-way gate at a determined point before a new group is allowed in.
The ideal thing then would be to send the second player group into their own, different instance — zarf and I have talked a fair amount about how useful it would be to have instances that were easier to invite people into than personal instances currently are, without being global.
But I’m experimenting in a WIP with having a small antechamber that assigns roles and gates the number of participants a bit.
I should add that OOC/IC stuff is one thing MUD theorists have definitely thought on (ex: Raph Koster here: http://www.raphkoster.com/games/snippets/what-about-a-mud-which-requires-you-to-be-in-character-all-the-time/)
What’s not been addressed so well are mini-scenarios (they go by different names depending on where you play) and the ones I have seen tend to be straight LARP equivalents — here’s your character, here’s your motivation, here’s a scene going on, now go roleplay. They at least used to be called “TinyPlots”. You seem to be aiming for some sort of more world-integrated thing which is less common (or at least I’ve only seen it maybe twice).
Yes — I should clarify that a) I don’t have a huge amount of experience with MUDs (something I should definitely rectify if I want to explore this space) but that b) what I’m trying to experiment with here is intentionally slightly different territory.
I’m not aiming, right now, at building a persistent world with dozens or hundreds of characters encountering one another; I’m interested in short-form interactive story that’s opened out to more than one player, something combining properties of short-form tabletop storygames and trad single-player IF.
In any case, if you’re giving people a chat stream, you really can’t control whether they stay IC anyway. But I would like to explore a space in which at least some IC roleplaying is part of the fun.
It’s mostly a question of establishing a convention for the group, I think. I went in expecting collaborative roleplaying and ended up in a group interested in solving puzzles efficiently. Either would have worked, but as it was, they annoyed me, and I annoyed them. Obviously this is easier if the group exists before the game begins, which I think would be as reasonable an assumption for a short-form interactive story as it is for tabletop storygames. Of course, this shrinks the audience.
I did have several people who said “I think this would have been more fun with a group of friends rather than random people who showed up for a tour.” So I asked, “Okay, should I not have done tours?” to which the response was, “Oh, I just wouldn’t have tried it in that case.”
Stubbornly, though, I’m enough interested in the design space to want to think of ways of addressing that; but you’re right that it’s probably worth framing both what kind of world it is and what kind of play experience the participants are looking for. (Maybe a ‘puzzle-focus’ tour vs a ‘RP’ tour? There may even be more categories than that.)
I’m sorry your experience was suboptimal, but thanks for giving it a try.
Sorry for offtopic, but you might be interested in the following game:
This is a text/parser based adventure available in both Russian and English. One of the first text games on Steam.
I’m not currently equipped to play Windows-only games, I’m afraid, but I did see Blue Renga’s writeup on it ( http://bluerenga.livejournal.com/56392.html ).
You can actually run it on Linux and Mac, but not from Steam.
In this case you need to install the game platform first (it is available in english):
Then download a crossplatform version of the game:
Are mac/linux versions on Steam forthcoming then?