Okay so I’m currently writing a ChoiceScript game of my own, I heavily underestimated just how much work would need to be done in order to write the game the way I want to. To make matters worse, I can’t bring myself to dumb down the game just so that it becomes easier for me to continue writing.
So right now, I’m trying to write this big fight between the player’s team against some bad guys. I’m trying to provide different branches and I’ll try to sum it up here before continuing.
The context here is that a mob of enemies are attacking a village from the rear.
So at the beginning of the fight, I have laid out three different approaches, whether it be from inside the village, from the rear, or the team splits up.
So each of these approaches will lead to different scenarios. And from those scenarios, choices will be set up, where each choice will yet again lead to different scenarios.
I’d really appreciate it if anyone can give me any ideas on how to do this efficiently. I have a rough idea of how to go about which is just set up a bunch of labels and gotos but that would be quite confusing when I try to map it out in my head.
I know a lot of people write this down in various programs, but I usually just keep it all in my head (I have a lot of empty space there, yuk yuk yuk). It helps me to visualize it as a circle. Write all the way down one path so that the circle is closed, and then the next, and the next. Make sure anything that is as yet unresolved sticks out, so you know to come back and close the circle for that path too.
Of course, it also helps to have good beta readers, to catch those times when you still left a circle open and it promptly spirals off into infinity.
So you’ve identified the problem and with more branching and variations in the paths people are taking, the worse this problem is going to get worse as you go along. I’d recommend starting with less options and adding more in later if it looks viable to do so, but that’s entirely up to you. The “most successful” way of writing choicescript stories seems to be a branch and return system. You can have variables that impact the story later on, but try not to go out on complete tangents too early as you’ll make a lot of work for yourself that most people won’t even read (many people only play most games 1-2x). Write it how you want to write, but bear in mind that the bigger it gets, and the harder the stats get to track, the lower the chances are of you getting this done (from someone who has been there and done that.)
Depending on how far things are branching out you can do one of two things. The first is to just use gotos and lables within the one file. If you’ve got completely different tracks going on, I find it easier to separate them out into different files and use goto_scene to direct to each distinct branch and lower the chances of entanglement with paths that shouldn’t be meeting up. Also avoid nesting too many choices within choices as it can also result in confusion and is a pain in the neck to track down if you test the file and start finding incorrect redirects due to the wrong spacing in the code.
I also like to use variables to track later choices. For example say you have three distinct senarios depending on if you go to the villiage (1), the river (2) or the city (3). Have a stat that’s something like fight1 and set it for one of those locations so you can tell right away if they’ve met or done certain things on stat checks.
Edit- I did something similar to what you’re suggesting in Abysm’s veil where there’s a battle that can be approached from several completely different angles. Honestly it was a mess to debug and I missed a section that a lovely beta reader picked up for me. I had it all in one file and if I were to do it again I’d separate things out into different files to help make things clearer particularly for debugging.
Identifying the issue (creep) is the first step. If you had not yet done so, there is this wonderful thread to read on just this topic:
This really is a design question you are wrangling with. Many authors here take different approaches to deal with this – @hustlertwo’s circle idea is one. I would also suggest using a flow chart to chart out your game’s path.
With flow-charting you can visualize, where each decision is, where each branch occurs and how you bring everything back into the trunk of the game. There is a free program I use: yEd Graph Editor, and it is a real gem.
There are other tools authors of this community use as well. I would look at the following thread for some ideas and options:
There are no “right answers” for every project – for example, even though I am using the flow-chart system for my major individual project, such a method would not work in a collaboration project. So, with the collaboration project, we are using the old-fashioned game “piece-meal” approach.
We design each “level” of the game as a group, come to a concensious(sp) and then break the levell down into parts that each collaborator then works on. The key to succeeding here is communication. The more you have of it with those you work with, the better you are.
I am very fortunate to have found people that sometimes seem inside my head for this project (it is amazing how we are always on the same wave-length) yet, even with such amazing and experienced people I am working with, we still talk every day we work on the project.
The way I map it out is literally to just map it out. I did this more in Machinations because I’m using a somewhat different approach right now in my current project, but for later chapters I’ll probably go back to this approach.
I use yEd, but any graph editor will work. Ideally you want one that lets you attach notes both to the paths between nodes and to the nodes themselves; I use this to mark requirements (like minimum stat values) on certain paths, and the variables being tracked and how much they change when the player reaches each node, respectively.
Here’s an example of a conversation from late in the game showing both of those things:
And you can break off pieces to keep your structure compact, so you don’t have to have something with a branch that stretches off into the distance. I put that on a separate page. Or to prevent lines from crossing all over the place when certain choices jump between branches, I use mini-labels to indicate that. Those are the green circles here, in this absurdly complex chapter from my current project:
I think one of the important things to realize is that no matter how you branch things, the same amount of work will lead to the same amount of choices, so you need to decide on what detail level you want.
Let’s say you start with the three attack angles (wide scope tactics), that means that the focus of the battle should be tactics, and not go so much into the exact detail of what gets done.
If you want to focus more on actual fighting choices, then pick one of the angles, and have more in depth focuses there.
Sure, you could have both, but then it ends in a massive mess and tons of writing for what might ultimately be little reward.
So the first thing I would focus on is this:
What is the focus of the battle?
If it’s setting stats, I would have shallow but varied choices that can test different things.
If it’s a final challenge that you needs to solve/win, then you need to figure out what would be viable tactics depending on the stats you set.
If it’s a way to get the action flowing and get closer to the mc and their comrades, then you need to have choices that can showcase that.
If it’s to put the fear of god into the mc and make them realize the stakes, then you need to focus on what can be lost.
And so on…
A scene that becomes bloated, overloaded and hard to understand/track/write usually tries to accomplish too many things at once, or you don’t have a clear vision of what you are trying to do. Settle that first, then decide how you are going to do it. Only then can you look at the scene, and each choice as you are tempted to write them and see if they serve the purpose you have decided, or are just adding complexity because technically anything can happen in a story.
I have the same struggle myself. I don’t get the logical graphics. What I do is planning the overall situation and write first ENTIRE IN A very straightforward way maybe one of two branches that divide clearly than when at least the basic outline is done go adding layer after layer of the in-between like main core is done is difficult ending something you cannot handle as the ending is basically designed now you have added stuff over it.
It is not intuitive but could help you end your first project
For me, branching is less about how far I can branch out and more about how much I can branch out before returning to a single set point. When I mentally map out my game (because, despite my poor memory, I still like to keep things in my head), I try to bring every event back to one conclusion by the end of the chapter so that I can start the next chapter with a bang and not worry about the four different outcomes created by the last chapter.
For example, at the end of Voltaic’s first chapter, there are two characters who are either present or gone:
Madison and Adrian both stayed with the group.
Madison went ahead of the group and Adrian stayed.
Madison stayed and Adrian went ahead of the group.
Madison and Adrian both went ahead of the group.
But by the end of the second chapter, they’re both back so that the entire group is together and can proceed up the hill to the party. The second chapter is written in a way that their present isn’t necessary, but can provide benefits for the players who decided to keep them if they choose the appropriate responses.
Now, admittedly, this strategy has its flaws. If you approach a story like this, expect it to be significantly more linear. Your writing is going to gravitate towards the same outcome most of the time, and that reduces the variability. On the other hand, it makes your job easier because you know where everything needs to end up, so you can write scenarios more realistically and choose behaviors that lead to that specific outcome. Plus, it combats scope creep by cutting down on the potential for huge variations that have to be accounted for throughout the rest of the game.
This style focuses a lot more on the approach rather than the outcomes. You always reach the same conclusion, but you reach it in different ways. You can save the huge variations for the endings, where they really matter. I always try to save huge world-splitting branches until the last few chapters because I’m basically writing two different stories if I do huge variations right at the beginning. Players will still get to make choices that reflect their personality even if they can’t just abandon the entire story or split the universe right out the gate.
This article was super helpful for me when planning Voltaic.
Divide and conquer is the name of the game when coding. While choicescript doesn’t really have subroutines or modules, you can still organize your labels so they behave in a modular fashion, preferably keeping each module short enough that it’s easy to see what it’s doing. Avoid spaghetti code at all costs. Also use descriptive variable names, especially booleans for more easily readable code, and comment heavily.
