SHF3 Progress Update- the Entity Component System (Patreon)
Content
It turns out, the Entity Component System pattern clears a path to finishing this update once and for all. This post is pretty technical, but I think it should be readable for non-programmers. I kept the technobabble to a minimum this time.
Oh, and also, I heard the WIP for Project Maple's background music during yesterday's stream, and it's coming along great! SkySprinter is a great (and commissionable) musician. I'm excited to be putting actual music into all of my projects.
If you missed the streams, VODS are here. (They won't let me link to the actual vods page. It's the 'videos' tab at the top.)
What’s being worked on?
An Entity Component System. I'm using an actual library and real-life game development pattern. I never thought it'd happen. I've talked about the benefits of components previously (modularity), but I hadn't fully grasped its power yet. And I was missing the "system" part of the ECS still. That's the tldr.
So I wanna give y'all a large-scale view of where we're at with this update. I'm gonna talk about different aspects of the game. These aren't hard categories, but a layman's look at how to divide up the project.
The pieces of the game are:
- Assets (art, sound, etc)
- Animation (the Spine rigs, and the code)
- Data (to configure toys, characters, AI, etc)
- Logic (game mechanics)
- Interaction (UI, mouse handling, etc)
- Rendering
- Balance (making it actually feel correct)
The work for the first part of this update was mostly around Logic and Animation. Besides the actual visuals, introducing oral required a pose-changing mechanic, expanding the stimulation mechanic to allow for gagging and more complex sensations, expanding the fluid inflation system to allow for connected systems and entry/exit points (mouth-stomach-bowels-butt), adding more complex penetration by putting in constriction systems (collars on the neck, for example), and a bunch of other side features that came along with those. Stuff like, needing the game camera to zoom out cause there wasn't enough screen space.
The second big part of this update was on the Animation code. Spine was becoming a bigger and bigger challenge, since the rigs were so unwieldy, and adding the pose mechanic exposed just how difficult it would be to continue without changing something. By updating the Spine code to allow for additive animations, I was able to simplify the rigs a ton, and open the door for a lot of cool animation features. Technically... IK constraints are still bugged, but the rigs don't use IK, so it's fine for now.
The third big part was/is dealing with Data. That is, how the game stores the data it needs to create toys, body parts, AI profiles, etc. The system I had "worked" but was locking me in to some weird spaghetti patterns of coding that was making everything hard to change or improve.
At this point, a lot of the improvements to the game worked but couldn't be used. That is, they functioned in a testing environment, but needed to be fully integrated into the game and work in all scenarios. I tripped a lot on this last hurdle, and eventually landed on the current stage of the update:
Core Logic. Improving the Data portion made clear just how spaghetti everything actually was. Instead of adding or improving game features, I was spending all of my time hunting bugs. Code architecture and design patterns came to the rescue. I broke the game down into individual mechanics, created the core Game Object that could perform all those mechanics, but struggled with how to then handle all the variations of the Game Object that this resulted in.
That's where the ECS comes in. The Entity Component System pattern solves that problem of how to handle objects with a variable amount of mechanics attached to them.
It took me some trying and failing before I started to get the hang of the ECS. I had the right idea with the Game Object, but had to take it much further. Instead of making a vibrate mechanic that could be attached to the game object, I had to make a set of mechanics (components): animate, vary animation strength, output X sensation, play sound, etc etc. Those components all combine to create the Vibrate Entity, which can be put on anything.
Breaking the game mechanics down into tiny, atomic components like that lets me build pretty much anything once they're assembled again. And since each of the game systems handle those components in a modular sense, I don't have to build an entirely new branch of code for each new feature.
~a brief interlude to study booty jiggles~
To learn how to work a full system using a set of components, I took an evening to try making a jiggle physics feature. This was done outside of normal work time, since I didn't want to waste official time on it. It took like ~3 hours to learn about spring physics, and <1 hour to actually implement it.
Now, I can attach a set of components (motion reader, bone mover, spring physics) to something and, without any extra code, that thing will jiggle like jello. That means teats, butts, manes, and bellies could all be wired to jiggle with one line of code. Just gotta set up a jiggle bone for them in the rig.
That's awesome! I thought building that feature would take a month given the complexities of the rigs. Hot damn.
~interlude end~
All of those mechanics I built early on in this update can be chunked into their atomic pieces, and put together like legos now. No more spaghetti. No more giant branches of code to handle each feature. And, most importantly, when a bug occurs, I don't have to hunt across the entire codebase to find it. Everything is quarantined inside the lego pieces.
FYI, it's not a true ECS system but a hybrid. There's no reason right now to waste time converting the renderer and stuff into components. I won't be refactoring the entire codebase. And right now all I'm making in the ECS is the mechanics relevant to this update. More things will get devoured into the ECS pattern as we go in future updates.
But... I'm not done yet :( At the moment I'm taking the unfinished things and using the ECS pattern to finish them. It's a learning process cause I'm still new to the pattern. But with each component and system that gets finished, I look at it and go "holy crap this'll fix all of those bugs I was dealing with before". It's good stuff.
We're getting there.
Q&A
Starting with the big one-
The game seems to be evolving into a personal project you're improving on (refactoring) constantly. As you study programming more, don't you risk falling into constant refactoring as you learn new things?
Absolutely a fair concern. Here's the problem though: I didn't know how to finish this update until I started studying this stuff. I thought I could do it, but the spaghetti had taken the place over without me realizing it. These new things I'm learning are the missing tools I needed to finish the update.
The code's foundation was too weak to handle the changes I was trying to make. The ECS, the data refactoring, the animation code update, etc, these are all necessary to go any further. It's how we'll get from A to B.
So I reject that characterization. I get where it's coming from, of course, given the last few posts here. But honestly I don't see a way forward without studying and applying these new things.
Although... an area where I have fallen into this trap is the UI. I've been tinkering on and off with using HTML as UI instead of WebGL. It'll be a major improvement. But I keep changing approaches as I learn more. Luckily, I recognized that this was gonna be a whole... thing... so I put off the HTML UI feature for later. The UI already works, so I need to not fuck with it right now.
So, there's my slightly defensive answer. It really is a valid concern. But, well, I learn as I go. It's how I learned to code in the first place, and it's likely how I'll continue to improve as a game developer. Just don't put me in charge of programming medical systems or self-driving cars and it'll be fine, probably?
Will there be non-pony species customization features? Non-pony, yes. General furry? Maybe. I'll have a more detailed answer after I'm out of this current update and can focus on that stuff.
What about pokemon? No current plans for it. Though it may be possible depending on where the customization stuff ends up. If I end up at a point where I can hire out an artist to do most of the work, then I would consider it. They're very lewdable >.>
Tentacles, with AI? If I can make it good. My idea would be a mostly-autonomous set of tentacles that you have some system-wide control over. It'd be a great complement to the machines, which you have independent control over. I have a lot of ideas for how that'd go, but my first concern would be making sure the visuals actually work.
Achievements? Yes, kinda! There'll be a system for discovering mechanics, which may be an achievement system, or something else that serves this purpose. It's hard to describe from where the game is at right now, but eventually I think it'll be well-suited for something like that.
Can we have infinite fluid containers for inflation? Yes, or at least, something that serves that same purpose :3
When will this be done? When I finish get the remaining stuff into components/systems, I'll have a pretty clear idea of how close we are. For now, I dunno yet, but we're getting there >.<'
That's all for now!
I'm working my buns off at the moment. This ECS stuff has insanely exciting potential, but I'm trying to keep it cool and just plug away until the update is done. Then there'll be more time to have fun with it. ^^
Huge thanks to my supporters for your crazy generosity throughout this. <3