Posts: 5,722
Threads: 303
Joined: May 2014
An idea for an invisible stat: Luck
Luck is a stat that is tied to your character. Certain actions and things in game would raise and lower it, but you'll never directly know what your luck is at nor what raises/lowers it as it changes from round to round. Sometimes is might not even be active
Luck would influence the odds of pretty much anything and everything that is percentage based, increasing or decreasing the probability of certain outcomes.
Some things that could influence luck to raise or lower:
- Drawing an empty chamber in Russian roulette
- Touching the Crusher
- Wearing a clover sticker
- Rubbing the clown
- Being cloned
- Zoldofs Fortunes
- Carrying a trinket
Posts: 2,552
Threads: 33
Joined: Oct 2014
Karma, lol.
Nah, I like it. I laughed a bit too much at rubbing the clown, though.
Posts: 2,722
Threads: 143
Joined: Sep 2012
BYOND Username: Powmonkey
04-09-2018, 09:45 PM
(This post was last modified: 04-09-2018, 09:45 PM by Noah Buttes. Edited 1 time in total.)
From
(04-09-2018, 09:07 PM)Frank_Stein Wrote: Luck would influence the odds of pretty much anything and everything that is percentage based, increasing or decreasing the probability of certain outcomes
This would positively murder the code's efficiency.
The cleanest way to implement this feature would be to replace the large majority of prob() calls with a custom proc that can take in luck as a param. This would require a pretty thorough refactorization of the codebase.
What's worse is that this custom proc would be marginally slower than just a raw prob() call. While this slowdown is negligible for a single instance, when repeated countless times over the entire source code, the inefficiency adds up to a significant performance hit.
Posts: 1,324
Threads: 57
Joined: Jul 2016
BYOND Username: Mordent
04-09-2018, 09:52 PM
(This post was last modified: 04-09-2018, 09:53 PM by Mordent. Edited 1 time in total.)
This is already a thing.
EDIT: Noah, for your consideration:
Code:
prob(50 * luck_multiplier + luck_constant)
Posts: 2,722
Threads: 143
Joined: Sep 2012
BYOND Username: Powmonkey
04-10-2018, 04:18 AM
(This post was last modified: 04-10-2018, 06:00 AM by Noah Buttes. Edited 1 time in total.
Edit Reason: actually being constructive
)
(04-09-2018, 09:52 PM)Mordent Wrote: This is already a thing.
EDIT: Noah, for your consideration:
Code:
prob(50 * luck_multiplier + luck_constant)
Oh my.
Edit: I assume this is only used in a few special cases and
not as the general form for all prob calls, right?
Posts: 1,324
Threads: 57
Joined: Jul 2016
BYOND Username: Mordent
Psuedocode, my good man. But yes, as with all things SS13, copy-paste is obviously how it's been implemented all over. Because who doesn't like refactoring lots of different files if they ever need to be changed?
Obviously it doesn't affect every prob call, that would be silly.
Posts: 2,722
Threads: 143
Joined: Sep 2012
BYOND Username: Powmonkey
(04-10-2018, 07:19 AM)Mordent Wrote: But yes, as with all things SS13, copy-paste is obviously how it's been implemented all over. Because who doesn't like refactoring lots of different files if they ever need to be changed?
This speaks to me on a near spiritual level.
Posts: 5,722
Threads: 303
Joined: May 2014
(04-09-2018, 09:52 PM)Mordent Wrote: This is already a thing.
EDIT: Noah, for your consideration:
Code:
prob(50 * luck_multiplier + luck_constant)
Well whaddaya know?
I think what should be a part of it is that when luck does come into play, it's essentially spent, sending you back down to default or even unlucky, where you have a higher chance for things to go wrong