Please confirm you are at least 18 years old of age. Otherwise leave the website.
Sign up
Log in
18+
Levy's Lewds
I make lewd pony games. :3
Subscribe
Message
Subscription Tiers
$2
per month
Tip Jar
Mostly just a tip jar! Occasionally I do polls, design discussions, post concepts, etc, and you'll have access to those. You'll also get access to any public game release a few days early.
51 subscribers
Unlock
$10
per month
Beta backer
Get immediate access to development builds as soon as they're ready.
I'll also really, really love you.
217 subscribers
Unlock
$25
per month
Crazy person tier
All of the above, plus my undying gratitude and special shout-outs everywhere I can put them. You're seriously amazing. <3
9 subscribers
Unlock
Features
The subscription gives you:
Access to Creator's profile content.
Ability to support your Creator by pledging – one-time or recurring.
Means to reaching out to the Creator directly via Instant Messenger.
Whoops, last two posts weren't set to public. Substar makes it very easy to accidentally make posts paid-only. All posts here should be public except subscriber-only releases.
To showcase how powerful and modular this thing is, I've given each eye a different reaction to the same emotional data in the following example, with 3 layers of reactions balancing with each other at once.
Observe:
It's balancing between 3 expressions- the base layer (neutral), and primary expressions to represent the 2 emotions I'm playing with. It can balance as many expressions as needed for each individual piece of the face and body. Also, when there are lots of layered emotions, it'll combine the weakest emotions into one simpler basic emotion to display. That's the hard part, done!
I'm still debugging the latest addition: quick-swapping groups of assets using the reactions system. You can see it in action a little here with the mouth and eyebrows, but there's some more to do.
Plus, I'm partway through a GUI to edit expressions, which'll speed things up a lot~
That's all for now! This month was weird, but the progress is actually looking pretty great. Each step in the game's todo list becomes easier than the last, thanks to all the engine work. Pretty soon I'll be able to add in a ton of expressions and body animations without touching any code. Looking forward to that ^^
Major breakthrough! Simple and complex reactions finally work! I'm inconveniently sick right now though, so gimme a minute to put together a visual presentation of it.
The system functions exactly how I thought it would, minus a few bugs. It's a modular chain of brain, body, and animation logic that can be as complex and nuanced as you need it. So, for things like blushing, it's very simplistic. For expressions, it's a monster of brain inputs and face configurations.
But... I was using stress-testing animations while making it, so it kind looks like a FNaF horror creature right now. When I'm less sick, I can swap in some real animations and show you why this system was worth the effort~
edit: this post was accidentally set to the paid tier instead of free. My bad >.<'
So last time, we had an unexplained fps drop. I showed off the two separate debuggers I made for the logic and visuals in the game. The problem causing the fps drop turned out to be tricky though, so I developed both of the debuggers more. Now they both give me a nice simple overview of what's happening in the game.
The animation renderer was slowing down. I was telling the debugger code to look for a big problem, but there were no errors, and the animation logic wasn't actually taking up any extra processing. And yet the fps would drop.
Since the code couldn't catch the problem, I added more human-readable stats to my debugger. The key was getting the debugger to tell me- how many times are we asking the animation code/renderer to do specific types of tasks? Once I implemented that, suddenly everything was way easier.
This is a bit hard to explain, so here's a couple of screenshots showing how I was trying to debug this before (Method 1), and how the debugging works now (Method 2).
That's the animation logic asking the animation code to start a new animation 30k times. Meaning there are 30k animations all layered over each other playing all at once. Whoops. You'll notice that the animation logic isn't actually causing any lag (the average/total durations are super small). So it didn't show up in performance checks.
Yep. Now I have a simple readout of everything happening in the game. If something is causing performance problems, but the debug code isn't able to tell me why, I can now just look at the readout and see if anything's weird.
Turns out I only needed to add 2 lines of code to stop the Body Reactions system from infinitely starting new animations. So yay, that's fixed! This debugging solution looks like it'll be good enough to carry us through at least the first few releases, if not much further.
Moving on! The Brains are throwing some errors, so I'm off to fix that next.
That's all for now! Thanks so much for following and supporting development. I'm in full code/debugging mode until all systems are ready for community playtesting.
While checking brain reactions, I noticed a big uh-oh.
A gradual linear fps drop. I figured it should be no biggie. It being gradual indicates something that should only happen once is instead happening over and over again, slowly eating up all the processing power.
Then I realized I had no idea where in the process this was happening and no way to check except... manually, system by system. Huuuge waste of dev time.
So I built some performance profiling into the engine's debugger. I made a profiler for both the game's visuals and logic since they're two different systems.
Neat! Now I can see where any unexpected processing or lag is happening.
A side effect is that I can see when something is processing unexpectedly, but isn't causing lag. Turns out a bunch of game systems were sneakily running when they didn't need to be. Thanks to the new Entity Component System structure of the engine, I can easily look and see why each system may be active.
The effort to make these profilers has already paid off twice as much as I expected. Should've had this from the beginning. Now that I can see what's happening, it's back to debugging reactions for me.
Reactions code is "done", and now I'm testing it and fixing bugs. So far it's surprisingly solid! The bugs have just been small mistakes and oversights, thankfully. For Reactions, there are four steps to be ready for release:
Code and structure (Done)
Debugging (In progress)
Vertical slice
Content
What that actually looks like in terms of expected dev time:
The Vertical Slice step means I'm gonna make the system do one of everything it MIGHT do in the final game to make sure it all works the way I want.
At this step, we stop working on Reactions specifically and transition into the Cleanup/Content phase for the first playable release. That means I'll be doing the Vertical Slice step for all the currently-implemented game systems at once to make the game actually playable.
Last, the Content step is just filling in a full set of reactions for a character, plus the equivalent for all other game systems.
Then, it's ready to be played~
UI upgrades
Since I need a lot of Debugger UI at this stage, I'm implementing the modular UI I've talked about in my last couple of posts. So in the past I've needed to make each menu and thing inside the menu manually.
Here's how it'd look. The red parts are things I needed to do manually:
Not too bad for a single button. But what happens when we need a bigger menu?
That's a lot of red. Every new menu item scales up the manual workload a lot. This is how I've been making the debugger and in-game UI. Since there are so many things that need buttons and sliders and displays and indicators, it starts getting really crazy. A typical menu would have dozens of elements at least.
So instead, I'm rearranging the order of things.
I've told the menu that if there's something to toggle, then generate a button for it. Seems like a small change, but...
... it now handles scaling up without a ton of manual work.
What's delightful about this is that each menu can be told to generate things differently. So a debugger menu will be bulky and technical, while an in-game menu will take the same wires, and generate a small and pretty version of the same buttons and whatnot.
For the technically-inclined, I'm using an MVVM architecture. There are multiple Views that can pop off and get swapped around, including an HTML view and multiple on-stage WebGL views.
I didn't need to overhaul everything, thankfully. Instead I've just rearranged the code to support this, and am only adding what I need at each new step. Right now it only handles the few types of menu items I need for the Reactions debugger UI. I'll put a lot more time into UI stuff later on, but for now my focus is getting us to the first playable build of the game.
...and that's all for now!
Thanks for reading!
It took a while this time cause I'm still finding my way toward a healthy work-life balance. I'm the healthiest I've ever been after all this personal improvement, and as a result, my brain is 100x more effective at actually solving problems. It's taken a lot of time and effort from me and my relentlessly-supportive partner, though. Sorry for the bumpy road. I'm blessed to have this community's support and am deeply excited to pay you back with playable content for many years to come.
... also i'm using draw.io for visualizing everything now and i love it omg
SubscribeStar and its trusted third parties collect browsing information as specified in the Privacy Policy and use cookies or similar technologies for analysis and technical purposes and, with your consent, for functionality, experience, and measurement as specified in the Cookies Policy.