How to avoid stat overflow?

[YHGS]

How to avoid stat overflow?

I want to have a opposed pair stat but in a test run of the game I can get to a point where stat 1 is more than 100. Is the there any way to avoid this besides using fairmath?

[trevers17]

You could just run a subroutine that automatically sets the stat to 100 if it exceeds 100. That’s what I do in my WIP. The subroutine is in every chapter and every stat change runs the subroutine to make sure nothing goes lower than 0 or higher than 100.

[anon61760289]

You can lock it with this setup in the beginning of your choicescript_stats.txt

*if (var1 > 100)
	*set var1 100
*if (var1 < 0)
	*set var1 0

Or like @trevers17 mentioned, thru subroutine with the same code above.

[YHGS]

Which is the better solution? @anon61760289 solution sounds easier but @trevers17 solution sounds like it will be more effective.

[trevers17]

It’s really up to you. I prefer my method because it automatically sets the variables as soon as they’re modified, and I don’t have to wait for the player to open the stats page. The other method is valid too, if that’s what you want to use.

Here’s what my code looks like:

*label r
*if adr > 100
	*set adr 100
*elseif adr < 0
	*set adr 0
*else
	*comment End

*if oli > 100
	*set oli 100
*elseif oli < 0
	*set oli 0
*else
	*comment End

*if mad > 100
	*set mad 100
*elseif mad < 0
	*set mad 0
*else
	*comment End

*if sab > 100
	*set sab 100
*elseif sab < 0
	*set sab 0
*else
	*comment End

*if car > 100
	*set car 100
*elseif car < 0
	*set car 0
*else
	*comment End

*if jor > 100
	*set jor 100
*elseif jor < 0
	*set jor 0
*else
	*comment End

*if fire > 100
	*set fire 100
*elseif fire < 0
	*set fire 0
*else
	*comment End

*if peace > 100
	*set peace 100
*elseif peace < 0
	*set peace 0
*else
	*comment End

*if wall > 100
	*set wall 100
*elseif wall < 0
	*set wall 0
*else
	*comment End
*return

And then, whenever I make a stat change:

*choice
	#"I don't feel that way about you."
		*set mad -2
		*set oli +1
		*set peace +1
		*gosub r
		She rolls her eyes. 
		*if mad < 30
			"Riiiiiight."
		*else
			"Whatever. Being nice to me for one night doesn't make us friends."

Take note of *gosub r - this is where the subroutine is called and where the stats are modified. It happens as soon as all stat modifications are made.

[YHGS]

Sounds great! Many thanks to both of you.

[trevers17]

No problem! If there was a specific post that solved your issue, make sure to mark it as the solution. You can find this option by clicking on the ellipsis on the bottom of the post next to “Reply” and then selecting the checkmark.

[cup_half_empty]

I think @trevers17’s solution is better because it makes sure every chage counts.

Let’s say the player rarely visits the stats page and that the stat gets way over 100, 180 for example. If there’s a decrease of 20, that is, the stat become 160, when the player visits the stats page they’re still going to get 100. That means that the decrease was effectively ignored. This also holds true for checks inside the game.

---

The sub-routines I use take 2 arguments stat name as a string and value as an integer.

Usage example:

Note that the stat is passed as a string.

*gosub increase "strength" 70

</>

*label increase
*params
*if param_count != 2
	*bug Function <<increase>> expected 2 arguments and received ${param_count}
*set {param[1]} +param[2]
*if {param[1]} > 100
	*set {param[1]} 100
*return


*label decrease
*params
*if param_count != 2
	*bug Function <<decrease>> expected 2 arguments and received ${param_count}
*set {param[1]} -param[2]
*if {param[1]} < 0
	*set {param[1]} 0
*return

[CJW]

FYI: I’ve renamed this thread “stat overflow”, as I felt the previous title was a bit misleading.

[cup_half_empty]

When I read the title my first thought was “how did someone get stack overflow with choicescript?”

[will]

This is a great way of doing it. It might seem confusing if you’re not familiar with params so if you don’t know what’s going on, look it up.

[cup_half_empty]

I beg to differ. You’d need a huge amount of params to raise a stack overflow. One might even say you’d have to do it intentionally.

[iota]

Oh this is quite useful. Quick question, would it be possible to avoid sub routines if you instead used the %? like using *set mad %+5?

[Szaal]

Yus.
Fairmath op itself automatically prevents a number to reach 0 or 100.

[cup_half_empty]

Yes, you can use fairmath, which has its own pros and cons. Personally I don’t like it because you get a logarithmic curve instead of a linear one.

My personal gripes are:

• It’s harder to balance your game because of diminishing returns.

• It can easily feel frustrating to the player when a success pass increases a very small amount and a fail pass decreases a huge amount, or vice-versa. This ties in with the previous point.

• The stat will never, ever, ever reach 100 or 0.

In the end I prefer to have a dedicated subroutine to deal with increases and decreases and know that a “+ 5” always means “+ 5” and not something else depending on the current state of the game.

[trevers17]

For this specific project, I’m using incredibly small numbers to increase/decrease relationships and stats, so I went with my current method instead. But yes, fairmath automatically prevents a stat from going over 100 or under 0.