I’m feeling a bit ambitious these days and have decided to create a kind of “proper” inventory system for my game, one that is based on arrays and allows actions such as equipping, unequipping and using items from within the stats screen. I’m going for a more old-school granulated experience, basically to see how close I can get a CYOA type game to feel like a classical puzzle based text adventure.
Anyways, I’m stumped with this bit of code:
Which item do you want to equip?
*temp a 1
*choice
…*label loopstart1
…*if (it_loc[a] = 1) #Equip ${it_name[a]}
…*set it_loc[a] 2
…You equip ${it_name[a]}
…*set a a+1
…*if (a <= 8)
…*goto loopstart1
…#Return to stat screen
*goto scr_main
So, array it_loc contains locations of items, with value 1 being carried and value 2 is equipped. it_name contains names of the items. This loop is supposed to go through all the items in the array and display a choice “Equip X” for each item that has value 1 as its it_loc.
But it’s not working. I get a message "Invalid indent? Expected an #option here not *label at the *label loopstart1.
So, if any gurus out there can help me out with this? I know that arrays are pretty much ignored and perhaps even half-implemented by the devs, so is this even possible in CS? I’d really hate it if i’d have to go through each and every item in the game via if… choices…
Afaik I don’t think there is a way to create dynamic choices like these, I wish it was possible. You’ll have to manually create these choices for each of the items (I had to do the same).
This is pretty much why I limited my stuff to a fixed number (6) since I would have to deal with each choice manually.
Also I recommend you use some sort of identifier for the index instead of just “a” (even something like “counter” is easier to understand), something that is more clear what that number is supposed to be.
I was speaking to GoldenSilver about this a few days ago. I’ve actually got a half-written article/tutorial written on how to create ‘dynamic’ choices in ChoiceScript. GoldenSilver is right in the sense that you can’t just “loop over” option lines. I honestly think this is a good thing, at least as far as syntax and code presentation go. Now you can dynamically “construct” choices, but alas, you’ll always have that finite cap on the number of options you can have (based on the amount of static physical # options you’re willing to write out). And let’s be honest… Anymore than 6 or so options on a screen can get messy anyway.
Afaik I don’t think there is a way to create dynamic choices like these, I wish it was possible.
All that said, I think there is definitely a way to create truly dynamic choices, with a reasonably infinite* limit, and variable amount, of options. It’s not a novel concept, quite an old one actually, but I think it’s an application that hasn’t seen use in ChoiceScript yet: pagination.
Admittedly it comes with its own caveats (like the tedium of clicking next/previous*), but I do believe it solves the “issue” at hand. I’ve spent a lot of time working on systems implementing various implementations of this, and have been very impressed with what I’ve been able to create (including email inbox, and an equip/unequip inventory with criteria filtering). It’s probably not going to be a catch-all for everyone, but it might just be enough to at least inspire more out of the box thinking when it comes to constructing more dynamic choices.
*Which you might see I’ve spent some time improving with a ‘predictive’ system that swaps out the positions of the next/prev options, so the most likely to be selected is the default.
I’ve listened to GoldenSilver’s advice as it seems that there is no way to get a loop into *choice construction However then I’ve run into another problem, and that is that variables do not update automatically once you leave stats screen… It seems that you have to move to the next passage in order for variables to update - not good.
So, my idea was to be able to have a following scenario: You encounter a door, you go to your stats screen and do use item → key, when you leave your stats screen the passage is updated with a message that you’ve opened the door using the key (and choices update to show that you can now go through it). However, with the way CS seems to be set up this wouldn’t be possible… Or does anyone have an idea how to get around this limitation?
Oh and as for CJW’s remark, I don’t think the number of options would be a problem… The loop checks whether the item is in your inventory (which can be made limited for extra old-school vibe) and then presents a choice based on that. Also, most items cannot be equipped so with the item set I have in mind i don’t suppose there would ever be more than four or five items on the list…
Thanks!
I’ve already found that thread but I can’t understand how to use *redirect_scene in this context. Basically it is just like *goto_scene, right? So… as I understand it I change the variable and then use *redirect_scene to return to the original passage or what? I don’t see how this would help in any way because it would return me to the beginning of the scene rather than the passage I accessed stat_screen from…
Please, could you give me a code example of how to use *redirect_scene for this purpose?
You’re right, it’s very difficult to do (as you never know when the stats screen is going to be called from). I’d sooner suggest you just add a hidden option to a choice in the main game code, rather than trying to allow usage of the ‘key’ from the stats screen.
Oh well… I guess I’ll just have to give up on my grand project of a puzzle based CS game… I doesn’t really make sense to have a puzzle if the solution is clearly offered as a choice.
Imho, CS is a bit too tight and stingy with features. I understand the minimalism and simplicity argument but I believe it can be going too far if you are sacrificing utility for it, especially if we are talking about a creative tool rather than a consumer product. I don’t know why the devs are so afraid of giving more power to creators who would like to be a bit different… Even simple arrays are all but hidden in documentation for fear of… I don’t know what. “Adding complexity without adding value.” Lol. I don’t want to sound salty, but it does seem kinda patronizing and passive aggressive to me. “I personally can’t think of why would anyone need arrays (or variable changes in stat screen) so I am not going to give it to them… because I’m the smartest person around and no one can think of anything that I can’t imagine”.
So I’m not sure if this is what you’re going for, but have you considered using *input_text as a pseudo parser to interact with objects?
Teach the player some simple commands so they know what to try and you have a flexible system for letting them puzzle out what to do.
In your example, you could have a choice at the door that leads to a text field where the player would need to enter “use bronze key” (for example) with the key in their inventory in order to unlock the door.
However then I’ve run into another problem, and that is that variables do not update automatically once you leave stats screen… It seems that you have to move to the next passage in order for variables to update - not good.