ChoiceScriptDev Wikia

It seems the best way of summing it up is that it could be entirely *fake, if wanted, but doesn’t strictly need to be! As @bawpie points out, the ability to use a simple *set just to record the actual choice made is a significant benefit. I’ve personally tended to shy away from a *fake more often than not, in the (mistaken) belief that I couldn’t record this (IMO, quite essential) player input, which just didn’t suit my preferred design style, at all. That meant I felt obliged to use ordinary *choice more, with all the extra requirements of that command, so I’m delighted to learn that this is not the case after all.

Selectable if does work in a fake_choice, I think it’s as @CJW says, it’s a carbon copy but allows you to lose the goto. It has changed over time though, so the original documentation was correct when it was written.

@Vendetta - it’s very useful as it means you can allow the player to make small decisions without having to code different labels for each choice made.

Sorry to hijack the thread, but I do think it’s important the wiki represents the current build where possible.

@bawpie It’s not “hijacking” the thread; this type of discussion is exactly what it’s intended for! Above all else the wiki is supposed to represent – and be an easy way to share – the combined, accumulated knowledge of the entire community, so that we can all make better games with greater ease (and a lot less frustration!). Factual accuracy of the information provided is therefore absolutely essential.

I just wrote up a page on using ‘Loops’ in choicescript, if there’s anyone who does not properly understand what a loop is (in scripting/programming terms), I’d LOVE it if you could spare a moment to take a look: http://choicescriptdev.wikia.com/wiki/Loops

Let me know if it’s good for beginners or whether it needs further clarification, happy scripting folks! :stuck_out_tongue:

@Vendetta. I’m glad it’s been useful. One thing you can’t do with fake_choice is a nested fake_choice - it won’t let you fall out of the statement (similar to a normal choice). So you can have a fake_choice followed by a choice (which is followed by a goto or a finish) but fake_choice to fake_choice is a no no.

@CJW The page on loops is really useful, and set out nice and clearly. I had an idea of how they work, but I’ve not really utilised them in choicescript yet. I suppose it’d be nice to see some in game examples as well, so as to give the reader an idea on where they could actually utilise loops.

Added an article on Ref Commands (*gotoref and *setref), there’s only the basics of gotoref at present, but if again, anyone not familiar with the commands could check out the page and let me know how easy it is to follow, I’d really appreciate it. Thank you!

@CJW easy enough to follow and made it simple enough to understand. I would say I’d be comfortable in using ref commands after the wiki article.

And after reading the wiki it made me think, is there such a thing of instead of going to a *label, how about going to a nested(embedded) *choice. I would think that a useful option and should cut back in the use of copy and pasting some code.

eg

*lable one
*choice
-#option 1
–*choice
#sub1 option
—*goto somewhere
#sub2 option
—*goto somwhereesle
#sub3 option
----*choice (this might would be a choice I would like to be avalible for another option too)
-----#subsuboption 1
-----*goto thisplace
-----#subsub option 2
-----*goto this otherplace
-#option 2
-*goto overthere
-#option 3
this is where it would be nice to goto the subsub choices…

You’d still need to use labels but you could put them under nested choices like so:

*temp var

Where do you want to jump to?
*input_text var
*set var “chose”&var
*gotoref var

What do you want to do today?
*Choice
__#Go outside
_____*label choseoutside
_____What do you want to do outside?
_____*Choice
_______#Play sports
_________*label chosesports
_________*Choice
Etc…

Typing ‘sports’ or ‘outside’ into the input box would jump you to the relevant sub choice.

Thank you for your feedback on the article! :slight_smile:

Ooo now that is nice! And I can definately use this (at some point in time!)

@CJW
So in theory I could allow the player to sell an item.


*label selling
List of items you can sell
Leather armor
Shield
Dagger

*input_text var 
*set var "choose"&var *gotoref var

What would you like to sell?
*choice
 #leather resell 15 coins
  *set coinage +15
  *goto selling

This just a small sample of what I am thinking. But in general this would work? And do I ned to set var up in the variables? Thanks

@Lordirish Every variable you use needs to either be created with mygame.js or with *temp. However, buying/selling items requires not extra variables aside from the ones to track the items and the money. Lets say you have leather_armor which is a boolean set to true if you have it, and false if you don’t, and coins which tracks your money. Then the code is just:

\*label store
This is the store. You have ${coins} coins. Would you like to buy, sell or leave?
\*choice
  #Buy
    You have ${coins} coins.
    \*selectable_if ((leather_armor = false) and (coins >= 20)) #Leather Armor (20 coins)
      \*set coins - 20
      \*set leather_armor true
      You bought leather armor for 20 coins.
      \*goto store
    #Nevermind
      \*goto store
  #Sell
    You have ${coins} coins.
    \*if (leather_armor) #Leather Armor (15 coins)
      \*set coins + 15
      \*set leather_armor false
      You sold your leather armor for 15 coins.
      \*goto store
    #Nevermind
      \*goto store
  #Leave
    \*goto leave_store
\*label leave_store

Now, when you enter the store, the option to buy leather armor is selectable only if you don't have a set, and have the money to buy it, while the option to sell only shows up if you have a set. Is that what your looking for?

@Lordirish you’d need *label chooseleather beneath that choice

Thenk yo@Reaperoa and @CJW
Its not a probem as far as calling the items as each will be set up for easy calling such as leather is set s_item12. Just was not sure about set a varible for var.

You don’t even need to call it var, nor do you need to use a concatenated name. You can just do *gotoref var after the input (*set should be on another line anyway). You’ll need to name your labela accordingly, of course.

Not that anyone’s officially responsible for the material, but if there’s somebody want to talk about a super simple savegame module on the wiki, I could really use it.

:>

@FcA the problem with that is it’d require “hacking” of some sort and COG still haven’t got back to us about how that would affect game publication. So it’s possible that creating a custom back end save system will prevent your game from being converted by CoG - I guess you wouldn’t want that?

@CJW Thanks for the heads up.
Looking back again at earlier threads I am guessing that there hasn’t been anything “new” since last time people talked about it? I understand that custom-made save system would likely have compatibility issue potential vs what CoG have running on their end. I was just thinking if we could have something similar going while playtesting the whole project, ie testing the save system itself. Not sure if I would go with that method with long password etc. Oh well. Back to working on the story for now.

It’s something I’ll endeavour to look into promptly :slight_smile:
I’ll be sure to share any findings!

@CJW What about hacking CS? As long as you’re using the *script command, it’ll work fine in CS.

@jasonstevanhill

I cannot tell you how happy I am to hear that, thank you! I’ve actually sent a couple of emails regarding the *script command to your support address and haven’t received a reply. It’s wonderful to know that’s the case at last, thank you.

With that information I’m sure we can definitely come up with something!

I’m also presuming you’re ok with the wiki so far, I do believe Alex tried to contact you before it’s “announcement”, but we went ahead, having not heard anything against it.

Thanks again!

@FcA consider a save system on my todo ASAP list! :slight_smile: