I’m working on a project, but I’m lacking a bit of motivation lately, so maybe writing about the project’s development here might help.
Also, I opened the project for the first time after an almost two-week hiatus — due to the lack of time — and got completely lost about what I was doing. I keep a project journal around (like, a physical journal, where I write with a physical pen on physical paper) to put ideas down and develop them, because writing things on paper helps organize my thoughts, but I don’t write what I actually did in the project itself — since I can’t index entries and search with a Ctrl+F like in a digital journal, it’s kinda useless to do so on paper.
So, yeah, I think keeping a log of development on this blog might benefit myself, in case I go again for long stretches of time without opening the project due to being too busy, and will probably motivate me a bit more to keep doing what I was doing before.
But, well, first of all: hi there! I’m not a game developer or a game designer or a programmer or anything like that. I have no idea what I’m doing. If someone else besides me is reading this, please, don’t trust what I say or my problem-solving skills.
Things to keep in mind
Why
I don’t know how to draw, I don’t know how to do 3D modeling and rigging, I know how to make music and play instruments but not how to compose with intent (or mix and master well enough), but I do know how to write in an acceptable manner. Given this, the game will be an interactive fiction, so I can use my best skill as much as possible.
Since I like to write boring things about places and occurrences, and not grand adventures or detailed personal stories, I figured that making a game with random events to explore a specific scenario would be easier than trying to write a novel or something of the sorts.
We’ll see if I was right.
How
Twine and Decker. At first, I was going to develop a prototype on Twine, due to being the easiest engine around to use, and then “port it” — meaning “redoing everything from scratch” — to Decker. But the project started to get too complex early on, so I decided to abandon Twine’s prototype and move straight away to Decker.
However, given the number of events and conditionals I’ll have to deal with, and how much work it is to self-organize cards and code on Decker, and how hard it would be to edit stuff if I wanted to change them later, I’m going back to Twine to finish the project there first, and then “port it” to Decker. There, it will have some illustrations and, hopefully, a more engaging interface.
Deckstamp was built to help me import images in an easier way into Decker; The Steppe was a “vibe check” and to learn how to navigate cards; Pet the Cat was to learn how to control elements in other cards, read code in fields, choose random cards, and make a hidden point system (details about how it all works here). All of them have useful bits of code (or whole modules) that will help me do what I want in Decker.
What
This is the thing I haven’t talked with anyone yet: it will be a game based on the setting of a short story I wrote a few years ago. The setting is called “The Old World” and I have tons of ideas for its world, but I’m not a worldbuilder, I make things as I go while following a loosely set of rules and vibes. For now, the desert is the most developed part of the scenario.
We’ll see if I can wrangle something narratively interesting out of this whole ordeal.