Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Multiple variable dependant widgets

So in my little game the player can choose between being a man or a woman and a couple different races. I would like to have a couple different widgets that are dependant on whether you are a man or a woman, your race and maybe another stat, strength for example.

I don't know how to write the code for this though. As an example this is sort of like what I want to do..

<<widget "plr-body">>
<<if $plr.gender eq 1>>
<<if $plr.race eq 1>>
<<print "strong toned body">>
<<elseif $plr.race eq 2>>
<<print "short strong dwarfen body">>
<<elseif $plr.race eq 3>>
<<print "tall elfin frame">>
<</if>>
<<elseif $plr.gender eq 2>>
<<if $plr.race eq 1>>
<<print "wiry human body">>
<<elseif $race eq 2>>
<<print "short curvy body">>
<<elseif $plr.race eq 3>>
<<print "lean elfin frame">>
<</if>>
<</if>
<</widget>>

That's just an example but the format is what I really want to know how to do. How do I stack multiple dependant variables within a widget.

If a character is a female, human with a strength of 10, the widget displays x.

If a character is a male, dwarf with a strength of 15, the widget displays y.

and so on and so forth..

Any thoughts? Am I even on the right track here?

Comments

  • edited June 2016
    If the first choice is to be female or male, it would be best to have a separate variable for that first, then have separate male and female widgets.

    <<if $male is true>><<malebodywidget>><<else>><<femalebodywidget>><</if>>.

    Otherwise the one widget gets needlessly complex imo.

    Also there's no need for a print macro in that, just write the text normally. <<print>> should only be used for dynamic text, eg <<print "This variable is" + $variable>>.
  • Might be more efficient to set the values up in an array, and then have the widget use the variables for a look up.
  • To expand on @mykael suggestion:

    1. Create an multi-dimensional array like the following to store the body descriptions in, the first outer element (index zero) is for females, the second outer element (index one) is for males. Because your races are one based I added an extra inner element at the start, the rest of the inner elements are the same as your examples.

    This code goes in your Story Javascript area:
    // The first element in an array has an index of zero, not one.
    //
    setup.bodyDesciptions = [
    	// Female body types ($plr.gender == 0)
    	[	"Unknown",
    		"wiry human body",
    		"short curvy body",
    		"lean elfin frame"
    	],
    	// Male body types ($plr.gender == 1)
    	[	"Unknown",
    	 	"strong toned body",
    	 	"short strong dwarfen body",
    		"tall elfin frame"
    	]
    ];
    
    2. Re-write your plr-body widget to look something like the following:
    <<widget "plr-body">>\
    <<print setup.bodyDesciptions[$plr.gender][$plr.race]>>\
    <</widget>>
    
    3. You use the new widget like so:
    <<set $plr to {}>>
    
    <<set $plr.gender to 0; $plr.race to 2>>
    Female dwarf: <<plr-body>>
    
    
    <<set $plr.gender to 1; $plr.race to 3>>
    Male elf: <<plr-body>>
    

    note: It would be a good idea to renumber your race (and possible gender) types so that the first race equals 0 (zero), the next race 1 (one), and so on. That way you could delete the "Unknown" elements from the bodyDesciptions array.
  • edited June 2016
    That seems complex for a simple <<if>> operation. Is there any advantage as opposed to doing something like?

    <<if $male>><<malebody>><<else>><<femalebody>><</if>>.

    <<widget "malebody">><<if $plr.race eq 1>>strong toned body<<elseif $plr.race eq 2>>short strong dwarfen body<<elseif $plr.race eq 3>>tall elfin frame<</if>><</widget>>

    And ditto the widget for the female.
  • Claretta wrote: »
    Is there any advantage ...
    It could be argued that comparing two values is a more costly operation than accessing an element in an array, so there may be a saving in efficiency.

    My reasoning behind supplying an example for @mykael's suggestion was more about explaining how to implement it than anything else.
  • Once again you guys are the bomb! Thank you so much! I'm going to try it both ways, see which one I like.

    Thanks again!
Sign In or Register to comment.