Home Artists Posts Import Register

Content

Technical progress is being made, but also I am going insane. Yayyy~

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

The Display Message Buffer

This was a big challenge last week, but it has been conquered, tested, and does its job. Eat that, hard code!

There will be more display logic to add to this as we get into the next section:

A great upheaval because I realized I was either too dumb or too smart

The display message system is good. It's so good that it's replacing the old display data pattern completely. Oh crap.

The “display message system” basically means there’s all these little messages being collected over the course of a game tick, saying to adjust the speed of an animation, play a different animation, move a sprite, etc. At the end of the tick, the system takes all the messages and reads them in order. It doesn’t know who sent the message, or why, it just does what the messages say. (I talked in the last post about why this is important)

Then we have the display data, being stored in the game’s database. Seen here on a vibrating toy:

The data tags the "vibe" mechanic as needing three pieces of data: the sustain animation that plays the entire time it's active, the alpha component that changes the strength of the animation based on the strength of the vibration, and the end animation to reset bones after the vibration stops. 

Unfortunately, this all requires context for the game to understand. The Vibe system will know when and where to use each piece of info. That context is something the display message system isn't going to have. Until now, I thought that meant I needed to translate from display data to the messages format. But no. That is, in fact, dumb.

The smart thing to do is this:

Now, there's a separate configuration for starting and ending an action. 

1 is called when the vibe turns on, starting the main animation.

2 is called every time the vibrator strength changes, setting the alpha/strength of the animation to match.

3 is called when the vibe turns off, killing the animation and resetting bones.

If I put this display data onto anything, it would have the same effect. That's the big change here. It no longer requires the recipient to understand what the data is for. By adding the "display messages" idea, I've exposed a need for my entire display data structure to be based around a no context environment.

Instead of translating between display data, and display messages, I simply write all display data as display messages that are ready to be read. No need for a translator when everything is in the same language.

Ugh. On one hand, this is the result of the wisdom and experience I've built over the past few months, and is a major improvement. On the other, I really wanted to not be remaking any of the display code.

Luckily, the conversion process isn't too bad- it's just a bit of data entry. The code itself will take a few hard days of work though. I'm determined to smash through this. At the end of it, we'll have the Actions system functioning. Oh, right-

Actions system

I've talked about this for the last few weeks as the big next step. It's getting built piece by piece as the display code is worked on. The Actions are the same format as the vibe entry above-

...and behave the same. When an action starts, changes strength, or ends, it fires one of the above sets of data as a message to the display system. 

The biggest, most challenging piece of the Actions system was the inability to provide enough context for the display logic to know what to do with the data.

I have addressed the issue by making context irrelevant. Yay.


Q&A

Shouldn't you be building a vertical slice of this game, instead of trying to do the whole thing one layer at a time like a big-ass cake? I'm trying to. I'm not experienced enough to know how to do that fully with this project. I also have the benefit of knowing certain things already work. There's this constant battle between two conflicting truths about making a working product: 

  • Get a working prototype as fast as possible so you know what your real technical challenges are going to be.
  • Don't rush and build an unsteady foundation that'll fuck you over 6 months from now.

My approach has been to push forward as far as the engine will let me in its current state, then stop and address the technical issues that arise. In the case of the Actions system, I think I failed on that front. I didn't get there fast enough, and wasn't aware of some important traits I'd need in my display data. If I rushed now, though, I'd screw myself by not addressing the issues. 

I'm gonna keep trying to learn from this. Actions, AI, expressions, clothing, and state machine testing are all gonna come in a big burst ASAP, so that I can see what pieces of my system are still weak. I'm in constant fear of building a shaky foundation, and want to do my best to navigate this as my own project manager.

>.<'

Any news on project maple? News on SHF3 is news on Project Maple. As soon as the foundations of the engine are stable enough for use, I'm gonna use the engine on Project Maple too. When starting the project, I didn't realize it'd take this long to get something usable, which sucks. But it's not on hiatus or anything! The current engine work is just blocking progress atm.


… and that’s all for now >.>;

I feel very, very behind. I know this is actually really good progress and everything though. It just sucks to look at the work ahead and think "ohh shit, this step is almost done!" and then realize that no.... nope. To be fair, this step is almost done, just not as almost as I thought.

Thank you guys. Your support throughout has kept everything going at the best pace it can be. This is my full time project, and will be until I've delivered enough to justify the time and resources we've all put into it. 

<3

Comments

No comments found for this post.