Best Way to Code Differentiated Scenes

I am working on my first ChoiceScript game, and so far it’s going well. I have learned the basics of the language, and I feel comfortable with it.

I am curious about the best/most efficient way to program the following scene type though, since choices/scenes like this are going to be pretty common in my game.

Which character will you go with?
*choice
  #Character A
    *goto scene2
  #Character B
    *goto scene2

Basically the main action in scene 2 would be the same. The differences would be mostly character interaction/dialogue.

The way I see it there are three ways to handle this kind of scene:

  1. If statements
    At first I thought this was the best choice, but I found that characters a/b played such a big role in their respective scenes that I basically had an if statement for every other sentence. This created an excessive number of labels and was pretty confusing to read (it also seemed to me that option 1 was just a much more involved variant of option 3 below)
  2. Temp variables
    I could create temporary variables for their names, pronouns, etc, but then each scene would be identical except for the name that appears, so there wouldn’t be differentiated dialogue at all
  3. Different labels
    Finally (and this is the option I’m going with so far), I could send the PC to different labels with their differentiated scenes (illustration below)
Which character will you go with?
*choice
  #Character A
    *goto scene2_characterA
  #Character B
    *goto scene2_characterB

I don’t see any draw backs to option 3 (except that it might artificially inflate total–though not average–word count), but as I’m so new to ChoiceScript, I wanted to ask for other opinions.

Thanks for your input!

5 Likes

I personally going for the conventional way, the first method. This way, I still have a total control of what will be said by both A&B characters, giving them distinct personality.

Of course, coding the first method is a hella nightmare, but it’s much easier to read than coding the third one; I’m only creating new labels if the scene contained within is substantially different (i.e. the setting takes place on different… place)

3 Likes

It might be worthwhile to not that implicit control flow can be used to prevent massive numbers of labels in *if statements.

3 Likes

The control flow doesn’t reduce the use of labels in *if. What they does is removing the *goto requirements on every #options, which in turn eliminate the consequent *labels.

1 Like

Implicit control flow also prevents the requirement of *gotos in *if statements.

1 Like

Even without implicit control flow, *if statements don’t need a *goto (unless you’re using *else, or want them to take the reader somewhere other than the next line). My game is peppered with *goto-free *ifs.

Edit: though many of them will be multi-replace functions in Game 2. That’s another option to consider.

5 Likes

I usually prefer labels, as I make less of a mess using them. If statements are prone to all sorts of bugs and errors, at least for me, so labels it is.

2 Likes

Sounds a gosub routine to fetch the character details might prove helpful. If you’ve got more than two pairs of characters.

If you’re text flavour is different multireplace is probably your tidiest best. If you’re changes are a lot heavier you’ll need to move towards if/goto special labels/scenes.

1 Like

Very helpful! Thanks :slight_smile:

Hadn’t considered this, but my scenes could be reformatted to incorporate this/avoid the labels, thanks!

I’m still pretty new to ChoiceScript, so I’ve admittedly not used the gosub command yet, but I don’t think this would help me since I’m not reusing code. Have I misunderstood/could you help me understand what you mean?

2 Likes

Gosub permit youto use *return into your code. With this you can gosub to a “character B” specific scene/test/routine that do stuff and then *return to your previous scene thus averting a break in your game flux.

Another feature I love in gosub is that any *temp variable you declared will work normally in your *gosub. Even if it’s another scene. I barely use *goto and prefer to use *gosub because of this recursive ability in coding.

But I’m a weird old man that like to overthinking stuff that probably a concatenation would make it work in an easier way.

1 Like

I recommend using multireplace for small stuff that isn’t worth creating variables for. Minor dialogue changes or differences in reaction. Etc.

2 Likes

I was looking through the code for dinoknight, it uses a technique that might work for you. I dunno what you’d call it, but I thought it was pretty nifty for fluff text based on variables, rather than using *if statements which lead to labels and whatnot

Weird Code-y stuff. Spoilers for Dinoknight

Your @{(joined_sargossa) heart sinks. What will happen you now, with your mistress gone?|knees go weak with relief. At long last, Sargossa’s terrible darkness has lifted.}

1 Like

Multireplace. :slight_smile: That’s what a couple of us have mentioned upthread.

2 Likes

Ah, thanks!

You have no idea how excited I was when I saw you could do it, solved my headache of having flavour text have to fall into different labels

I find a very effective way is to copy and paste the scene then rewrite the 2nd version. That way I can focus more on writing creatively than coding. Lots of little differences and nuance in the narrative text. And I’ll also change a few of the choices while I’m there.

1 Like

Note about multireplace:

  • you can not nestle them
  • you can not have linebreaks in them

It’s possible using the [n/] tag, you know.

Eh. I think in such case using if again makes keeping track of the formstting easier. Also: how does screenreader handle that?

From the diverse responses it seems like this is a different strokes for different folks situation.

Thank you everyone for your input! I’ll definitely play around with these suggestions to figure out what works for me as a coder.

1 Like

If you need a paragraph break, using *if is definitely the better option than double [n/].

And AFAIK, unless the user set up their screenreader so the app will mention all the punctuations, I don’t think it should be problematic. Heck, even if it does, it shouldn’t pose any problem anyway.

It’s not like the app will tell you “left square bracket - N - slash - right square bracket.”