Use Google Docs
I have experience in designing LARP rules using Google Docs, and it was awesome. LARP rules, even though typically shorter than tabletop RPG rules (around hundred pages against like several hundred pages), need to be a lot more precise, because there will be no constant GM presence to judge each of the rules' applications. It makes them also go through a lot of iterations, which can also cause confusion.
I also have a lot of experience of using Google Docs for different purposes, both together with someone and alone, I use it as my main office program, and I don't even have normal offline office programs installed on my PC.
Why should you use Google Docs, or, to be more exact, Google Drive?
- Google Drive is essentially very similar to a normal folder on your computer. You can split your rules in parts that are all in one folder, it makes the amount of confusion a lot less. For example, we had combat rules in a separate document from economy rules, so it is easier to understand what is being changed.
- It is completely free. You only need to register a GMail account. Unless you need to store particularly large files, free 15 GB that you get should be more than enough. LARP design has very limited budget, as it is done by volunteers, and the budget is formed by players covering the costs of hosting the event, so being free is a big asset. An open-source RPG likely has zero budget.
- It requires very little training to use. If you are trained to use some standard office software like Microsoft Office, or Open/Libre Office, you will learn Google Docs in almost zero time. Basically, all you will have to know are sharing settings and version history control, which require extremely little special effort to use. If you are not interested in learning a lot of new complex stuff, Google Docs offers a lot of functionality that is really easy to learn.
- It has many types of files supported: not just plain text, but also drawings, Excel-like spreadsheets etc. We used a Google Spreadsheet for budget calculations, a Google Drawing for the game territory marking, Google Forms for accepting players' data, and a spreadsheet to store it. You probably won't need to calculate budget of an "open-source" RPG, but you might use spreadsheets for other important calculations, which you would typically need Excel for.
- You can download any file you can view as any of the common formats with ease, such as .odt or .docx, or .pdf. You can also make a separate copy added to your Google Drive.
- Google Drive requires totally no special software to download. If you have one of the common browsers, you can use Google Drive. If you have an Android smartphone, you can have fully functional Google Drive too! Also means that system requirements to use Google Drive are very low, and you can use it on any PC, even if you are not allowed to install software on it.
- Google Drive allows many people to edit the same file at the same time. They will see which parts are being edited by the others. It can go very smooth if you all have good internet connection, or not so smooth -- in the latter case you will have to refrain from editing the very same lines in the same document, but most systems I know don't allow it at all! And, again, you can do it if your internet is good, especially if you use some kind of voice communication when editing, such as Discord, TeamSpeak, Skype, or simply sitting together during an offline meeting. :)
- You don't actually need constant internet connection to edit files in your Google Drive. Almost all of the Google Drive functionality is available offline. I do not have experience with working only offline for large periods of time (more than a couple of hours for shared documents, more than a couple of days for solely-edited ones), but you can, for example, edit a file for a couple of hours when you are in a train, and the changes will be automatically uploaded next time you have internet connection.
- You can also have non-Google Docs files in your Google Drive. But Google Docs take zero space in your Drive, while 3d-party files do take space.
- It has a built-in autosave feature which happens like every few seconds. You won't lose your work if electricity suddenly turns off, or if your OS crashes.
- Neither can you lose your files due to HDD failure. You can actually trust Google at storing your files.
- It has perfect sharing and version control settings that I discuss in the next two chapters. :)
How do Google Drive sharing settings work?
The Owner of the document has all the rights for this document, and they can only be revoked by the Owner themself: the Owner will need to transfer the document to another Owner.
The Owner, among other stuff, can do the following things with any Google Doc or Google Drive folder:
- Add specific people with specific GMail addresses to the sharing list, assigning specific priveledges to each of them. The Owner can also delete people from the list.
- Make a sharable link to the document, assigning a priveledge level for any person that gets the link.
The priveledge levels are, by ascending level, are:
- "Can view". Your files are not visible to anyone by default, so your data is private, but you can allow specific people to view it, or share it by the link with unlimited amount of participants. Those who are allowed to view the document will also see the editing process going on if there is any. They will not be allowed to see the version history, share the file with someone else and touch the sharing settings at all. In LARP, we use this settings for the players who are allowed (and required!) to read the rules, but certainly not allowed to change them.
- "Can comment". Very useful for your beta-readers. Those with this priveledge are allowed to select a portion of the document and enter their comment for it. It is very useful for discussing specific parts of your text. Comments are only visible to other commenters and those who can actually change the document. Commenters are also allowed to suggest changes: they appear in a specific formatting so it is easy to distinguish a suggestion from a finished text. Suggestions are not visible to "viewers", only to those who can edit the text and comment on it. Even if you are allowed to edit the document yourself, it might be useful to use suggestions and comments mechanic so viewers only see your changes when they are ready, but can still access your document by the same link. We didn't have any people who were only allowed to comment, but those features were commonly used.
- "Can edit". Those can do pretty much everything: edit the text directly, change sharing settings, accept and reject suggested edits, delete comments and mark them as resolved, etc. They can see and fully use the edit history. This should be used for your core collaborators' team. But keep in mind, again, that "editors" also have ability to suggest edits, and it is often better to rework a part of text via suggested edit and only "accept" it yourself when the rework is ready to be presented.
Note that the very same priveledge levels exist for both your team with given e-mail addresses (obviously, priveledges of each member are separate) and link sharing. If you don't give your link to a lot of people, you might turn link commenting on, but it will turn to be a mess if lots of people have such a right while you also actively work on the document.
If you are working on something with your one close friend and only with him, you can give him a link with editing priviledges. But if it leaks, anyone who finds it will be able to edit the doc.
To manage sharing settings, right click on the file and press "Share".
Here is the official sharing manual.
How does Google Drive version history work?
There is a very good official manual on version control, but for the sake of completeness I will share the basics here.
To access the version history, click on the button right from the "Help" button. It may read in one of the following ways:
- "All changes saved in Drive" -- if it was just edited by you, and the edits are successfully saved
- "Last edit was made [time frame of the last edit]" -- if it was edited by you some time ago.
- "Last edit was made [time frame of the last edit] by [author of the last edit]" -- if it was edited some time ago, and not by you.
You can edit when offline, and there will be text signaling if the changes are saved offline or something goes wrong, but you cannot access version history offline.
When you click this button, you will see a list of versions (revisions), sorted by time (newest first, oldest last). For each version, you will see time and date, and authors.
If you click on a revision, you will be able to see single edit in the text, including the author of each edit, and will be able to roll back to the said revision.
If you click on the three vertically aligned dots right to each revision's name, you will be able to name a revision, briefly signaling out the edits. A switch in the upper right corner allows you to only look at the named revisions or look at all of them at once.
You can signal named edits in the text, like "Version 3.1a: blahblah changed". The best way to ensure that it is very clear which version are you reading on print is adding page headers: they will be added automatically for every page if you press "Insert", then "Header", and then enter the version name/number.
While working on a document, you can enter the edits as "suggested", and name a revision each time you accept anything, signaling it in the text. It is also good to have a written change log. We didn't need it because we didn't need forking of our rules, but some other russians designing LARP with Google Docs did (for example, the one who has created a very popular model of medicine, perhaps the most popular one in Russia).
Releasing new versions
From my experience, it is a very bad idea to allow access to the live version for anyone who is not supposed to edit it. Once you have made a substantial amount of changes, you might decide that you are ready to make a new alpha release. What should you do then?
- Update the changelog, which should likely be in the beginning of your document. When you are reading a slightly different version of something familiar, it is very easy to miss important changes. You can go through all of your edits in the Google Doc since the last release, and just write what has changed since then. It is actually better to write the changelog while working on a new version, but if some of your participants fail to do everything right, you might have to recheck, or even decide to do all the versioning yourself, which is not a bad idea. We didn't have proper changelogs during our development, but we had "resolution" documents, where we have wrote what have we decided to change on each of our meetings.
- Update the version number. It should be included somewhere on the title page, so you can see it clearly, but don't forget to also add it on a page header, so if you have a printed version and pages get separated, you are not lost in the chaos. Change the document name aswell, so you will not be lost in them. It is a good idea to base your version name on the date and time of the release and on the fork name, so it could read like that: "Version 30.11.2017 2:22 alpha Main_fork", where "Main_fork" is your fork name. Better invent something more or less original, so it is easy to Ctrl+F for it. Don't use common words as fork names.
- Make a copy of your document in your own Drive, and freeze any editing of the released one. Revoke editing rights from anyone who has access to it, so they cannot edit the old version, and don't edit it yourself. Name the old document exactly as its version is named, and publish it in whichever way you use: link sharing, exporting to PDF, etc.
- Copy the old version's changelog data at the main changelog at the end of the document, so you have a total list of your changes.
This way, any reader will have a very clear understanding which version are they reading, what changes have been done, and, thanks to the good versioning tools, it will be very easy to mark the changes.
How can you have forking?
As mentioned, Google Docs have a built-in tool to make a copy of any document that you can view, including your own documents. This is done via pressing "File", then "Make a copy". The problem is that the copy is not different in any way from the original file, aside from its name: it will be called "Copy of [previous file name]". It will also not inherit the original file's version history. This means that you will rely on marking the changes manually anyway.
If someone wants to fork your project, you may give the following actions, which you can require in your license:
- Make a copy of the document via the "Make a copy" functionality
- Name your new fork by substituting the old name with your own one. For example, if the old was called "Main_fork", you can substitute it with "Brave_new_fork" in the page headers, on the title page, and in the document name.
- Move the changelog of the fork you copied at the end of the document
- Start your new changelog with the line that reads something like "Forked from version X of fork Y, named Z, on day DD.MM.YYYY
How can you get a list of changes from a document?
Let's imagine that someone has forked your RPG, made a list of popular changes, but failed to document them properly. To find them, you will need to make a copy of the version that it is based on, and the forked document itself. You need to select all data on the forked document and copy (Ctrl+A, Ctrl+C), then select all and paste it on the copy of the old version document (Ctrl+A, Ctrl+V). You Then look at the changes done by checking the revision history. You will be able to document all the changes yourself, and, perhaps, incorporate into your main fork.
Overall, Google Docs work perfectly for small projects developed by small teams (below like 10 people), but I can't say anything about something larger. Note that, while I have done it for myself, I have zero experience with forking documents as community effort.