mattdelsordo / friendo

Friendo: your virtual buddy
http://friendo.mattdelsordo.com
MIT License
0 stars 1 forks source link

Overhaul speech system #186

Closed mattdelsordo closed 4 years ago

mattdelsordo commented 4 years ago

This issue sort of encompasses #68, #80, and #110. A number of things need to be done:

  1. Overhaul the speech system to allow it to be more dynamic. Ideally, phrase picking should happen dynamically based on the Friendo's current state/hunger/fatigue/stats. At the same time, this needs to be done as efficiently as possible, so that the animation thread doesn't lag every time it decides a Friendo should speak.
  2. Overall, add more speech options. Current ideas for speech variance:
    • Idle speech options that scale (volumetrically) off of Meme Tolerance. E.g. higher meme tolerance = more memes the friendo can spout off. Maybe these can be sourced from some sort of Meme API to keep the references up to date because I am incredibly out of touch. On the other hand there are enough subtly racist memes out there that they definitely need to be vetted if I try something like this.
    • More speech options in general for exercise
    • Speech options that vary by element, e.g. a fire friendo will make more fire/heat puns, water friendo will joke about being moist, etc.
    • Speech options that reference a Friendo's fatigue/hunger, e.g. saying its sleepy, hungry, full, etc.

Pre-existingly, speech is fully controlled by the animation system, and I'm not sure if that's the part of the Friendo that should own it. Speech options should probably be associated with State, which the animation can call to pick a speech option. On the other hand, the speech system should also know about Friendo stats/state/element so MAYBE it should live in the root class as a new attribute of the Friendo itself. On the other other hand, I need to minimize the amount of nested ifs just to check those factors, so the Element-centric speech options should probably live with their element, and the state options with their state. This gets more complicated when options could hypothetically be both state and element dependent. In summary: hmm.

mattdelsordo commented 4 years ago

Idea: associate phrasebooks with state, have animation call pick from the Friendo's state. Add element specific phrase lists to element objects, call those when building idle phrase list. Don't need to worry about rebuilding the idle list to account for stat changes because a stat increasing necessitates a state change, automatically rebuilding the list. For stuff like hunger/sleep control picking that separately, don't add them to the list.

mattdelsordo commented 4 years ago

I think the way to do what I actually want to do is to create a database of tagged speech options and then query the database each time a speech option needs to be loaded. OR, put EVERYTHING in a giant JSON file where everything is a tagged object and run Array.filter() on it every time, which might actually be faster since it's a local function call even though it's O(N). Would that have terrible implications for local memory usage?

mattdelsordo commented 4 years ago

Resolved by #201