As I said in the previous post, I’ll be making the game in Twine first, and then porting it to Decker. My original idea, though, was to make an “open-world” exploration RPG, something like SaGa: Scarlet Grace or Emerald Beyond, in RPG Maker. Maybe go even further and do something like Romancing SaGa 3, which is a bit more traditional, with proper dungeons and towns to explore. But, I don’t know anything about proper game development. Also, making a game with visual assets means either buying or drawing them, and then visually building the scenario, and then setting up the combat system, enemies, and so on. It’s just too much stuff for someone inexperienced working on something a few hours a week, so I decided to go to the minimum required to make a game: words and choices.
Going with Decker for the final “engine” of the project, though, means that it will still have visual elements. However, they are going to be sparse and illustrative, not part of the gameplay, so it should be manageable. Things like MacVenture, or even World of Horror, show how much the 1-bit aesthetic can express, and it’s awesome. With the tool I made to import images more easily into Decker, I can grab copyright-free photos and they will fit nicely with the overall game visuals thanks to Decker’s native conversion. I even got to know someone who’s a great artist and a Decker wizard (shoutout to crowmorbid, go and check their projects), from whom I plan to commission at least a cover and background art when the time comes.
But before I get to that, though, I have to have a game. That’s when Twine comes in.
The thing about Twine is that it’s very easy to use. A lot of text-adventure/interactive fiction engines are. Twine, though, is the easiest of them all, and being able to check connections between events makes for a quick way to manage branching paths. It’s very easy to prototype something there without that much knowledge of coding, and I plan to take advantage of that. Decker wasn’t built to handle “proper” game development for things like this, even though it’s totally capable of it, as the “stack of cards” concept works fine, but when you start to have branching paths, things might get confusing or be lost along the way and, especially with every widget containing (or not) bits of code, it might be hard to track bugs or diverging paths. Twine’s easier on that front.
Don’t get me wrong, though: Decker is awesome and it will be the final platform for this project.
Concept
As stated in the previous post, the game will be based on a short story I wrote. It won’t be a recreation of that story, but a shoot-off of that idea: crossing a dangerous desert in a caravan and the perils and challenges this involves. The game will have resources, but it’s not a resource management game: whatever the player has is always depleting, so the desert has to be crossed before they finish. Think of The Oregon Trail, except that’s impossible to acquire supplies. The player will be met with random events that might or not have repercussions along the travel, but they will most definitely consume the limited resources available.
For the Twine prototype, I chose the Chapbook story format: it’s the newest and the most untested of all formats, but also the easiest, requiring the least amount of coding syntax. This has its pros and cons, as I’ll show soon, but so far I’m happy with it: it’s easy to edit the footer and header, the default template has great readability and dark/light theme, the testing/debugging is very comprehensive, and the snapshot feature will be handy once I start to test branching events. Also, it’s very easy to read the prose in the code
Loop
When starting, the player will be met with introductory scenes to learn about the world. The game has 5 resources: Food, Fuel, Guards, People, and Machines. What they do doesn’t matter for now, but it’s relevant to know that Food and Fuel deplete daily, and some events might change the rate they are consumed; Guards and People might deplete according to some events’ resolutions; Machines is an important resource that, if reduced, can have severe consequences over the rest. Each day has 3 different “stops” with chances for events — Morning, Afternoon, and Evening — that might affect the amount of resources. If Fuel, People1, or Machines reaches 0, it’s game over.
At first, I thought about letting players choose how much of each resource to use. This would shorten or lengthen the cross using a hidden variable for distance — which didn’t use any real distance measurement, it was just a numeric value easy to keep track of. Since Chapbook doesn’t do variable calculations with if statements, only after reloading the page on a passage change, I had to work around that by using two pages for events instead of one and relying on embeds to do the calculations (because Chapbook only does calculations in the var section). I made it work pretty easily, despite looking like a mess.
It looks confusing, right? But it’s pretty easy: the player would choose how much Food and Fuel to consume at food and fuel choices using cycling links to save their choice in a variable, and then proceed to the the next passage, food and fuel resolution, where it would change the formula for consumption with an embed passage under an if statement for the variable chosen in the previous screen. The high, medium, and low passages each contain just two lines of formulas, due to Chapbook’s limitation. On Harlowe or SugarCube, none of this would be necessary. I don’t mind, though, as I still find Chapbook easier to handle.
Anyway, the player would originally do this 3 times a day. On this screenshot, it was reduced to only once a day. The reason was… that it was boring. It was a boring aspect and very repetitive2 that didn’t add much. Even in the screenshot’s format, it was still very boring, so I chose to remove it completely and focus more on the writing. Now, the consumption has a fixed rate, being changed only by events instead of it being a daily decision. This simplified things so much that I was able to put almost every formula in a single passage that will be called, through the embed passage, 3 times a day, freeing me to focus on the events.
The current structure of the basic gameplay loop now looks like this. The red passages cover what was on the screenshot above.
The game will do variable calculations each Morning, Afternoon, and Evening with the embed passage on their respective “hubs” — noticeable due to the dotted line — and then check a few resources. If People, Fuel, or Machine is 0, it’s game over; if a hidden variable reaches its maximum, it’s a victory. If none of this happens, the game will roll a d5, with a 2/5 chance of nothing happening. With the other 3/5, something happens, so it will lead to random events that might have instant effects or late repercussions.
And this is where I’m at now.
This is just the skeleton of the system, but already uses tons of variables and conditionals, all of which would be hard to handle and test on Decker. I spent quite some time trying to predict issues and coding solutions to the most probable problems and resolutions, but the loop is mostly ready, now I just need to start writing the events.
Events
This is the part that will consume the most time, as mixing branching paths with random events will require a lot of writing. At least, with an interactive fiction project, it needs only writing and nothing else. I did some basic math and the crossing should3 last ±X4 in-game days, so I have a ballpark of how many events I need to write. For the “nothing happens” rolls, I think 5 generic-but-nice-to-read repeatable blocks of text for each time of the day should be enough to avoid being too repetitive, but I might add more over time. As for the events when something happens, though… that’s another story. For now, I think I’ll need to write around 100 of them, give or take, to keep things interesting. A lower number might be enough, but a higher number can provide more variety. Since the game will be short — I’m predicting each session should last around 30 minutes, but there’s no way of knowing for sure right now — a larger variety would make the game more replayable or, at least, more interesting. If nothing goes wrong with my life in the meantime (haha), I think this can be done in a few months, like 4 or 55.
Now, this is the part where Twine’s advantage really shows, as I’ll be able to track branching paths and connected narratives just by eyeballing the interface. Since the game will happen through the course of multiple days, I’ll have to use control variables for all of the larger events and conditionals to check them and bring up the consequences later. I have no plans for making multiple endings, the journey will be the most important aspect, but I might add some depending on how things go when I get to this stage. For now, I just need to start writing and see if I’ll have to expand the original loop or if it’s ok the way it is.
Finish
After all of this is done, I’ll test and retest the game to look for bugs and see if it’s enjoyable to play. If it’s worthy enough, I’ll rewrite everything in Decker — which should go pretty smoothly, as the hardest part will be already done — then I’ll add images and whatnot, and then it will be ready. If nothing goes wrong, the whole development should take between 6 months and 1 year. It seems like a lot, but I’ll be working only a few hours a week on this project. If I could spend 8 hours a day on it, I guess it would take only 2 or 3 months.
In any case, it’s a large project for someone without experience to make. I’ll probably keep working and releasing smaller projects in the meantime, not only to learn new things, but also to avoid burning out on this one. Protracted development can definitely be a motivation-killer if not paced well. Ask me how I know this.6
So, this devlog got a bit longer than I expected, but it’s just to get the full context of the project out there. I don’t know when the next one will be written but, I hope, it won’t be as long as this. Since now the only thing left to do is proper writing, I’ll give out less details about in-game stuff and will, probably, talk more about the practical challenges with branching and random narrative and Chapbook’s coding limitations.
Not gonna lie, though: despite being limited by design, I’m loving to work with it. We’ll see if my opinion on that changes in the coming months.
- I just noticed the code was checking for Food instead of People, so I’m starting to see the benefits of writing this devlog already. ↩︎
- Hence why we must build prototypes, I guess: to find out about this stuff early in development. ↩︎
- I’ll only be sure after the whole thing is done. ↩︎
- I won’t reveal how many because it might spoil a bit of the discovery and the fun. ↩︎
- It will be funny if I end up way off on this. ↩︎
- Please don’t, I’ve signed NDAs. ↩︎