Scratching the same itch
Summary: I contemplate the future of my world-building app when other possible solutions exist.
Back in February I posted about my tendency to reinvent wheels. The gist was I like to tinker and I’m a born procrastinator. By the end of the post I resolved to write more and use the tools on-hand rather than making my own.
My resolution (mostly) hasn’t changed, but I left the elephant in the room un-said. What about my world-building app?
The app has undergone various incarnations over the years. Its history and the thinking behind it is documented partially on this blog. Last year I undertook to rewrite it in Python. It stalled a bit while I worked on my novel and few other projects and because I’ve been mulling over what persistence model I want to use. Regardless of its incarnation, it’s purpose has remained the same: to help me organise and structure the worlds in which I set my stories.
Organising and structuring a world-building project is something that all fantasy writers face, even a master like Raymond E. Feist, who’s recently moved on from the Riftwar Saga only to muse that world-building from scratch is hard.
The process of creating a world is as individual to the writer as the craft of writing itself. There’s no right way to be creative – all you need is to be. Naturally, all creative endeavours will benefit from the application of structure and we’re all faced with the challenge of storing and retrieving this information when we need it. It’s here–structure and storage–where I thought my app would help.
There’s no right way to be creative – all you need is to be
Writers the world over have developed different methodological approaches to worldbuilding. Two great strategies that come to mind are include the question-answer format of Patricia C. Wrede and Kitty Chandler’s World-buidling Leviathan. For writers rooted in table-top gaming, there’s a host of DND systems, rulebooks and worlds from which to draw inspiration. Mostly though, I think writers turn to the cultures of our own world as inspiration and, as someone who spend nearly five years studying history and archaeology at university, I’m no exception.
Strategy and inspiration needs application through a tool kit. We’ve all hacked away at our fair share of tools in the pursuit of craft. Most of us start young with little more than pen and paper and a desire to create. At some point, we go digital and adopt whatever tools we have available to us. Pick your poison: Microsoft Word/Excel docs, maps drawn in Adobe Photoshop, personal wikis, a Scrivener project and Microsoft OneNote. As cloud services become more people, people turn to Google Docs, Evernote and new entrant Notebook.ai.
The world is moving headlong into cloud hosted subscription services and it’s not something I’m interested in developing.
Notebook.ai is very similar in concept to what I am building and so its existence has given me considerable pause for thought. I only recently discovered it, after finding a link to it on /r/worldbuilding.
Firstly, I want to get out of the way any notion of sour grapes. I think Notebook.ai is a great platform and if you are looking for a hosted, cloud-based solution for worldbuilding then I strongly suggest you sign up and play with it. In fact I’m kind of relieved they are doing it. The world is moving headlong into cloud-hosted subscription services but it’s not something I’m interested in developing.
Technically, Notebook.ai is quite different to what I’m building: for example, it uses Ruby-on-Rails, while I’m writing mine in Python. It’s built for the web, first and foremost, whereas mine supports CLI, web and (eventually) the desktop. It operates under an open-source model with a freemium hosted service. I’m was never interested in hosting other people’s data but I respect that it’s open source.
There’s plenty of room in the world for more than one open-source project that covers similar ground. I’ve already established there are technical differences; having played with Notebook.ai I can say there’s also stark differences in approach and design. Neither of these are reasons to continue or end my project, however – that’s not my issue; in fact I have no issue with the existence of Notebook.ai at all.
The issue for me, again is down to how I spend my time. Time spent coding is time I’m not writing. It would be entirely reasonable for me to use Notebook.ai and, assuming I can get over my dislike for Ruby, even contribute to the project. I’m under no obligation to create an alternative. Any notion I had of other writers finding my app useful enough to use is now gone. That’s great because now, I not have to bother with developing GUIs, since I’m perfectly happy working on the command line. I much prefer dealing with files and folders to databases and web services.
Notebook.ai has freed from making my personal project user-friendly for others. There’s nothing to stop me scaling back my efforts and building a minimum viable solution from templates with a little pixie dust supplied by Python. Not everything needs to be an app; sometimes, perhaps most times, a well-thought out process and a template is good enough.
Stay tuned, because I’m not done weaving this thread of an idea!