Progress Update- Deep in the display code uwu (Patreon)

A tough but productive week!

I have a coding stream starting in an hour! 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 is an exhausting one. It’s going well, but it has taken a lot of mental fortitude to keep pressing through this damn thing. It delays updating the game’s visuals until the end of a tick. That’s the whole idea.

There’s a handful of benefits:

• The game logic can happen without knowing or caring how it’s displayed
• The display logic can happen without caring about game logic
• Display logic can happen in a different order to game logic, avoiding thousands of null errors and saving billions of lives

There are three steps for this to work properly.

1. Game logic happens (a dildo is moved). It doesn’t know anything about how the dildo is displayed. It just sends out an alert that it happened.
2. A display controller catches the alert. It knows exactly what animations and sprites are associated with the dildo. It writes a message detailing how the animations should be changed to match the dildo’s motion, and where the sprite should go. (And technically, there could be just 1 or 10 different controllers, updating the dildo’s UI, doing dildo screen effects, zooming the camera on the dildo, etc)
3. The display message system receives the message. It knows nothing about the dildo or why anything is changing. It just gets the order to move the animations and sprite, so it does it.

What’s common here is that in each step, the systems don’t know anything about each other. Game logic, display logic, and the actual display are separated, and done at completely different times. And the last step is the important one. It takes all the messages the display controllers send, sorts them by priority, and does them all at once.

This whole thing was made necessary by the Actions system, which I detailed in my last post. It turns out it’s a good thing I was forced to do this, cause it’s making my code wayyy better. Having the different steps separated makes things a lot easier to maintain and grow in the code. Adding new features and mechanics is dead simple with this architecture.

Productivity this week

The code was hard so I struggled to focus on it. It required a paradigm shift in the way I look at what the code is doing and trying to do. I also wasn’t fully convinced it would work, or was a good idea, despite the decision to make this change. The confidence came once I broke through the first few challenges in it though. It proved to not only work just fine, but be a lot easier to build and debug than my previous code.

I ran into this Veritasium video along the way. It’s a broader video on expertise, but the main point I took from it was about the exact experience I’ve been having. It’s about when you’re practicing a skill and doing something that feels frustrating and confusing and uncomfortable. That feeling is a sign that you’re pushing against the edge of your knowledge and understanding. And when you’re in that zone, that’s when you’re actually learning and improving. Seeing that frustration as a sign of positive progress - and inevitable improvement - was an important mindset shift for me. It recontextualizes the struggle of learning into a tough-but-sweet experience that builds up strength and confidence, rather than wearing me down.

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

Sorry if there’s not much in this post. Since the entire week was just this one task, and I’m not finished with it yet, there’s not much to talk about. When it’s done, I’ll be able to use it to start showing off the Actions system. That'll be fun!

Thank you all so much for following and supporting this absurd project. I’m doing everything I can to make it worth the wait <3