Performance Screen Judgement/Emojis Doesn't really sync with Supervisors or game state judgment

[habmin]

• Was discussed earlier, but there's a bit of a conflict between what the performance screen emojis show and how the game thinks you're doing.
• Why? Because the state calculations are completely independent to the performance screen's calculations.
• I think there should some decisions made before working on this.

1. There are currently four metrics in the performance screen, and here are their ranges right now (Rent is deduction is always bad). Do they seem good?
   • Approval Rate: How many tasks were labeled "correctly."
     • Good: > +10
     • Average: [+10:-10] (inclusive)
     • Bad: < -10
   • Average Time: How quick the response was
     • Good: > +2
     • Average: [+2:-2]
     • Bad: < -2
   • Earnings: Total Earnings player has accumulated the entire game (not by day)
     • Good: > +%10
     • Average: [%10:-%10]
     • Bad: < -%10
   • Earnings minus rent: Player's actual earnings/'score'.
     • Good: > 100
     • Average: [100:51]
     • Bad: < 50
       2. Which of these variables are responsible for determining the story path?
       3. Which should determine their emoji rating, how the player did that day, or be directly tied to the game's overall story? For example: If the player is on the 'good' story path with the Supervisor liking them, should the emoji always be good, regardless of the performance of that day?
       4. Should some metrics be independent from the story? Example: if their timing was bad but they still have the 'good' story going, should the emoji be good anyway?
       5. Where should these metric calculations reside, the state or in the performance screen calls?

[hobg0blin]

Thinking this through here:

1. I need to evaluate this in the code - reads okay to me, although the values may need tweaking.
2. Variables that affect ending: average performance (e.g. good/bad/neutral). earnings_minus_rent < 0 or bad performance on the tutorial can result in an early failure. I've also implemented a "bad performance" failure state, but that should map almost identically to earnings minus rent, so it's commented out right now.
3. Emoji rating should be based on the day's performance, not overall performance in the game.
4. This is an interesting point. Average time can't directly result in a fail state, but if you're consistently running out of time you're almost guaranteed to fail. I think this can remain separate from state/performance, but what it's currently set to should be more generous.
5. These should absolutely reside in state. If you feel confident implementing this and have the time, you have my blessing, but otherwise I'll take your code and reimplement it in state so that the screens are just pulling from state as the source of truth.