3 ms·

It's a cool idea! I've been toying around with some Interactive Fiction tech, was thinking about making a collaborative story-telling experience, except using s

It's a cool idea! I've been toying around with some Interactive Fiction tech, was thinking about making a collaborative story-telling experience, except using slack as the base platform. Was thinking you could use Amazon Lex + slack bots as interactive NPCs, and channels (and private channels) to represent locations. I hadn't considered how the GM would work, but I'll read into how they're doing it here. I don't have time to actually build this though, or the patience to even read most IF so I'm sure I would lose steam quickly, but it would be a cool project (which anyone reading this is welcome to run with).

throwanem 9y ago
I've actually done something like this, a couple of times, on a much more ad-hoc basis, writing interactive fiction one response at a time in collaboration with another guy who wrote commands like you would to an Inform parser. It was fun to play and received a degree of general acclaim, but it was also a lot of work! If I were building tooling in support of a similar game, the first thing I'd write would be a bot that'd observe and correlate directional moves, "look"/"examine" commands, and the like, with their responses - and, when a previously visited location or a previously examined object were encountered again, give the author the option of reissuing the previous response, with or without prior editing. Such a bot could also be preloaded with responses to commands likely to be issued during a game. Inventory management, and object management in general, would be another high-payoff automation target. Remembering what's where, both on the map and in the player's inventory, is a drag and severely error-prone; a bot tracking TAKE, DROP, and like commands, or even just able to be told by the author of object status changes (or both!), will both save a lot of time, and greatly improve the flow. In my experience, it's easier for players to remain involved and engaged, and the game to remain enjoyable, when responses come quickly - although I'm not too sure this isn't an artifact of my having played these games in a public Slack channel, which necessarily has a certain performative aspect about it. Games with a smaller audience, or no audience at all beyond those actually playing, might not have such concerns. In any case, having a bot that's seen what came before and can reproduce it without manual effort, but also gives the author a chance to modify those responses where necessary, saves a lot of work that could be better spent on imagining and describing a compelling story, and would thus I think be a good place to start. How to scale the game to multiple players, I have no idea - for classic interactive fiction, that'd more or less mean multiple games running in parallel, so the model doesn't really fit. For something more like a multiplayer RPG, I'm not even sure where I'd start. (One other note - unless there's a very compelling reason otherwise, I'd lean by default to an open source offering like Mattermost or Rocket.chat over Slack for this. On the one hand, Slack's pricing model and rolling archive on the free tier lack appeal; on the other, some of the tooling we're talking about might well be more effectively built as part of the platform than as user scripts or as bots interacting with webhooks. I've used Slack, and it is very good! But another similar platform might be better for this use case.)

throwanem 9y ago

I've actually done something like this, a couple of times, on a much more ad-hoc basis, writing interactive fiction one response at a time in collaboration with another guy who wrote commands like you would to an Inform parser. It was fun to play and received a degree of general acclaim, but it was also a lot of work! If I were building tooling in support of a similar game, the first thing I'd write would be a bot that'd observe and correlate directional moves, "look"/"examine" commands, and the like, with their responses - and, when a previously visited location or a previously examined object were encountered again, give the author the option of reissuing the previous response, with or without prior editing. Such a bot could also be preloaded with responses to commands likely to be issued during a game. Inventory management, and object management in general, would be another high-payoff automation target. Remembering what's where, both on the map and in the player's inventory, is a drag and severely error-prone; a bot tracking TAKE, DROP, and like commands, or even just able to be told by the author of object status changes (or both!), will both save a lot of time, and greatly improve the flow. In my experience, it's easier for players to remain involved and engaged, and the game to remain enjoyable, when responses come quickly - although I'm not too sure this isn't an artifact of my having played these games in a public Slack channel, which necessarily has a certain performative aspect about it. Games with a smaller audience, or no audience at all beyond those actually playing, might not have such concerns. In any case, having a bot that's seen what came before and can reproduce it without manual effort, but also gives the author a chance to modify those responses where necessary, saves a lot of work that could be better spent on imagining and describing a compelling story, and would thus I think be a good place to start. How to scale the game to multiple players, I have no idea - for classic interactive fiction, that'd more or less mean multiple games running in parallel, so the model doesn't really fit. For something more like a multiplayer RPG, I'm not even sure where I'd start. (One other note - unless there's a very compelling reason otherwise, I'd lean by default to an open source offering like Mattermost or Rocket.chat over Slack for this. On the one hand, Slack's pricing model and rolling archive on the free tier lack appeal; on the other, some of the tooling we're talking about might well be more effectively built as part of the platform than as user scripts or as bots interacting with webhooks. I've used Slack, and it is very good! But another similar platform might be better for this use case.)