How do you approach writing collaboration?

Authoring General Design Discussions
1

For authors who have collaborated on IF gamewriting with others before – how do you do approach it? I specify gamewriting as opposed to general gamedev where like one of you is doing coding, one of you is doing writing, and one of you is doing music or what have you.

A few questions to consider:

  1. How do you split up the work of plotting the story, setting, characters, etc? (Ex: One person has a world/concept and the other(s) create inside those bounds; everyone works together on the idea from the ground up)
  2. How do you split up the work of writing actual parts of the story (Ex: Each person gets assigned a route or room; one person writes the action parts and another writes the dialogue)
  3. How do you share the actual work between yourselves in a technical sense (Ex: Everyone sends their finished versions to a shared folder in the cloud; a collaborative software like Microsoft OneNote or Google Docs; version control like GitHub)
  4. How do you make the game’s writing consistent with multiple people working on it? (Ex: One person is in charge of editing the entire game to cohere; we have a writing style guide; consistency what consistency??)

And any other questions or details you care to add.

8 Likes
2

Leaving a reminder to myself to come back to this on the 9th when I can talk about IntroComp things!

7 Likes
3

Do you have really finite time (gamejam), finite time (IFComp) or ‘infinite’ time (passion project)? That will govern the approach a lot. Of course, beware entering any passion project (yours or others’) with collaborators you don’t have 100% trust in and knowledge of.

Otherwise, I might talk about it on point 4, consistent writing.

I was recently involved in the If You Had One Shot collaborative project, where four of us wrote a two-step choice stream each starting with a shared situation. For time expedition reasons, this was a completely non-social project where we all worked in isolation, except to interact with Brian whose invention the project was. I have not said a word to either of the other two writers about it to date :slight_smile:

By having experienced writers and a shared starting point, there was pretty good consistency immediately. Now, I don’t know what the other two guys thought, but when I read theirs, I wanted to make everything fit a bit better, so was suggesting to Brian, ‘Let’s get character names consistent across the streams’.

So a shared project is not where one writer can use an inimitable voice, because then it won’t fit others’ writing, and to edit it enough that it fits might destroy it.

Having a sample or two of desired output by a project coordinator is a great (probably necessary) way to stop anyone going way off piste. In One Shot, we had Brian’s start piece. If you say to the writers, ‘It should match this or be like this,’ and your writers are decent and cooperative enough, you should get output that you’ll be able to integrate without too much work. It’s a huge plus if one of you is very good at the editing angle, or massaging bits of writing to resemble each other.

This is all nice theory, but of course the real stuff happens when the real people react to each other. I think that’s why its best to have a chat (IRL is best, offline the next best) as a way to start off any co-op project. You work out so much about what everyone wants and what everyone’s got, even in five minutes.

-Wade

10 Likes
4

Generally my experience has been:

  1. The group writes up a style guide, so everyone is working with a coherent vision.
  2. The whole thing gets outlined as a team. What happens where is discussed before actual implementation happens.
  3. A shared spreadsheet is set up somewhere that has the segments of the project divided out to each team member.
  4. When a team member finishes a segment:
    4a. It’s marked off on the shared spreadsheet.
    4b. It’s passed around to other members for feedback, notes, etc.

At least, this has been my experience mapping as a team for Doom level pack mods (and co-writing fiction), but I feel the skills transfer 1-to-1, because you do not have a dedicated coder, writer, composer, etc. Everyone is mapping, so everyone has a hand in the same field/medium of creation.

5 Likes
5
  1. When we wrote The Chinese Room, the writing was split up fairly evenly between the two of us. Josie wrote the initial skeleton of the game. Through discussion, I came up with a load more puzzles and locations.
  2. Then we split up each location and puzzle-cluster between us, so we were working on different areas concurrently.
  3. I don’t think we needed to merge text on this project as we were working on different sections. Later we would go over each other’s stuff and round it out with more little bit implemented, more conversation etc. On other projects where I collaborated on the complete source all at once (Sub Rosa, Escape From Summerland and Calm with Melvin Rangasamy), we used heavy use of text-document merging software, like WinMerge. In the future we might use Github.
  4. Coherence of writing style or tone came up in conversation but it was agreed that a joint style would naturally emerge. (Rereading the game 16 years on, I can remember who wrote what part for certain sections, but there are plenty where I don’t remember and the writing gives no clue.) This is perhaps easier to do as it was a comedy. We did end up with two or three characters who spoke with a notable west country accent quite by accident.
