🔃 Sunday Devlog 38: Doodad Emporium

At the moment, the heavily lifted features for 1.3 are waiting on controller support on the engine side (this has been going on for a while...) as well as some engine-side bug fixes as well. I've been doing my best to help get those resolved by working with the engine dev, but oh boy is development messy.

So, for this log, allow me to showcase some funny circuits 1.3 utilizes and how they'll be running the upcoming major update!

1.3's Circuits

Starting off, we have the:

Achievement Registrar

This group's job is to send a signal into the "SAI" bundle at the end, the achievement bundle that was successfully tested last devlog.

So, why's there all this random stuff around it? Well, the thing is, the achievement system can only successfully register one achievement per three seconds. Because of this, if multiple achievements get activated at the same time, there needs to be a way to ensure that the "pending" achievements have their shot. So, the timer placed before the text that activates the achievement is there to send a new signal every three seconds, until the achievement bundle sends a signal out confirming the achievement.

After it does this, it disables the timer so it stops sending requests over and over. In addition, it sends a signal to a saved value that ensures that a signal is never mistakenly sent to activate the achievement again, further helping minimize clogging.

There are very few situations with the achievements where you can get multiple in a row, but it's a very real possibility. This system allows the achievement system to work in a much safer way!

Controller Nav Configurator

The actual controller navigation system is complicated, a little messy and very spread out. Most circuits would take a while, so here's a simpler one. This group of values that go to message behaviors get whatever info is necessary for the controller nav target to work.

The controller navigation system works by having an invisible object shoot a ray out in the direction of the D-pad to find a button to select, and it then teleports itself to that button. This sounds like an odd method, but this way allows button layouts to be visually edited.

This visual editing is enhanced by this group of behaviors here - you can set how big you want the target to be in terms of X (width) and Y (height), you can set if the raycaster should start at this specific button on the level start, what scenarios permit the button to be selectable at all, and more. This took a lot of extra work to set up, but it means that adding new menus is a complete breeze!

Level List Assigner

In Sunday Devlog 32 and 33, a level list feature was shown that displays all of the levels in the game in a big list.

The way each object knows what level info to display is determined by the code above. When you flip through the list, you're not actually flipping through separate objects - instead, the objects themselves change themselves to display the info for a different level!

Put simply, when you press the left or right arrow, it updates this value inside all of the level lists that tells them what page they're on. The filters above and below the number behavior allow the pages to loop if you go beyond page 5 or further back than page 1.

From there, an expression takes the list, along with a value that determines what place in the list it is (the name), and uses this to figure out which number, representing a level, the list object should display.

You may also notice a section at the end labelled "17 erasure". Essentially, the warp album was originally planned to have four levels instead of three, so the numbers for all of the levels got assigned back then. By the time we learnt that the album would actually have three, it would have taken more time to update the numbers for all of the other levels across different parts in the game. So instead, every time the levels are listed, the code just makes sure to pretend 17 doesn't exist and outputs the next highest number instead :P.

Wrapping Up

Truthfully, I'm not aware at what point the engine shenanigans will be fixed up enough for public testing to start. On top of that, I'm once again getting weighed down by schoolwork a lot, which is why this devlog is coming a little late (sorry ;-;).

For now I'm unaware of how much is coming for the future, but regardless, 1.3 being so close in general is really exciting! I can't wait for everyone to eventually get to enjoy everything we've been cooking up the past couple months. Thanks for reading as always.

-Encabulated Games