Progress update- code architecture QQ (Patreon)

Hoooo boy. This time it's alllll code. 

What's being worked on?

I think I made a bad call this week. I spent the whole week on refactoring. It's important stuff, but like... it always is. 

Basically, the toy code/data is unnecessarily complicated, since it was some of the first code I wrote for the game. That complexity keeps mucking up my process. It's kind of a headache to figure out what data is going where. Fixing that isn't too hard now that I have a better sense of how a code architecture can help things.

So like, the choice is either to add more stuff to the poor organization, making it harder for later, or fix it now so it's better in the long run. I chose to fix it. Looking back, I think I should've just dealt with the unnecessary complexity and piled a little more unorganized code into the mix. Cause it only would've made it a little worse, and then I could've tackled this later, after a playable version is out.

If this struggle sounds familiar, it's cause I've been facing choices like this for months. Been getting way better at making the right call, but there are still some where I miss.

So anyway, the thing I've been doing is...

Toy code architecture

Basically, I've been working on separating the code that governs "what's happening in the game world" vs "what we see as a result". Toys are pretty complex, because they can be used in a bunch of different ways. I have to account for every permutation of every toy's size, function, position, shape, etc. So, in the game data, there's an entry for what assets to use specifically on a dragon dildo being used anally, which is different from if it's being held in the hand, or being used orally, etc. 

This explodes in complexity fast, since there's a lot of variety in which toys can be used. Gotta swap between identical assets each time the toy changes to a new context. But what the toy is doesn't really change (Game logic), just the information the game needs to display it (View). So that's the focus of what I've been doing- separating the Game logic from the View.

I didn't bother with separation of concerns early on, cause I didn't know much about coding patterns. But information should flow one-way from Game logic -> View. Any violation of that spaghettifies the code, and, well, I made a lot of spaghetti when I was starting out. Fixing this is easy in theory, but in practice it took a lot of thought. I was able to boil it down into three pieces minimum: Game logic, View data, and pure View. 

Game logic is simple. What "is" the toy, and what is it doing? It's a dragon dildo 190 units long, at a certain x/y position, with the 'vibrate' function on at 60% strength. 

View data is the idea of what that looks like in practical terms. It's a dildo with the "dragon" model. It's tinted orange. It's at .8 scale, placed at a certain x/y on the stage, playing the vibrate animation at 2x speed. 

The pure View is just code for displaying all of that in a specific context. So if it's being used anally, or orally, or being held in the hand, or resting in the inventory... all of those require a completely different View. But the Game logic (what it is) and View data (the idea of what it should look like) don't actually change. Just the actual assets being displayed.

In the past, there needed to be different Game logic, View data, and View code for different contexts. Now I just pop one View off and put another on, no sweat. Both bugfixing and adding features are immensely simplified by doing this.

Btw for programmers- this is a loose interpretation of the Model, View, View-Model code architecture. It's a bit hard since games are different from applications that usually use MVVM. I'm sacrificing some purity for practicality. There are technically more layers below the Model and above the View in this case.

This is a massively efficient upgrade overall. I would've needed to do it immediately after this update was released if I didn't do it now. But still, I probably should've waited. As a benefit, though, this reduces uncertainty in my process, which has been a big pain.

Q&A

What's the long-term roadmap look like for this game? Portals, UI redo, and a lot of focus on how the mental/physical states of a character change over time being pleased/tormented. There's a million smaller things that'll come up, but that's what's in my head atm.

Custom characters? Big question. It's hard from a technical perspective. Customization will probably be a slow burn for that reason. It'll start with mostly color changes, then adding more and more ability to customize further. Some of the features are already there, but hidden atm.

Handjobs? Yes! I'm all about this. The current work I'm doing on toys code (technically a hand would be a 'toy' in game terms) is making stuff like handjobs wayyy easier. I'll be diving into this kind of thing super hard during the Portals update, which deals heavily with upgrading toy code.

What will we be able to use portals on, when they're added? Hopefully everything. I want portalled pussies rubbing against each other. Portalled mouths licking hooves. But to start with, I'll just do the basics- dicks n stuff, and expand from there. There are bound to be technical challenges, so we'll see!

When can we play the new version? Unfortunately, the only answer I can give is "when it's done." Until I'm bugfixing the release candidate, I won't know the timetable. But... we're getting there! >.<'

Stream VODS

I've started recording the weekly streams. You can see the first recording on my Picarto page on the Videos tab at the top. Heads up- it's full of Discord voice chat shenanigans and chaos, and I struggle to maintain focused productivity throughout. There are a handful of great conversations, but I don't have the time to edit hours of stream content. I'm working on reducing the chaos and making these streams better, but this is what we got for now. 

Enter at your own risk! :3

That's all for now! Thanks so much for staying with me throughout this whole... whatever it is we're doing. I love you all! <3