Is there a maximum number of choices that can be used with the *choice command?
I’m hoping to include a couple hundred choices in one *choice, as long as it doesn’t break the language. Yes, I have my reasons. 
Most will be hidden with *if modifiers.
Well, my longest *choice record is 10 #Options.
And it works just fine 
But those options are actually consisted of single word. And no hidden options.
No! No 
solution!
Bad @Sophia!
He found out?! Run for my life~~ 
I’ve used 40 odd before without any issues. I don’t see why you couldn’t use 200+
Let us know when you’ve got there, @Lucid…
Wow. A couple hundred. I am goggling at the very idea. I need to see this choice right away. I feel like there would be diminishing returns after the first hundred, but I love the notion.
Correct me if I’m wrong @Lucid, but I believe only a quarter of the choices at most (perhaps less) will be visible in any one play through.
I do actually have a choice with 100 options, but I broke it down into groups of 10 for convenience. That might be an option…
No, it needs to be all of them. It’s a “drop, sell, examine” from inventory. I’ve done some interesting *setref and *gotoref coding to make it all work, but the easiest way to do something from inventory is to list all the objects that ‘could’ be in inventory, even though most won’t be.
Hence, a 1000 option choice is born.
If it won’t break the code, I’d like to keep it. I use a weight system, so this works nice. If I did an “each item weighs 1 unit” system, I would code it differently.
I don’t know how Choicescript works, but I hope that it’s essentially unlimited options, reading them all until they’re done. Nobody knows for sure though, eh?
At one point I had 50 choices and it worked fine but ended up dropping the idea as many readers complained it was to long a llst. Your idea sounds intresting.
That won’t technically be a problem - just consider whether it will make your code or your menu unreadable due to complexity.
I guess if it was a problem, you could group the items by type. (e.g. weapons, potions, etc, depending what genre you’re writing). In fact, that might be easier for the reader to use anyway, thinking about it…
Yes, they’re grouped. It seems like a lot of choices, but you’ll never get them all, unless you somehow manage to carry item every in the game, but you won’t have the strength to reach that weight limit.
I would like a more educated answer, since it could change how I code my next game.
Sorry to tag you guys, but this is kind of important to me @dfabulich @RETowers @jasonstevanhill
Closely on the heels of this question and while I have your attention:
Thanks for your time.
My educated guess will be, it depends on 2 things: software and hardware.
Software. Can the Javascript handle xxx kB of text files and renders it?
Hardware. Does the player’s hardware can handle the rendering process? Is the RAM large enough? Is the processor… not too underperforming and crash?
That being said, I’m not really a coder-man or a computer-engineer, so take my words with a grain of salt.
Perhaps @dfabulich can enlighten us (again)
That’s exactly right. Nobody’s ever tried to stress test it. I’d be especially curious to see how many options you can have on an old Android phone.
Having said that, there might be a cleverer way to handle this with arrays. You can presumably have no more than some small number N items at a time, so make your first option be #${item_1}. Then the choice will have no more than N options.
Thanks for answering.
So, from what I gather, CS itself has no such limitations, but old hardware might prove to be an issue, but it’s untested.
I don’t know how things work on the inside, but as a device goes through the *choice, does it have to store the unavailable options hidden in an *if? If not, then I’d be even more safe, since most of the options are skipped over.
This sounds good. If older devices become my only problem, I could always provide a disclaimer. I think all will be well.
It does store even the hidden options. But I think it’ll be fine. It’s just text being stored for the options, along with a few other pieces of information like whether it’s a selectable_if. It’s a pretty small amount of memory per option. You’re more likely to run into problems first with overall scene size. Even then, it’s all just text – pretty memory-light compared to pictures. Nobody is likely to break anything by making anything about a ChoiceScript game big. In the worst case, you’d make the scene slow to load by giving the interpreter too much to chew on. How bad that is, seems pretty device dependent, but it seems like you could almost always solve the problem by breaking things up into more scenes.
But I second Dan’s suggestion. Arrays seem like a good way to not need to make giant choices. You could probably have an array that contains the maximum number of items per screen, then an option for “next page” that loads the next N items into that array. You could nest that in another menu for buy/sell/inspect. Then have all the options just lead to a different gosub for each action, where the gosub processes the item based on price and weight and whatever.
Any time you have repeated code, you can probably make your code smaller. The more you can make your code smaller, the fewer places bugs can hide. This is generally accepted programming wisdom.
I’m not the best coder, but I’m not too bad either. I’m using all of the arrays, setrefs and gosubs that exist. I code for fun, so it’s very spaghetti like and would probably give a professional coder nightmares, but it’s also fairly efficient. You’ll find very little duplicate code in it.
The problem with using an array-based system like that is that it makes each item a single entry and then makes your capacity based on number of items. Multiple items of the same type would also cause some difficulty, as well as searching through what is being held.
I’m using
*set item_5_owns 3
This gives unlimited storage, but it’s based on weight instead. Multiple items automatically group together, so holding 3 apples uses the same data as 75 apples, which helps. Checking to see if a person is holding a particular item is very easy.
The only part that becomes worrisome is the examine/drop/sell *choice, which is a single routine for all three, which cuts back on duplicate code too.
I could potentially check a group of 100 items, but if a player only holds one from that set, it would display a single option and then the next set could be enormous.
If I don’t run into any trouble with leaving it all in one choice, I won’t touch it. If it becomes a problem, I could break it into types. Use an *if, then have a *choice for weapons, another for armor, another for items, etc. That’s my backup plan.
Well, it sounds like if you wanted to, you could iterate through items until you had filled the whole array to display in the menu – incrementing N in item_N_owns and incrementing numDisplayed when you hit a count > 0 until numDisplayed hits the number you want on the page or you run out of possible items. But it also sounds like you have working code already, and there’s certainly something to be said for that.
I didn’t mean to impugn your coding – I just made assumptions from the fact that you weren’t looking in scene.js for answers. I can be a little too didactic at times, I admit.