Twine, ordinarily speaking, is software that assumes a single author. There is no built-in cooperative editing mode. But because it uses web standards, a complete Twine game exports as a single html file. All you have to do, then, is version-control that single file, and use GitHub's collaboration tools.
Here's how it'll work:
- Start with a shared repository on GitHub.
- If you're reading this after forking a copy of the assignment, congratulations! You've already done this step.
- If you need to add collaborators to a repo, you can do so on the Settings tab.
- Clone the repo to each of your local computers.
- Download the latest version of Twine, if you can and you haven't yet done so.
- One of you, fire up Twine and start a new story with the green +Story button.
-
Make a few edits: I suggest a title screen as your first passage. You can always edit it later!
- Twine will save automatically: click outside the passage to go back to the map.
-
Use the menu at the bottom left to Publish to File. Be sure to save the resulting html file into your local repository folder.
- Using either the command line or the GitHub app, add the file you just exported, write a commit message to tell your colleagues what you've changed, and push your changes.
- Every time you start a working session, immediately pull from the shared repo so your local files are all up to date.
- In Twine, use the Import from File button, and re-import the latest version of your shared html.
- Do whatever work you want to do; when done working, or just at a good point to comment on a revision, Publish to File and overwrite that same html file in your local repository folder.
- Don't worry: the previous saved version is still recoverable with git!
- Using either the command line or the GitHub app, add the file you just exported, write a commit message to tell your colleagues what you've changed, and push your changes.
Depending on how your group has decided to divide the labor, you may add some other wrinkles:
- You may be editing images or sound files, rather than working in Twine. Same principles apply, though: pull, import, edit, save; add, commit, push.
- You may want to tell each other when you'll be working, to make sure you don't make competing changes at the same time. Be sure you have each other's best contact info! (Phone, Slack, What'sApp, take your pick.)
- If you want to get fancy about it, you can create a new branch for your changes, and then file a pull request instead of just pushing.
- This alerts your collaborators to review your changes before merging them into the shared, official version of the file, and creates a forum space for conversation about the change.
- To review how pull requests work, head back to Git and GitHub for Poets, episode 2 and episode 3. (He's also got a video on resolving merge conflicts, if they end up unavoidable.)