SHF3 Progress Update- learn to code. (Patreon)

If you’re interested in seeing early animation rigging on Project Maple, or watching me descend into a pit of madness with SHF3, check out the VODs of the last two streams! (They won't let me link to the actual vods page. It's the 'videos' tab at the top.)

I’ve been trying to learn to lean on PussPuss and my other artists more for help with assets. Hopefully I’ll be able to show off everyone’s hard work soon. But...

This is a heavily technical post. Non-programmers are gonna struggle with many of the details. I tried to keep the ideas as accessible as possible, but honestly it's just complicated.

Also, this post is late. I have no memory of why. Sorry guys >.<'

What’s being worked on?

Design patterns and fundamentals.

SOLID principles are finally starting to stick. I thought I understood them before, but I wasn't ready for them yet. Now I'm getting the basics, and it's a world of difference.

S.

Writing my classes to better fit into a Single Responsibility, the S in SOLID, is giving me a much broader understanding of how each class fits into the whole project. Until now, a small collection of classes have contained the bulk of the game's work. Separating ideas out into smaller classes, which handle their own issues only, is turning the game’s systems from complicated black magic into an actually fairly simple machine.

I keep finding places where I've reinvented the wheel to solve the same problems for different systems.

O.L.

The Open-Closed and Liskov Substitution principles are still a little tough for me, but I'm seeing where I've violated them in the past and how that has made refactoring extremely difficult. I'd mostly been treating inheritance as a way to reuse code. So, with that mindset, I never thought twice about changing the behavior of a class through refactoring, or making a child class with entirely different behavior. It made a right mess of things.

My new code is doing much better, but I suspect I have a lot more to learn in this area.

I.D.

The Interface Segregation and Dependency Inversion principles are where the bulk of my work has been the last few weeks.

So I've been pulling apart every piece of how a game object works, and figuring out how to add pieces back only as-needed onto a specific object. In a scenario where a sock, a massive dragon dildo with a psychic link to a mare with a dragon dick, and a ticklish armpit are all based on the same class, I needed a way to use composition instead of inheritance to give them properties. 

I'm not going full ECS, which would take starting over again from scratch, but instead just using components for each major mechanic.

This was the missing piece of the epiphany I had in my last post. It took a WHILE for me to really internalize how to break down game mechanics into components, and then attach those components to a game object. Instead of a million if/switch statements to see who should be run in what way, components that exist on an object will run, and no one needs to ask 'if' or 'who'.

A game that actually runs.

A side effect of doing this is that I’m starting to fix the most enduring problem I’ve had since the start of this project- a problem anywhere in the codebase breaks the entire game. I can’t test a new feature involving magically storing up and releasing physical sensations on one side of the game if there’s a striped sock causing errors on the other side.

All of the features were tied together in weird ways that made it impossible to test game mechanics in isolation. Design patterns are finally fixing that.

Primitive madness.

So I'd been attached to this idea of keeping data primitive for ease of use and performance. Until now I've been using enums to define lots of the different concepts that exist within the game. It's how the AI system figures out what an npc is looking at, for example. And how the game distinguishes the difference between body parts.

But an enum is literally just a numbered list of labels. That's not enough information for the game to understand what the difference between a hoof and a mouth is. So then I had to attach more information to each of them in janky ways, defeating the original purpose. This built up over time, until I'd essentially made my own type system with none of the benefits of actual typed objects. Think static Maps and Arrays full of relational info.

I've been moving it all from the spaghetti of primitives to simple objects that can describe identities. It just… fixes it. This solves SO many problems I've struggled with since I started this project.

The metamorphosis.

I feel like I'm undergoing a werewolf-like transformation. I'm buying programming books. I'm researching hellish things like the "Factory Method Pattern" and "Composition Over Inheritance" in my free time. What's happening to me!? Why do I wake up covered in tufts of fur, blood, and UML diagrams?!

Honestly, I wanna cry. As a self-taught programmer, this knowledge is such a game-changer. The experience of doing things the wrong way has been a vital step. It's helped me understand why design patterns are important, and what they're really used for.

But, well, fuck me. Not following them is the reason this entire process has taken so much time and effort.

Do we have to do all this?

Yes.

I've mentioned quite a few times now about how I can't always tell if I should refactor something, or just leave it for the next version to get the current update out faster. I'm finally confident that this is 100% necessary. All this time, I've been figuring out where the issues are, but have lacked the ability to fully correct them. Learning this crap has finally clarified the "HOW!?" after months of work figuring out the "what?".

This knowledge is the difference between spaghetti code and a game engine I can actually keep expanding upon. I'm looking at all the future features I have planned and realizing that many of them that sounded difficult are actually hilariously simple to add now. That shit makes me giddy.

Delete 33% of your code with this one simple trick!

I made a major restructure to the concept of items/anything in the game. It was really bending my mind to think of how each game object could have multiple "models". E.g. a dildo could have different shapes, a torso could be skinny or chubby, etc. Each of those models were of different sizes, had different animations attached, and acted slightly differently.

They weren't really separate "things", since they had the same behaviors, but they weren’t really the same either, cause too many properties were being altered. It introduced a layer of unneeded complexity that blanketed everything, creating permutations of all game mechanics an extra level deep.

...so I split them up. Making them into their own game objects reduced the size of this entire feature branch by a full third. It feels damn good to delete that much code without breaking anything.

Q&A

Did you just delay this update even more?! Yes and no. Yes, it’ll take longer than I was hoping. But actually no: the issues here needed to be solved. I thought I had an answer before, but it would’ve been ugly the way I was gonna do it. Learning about design patterns and SOLID principles gave me an actual solution that’ll be much faster than anything I had before.

What's left to do before release? Currently, I’m making the Game Object that rests at the core of the game. I’m still hooking it up to the data (also being restructured), and to the existing systems in the game. All of the actual features already exist, but need to be hooked up in a way that doesn’t make my brain explode (hence all the refactoring). It’s the final code task before running tests and balancing. 

I’ll probably release a version with some characters or mechanics disabled. It may take me a while to get oral stuff really working on the dragon rigs, for example, but that doesn’t need to delay the update.

Sorry if that feels vague! I’m trying to be open, but I also have a horrendous track record of saying “I think I’m almost done” and then being totally wrong. This stuff will take me a bit, but honestly I’m the most optimistic I’ve ever been about my ability to deliver this release.

Is the pony selection menu getting a rework? Yes. I’m not sure what will/won’t make it into the next update so I can’t promise when, but UI is a big thing I’m also tackling. The reason the UI is clunky is because I’ve had to write it myself in-engine. I got some great design help (without which it’d be much worse) but it’s just too much work to do it this way. I’m migrating to a new HTML-based UI system that’ll be wayyy easier to use. As that happens, all the menus will be reworked and much easier to read and navigate.

And even maybe... localized? gasp.

Will we be able to add OCs into the game? I hope so. Character customization would be so cool. It’s hard though. The most I can confirm right now is- over time, I’ll be adding ways to change colors, sizes, manes, etc. My artists will help me add more body types, mane styles, body patterns, accessories, etc bit by bit. The customization features will probably roll out as side notes on each update as I figure out pieces here and there.

In terms of the “can I draw my OC and have it appear in the game?” question… I don’t know how to do it yet, but I have a couple ideas. So that one’s a maybe, but not for a while!

Um... u ok? Yeah. I mentioned being stressed in my last post, and while things aren’t fully recovered, I’m doing wayyy better. Just lost track of time on this post.

That’s all for now!

I genuinely cannot believe that I’m being forced to become a real programmer. But all the support I’ve gotten so far is more than I ever could’ve asked for. To pay back your kindness, this is the only option. 

Also, holy shit it’s way easier to code when you know what you’re doing. xD

<3 <3 <3