So general submissions for Alabaster are closed, and I’m working on incorporating the last changes that I was sent. Thanks everyone who participated — this has been really useful and interesting, and I have hopes that the end product will be interesting as well.
My plan at this point is to
— work on the file myself a while (debugging, optimizing the code, tying off some conversational loose ends that no one wrote any conversation for)
— beta-test the game (I usually hold closed beta tests, but since this has been an open project an open beta seems more appropriate as well); this will also be an opportunity for collaborators to comment on how their contributions were interpreted or add any finishing touches that they wanted to add
— upload to the archive and add IFDB info, at which point the game will be considered officially released.
What follows here is mostly a postmortem on the experiment, with some further thoughts.
Going into the project, I was thinking that
- having lots of contributors would probably lead to a lot of fleshing-out of many details, guaranteeing more coverage of conversation topics than one author alone would think of
- on the other hand, having lots of contributors would produce lots of diverging branches leading to contradictory endings, along the lines of Galatea or Aisle
- contributors might submit several iterations of corrections, after seeing what their first set had done
In practice, that’s not quite how things turned out. Some contributors did add a lot to the project, and over multiple iterations (yay), but in general the people who were most interested in doing that did so by partly or completely working around the collaborator interface: they used the first run-through to teach themselves syntax, then started composing or tweaking their own quips by hand.
On the other hand, people were concerned about continuity, with the result that some emailed for discussion and/or looked at the source, while others (apparently) refrained from contributing for fear of damaging the storyline. And the piece also didn’t attract a great deal of casual contribution (i.e., large numbers of people sending in small, polishing sorts of amendments).
There are several things to observe from this.
One: the collaboration interface needs to be improved so that it offers people more options in terms of creating complex multi-step threads in a single submission file. When it became clear that this was necessary, I was hoping to add that functionality to the interface before the project closed, but it soon became obvious that it would take some real work and that I shouldn’t make such a major, breakable change half-way through the process. (It would have been a bummer to “improve” the collaboration interface into something so buggy that it couldn’t be used at all.)
Another interface issue, orthogonal to this, is that for casual, high-volume collaboration, it would be nice to do this with a server-side interpreter playable through a browser, with code files being automatically sent to the author. It turned out that different interpreters store their Glulx data files in different places than I anticipated, so some players weren’t able to find the NewConversation file to send me. (On the other hand, inability to edit the text files would have been frustrating to the more dedicated participants in the project.)
Two: I enjoyed the open-endedness of the project, and the story definitely ended up heading in some directions that I would never have anticipated at the outset. I’m quite happy about that, and one of the things I want to do is try to polish up in order to make the most of the different-but-complementary ideas that different contributors added to it.
But, while I’m happy with the way things turned out, I’ve also been considering how the project participation might change with different parameters. My ideas included:
- Releasing another plot-hook type game, but including a plot outline, or working out a plot outline in collaboration with others before starting, for a more directed co-authorship experience. I would guess this would be good for a small group of fairly dedicated participants.
- Releasing a game that did have a complete story arc, and just allowing people to add peripheral material to it; this might seem less daunting to casual participants since they would not be responsible for major plot features of the game. On the other hand, it might be less appealing to people who enjoyed feeling that they were really developing the story.
- Releasing a game where the collaboration interface was stripped of everything except the “what does the player say?” sections, so that the players would be writing the voice of the PC, but the game’s main author(s) would be composing all the NPC responses. This would, I imagine, feel really different from the process on Alabaster: something more like a blend of traditional RPG-playing and IF, where the author takes the role of human game-master in filling in those corners of the game world that the player wants to evoke but initially cannot.
At the end of the day, there’s probably no best way to organize such a collaboration; it’ll come down to a question of what we want to achieve.
Three: I’m sure that the time-frame of the project, and the fact that I ran it during IF Comp (not to mention right before a very compelling national election), were limiting factors as well.
To be honest, this was deliberate. It’s not that I wanted to exclude people arbitrarily. On the other hand, I was worried both that Alabaster would get no feedback and that it would get too much, but too much feedback would have been considerably more difficult to cope with, especially given a faulty, brand-new system.
However, people doing projects of a like nature in the future will probably want to schedule themselves quite a bit longer for participation, if they want to maximize contributions.
Four: I need to optimize the system further, as it starts to slow down for some people. But, to go alongside that, Glulx interpreters that (a) wrapped input lines and (b) were themselves speed-optimized would be a great help for this kind of thing.
Emily Short's Interactive Storytelling 
One: the collaboration interface needs to be improved so that it offers people more options in terms of creating complex multi-step threads in a single submission file.
That’s great if it can be done cleanly, but I doubt it would remove the need (or at least the desire) to edit the generated code file by hand. At the very least contributors might want the opportunity to correct typos, or to improve their own first conversational drafts. Also, in a game like Alabaster, where contributors can influence the plot, they may often want their contributions to extend beyond pure conversational exchanges (e.g. the need to add a scene to talk to the hart and additional code to ensure there’s always a way out of the scene).
In any case, I suspect that however comprehensive the contributor interface is, there’ll inevitably come a point when a contributor feels that s/he can most easily do what s/he wants to do by editing the code by hand. Also, a potential downside of trying to make the contributor interface ever more flexible is that one could end up making it ever more unwieldy. It may be that clever design could minimize this risk, but an interface that requires contributors to answer too large a number of questions for each quip may not be perceived as ideal. There may come a point when most contributors would find it easier to use the interface to do the basics and then tweak the results by hand.
I’m not trying to argue that you shouldn’t try to make the contributor interface more powerful/flexible, I’m rather floating the idea that the optimal solution may be a hybrid one (a contributor interface plus additional tweaking by editing the code it generates). Of course, this in fact represents the way I worked on my Alabaster contributions, but it was part of the enjoyment of the experience that I could work this way.
Four: I need to optimize the system further, as it starts to slow down for some people. But, to go alongside that, Glulx interpreters that (a) wrapped input lines and (b) were themselves speed-optimized would be a great help for this kind of thing.
Towards the end Alabaster became almost unplayably slow on Windows Glulxe, but playing it on Windows Git greatly alleviated the problem. My guess is that Git already meets your point (b) for Windows – or at least goes a long way towards doing so.
Personally, the second idea appeals to me most – crowdsourcing the fleshing out of the dialogue, as it were. That looks to me like the best use of what you’ve got so far, since I don’t think it’s advanced enough to handle conversations of any complexity, and if you DO want to write more complex conversations, it looks easier to me to learn a bit of the language, or to write out dialogue branches in a more convenient format. (Also, I confess I’m less fond of collaberations like Alabaster, which tend to meander aimlessly and feel somewhat choppy.)
I’m not clear on how you see the third idea working… it sounds like it could easily lead to confusion, non-sequitors, and less-experienced players expecting the parser to handle actual dialogue. Or did I misunderstand the idea?
Eric Eve wrote:
Towards the end Alabaster became almost unplayably slow on Windows Glulxe, but playing it on Windows Git greatly alleviated the problem. My guess is that Git already meets your point (b) for Windows – or at least goes a long way towards doing so.
But I thought Git was too buggy? At least, I remember that, for the French game Lieux Communs, Git caused important and totally unpredictable bugs, and we had to recommend Glulxe for people who wanted to use the Gargoyle interpreter. I think Emily Short had similar problems with Floatpoint.
Unless there was a better version of Git more recently? But this recent RAIF post suggests that there wasn’t: http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/c86ff1c175c390c8 (“[Git] doesn’t work well in a lot of configurations […]”).
I’ve had good luck with Git on older games, but yeah, it seems to be unreliable on more recent stuff, so I didn’t recommend it to anyone. This is really too bad, because the speed gain is fantastic.
In re.:
(Also, I confess I’m less fond of collaberations like Alabaster, which tend to meander aimlessly and feel somewhat choppy.)
Part of what I’m trying to do now in editing it is draw together the different strands and make it feel more directed and less choppy. There’s quite a lot one can to do make it more likely that players will encounter the interesting material. Editing for tone is a slightly trickier point, of course.
That said, in general I agree with you: unedited open-source IF projects would not be likely to produce very coherent stories or play experiences. (The IF Whispers projects, for instance, tend to be interesting but very variable — and they’re at least divided up into scenes by different authors.)
With Alabaster it’s easy for major plot threads to be hanging on whether the player does something very specific and perhaps not at all obvious. This is partly because the interface makes it harder to add the complex logic that makes threads available under multiple circumstances (though the presence of facts helps). Partly it’s because one of the best ways to have the game flow and make sure the player has a good experience is to line up active comments by the NPC to drive the conversation when it doesn’t seem to be going anywhere. The core system allows this, but the collaborator interface doesn’t make it easy to write such interventions.
I’ve given that a lot of thought and made a few feints towards coding in such a feature, but the fact remains that no matter how I design the questions, at some point the participant has to know something about the code itself, in order to know when to queue a new piece of conversation.
I thought I would give the open-ended project a try with Alabaster anyway — I wasn’t expecting to do this much cleanup afterwards, just to release it as a crowd-designed project and leave it at that — but in practice most of the collaborators who put substantial work into it seemed really interested in promoting continuity and in making sure that it worked together as a game. So editing it more seems more in line with the authorial intention as a whole (as far as I can measure that).
I’m not clear on how you see the third idea working… it sounds like it could easily lead to confusion, non-sequitors, and less-experienced players expecting the parser to handle actual dialogue. Or did I misunderstand the idea?
I suspect it would need a certain amount of judicious editing from the person working with the material: if the player entered actual dialogue, that could be moved into the “what the player says” section, and the quip given some more sensible tag for the “You could…” line.
Or it could suck. I don’t know. :)
But I thought Git was too buggy? … Unless there was a better version of Git more recently?
There waa a fairly recent update to Windows Git (1.2.1), which fixed a save-and-restore bug I encountered before. I haven’t (as yet) encountered any bugs with this version; it played Alabaster just fine.
>i>But this recent RAIF post suggests that there wasn’t: http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/c86ff1c175c390c8 (“[Git] doesn’t work well in a lot of configurations […]“).
I don’t know if the poster there was talking about the same version of Git. The context seemed to be Gargoyle, which may be using something separate from the Windows Git 1.2.1 (released late September or early October, I think); though to be honest I get a bit confused by the profusion of Glulx interpreters that seem to be around, some of which seem to be different branches of the same family.
In any case Git 1.2.1, on which I played Alabaster is several releases further on from any version of Git that was available when Floatpoint was first released.
“Git” seems to run Blue Lacuna okay– at least I’ve never seen it crash even on complete playthroughs– and is, in fact, the only current interpreter on which the game is remotely playable without a screamingly fast processor. I’m dismayed to hear it’s had crashing problems with other games. What sort of crashes/bugs were there and was the cause ever isolated? (i.e. a specific feature usage or something?)
Addendum: “remotely playable” is probably a vast overexaggeration. It’s still playable on WinGlulxe and Zoom, but the delay between prompts is noticeable and mildly annoying.
Possibly I’m behind the times — I didn’t know there was a more recent update, so I haven’t retried since whenever this rebuild happened (and I don’t know whether the current version of Spatterlight uses the revised Git).
The problems I had were crashes in Floatpoint when it was released to the comp, usually fairly early on, of a closing-the-game-and-quitting-abruptly variety. I am not sure what the root of that was. But it sounds from Eric’s evidence as though Windows Git at least is past whatever that was.
Addendum: “remotely playable” is probably a vast overexaggeration. It’s still playable on WinGlulxe and Zoom, but the delay between prompts is noticeable and mildly annoying.
Yeah. I spent a lot of today on optimizing the core of the conversation system. It is now, I think, substantially faster to play, but the price one pays for that is a mildly annoying start-up delay while the game caches various information for future reference.
I assume players would much rather wait 30-45 seconds at start-up than 7-10 seconds per turn; but it would make me happier still to be running all this on a system where none of these things are noticeable at all.
Note: the bugs I mentioned were indeed with the version of Git *included in Gargoyle*, not another one!
If I understand your comments correctly, the more recent versions of Git are OK, but it seems that Gargoyle uses (or used until not so long ago) an old version of Git and should be updated. Is that true?
The latest version of Git has fixed the problems with Floatpoint and most other games released up to and around that time. However, recent Inform 7 games that use features like lists and indexed text extensively will still fail. http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/6a90c800edf8d8ba/ explains why (it refers to 1.2.0, not 1.2.1, but 1.2.1 is only a minor bug-fix version). The problems with Superglus games are also still there, according to the readme.
On the RAIF post that mentions Eric Eve, I wrote what I meant GIT of Gargoyle, actually.
GIT 1.2.0 (Gargoyle) and Windows GIT 1.2.1 does not work well with the new version of Damusix (v3/081104). This will be the version to be used in the extension to Inform7.
Damusix v3 uses the Opcode “@protect” for a new feature that allows “don’t restart the sounds that are playing in the background” if it does UNDO/RESTORE. In GIT, this opcode is not fully implemented, apparently. It produces totally unpredictable errors in the interpreter.
At least for now, GIT is not a good interpreter for the adventures of Inform7 that could be used Damusix in the future.
[I am providing optionally a conditional compilation constant for not using this new mechanism of Damusix, and then it works effectively in GIT, but I really think that this should not be so … =(]
I apologize if my previous comment seems very pretentious on my part. Only attempt to comment on the bugs I’ve found. =) Thanks for your time.
Is the point of this to show how multiple people can actually create something quality in terms of an IF experience? Or just an attempt to show that multiple people can collaborate?
I can’t really see how an idea like this does anything for producing better games. It would be like if 10 authors all got together and decided to take turns at writing chapters.
Is the point of this to show how multiple people can actually create something quality in terms of an IF experience? Or just an attempt to show that multiple people can collaborate?
The point of it wasn’t to show anything: it was to find out what would happen if someone tried this process, and also to test whether collaborators found the provided interface usable. (Answer there: sort of.)
A number of people have proposed open-authorship collaborations as a possible way forward for the development of IF. I came to Alabaster rather skeptical about that approach (since it seems to me as though the improved responsiveness you get from crowdsourcing is not necessarily enough to make up for the lost unity of vision). After the experiment, I still have mixed feelings on this topic, but they’re more informed mixed feelings. Alabaster is coming out less incoherent than I had expected; the participants did seem all to be pretty interested in trying to produce a cohesive view of the world, and now in the editing stage I am trying to work further in that direction. Certainly the collaboration also produced ideas that I would not have thought of on my own (and, I would guess, a combination of ideas that no single one of us would have thought of).
On the other hand, the prose style varies a lot between contributions. While it would be possible also to smooth that out with judicious editing, I’m disinclined to do too much about it because I don’t want people to feel their contributions were stomped on or sanitized. The result is interesting but, to my eye, a bit peculiar: characters can go from haughty responses in archaic language in one line to sarcastic modern humor in the next. So I expect the art produced by this project to be rough-edged in some different ways than individually-authored IF tends to be. But I don’t think it will be worthless, either.
As a test for the conversation extension package, Alabaster has worked out really well. My reasons for wanting to develop the package are (a) I want people interested in broad collaboration to be able to do their projects, even if the artistic value of the results will not be uniformly fabulous; and (b) I can easily envision collaborations using this technology that were not open-ended but were on the contrary very focused and organized to a particular end. (Two or three writers with a closely-allied vision working together; different characters being scripted by different writers in order to give them distinct voices; cool stuff like that.)
A really nifty innovation. I had technical hitches adding quips (they didn’t keep), but was glad to be a lurker-observer on this one.
I look forward to whatever next iteration of this scheme you dream up, whether people contribute around a fixed plot, contribute solutions to fixed puzzle-situations, contribute paths between plot nodes (which was basically how I thought of Alabaster), or what have you.
Very cool stuff.
Conrad.