Progress Update- Finite State Machines (Patreon)

A technical and design-focused week!

I have a coding stream starting in a few minutes! If you miss the stream, VODS are also available. ('Videos' tab at the top.)

To new patrons: We’re in the middle of an absurdly-long update cycle. Here’s the summary and how to access content.

What's being worked on?

Mental states, bodily states, body part states

(fyi- “state” just means a thing happening that we need to remember for more than one game tick. A light bulb has two states- on and off. A thermostat has a state from 0 to fire. It can apply to a lot of things!)

Last week’s stream was quite productive. It ended up being an hours-long brainstorming session on how to handle emotion, body states, and the status of different body parts. Previously, all of those were jammed into the same list.

When the body was stimulated, it went like this:

• Body part stimulated
• Body part holds resulting sensations for one tick
• Brain snatches up the sensation, erasing it on the body part
  • 5 tickling on hooves, 8 on armpits just becomes 13 on the brain
• … (stuff happens)

Also, somewhere in the body part’s code, it would hold part-specific data about inflation levels, and somewhere else it’d hold tightness, wetness, etc. Somewhere else in the code, it’d hold whole-body data like are we orgasming, are we conscious, etc.

I was missing something design-wise: individual body parts can and should retain their own sensations. Tickling toes vs armpits would be the exact same (except for some AI stuff) in this model.

Plus, there’s something weird about this whole setup. Things are scattered all over the place.

The improvement

There are two main types of state- something happening to the brain/entire body, and something happening to a body part.

The brain includes:

• Emotions
• Whole-body experiences like orgasm, unconsciousness, fatigue
• Experiences that are either happening or not for the character, like crying, gagging, etc.
• Mental states like composure
• Overall experiences of sensations, like, “I’m feeling tickled, pleasured, etc”

A body part includes:

• Sensation. So even if the body overall is feeling pleasure, this one part might be feeling pain.
• Wetness.
• Lingering effects, like soreness, residual pain, numbness, etc.
• Part-specific states like ejaculation, lactating, erections, gaping, tightness, etc.
  • Head/face-specific states like blushing, tears welling, etc

Holy crap, this simplifies the hell out of things. Instead of things being scattered, all of the important data is contained in the same places. Each of these are just a list of values from 0 to 1 (mostly). They can see each other, and there won’t be any confusion about how to use this data.

Also, it allows body parts to properly remember how they’re feeling, which design-wise helps with a lot of things. Like, for example, vibrators causing some numbness, or lingering sensations, or better reactions to certain parts being played with, etc.

I dunno yet, but… emotions might end up as a separate category on the brain. Could be good for AI, but everything else (like facial expressions) uses a combo of emotions and physical sensations. I’m keeping them all as one category for now.

The sudden arrival of Finite State Machines

A finite state machine (FSM) is just a set of states that make things act differently. The state of being awake vs unconscious will make an npc do different things, even with the same inputs. The game already acted this way, but I never really realized that I was programming a finite state machine before. It became clear when I saw all the brain states laid out: I need to add FSMs to the engine itself.

Here’s a little FSM 101 lesson if you’re interested in game programming btw.

Consider how orgasming affects the character. It has animations, all sorts of AI effects, visual effects, produces fluids, etc. There’s a lot that’s specific to orgasming that doesn’t happen otherwise. So I’d define two states:

Baseline -> Orgasming

It’s not just the two states themselves, but the transition between them that’s important. Ejaculation begins and ends, animations switch around, etc. That’s what a FSM handles. Both the way the character acts in each state, and what happens in the transition between each state. And what’s useful is that I’m allowed to just add new states when I need to. So the states might actually look like this:

Baseline -> Edging -> Orgasming -> Post Orgasm -> Refractory Period

And the logic, and transitions, can all be placed into the FSM. And then, we can think about what really happens with these states. What if you’re edging, but then stop? The cycle is actually bi-directional in a couple places:

Baseline <-> Edging <-> Orgasming -> Post Orgasm -> Refractory Period (skippable) -> (loops)

Now the machine flows correctly. Having transition code for every link also means that we enter and exit each state properly. And each one will do whatever it’s supposed to do without needing to be babysat.

Same thing can be done with being awake vs asleep, or crying vs not crying. And it also applies to body parts, like being soft -> hardening -> erect.

Finite State Machines in an ECS

FSMs are a fundamental addition to the game engine. I’ve been working hard to get them right before continuing. Being inside an Entity Component System structure means there are some struggles, though.  This technical post details the difficulties, and delves into the solution I ended up going with.

I feel good about the progress, but still need to finish and test the feature.

Tools additions

I took another “real programmer” step this week and dove into generating some code from the game data files. It’s basic, but it’s an excellent step toward making development faster and easier.

Technical details- I wrote a script to generate enums from lists of things in the CastleDB. It’s important because I need to reference those things in the data and in the code, so I had to clone every enum into the database, and update them back and forth manually.

Now my code adds code to my other code based on my data. Woo!

Q&A

Vore? Maybe, kinda. It wouldn’t be direct, but soft vore might be explored either through voodoo dolls, or transformation into a toy or small plushie.

Resizable fleshlights? Yep, this is planned!

Can we have dildos that match a specific character’s penis size/shape? Yep! This’ll come with the portals feature, since the code for that will be the same.

Changelings… changing form? I’d like to implement this. It’s actually quite doable with the new update. Later on, I’d love to play with changelings actually fooling the other characters by pretending to be someone. It’s low priority for now though!

… and that’s all for now!

Gettin ready for stream. Thank you all so much for sticking around! It’s been a long journey, but I’ve realized how much my programming and project understanding has improved over the course of this. It’s very motivating to see how the things I built before with this game can be improved with my newfound knowledge. I can’t wait to be able to show things off!

<3