Iterative Worldbuilding

Starting is always the most exhilarating part of any project. But that exhilaration quickly turns to disappointment when you finally put pen to paper (fingers to keyboard in this case) and the result doesn’t live up to what you had envisioned in your mind. It’s easy to get discouraged at this point. Hell, look at the giant gaps between posts as I delayed publishing because what I have written didn’t quite live up to my own expectations.

I think the mistake here is thinking that you’re working on a book; that there’s an end state that you’re working towards. But world building isn’t linear. Neither is writing books for that matter. But even more so than ever before, the text is living, it is subject to change and evolution, and doesn’t have to be constructed to its final perfection before publishing. And it most certainly should not hold up other pieces of the project while you tinker with production.

To be honest, the Mars artifact here is quite disappointing. It’s very generic and lacks any sense of creativity. However, I had to get it out of the way to move on. By no means is any of that set in stone. In fact, I expect it to drastically change over the next few months but you have to start somewhere.

Hwever, as I thought about the subsequent iterations that are to come, I quickly came to the realization that there needs to be a method of organizing the various changes. Managing change is a common problem in the realm of software development. There are many ways to tackle it but for my purposes here I thought that Semantic Versioning would be quite useful. A more complete explanation can be found here but in short it is a numerical system that indicates changes. In the software model, the changes are presented as such MAJOR.MINOR.PATCH.

• MAJOR version when you make incompatible API changes
• MINOR version when you add functionality in a backward compatible manner
• PATCH version when you make backward compatible bug fixes

This can easily be modified to suit our purposes here:

• MAJOR version when change becomes incompatible with previously established continuity
• MINOR version when changes are still compatible with current continuity
• PATCH version minor updates to details that do not have any great effect to the continuity

Who knows if this will work. Perhaps, we’ll need a more granular system with major and minor patches but for now it will suffice. All artifacts will now have a semver (semantic version) number associated as to indicate how well developed the current state of the artifact is.