Progress Update- stimulation breakthroughs (Patreon)

Big progress! …but it’s pretty technical this time. There isn’t an easy summary of everything done this week, so I’ll just go down my list of update descriptions and try to make them readable >.<’

I have a coding stream starting in an hour! 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?

Stimulation

Last time, I mentioned having the stimulation chain -> sensation -> npc state built. This week, I’ve been hooking everything up and testing it for real. There were quite a few improvements and evolutions of the design needed:

Brain as root:

Each body part runs on its own, gets alerted to touches on its own, and when touched, starts the stimulation chain. It then runs its given filter on the kind of touch, turning it into sensation. It then sends that sensation directly to the brain. Designating a brain as the root entity of living game objects was the last piece of the puzzle in terms of information flow. Was contemplating whether the brain should manually check all attached body parts, or the body parts should alert the brain to new information. Went with the latter.

Makin’ it actually work: Stimulation filters were thoroughly bugfixed until they’re giving expected outputs, debugger improved until it can show the entire flow of info.

The vibrator problem:

Right now, any object that can touch another object has a stimulation_giver column in the data, where there’s lists all types of motions and interactions that it can have with other objects. i.e. what happens when you touch someone with this thing?

The “stim_preset” (silicone_rub in this case) points toward a list of stimulation types and amounts. These are what get sent into the recipient’s stimulation -> sensation converter filter, based on how much movement has happened.

This accounts for movement along x and y separately (since penetration needs those handled differently) as well as just holding the object still. But I realized once it was set up that I was missing a pretty important detail. Vibrators, and anything else with controllable settings, add their own stimulation info, based on how high you turn them up.

So the vibration mechanic, and all similar mechanics, needs its own stimulation_giver settings.

Pointing toward its own stimulation preset (values here are just for testing btw)

In the code, we have all mechanics’ stimulation values being recorded separately, so it’s easy to adjust them when the player turns up the vibrator, for example. Whenever there’s a change, it recalculates the final stimulation output, which is what actually gets used when it’s touching something. Yay, solved!

Now, all basic vibrators can just inherit the data above, and whenever I make changes to vibration, or shocking, or other adjustable abilities on the toys, it’ll affect everything equally. Everything’s in the data, easily adjustable, nothing’s hard-coded, and it all actually works. Whew.

The uh-oh moment:

The code worked, but I realized that I’d made a mistake in the concept portion. So I had this chain:

Stimulus -> NPC’s conversion to sensation function -> body part sensitivity -> current state -> … (reaction)

The conversion to sensation function runs based on what type of stimulation. So for example, a simple touch would run the TouchSkinFilter function. This is the logic of “what happens when this character is touched?” So a scaled dragon, for example, would be given a different touch function (e.g. TouchScaledFilter), because touching scales is fundamentally different from touching skin.

The idea was to allow full customization of both the logic (the function) and tweaking the values and multipliers (the individual body part sensitivity).

The logic was being placed on the character. So a normal mammal character might get the TouchSkinFilter and a dragon would get the TouchScaledFilter. And android would get the TouchSyntheticFilter, and so on. Then do this for every form of touch- rubbing, fucking, scratching, vibrating, slapping, etc.

… so like, I knew there was an issue here, but I guess it didn’t really click until now. Wouldn’t you want the logic to change per body part, not per character? What if you have a hybrid character with some scales, some skin? Or, more immediately- you’d want different logic for different kinds of parts on one character. The clit and the forehead should probably have different logic for how they handle vibration.

In fact, this is one of the biggest strengths of being able to change the logic. Before, all body parts used the same logic, and I just tweaked them with multipliers. It was okay, but needed a lot of tweaking to make sure characters weren’t cumming with their elbows and stuff.

So, yep. Had to change the functions to be on the individual body parts. It was a bit of work, but it works fine now! So now the chain looks like this:

Outside stimulus [e.g. TOUCH] -> Body part’s conversion to sensation function [e.g. TouchSkinFilter] -> body part sensitivity -> current state -> … (reaction)

Sensitivity

So there’s another step to this, and it’s sensitivity, i.e. the multipliers that get put onto different sensations based on the body part. So I’m still grappling with the concept right now, cause I don’t want to repeat the previous mistake. My current idea is that a body part has just set of one sensitivity settings (e.g. ticklish * 10, pain * 4). Those get applied after the stimulation -> sensation logic.

The difference is that there are 0 to 10+ stimulation -> sensation functions on a body part, based on all the ways it can be touched. The sensitivity doesn’t care how we were touched, it just amplifies or dulls the resulting sensations. This makes sense to me right now both in terms of concept, and ease of use.

Gonna be working on that on-stream.

Tools

I also took a brief detour to make some customizations to CastleDB, the json editing software I’m using to hold all of the game’s data. You can see the colors in the above screenshots, showing the level of data being edited. I added those and some other things, and it’s been helping me handle the data a lot better now that the file is getting bigger.

I’m also looking at forking the program and adding some more quality of life features. Having proper tools makes a damn big difference, it turns out >.<’

… that’s all for now!

I’ll do another proper Q&A next time. Thank y’all so much for sticking around and providing me feedback that helps me grow and improve. This be fun but also this be hard. We’re damn well getting there though :3

<3