6 Likes
6

I’ve only worked on one project with someone else, and for that the division of labour was pretty obvious: he would write and I would code the game. It was his story first, he knew best how to put it into words (I’m not great dealing with horror stuff, and he’s quite read on the subject), and he doesn’t have time to learn how to code/design. It just made sense.

While we don’t share the writing process, we do for the editing. I go over the drafts to give comments or re-write things, and we send the Word document back and forth until the comments/edits are either approved or rejected. Since he is the one writing the game, I’ve learned how to emulate his style as best I could to keep things coherent - it’s worked at times…

We still discuss the project outside of the separated tasks, to help unstuck the story or agree on how interactive an element should be. But it’s often very minimal, we trust the other knowing what’s best for the game (I don’t even share the coding files :joy: but we test the final update together).

5 Likes
7

This seems like a great idea and well worth learning. Github sounds intimidating but it’s built for simplicity once you use the basics: clone, pull, fork, commit and push. (This is a general you for anyone thinking of collaborating.) I really like how it allows you to write issues to track “we need to do this later.”

The TLDR is that source control helped me feel like I was really part of a project even if my suggested changes were trivial.

To name-drop here, at an IF Chicago meeting, I remember Ben Collins-Sussman showing a repo for a tentative sequel to Rover’s Day out. Over the space of the hour, Jack Welch sent and pushed a commit. It wasn’t a big one, but it was neat. Ben is the coauthor of Subversion so he of course preferred that & that (among other things) also takes his time from writing a sequel! But the point still stands. Yay source control.

The key thing is, with github, you worry less about “should I email my collaborator with small changes? Too small to bug them with?” or “Boy, this is a code dump, do they need this right now?” You can sort through it.

And it feels good as a very minor contributor to a project to be able to do that.

I also remember for Cragne Manor being able to either write an issue with typos or push a small commit that fixed typos for one of the rooms. I took a loot at the story.ni after playing through & said oh, hey, here are some straightforward tweaks. This was really neat, as it eliminated a lot of red tape.

And this final bit isn’t really writing collaboration, but more bug hunting: for Mark Lemmert’s Nox Archaist, the old-school Apple adventure which is really really good because it’s not just nostalgia but it took the best parts of old Apple RPGs, I was given access to push various trivial cosmetic changes.

There was a delicate balance between sending in a pull request and saying “Well, this game text seems odd, it needs a fix.” For instance one character who joined your party was referred to as Nox Thum and Nox Thun. So for that I just wrote an issue and pushed it back to Mark. But for typos etc. I submitted a trivial pull request.

8 Likes
8

Now that Introcomp is over I can talk about this!

Neither of us had done choice-based IF before—I’d only written parser things, they’d only written static fiction—so we were both feeling things out as we went along. All the planning was done collectively. Then we divided up the writing roughly evenly, based on our past experience. Since they had a lot more experience with dialogue, for example, they wrote the dialogue sections, while I wrote descriptions of places and objects. I then converted it all into Ink.

The end result is that there are two main “modes” of interaction in the game. My sections come from parser experience, so there are places to explore, objects to interact with, short bits of narration between choices, and lots of loops in the flow (room → examine object → back to room). Their sections come from static fiction experience, so there are a lot more words between each choice, and the overall flow tends to be linear instead of circular (start conversation → dialogue options → end conversation).

In general, I was always pushing for more choices, even if they didn’t change anything in the long run (“the player should have something to click during this long dialogue, even if it’s just for flavor”), and they were always pushing for more consequences to every choice (“the cop should come back if you spend too much time searching the crime scene, you shouldn’t be able to choose a dozen different choices there”). The end result is a compromise between these two extremes, and hopefully one that works!

Logistically, since I was the one doing all the coding, we mostly exchanged snippets via Discord instead of using proper version control. Now that they’ve learned Ink we’ll probably need to switch to git.

8 Likes
9

I second all of this—Github made things so much easier for @Encorm and me.

5 Likes