11

Keeping track of details invented for a work of fiction is never simple, often requiring writing bibles and continuity editors. But when two people are working on the same book simultaneously, then you're not only dealing with the details you've made up, you also need to work around a slew of fictional details that your co-author sprouted up on their own.

How can detail-organization techniques be adapted for collaboration, where they need to be shared constantly? How can an author keep abreast of a bunch of invented details their co-author thinks up? And when two co-authors have made up minor details which clash with each other, how can one resolve the conflict without knowing where and how the other used the detail?

| improve this question | |
6

My own habit is to use either Dropbox or Google docs to store what I refer to as "lore files." Each file contains all current details for a particular category: cities, characters, items, species. When making a minor change, the files are changed directly. If it is a major change or addition, it is added to a discussion file, to be added later. Before referencing something in your writing, simply check the lore file for that item. While this requires a bit of work keeping everything up to date, I find that the work translates directly into making the end result as congruous as possible. Additionally, it can help to record in the lore files the locations of references to the entry in your writing. This way when a change is made to the lore, it is easy to find chapters and pages that may be affected by the changes. Again, a lot of "not writing work," but in personal experience, it helps immensely.

As a slight aside, these lore files can also be helpful if you feel the need to include an index or release a sort of encyclopedia to your book. :)

| improve this answer | |
  • 2
    "Lore files" or writing bibles certainly seem like the way to go. I'm kind of wondering how working in a team affects their construction; the discussion file sounds like a good idea! And structuring around individual elements does sound very helpful. (Helpful for an individual too, but doubly for a duo...) – Standback Feb 16 '12 at 10:17
  • When you work with large, possibly dynamic, systems of lore, it does make sense to go about it this way. You see this even with large non-writing-specific projects, such as with the original Doom game: 5years.doomworld.com/doombible – Strozykowski Feb 16 '12 at 14:04
5

The first step I would suggest is to develop a timeline and then place your characters on that timeline. It would be better if each of you is writing from the perspective of a different character, because then you wouldn't have to worry so much about what the other person is writing.

It would also help to periodically exchange content so that you can see what the other person is doing. If they have a significant event happening that your character should know about, then you'll be able to react to that. (For example, if your character sees a pink glow around the moon, and both of you are writing about characters in the same city/region, then your co-author should probably comment on how their character sees it as well.

This would be easier if you have a detailed outline that identifies any critical bits of information. Define your setting for each scene/chapter, and document any major events happening in that scene. If there are fireworks going off, then each character might describe them from different perspectives.

The main point is to document as much as you can up front. Then if either of you goes in a different direction and decides to add something big, then just communicate that to your co-author.

| improve this answer | |
  • I'm less concerned with the critical bits of information - anything that's clearly critical is easy to coordinate. I'm much more concerned with small details we're likely to miss. – Standback Feb 16 '12 at 10:15
5

Another suggestion would be to use some sort of distributed source control system to keep track of the changes that you each make.

Dropbox

Dropbox has built in source control, so you can roll back to previous changes, and it is fairly simple to use. Their Terms of Service kind of trouble me, but I may have donned my tinfoil hat in recent years.

Benefits

  • Easy to use
  • Easy to get started
  • Track changes
  • Syncs to multiple machines, making backups easier

Drawbacks

  • Your work is stored on someone else's servers
  • May not be able to see fine-grained changes easily

Git

If you're decently technical, something like git might be a better option, as you can easily see differences between check-ins, and keep track of who is changing what. As a programmer, I use git every day, and that sort of mindset has become second nature to me. This is beneficial when you're working with 10 other programmers/designers, and you need to keep track of who is doing what.

This would also give you the benefit of keeping all of the content on your own systems, making sure that it's not inadvertently copyrighted by some other entity.

The downside might be that Git was designed to work with non-binary files (such as flat text files), rather than proprietary Word files (or other proprietary file formats), so the change tracking might not be best used with Word files.

Benefits

  • Track changes at a fine-grained level
  • Your content is always in your possession
  • Allows you to keep multiple branches of the same work
  • Keep multiple versions in local source control before committing to the main repository
  • Don't have to keep multiple, differently-named files to track versions
  • Tons of resources to get you started, and keep things going
  • Many GUI application options to choose from, regardless of the operating systems used by the contributors

Drawbacks

  • Works best with non-binary file formats
  • Requires more technical knowledge to learn and get setup

See what other writers here on the site think about using source/version control with their writing in this question.

| improve this answer | |
  • @oldrobotsneverrust Pick your poison :) – Strozykowski Feb 14 '12 at 21:27
  • 1
    I was aiming more for organization technique than organization technology, but this is certainly a great run-down of the latter, and obviously applicable :) – Standback Feb 16 '12 at 10:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.