[WIP] BetterLives Fitness/Happiness/Sanity for Kerbals pre-alpha planning

[Cyrik]

Notice: active development on this will be starting once we know more of what will change in the Kerbal APIs in 0.25. As NathanKell mentioned, there might be significant changes incoming that I didn't think about:(

Hi,

so without boring you to death with reasons why I want to start this addon, here are the ideas that are swirling around in my head:

What does it do:

• tracks stats for every Kerbal, such as Happines, Sanity, Fitness, whatever
  
• changes these stats based on situations and enviorment
  
• gives advantages and disadvantages based on those stats, ranging from flavor text popups to crew deaths
  

Ok now that you know what the vision is, here are my ideas so far:

• starts out as a part-less plugin to see what is possible with just adding some programming to stock parts
  
• keep the initial stats low
  
• initially do take any dependencies other then toolbar ofc
  

Stats:

1. Happiness:
   
   • mostly determined by excitement
     
   • same orbit around the sun for the 6th time?
     
   • never on eva in a 6year trip?
     
   • same module of a space station for 20 years?
     
   • mostly a flavor stat
     

[*]Sanity:

• Influences:
  
  • the big brother of happiness
    
  • determined by living space
    
  • loneliness
    
  • entertainment on board
    

  [*]Effects:

  • random behavior
    
  • staging errors
    
  • input lag
    
  • turning stuff on and off
    
  • undocking
    
  • eventually death?
    

[*]Fitness:

• Influences:
  
  • training
    
  • gravity
    
  • sleep?
    

  [*]Effects:

  • sluggish behavior
    
  • death
    

All these stats would change over time. So a Kerbal flying to the mun and back wouldn't go crazy because he´s alone in a tiny capsule. He will go mad doing the same thing flying in orbit for a year.

The stat changes would be accomplished by checking the vessel for essentials like space and entertainment and so on. I would add modules to some of the stock parts as a start and see how far I can go with that. If it's not enough (I'd guess its not), adding new parts or integrating with other mods would come in.

I would also try to keep the mod as extendable as possible so that other mods can take advantage of its functionality and hook into it. As an example MKS/OKS parts would make perfect sense or even TAC life support for food quality and consumption.

For anyone that has gotten this far: I´m not a graphics guy, so if I need parts for this mod at some point they will either be ugly or provided by someone else:P Aside from that I'm a decent coder so i hope at least that part is covered. Oh and while I'm at it, I'm starting with TAC Lifesupport as a design base since i really like his mods architecture. I'm not sure how long that base will be recognizable however.

Enough rambling, lets hear some input:P

Edited September 5, 2014 by Cyrik

[cakepie]

For how long a duration do you intend to track the "activity history" of what each kerbal has done in the past? Your ideas seem to suggest quite a fine granularity of tracking, including orbit/SOI, craft, EVA, part of craft that the kerbal is "living" in, etc, so my first reaction is that it might get costly to keep track of a long and detailed history.

[Cyrik]

For how long a duration do you intend to track the "activity history" of what each kerbal has done in the past? Your ideas seem to suggest quite a fine granularity of tracking' date=' including orbit/SOI, craft, EVA, part of craft that the kerbal is "living" in, etc, so my first reaction is that it might get costly to keep track of a long and detailed history.[/quote']

It depends a bit on the the stat. I don't want to write a plugin that lags everything and this isn't supposed to give you a mission history. So if I change SOI i can forget the old one and just remember the new one. Other stuff wouldn't have to be remembered at all, like EVA. It would be enough if i increase happiness by a certain amount once an EVA happens.

What I´m getting at is that I don't think I need a huge history since everything changes the base stats while it is happening and you can forget most things once the situation changes.

I can't be sure of that of course since I just started with the basics a few hours ago, but memory doesn't seem to be a big concern. Just like our body doesn't remember what made it fit, just that it is fit and what is happening to it now.

But thank you for the feedback. Stuff like that can easily creep in without it being noticed and then you are screwed:)

[cakepie]

It depends a bit on the the stat. I don't want to write a plugin that lags everything and this isn't supposed to give you a mission history. So if I change SOI i can forget the old one and just remember the new one. Other stuff wouldn't have to be remembered at all, like EVA. It would be enough if i increase happiness by a certain amount once an EVA happens.

What I´m getting at is that I don't think I need a huge history since everything changes the base stats while it is happening and you can forget most things once the situation changes.

I can't be sure of that of course since I just started with the basics a few hours ago, but memory doesn't seem to be a big concern. Just like our body doesn't remember what made it fit, just that it is fit and what is happening to it now.

Ah, I see, so it's going to be some stat increase per activity, and decay over time. That may be exploitable, though -- for instance you'd be able to boost stat by repeatedly doing some token "exciting" activity such as taking a Kerbal on EVA just out the airlock and immediately go right back in -- flavor-wise that's not really doing anything meaningful (and might actually be mundane if that's the only thing you do repeatedly). Without some kind of history you wouldn't be able to tell the difference.

[Cyrik]

Ah' date=' I see, so it's going to be some stat increase per activity, and decay over time. That may be exploitable, though -- for instance you'd be able to boost stat by repeatedly doing some token "exciting" activity such as taking a Kerbal on EVA just out the airlock and immediately go right back in -- flavor-wise that's not really doing anything meaningful (and might actually be mundane if that's the only thing you do repeatedly). Without some kind of history you wouldn't be able to tell the difference.[/quote']

I've been thinking more along the line: you go on eva, your happiness increases by 0.1 per second because you are excited. That increase stops at some point though since EVA is only a part of the happiness equation. But you are right, in that case I would have to add an EVAHappiness or something to keep track of it. So there's a bit more to think about there. But I think it would come down to at most 200Kb per Kerbal, so unless you plan to start a huge colony it shouldn't be to much of a problem:)

[NathanKell]

This sounds really great!

You might want to hold off a couple weeks or so putting major effort in, though, given all the new persistent-kerbal-stats stuff .25 will be adding.

[Cyrik]

This sounds really great!

You might want to hold off a couple weeks or so putting major effort in, though, given all the new persistent-kerbal-stats stuff .25 will be adding.

Oh right, I didn't even think about this. Good catch, thank you! I guess I really should hold off a bit and see how the API changes.

[madlemur]

How's this for a thought: Activities give a certain benefit per second, up to some maximum, but there is a cool down before the same activity can grant more benefits. Possibly modified by the benefit gained...

[Cyrik]

How's this for a thought: Activities give a certain benefit per second, up to some maximum, but there is a cool down before the same activity can grant more benefits. Possibly modified by the benefit gained...

Mhhh, is there any benefit to having a cooldown if you have a maximum and an increase over time instead of per "usage"?

[cakepie]

How's this for a thought: Activities give a certain benefit per second, up to some maximum, but there is a cool down before the same activity can grant more benefits. Possibly modified by the benefit gained...

Using cooldown time sounds really promising. Repeating an action increases time left on the cooldown "timer" and diminishes the benefit proportionately; timer can be forgotten once it reaches zero. This way you'd only need to track the actions that are still on cooldown and forget the rest, rather than constantly maintaining a separate stat like EVA happiness for every possible activity [edit: in order to cap the benefit obtainable from any one action].

[Cyrik]

Using cooldown time sounds really promising. Repeating an action increases time left on the cooldown "timer" and diminishes the benefit proportionately; timer can be forgotten once it reaches zero. This way you'd only need to track the actions that are still on cooldown and forget the rest' date=' rather than constantly maintaining a separate stat like EVA happiness for every possible activity [edit: in order to cap the benefit obtainable from any one action'].

Unless I'm just not seeing how to code this properly, you would be trading a relatively minor gain in memory for a relatively large increase in cpu time and program complexity.

My first thought on implementing your idea would be a dictionary of cooldowns. Which would mean you have a string and a double for every active cooldown. The string+hashmap lookup is a lot slower then just a field access. And if even a few timers are active you are actually loosing memory efficiency since you are now storing a string + a double for every value.

Aside from the performance concerns you do have quit a bit more code now because of all the dictionary access and checks and you lose the type safety by just throwing around strings.

[cakepie]

Unless I'm just not seeing how to code this properly, you would be trading a relatively minor gain in memory for a relatively large increase in cpu time and program complexity.

I guess I'm still thinking about it from the PoV of potentially large numbers of actions/activities that need to be separately tracked in order to prevent exploitative repetition. I don't know how many of those you have in mind.

I'm also considering that you'd want this to be extensible by other mods. Besides mods that want to know the well-being of a kerbal, there may be mods that would like to add activities for kerbals too. So I figure you'd need to be prepared to handle arbitrary numbers of trackable activities, each of which would need its own "EVA-Happiness" variable. Hence my instinctive response is a dictionary approach.

Ultimately, you're right there is a memory/storage vs time/complexity tradeoff and obviously you're in a better position to evaluate that, having put a lot of thought into this whereas I'm just working off gut responses (e.g. "whoah seems like there might be arbitrarily many tracking variables")

[Cyrik]

I guess I'm still thinking about it from the PoV of potentially large numbers of actions/activities that need to be separately tracked in order to prevent exploitative repetition. I don't know how many of those you have in mind.

I'm also considering that you'd want this to be extensible by other mods. Besides mods that want to know the well-being of a kerbal' date=' there may be mods that would like to add activities for kerbals too. So I figure you'd need to be prepared to handle arbitrary numbers of trackable activities, each of which would need its own "EVA-Happiness" variable. Hence my instinctive response is a dictionary approach.

Ultimately, you're right there is a memory/storage vs time/complexity tradeoff and obviously you're in a better position to evaluate that, having put a lot of thought into this whereas I'm just working off gut responses (e.g. "whoah seems like there might be arbitrarily many tracking variables")[/quote']

Well its good to have the discussion:)

Besides, you have a point with the extensibility thing. I didn't consider that since I was thinking that other mods would pretty much update my variables, not add new ones. But it kind of makes sense for someone to add a WasHuggedHappiness variable if thats what their mod does. So the dictionary approach might actually be the better way to go. Thanks for that:)

[cakepie]

Glad that was of some use to you

[Errol]

I have two pieces of input to this discussion.

Is there any planning for a visual representation of sanity/happiness/fitness status? Will they be treated like resources (as some of the early discussion had me thinking) where events either add to or remove from the total resource/stat? If so, they could be new TAC-LS style resources. I don't know what the licensing is, but it would be awesome if kerbals just consumed fitness and sanity stats and we had to keep them topped up. Would it be possible to perhaps have usi generator modules in certain parts, perhaps an mks/oks recreation lounger and gym, that provides enough of each resource/stat to keep a certain number of kerbals in that craft stable at the cost of EC?

And here is where point two comes in. Can there please be remote tech integration for sanity. So you get a bonus for making sure that vessels have a connection back to kerbin. Maybe even if you have less signal delay they get more of a bonus, encouraging you to build better networks as well. It could even integrate with the mks/oks recreation lounge so that it either gets a huge efficiency boost while it is on a connected vessel or something like that.

Also, this just occurred to me, integration with snacks? For sanity?

Edited September 25, 2014 by Errol

[Helix935]

will this use a complex ui or will it be light weight?

or has the UI design not been determined yet?

[Cyrik]

I have two pieces of input to this discussion.

Is there any planning for a visual representation of sanity/happiness/fitness status? Will they be treated like resources (as some of the early discussion had me thinking) where events either add to or remove from the total resource/stat? If so, they could be new TAC-LS style resources. I don't know what the licensing is, but it would be awesome if kerbals just consumed fitness and sanity stats and we had to keep them topped up. Would it be possible to perhaps have usi generator modules in certain parts, perhaps an mks/oks recreation lounger and gym, that provides enough of each resource/stat to keep a certain number of kerbals in that craft stable at the cost of EC?

And here is where point two comes in. Can there please be remote tech integration for sanity. So you get a bonus for making sure that vessels have a connection back to kerbin. Maybe even if you have less signal delay they get more of a bonus, encouraging you to build better networks as well. It could even integrate with the mks/oks recreation lounge so that it either gets a huge efficiency boost while it is on a connected vessel or something like that.

Also, this just occurred to me, integration with snacks? For sanity?

I´m to sure about point one yet. The representation is still up in the air but I like your idea. I´ll think about it.

Point to is a definite yes, but only one the basics are implemented. I don't want to have dependency's unless they are optional.

And a definite yes for snacks:)

will this use a complex ui or will it be light weight?

or has the UI design not been determined yet?

Not sure about the UI yet.

The project is frozen until I see what is in the next KSP version.

[zekew11]

Here's how I'd lay this out: bear in mind that I'm as novice a coder as they come, but I like thinking about these things. For a lot of my inspiration (as to what the system should look like, less as to implementation), see rimworld.

I'm mainly reacting to the tacit idea present in this thread that we need to be updating happiness values in real time. that just seems silly.

Each value that the plugin created and tracks is on a turn system. One turn=one kerbin (6hr) day. A complete re-calculation of the value only happens once per turn, though certain actions, like transferring to a new vessel, could force a recalculation. Second, factors affecting these values break down into "conditions" and "events". As I explain I'll assume we're working in the value "happiness"

The first calculation layer is "conditions". Conditions are things like "spacious environment" or "experiencing gravity". Conditions can be stored in code as two bytes: one being the effect on happiness (if your scale is -100 to positive 100 a zero value would be equivalent to -100 while 200 would represent the positive 100) and the other being the condition id (used to fetch, for example, the description string from a config file.). using a string instead of an id byte would open the system up to modding quite nicely. Conditions underpin ultimate happiness value calculated at the beginning of each turn. Essentially the calculation starts when, each turn, the program checks what conditions apply and then finds the sum of their buffs/de-buffs. the value returned will henceforth be referred to as base happiness, and should also be rounded and stored as a single byte. We're also going to duplicate this byte under the name "active_happiness".

The next layer is the events system ("went on eva", "had friendly chat", "ate hearty meal", ect). This is where the mod can have the most flavor, but is also a processing and ram heavy proposition. My thinking is that while events can have influence over a kerbal's mood, you shouldn't be relying on events to keep your kerbals happy. That's what conditions are for. With this in mind, we only need to track events on loaded kerbals within a single turn. None of the events system I'm about to describe needs to be processed in time warp or for unfocused vessels Each event, upon manifestation, applies its own offset to base happiness. This allows you to dynamically alter the final happiness value in real time, without going back and re-checking for all the current conditions. base happiness is still stored, along with two bytes for each event (in the same style as a condition), and we add one more byte: active happiness. The calculations involving this data still don't occur every frame, but simply once when each event manifests. For example; you tell your chef to prepare 5 hearty meals. for 5 random kerbals aboard your vessel, "base happiness" is retrieved, an offset is added for "ate hearty meal" and "active happiness" is saved. To be clear, at the end of each turn the events list is deleted for all kerbals, and was only ever present on kerbals that you focused on and who had an event occur effecting them.

The third and final layer is happiness inertia. If you take Bill out of the space station and put him in a tiny pod on a tug, he shouldn't immediately go bananas. This can be tackled very simply by taking advantage of the turn system. Previously we discussed calculating base happiness from the average of a list of conditions. Now, we simply take this value and average it against "active_happiness" from the last turn (weighted average if you so fancy: useful perhaps for something like "fitness", which should have considerably more inertia). The result is that whatever you did yesterday that made bill so happy: the computer doesn't care. Bill doesn't care. the last trace of that data was obliterated when, in the next line, we overwrote "active happiness" with the new turn's base happiness. But even though his head is touching the ceiling, he just ate spinach goo out of a tube, and he's on freaking space tug duty again... he's... smiling...

To review, we have two calculations: a conditions calculation that returns byte base_happiness and occurs for every kerbal once every six hours, and an events calculation that occurs for one kerbal, only when focused and only once when an event actually occurs. Two bytes describe the current state of the kerbal: base happiness: for use in events calculations, and active happiness: the actual final value to be printed on a ui for example. up to two lists (functionally tables or arrays: looking up an offset (byte) via an id (byte or string)) are kept per kerbal; one for conditions and one for events.

Polish. The events system is where this mod will derive the bulk of its flavor, but no events will occur on unfocused vessels. I would argue for a simple system that spawns 1-3 applicable events per kerbal when he is first focused on during a turn. this way an events list can have some background population with things like "had pleasant chat", "didn't like the food", "Beat Jeb in chess". these would be balanced for an even distribution of positive and negative offsets so as to not give an advantage to traveling to duna in physical time warp, and thus very deliberately avoid having a large game play effect, but the added atmosphere would be almost free computation wise and imho add greatly to the mod.

Expandability. The list system allows us to keep one list of all the conditions impacting a kerbal. multiple different offsets can be defined for each of these conditions, allowing the same master list to be used in the calculation of all variables addressed by the plugin.

Example ram usage for 1 of 2 crew in a hitchhiker and a 3 man pod headed for duna, using happiness, sanity, and fitness:

Conditions List: (2d array)

[23,90,99,100] (id 23: "vacuum packed diet", -10 happiness, -1 sanity, 0 fitness)

[47,100,95,50] (id 47: "zero g", 0 happiness, -5 sanity, -50 fitness)

[8,100,105,100] (id 8: "its me and a partner", 0 happiness, +5 sanity, 0 fitness)

[27,110,115,120] (id 27: "ability to exercise", +10 happiness, +15 sanity, +20 fitness)

[233,110,100,105] (id 233: "breathing room", +10 happiness, 0 sanity, +5 fitness)

4x5 bytes is 20 bytes. the program additionally creates 2 more bytes times 3 variables (base happiness; active happiness); so we're at 26 bytes for this guy. lets square that because other mod authors add more variables and more conditions. 676 bytes per kerbal. 200 kerbals in your save: 135200 bytes. about 135 kb. about the size of this post as a .txt file, or 1/3000th of the ram one with 4 gigs on their system might expect to be allocated to ksp. What I'm saying is that if you play with variables as bytes you have to try really hard to blow up your ram usage.

what I'm unsure of:

How to apply random flavor events: My thought is to attach them to conditions. for example; the condition "Large Crew" would enable the random event "Beat Jeb at Chess" to spawn. I just don't feel it's very elegant though; and would certainty complicate the conditions definitions, wherever these were stored.

How best to track the conditions list: What constitutes "spacious living quarters"? do we re-check the list each turn (seemingly prohibitively expensive) or force specific types of changes to cause a recheck (seemingly very sloppy) probably some hybrid: we cant rebuild the list for 150 kerbals every 6 hours in 10,000x warp, but we also shouldn't attach code to every SOI change and write and run code that's constantly looking for perceivable gravity.

How best to implement the list system: The thought crossed my mind that we're going to load the directory of possible conditions and events into ram once; why copy most of its data over into each kerbal's lists. Basically, do we use the id of a condition to reference a common database elsewhere in ram to retrieve offsets for calculations, or do we save the cpu some effort and simply copy over the couple bytes into the kerbal's data. In my example I did the latter, as it seemed simpler and still not too costly, which I figured was good given my poor understanding of transactions in ram in unity or C#

Event StackingOne of the big discussions in this thread has been avoiding exploitative stacking of event buffs. The turn system makes this much easier to avoid. The options are A) once an event has occurred that turn it cant happen to that kerbal again until the events list is purged at the start of the next turn. you could conceivably do this with around three lines of code. alternately, each time you stack an action it has half the effect of last time. first eva of the day? +10 happiness. Second? +5. Third? 2 (rounding to floor bc we have only a byte). Thus, the fifth eva and onward has no effect, and the previous four contributed +18 happiness.

Lastly, I'm a big fan of the adversarial system for idea development: tear this thing to pieces and I'll do my best to defend it. Do try though to offer better solutions to problems that you dislike how I solve.

Edited October 8, 2014 by zekew11