So, I just wrote a little subroutine to carry out stat bonuses in game, and make them optionally visible, and I’m curious as to people’s thoughts on them. I know some people really like them, and are vocal about it, but I’m not quite certain how many people actually like them.
Not only should there be no stats mentioned in the game, there shouldn’t be a stats screen!
Stat bonuses appearing in game are a distraction. They shouldn’t be included.
It really depends on the game/my mood/something else. There should be a choice.
Stat bonuses notices are great. They should be included wherever possible.
Not only should there be stat bonuses visible, it would be great if every variable was visible in game (such as from the stats screen, but an expanded list).
0voters
In case anyone wants to see, this is the subroutine I'm using.
*label stat_bump
*params s x
*if param_count >= 3
*temp m param_3
*else
*temp m false
*if param_count >= 4
*temp f param_4
*else
*temp f false
*temp r s
*temp o false
*comment param_1 s:("variable"(numeric)) Stat: Input is either stat, or opposed pair (setup below)
*comment param_2 x:(numeric) Amount of change
*comment param_3 m:(boolean) Minus: subtract rather than add. (optional: defaults to false)
*comment param_4 f:(boolean) Flat: Use flat addition/subtraction rather than fairmath. (optional: defaults to false)
*comment r:report stat; o:opposed(second of an opposed pair); y:amount of change
*if (m = "+") or (m = "%+")
*set m false
*if (m = "-") or (m = "%-")
*set m true
*comment fixes above
*if s = "mature"
*set s "cute"
*if s = "honesty"
*set s "charm"
*if s = "retro"
*set s "modern"
*comment set opposed pairs above, where *if s = "non_variable"; then *set s "variable"
*if r != s
*set o true
*if r = "julia_like"
*set r "Julia like"
*if r = "julia_love"
*set r "Julia love"
*if r = "isiah_like"
*set r "Isiah like"
*if r = "isiah_love"
*set r "Isiah love"
*if r = "sam_like"
*set r "Sam like"
*if r = "sam_love"
*set r "Sam love"
*if r = "julia_isiah"
*set r "relationship between Julia and Isiah"
*if r = "isiah_sam"
*set r "relationship between Isiah and Sam"
*if r = "sam_isiah"
*set r "relationship between Sam and Isiah"
*comment set display names above, where *if r = "variable_name"; then *set r "stat name"
*temp y {s}
*if f
*if (o or m) and not(o and m)
*set {s} - x
*set y - {s}
*else
*set {s} + x
*set y ({s} - y)
*else
*if (o or m) and not(o and m)
*set {s} %- x
*set y - {s}
*else
*set {s} %+ x
*set y ({s} - y)
*if announce
[i]-- $!{r} @{m decreased|increased} by ${y} to @{o ${100-{s}}|${{s}}} --[/i]
*return
Mostly they are good when possible, but I also would say it depends on the story. Did visible ones in my contest entry (had pondered a toggle for visibility as part of a potential Easy/Hard Mode, but decided against it, felt like with the time limit it might have taken too long to figure out how to implement it right). For my new story, won’t have any, because it is less ‘game-y’. I would say it comes down to whether it is primarily a gamebook, or an interactive story. If the former, definitely visible. If the latter, could go either way but probably not visible.
Yea, inventory based (and using some arrays). Interesting, although I kinda doubled my effort in that when writing my subroutines, since I was planning on making them as a drag and drop list.
Min-max-ing stats is a compulsion of mine that cannot be satiated but anything close to that is good enough
But in all seriousness, if showing stats somehow affect the story negatively then feel free to hide some (not all of them though). If a game didn’t have ANY stats, then it’d have to be pretty damn good for me to even consider playing
No no, that’s relatively easy to code. I mean drag and drop as in they are easy for anyone to just drop in their game and use. Meaning minimal required parameters (e.g. with mine you can see there’s 4 parameters that can be entered, but only 2 required), plenty of error catches [e.g. m (a.k.a. param_3) is supposed to be boolean, but accepts "+" / "-" too], minimal variables (this one only requires one, and even that I can turn remove and make a parameters fairly easy), etc.
Partly is I’m thinking of, when I rewrite the CS documentation, of packing a bunch of subroutines together as part of like a “here’s an example of some of the more advanced things you can do, and you can insert these into your game as is if you want”.
