Is there a more "permanent" alternative to *hide_reuse or *disable_reuse?

Game Development ChoiceScript Help
1

I mean, other than creating a new variable and having the choice be dependent on that variable? My game uses “hubs” that you can return to over and over again to navigate the story. this means that players will often be returning to the same scene multiple times.

I have scenes for talking to each different companion character, and one of your options there is to ask their opinion on a previously completed quest/mission. There’s going to be a lot of missions, so rather than clutter the player’s view with sixty+ choices for each mission, I wanted to use *hide_reuse so that the option disappears after talking to them about any particular mission. The problem is, if you leave the scene and come back, the *hide_reuse resets.

I already know that one alternative would be creating a new startup variable for every single option, and again for every single character, so It’d be like:

*label choiceblock_character1
*fake_choice
 *if character1_mission01_talked_about false #Talk about mission01
  *set character1_mission01_talked_about true
  *goto choiceblock_character1
 *if character1_mission02_talked_about false #Talk about mission02
  *set character1_mission02_talked_about true
  *goto choiceblock_character1

*comment and-so-on...

*label choiceblock_character2
*fake_choice
 *if character2_mission01_talked_about false #Talk about mission01
  *set character2_mission01_talked_about true
  *goto choiceblock_character2
 *if character2_mission02_talked_about false #Talk about mission02
  *set character2_mission02_talked_about true
  *goto choiceblock_character2

but that’s like, a lot of variables and I already have a ton as it is. So, is there a way to permanently *hide_reuse, even across multiple scenes? Or am I doomed to make a disgusting amount of variables?

The other alternative I can think of is, making the choice dependent on whether or not the mission was just completed. I already have a variable for every mission called “current_mission”

So long as you don’t start a new mission, “current_mission” will continue to reflect the last mission you completed. So I could do:

*label choiceblock
*fake_choice
 *if (current_mission = "mission01") #Talk about mission01
  *goto choiceblock
 *if (current_mission = "mission02") #Talk about mission02
  *goto choiceblock

*comment or alternatively: (this one is favorable since it uses less choices, but the choice itself is pretty generic.

*label choiceblock
*fake_choice
 #What did you think about our last mission?
  *if (current_mission = "mission01")
   Character gives their opinion on mission01
  *if (current_mission = "mission02")
   Character gives their opinion on mission02
  *goto choiceblock

The only reason I don’t like this is because, once you start a new mission, the option to talk about a previously completed mission is gone forever. If a player missed that option, that dialogue is totally lost to them unless they start a new game.

This is actually how Mass Effect did things. You could ask your crewmates what they thought about the last job you did, but if you ever forget to talk to them immediately after a mission, that dialogue (usually) is already gone.

I really would like players to be able to explore how their companions fit in the world, and their stances on anything significant you do. Cutting them off from entire dialogues because they didn’t stop and talk to all their crew immediately after every mission is very counter-productive to that goal. In fact, for me in Mass Effect, it always felt like a chore. I would’ve much rather been able to do things at my own pace instead of having a mental checklist of characters I needed to speak to after every mission.

3 Likes
2

Yeah, I think you’re gonna need that disgusting amount of variables. Or reconsider whether you could consolidate many scenes into a single one and use gosubs rather than goto_scene to navigate the options. But if your game structure doesn’t allow that, I don’t think there’s any way to do it without more variables.

5 Likes
3

An alternative that many designers considered was to “record” the dialogue into a journal or compendium form that the player would be able to access at will.

The extensive lore found in some of the more popular games was also an attempt to address this issue.

Both of these approaches had minuses that the devs considered at the time as well, although, these may not be of concern in your situation.

With this engine, and the text-emphasis of these games, I feel the journal approach would be your best alternative solution.

3 Likes
4

That is a really good idea but doesn’t mesh very well with my game’s style, I don’t think.

I do have a sort of “journal” in my stats menu that functions similarly, just not for dialogue interactions. More a recording of events.

5

Consolidation isn’t really an option. I mean even if I did, the effects of *hide_reuse would still only be temporary unless I consolidate the entire game into one scene which… sounds like a nightmare for me lol

I guess the disgusting quantity of variables is my best bet for my desired effect. Just not looking forward to doing it lol. I mean it’s not a huge problem it just means my startup scene is going to get even larger, and that much more annoying to sift through when I have bugs to squash.

2 Likes
6

If it’s any consolation, my startup files are getting to be about the length of what I had previously thought of as a chapter length in my first game.

7 Likes
7

I have not tested this to make sure I have the brackets right, but you could try the following.

My thought process is that each companion’s dialogue tree has it’s own sub scene. Then you just have a variable that checks which conversation you are on. There is a separate variable that you lift after getting far enough in the main story. This makes heavy use of Truly bizarre references.

*create CurrentCompanion "Character1"
*create Character1_CurrentDialogueTree 3
*create Character2_CurrentDialogueTree 4
*create Character3_CurrentDialogueTree 1
*create CompanionMaxDialogueTree 3
*create Character1 "Ed"
*create Character2 "Edd"
*create Character3 "Eddy"

*if {CurrentCompanion&"_CurrentDialogueTree}" <= CompanionMaxDialogueTree 
	*gosub_scene {{CurrentCompanion}&"_CurrentDialogueTree"}
	*set {CurrentCompanion&"_CurrentDialogueTree"} +1
*if {CurrentCompanion&"_CurrentDialogueTree"} > CompanionMaxDialogueTree 
	*gosub_scene {{CurrentCompanion}&"_DefaultConversation"}

There also is probably a better way to do this, it was just a quick write up that I hope helps. If I give it more thought I could probably make this simpler. If you are confused about anything I would be happy to explain.

8

Okay I think I follow what you did here.

But correct me if I’m wrong, this setup only works if the story remains in a linear sequence of events?

My game includes optional side-missions that aren’t in any sequential order. The player could play one before another, vice versa, or play none at all.

9

For the ‘last mission’ approach, this method should minimise the number of variables you need:

*create current_mission "mission_1"
*create current_mission_desc "breaking into the bank to steal the goats"
*create companion "Bob"

#Talk to ${companion} about ${current_mission_desc}
    *gosub_scene mission_discussion {current_mission&companion}

Then you can place all of your mission discussions within the same scene, with labels for each mission x companion combination, E.g., *label mission_1Bob

This approach means you only ever need one set of code, but as you say, restricts you to only the previous mission.
You could have another layer which after the option has been taken for the current mission, it uses an RNG to seed a previous (not talked about) mission as the ‘current mission’, so that the option remains available to discuss prior missions in a random order (you can also add more logic here to exclude very old missions and the like).

If you want to drive it so that they can work backwards through previous missions, then you could have a variable for every mission called ‘mission_order_1’, ‘mission_order_2’ where you store the order in which that mission was taken. So if they did missions 4, 3, 6 and then 1. The corresponding mission_order 4/3/6/1 variable values would be 1, 2, 3, 4. You increment a counter for the current mission order value (5). With a subroutine you can calculate the latest mission that hasn’t been discussed (thus always on the current mission after they do one, then jumping back in the stack to wherever they are up to).

10

Yes, I did build that with an assumption of linear sequence of events. For something more dynamic than that, you would need to make use of a lot of variables. If choicescript truly supported Arrays you would not need so many variables, we would just store everything you need in one.

How many missions are you planning to have? Maybe there is a way we can limit the amount of variables needed.

1 Like
11

More than it’s worth the effort for honestly lol. I appreciate the attempt but I don’t think it can be helped any further. A few dozen variables never killed anyone… yet