Welcome to today's blurb!

I KNOW IT'S BEEN FOREVER SINCE THE LAST BLURB.

Turns out when you combine getting back into college after a couple years with work and other social proclivities, your schedule gets a little bit. Add on a cool animation for a banner, and it's not super tough to see why this took a bit to come out. Sorry folks, I'm not a millionaire. If I was, I'd work on the blurb full-time!

Do you guys like the banner? Recently, I've really gotten into the NES title Metroid. It's a really interesting game! Although not great by today's standards as a result of particular gaming conventions of the era, specifically in regard to particular gameplay features (or detriments, as some would call them), it's not a title that you can say aged particularly amazing. However, in terms of atmosphere, music, and the level design, I think it's just a really neat title! The biggest draw for me from this title really comes down to two things: I feel like a rat in a maze, and I love the science-fiction aesthetic! I don't know why, but I hate it when I get stuck. I look all around, I consider all my options, and I can't get anywhere. Yet, when I think about it, it feels a little cool. A game has me stuck, and I need to really, really trace my steps. I want a game to make me draw out a map of where I've been, and where I need to go, even if I really find it super tough to the point that I hate it. That's what makes me like Metroid a whole lot. So far. Yeah, I haven't beaten it yet, and I really like that!

Apart from that, I also love the visual aspect of the game. Apart from the literal pixel-art bias, I really do enjoy the idea of exploring a desolate, hazardous, dangerous place. It is truly the equivalent of traversing a dark dungeon in a medieval setting. And guess what? You're alone. And the folks that want to stop you certainly aren't pushovers, they're BIG. They're STRANGE. And most importantly, they're ALIENS. I think just this aspect of NES Metroid is what's going to get me into its SNES successor, Super Metroid. The time will come, but first I actually need to beat the game. So hopefully you guys enjoy the banner for this blurb, it certainly is a lot of fun to make pixel animations when I get the chance. Almost makes me want to go back into game development again!

So what's been up? What has happened for the past HOWEVER MANY WEEKS it has been since the last blurb? Ever since the Brickadia Demo was shutdown, we've all been eagerly anticipating the release of Brickadia! With that in mind, it would definitely seem to be the case that many folks are in hibernation until then. Who can blame them? If I had a time chamber of some sort that put me into stasis until release, I'd go into it and use it.

For this blurb, our speculation column will be going into the last and final bit of the recently released development blog. I say recently, but considering how long the last two delays were, it would seem to be it released as recently as when the Hindenberg crashed and burned, relatively speaking.

With that out of the way, let's take a look into the paranoid ramblings, delusional art, and the images described by the voices inside the community's heads since release are!

Time to finish the next half of this blog post released by the developers! If you haven't read it yet, read up on it here: Next Fest Wrap-Up: Survey Results, Plans for EA

If you weren't here last time, we took a look at the survey results from the demo release of Brickadia. To summarize it concisely, the results were, all around, pretty good! We got statistics on the playerbase, such as age demographics, we got to see what users spent their time on the demo doing, what they found super easy, and what they found to be not so easy!

But now that we've gone through the positives, it's time we get to the feedback. That's right. Survey results really only say so much, but they don't always get into the nitty gritty of what could potentially be an issue for the game!

So let's get into the feedback that the developers noticed, their plans to fix them, as well as some other news...

First of all, the acknowledgement of a long time issue: the bad, bad hit detection! (whatweretheythinking.jpeg)

For a while now, the hit detection from weapons haven't been the best. But what is hit detection? Put simply, You could swing an axe around, you could SEE it hit another player, but it wouldn't register as an actual hit all the time. This is an issue that can be especially annoying in situations that require intense concentration.

Beyond other weapon issues comes the acknowledgement of vehicle handling issues. They're a little tough to control! I mentioned before that I believe part of the issue specifically comes down to the default settings for vehicles in terms of torque and driving speed, since the heading for this section specifically mentions slipping. However, there is a whole other issue being talked about here instead!

What's the issue? Generally speaking, the issue is wheels going over small bricks. You drive up a studded ramp, you hit the brick, the car does somesaults. There is also an issue of what the developers called clipping. To put it in brief terms, you'd drive along a completely smooth surface made of multiple bricks, but go far enough and the vehicle would act like it was hit by a tiny little bump or obstacle that ruins the ride. Imagine driving along a road, passing through a crosswalk, but the bricks that make the smooth crosswalk, despite the road being completely flat with no bumps or extrusions of any kind being present, collides with the vehicle.

Another problem, one that hits home for me, is the lack of prefab support for physics grids. Let's reword that to better understand what's being said: there's no physics prefabs. What does that mean? It means that there isn't support to just paste a prefab that has multiple physics connections intact. Instead, with what we've seen in the demo, the most we got was the ability to place objects as physics objects, but you wouldn't be able to retain the physics connections intact. This also applies to copying and pasting builds with physics connections or constraints. Got a car you want to paste several times? Well, you can copy the vehicle, but you can't paste it with its wheels, got to reconnect them!

Let's move on: physics griefing! Turns out the reason the developers didn't really want to give the demo a public server list was as a result of the possibility of server griefing which, inevitably, took place on some servers. A bit too easy for some folks to do, so much so that even I experienced it on a server that I had hosted briefly. This could possibly tie in to the lower-end rating of admin tools in the demo release of Brickadia in the demo survey.

This also comes with the acknowledgement of some people hoping for a position resetter for physics contraptions and vehicles. A neat idea, something that would make things like (sort of) respawning vehicles convenient!

Then we get to a big thing: the demo tutorial! It was BAAAAAD. Promps on the corner of my screen that I also can't immediately click exit on? What were they thiiiiiiiinkiiiiiing!

In all seriousness though, I feel like a tutorial that has a dedicated world to it that involves creative engagement is effectively the way to go. Want to learn how to use the manipulator? Use it to bring a bridge down! Want to learn how to drive? Crash a semi into a grocery chain! There's a lot of ways to make a good tutorial, so it's good to see the developers acknowledge how clunky and mind-numbing the tutorial was for the demo.

Lastly, limited minigame mechanics! You got the wires, but there's no direct implementation for it in minigames, which sort of ties into the home position reset idea previously mentioned for vehicles and physics contraptions. If you wanted to make a minigame where players competed to destroy the same building as fast as they could against each other, how would they do that without some sort of wire implementation that compares scores, resets the position of bricks, and so on and so forth?

And now we've gotten to the plans for Early Access. Yeah, so we've heard the problems. Now this is the part where they say "Alright guys, shut up, this is what we're going to do." And man, the the things they're going to do looks pretty alright!

For one, we get a bit of a bombshell straight off the bat. For one, the plans mentioned are their priorities for the demo. The cherry on top?

The developers of Brickadia will be aiming for July 2025 as the Early Access Release of Brickadia.

Now here's the million micro-brick question:

Extraordinarily difficult questions aside, let's see what the plans mentioned for the Early Access demo are!

In this section, we basically see a lot of fixes for the criticisms we saw earlier in the post.

For example, we'll be having an upgrade to the save and build-paste system. This will allow physics contraptions to be pasted easily!

On top of that, it's also mentioned that the Selector tool will be updated to allow for the selection of multiple brick grids, which basically boils down to being able to copy-and-paste physics builds. So yes, we WILL be able to have the convenience of copying and pasting cars in the futures without losing your wheels in the process.

Improved hit detection! 'nuff said.

The GALLERY? That's right, in order to share your builds more efficiently (in contrast to posting a file of it on a Discord server where only part of the community is on), a new feature is being added that allows you to post your builds in-game that allows for the build to be shareable to other people. Think of it like Garry's Mod's workshop feature except in-game. Or at least, that's what I assume it'll be like, considering it's a "...new feature coming to EA" and that "[i]t comes with full in-game integration", as the blog post describes it.

Now here's some good stuff, we're getting improved physics and vehicle handling! Ripped straight from the post, you can read it as if it were a quote.

What does that mean? While the issue of clipping with regard to vehicle movement is what the developers describe as a "limitation of physics engines", there are ways to potentially either fix or, at the very least, mitigate this issue! The phrase "implementing sweep-based vehicles/wheels" was mentioned in the post, and I have no idea what that means. My ability to understand it more in-depth is being impeded, likely due to my degrading mind as a result of months of unintentionally consuming brain-rotting content. So let's ask Google for some help!

After getting a headache, from what I'm able to gather, it's sort of changing how wheels and vehicles collide with the environment. Generally speaking, "traditional" collision as we know it in-games tend to check if two objects overlap each other at any interval. However, for sweep-based collision, which is what I am assuming is being implied here, this takes an extra step, so to speak. Instead of checking at the moment, sweep-based collision checks to see if there's any collision along its directed path. So when talking about situations where a vehicle is travelling at high speeds, the vehicle itself will end up colliding with barriers in the line of its path, in contrast to traditional collision systems that allow you to pass through certain barriers as a result of being too fast in such a short duration of frames.

Okay, so we got that, but what does that mean for the issue discussed earlier in this blog post? How does this relate to clipping? My guess, as peasant-like as it is in regard to complicated issues like these, would be that they could use the detection aspect of this sweep-based collision solution to look out for points in the floor collision to see where there could be a "spike" of collision, and respond accordingly. So instead of feeling like your vehicle hit a stray cat with your car going up in the air or tipping over as a result, it could potentially feel a lot smoother instead.

If I got the idea on point, please let me know. I will take a gold star as a reward for guessing that could be how the solution is tackled.

Moving on, it's also mentioned that we'll be getting weight bricks, as well as the ability to adjust a vehicle's center of mass. On top of that, the developers plan on upping the friction on tires alongside handling improvements. If I had anything to say about that, I think it would be neat to have the friction of tires be an adjustable property. Also, hang on. Weight bricks? We lifting? Jokes aside, I'm assuming that the developers plan on adding weighted bricks. But in what way could they be added? Will there be a distinct variety of weighted bricks? Is their weight an adjustable property? Based on the wording, which is "various weight bricks", it gives the idea that there will be a collection of weights for physics use, possibly for vehicular and non-vehicular uses. If I had anything to say about that, I think it's a neat idea. I'm more in favor of just having the weight as a property in any brick, but we'll see what they have planned in that future blog post they alude to.

WIRES 2? Oh, Wires V2, my bad.

One of the big problems with wires, as mentioned earlier in this column, is that there isn't really any implementation for it in regard to minigames. Tacked on top of that is wires being dependent on brick components to even do anything.

The solution? Generic gates! This enables the use of multiple different wire types. The term "generic" is dropped in reference to this feature. What the heck could that mean? Obviously, it doesn't mean that it's boring, far from it, actually! If I had to make any conclusions regarding what this generic gate could be, especially based on the text that follows described that it "[allows players] to implement gates for many different wire types", then the generic aspect of generic gates would probably be similar to what it means on the programming scene. From what I recall, generic specifically referred to classes or, to oversimplify it, particular pieces of code that can take multiple different types of data types, whether they be String, integers, or whatever you may have. I won't go too deep into it, but I would assume that generic gates allows for the use of multiple different types of values, whether they be strings of text, mathematical values, boolean values, or whatever in relation to whatever function these gates are meant to help fulfill.

Now take my word with a grain of salt for all of that, it has been a while since I've been on the programming scene, mainly as a result of being busy with work, blurb, and my own laziness.

What is interesting that they do mention after the convenience generic gates can provide is the mention of a selector gate. Based on what I am able to ask from my engineer source from many blurbs ago, a selector gate could literally refer to the idea of allowing there to be multiple inputs and outputs for a particular gate, which lines up with the text that prefaces the mention of selectors. This could also refer to any gate, meaning you could potentially have multiple inputs and outputs for a lot of in-game logic gates.

The next fix that's mentioned by the developers regarding wires is a fix in the timing of logic gates. Before, it was possible for the order of function for logic gates to go out of sync. This is as a result of the current wire system being, in essence, a hardware simulator. However, this brings a problem around where as a result of differing lengths of logic gate paths that a player may have for particular wire functions, the timing for wires could not only just go out of sync, there was the very real possibility of endless wire loops. For this, Wires V2 will make everything work in a single tick. Definitely an oversimplification on my part (I can't help it, I'm NOT a wires guru).

Finally, for Wires V2 comes the introduction of a new logic gate: the Microchip! Now unfortunately, despite being aptly named the Microchip, it's not actually micro-sized. Neither can you stick it onto someone as someone with a mind inclinded towards ill-conspiracies and ominous, government plots might think. Despite these shortcomings, it actually has something pretty awesome packaged with it: the fact that you can package entire logic-gate functions into the brick itself. Think of it as a way to nest whole entire functions into one brick. Modularization, pretty epic!

To talk more about what the Microchip brick is able to accomplish, we need to talk about what the developers are planning in reference to minigames.

For a while now, they've been talking about completely replacing the minigame system. It's old, it's limited, you can't do much with it. Good riddance! So what do we have to replace it? A new Game Mode system! Generally speaking, the new system operates like the old, but the key difference is in regard to the UI and how you set a game mode up.

For what's described in the blog post, the game modes are saved separately from world saves. That way, if you want to slap a new game mode into a world, you can swap them out. Additionally, Microchips will enable new functionailities into game modes, allowing for potentially new gameplay features to be made into the game modes themselves. And remember how I mentioned that you can't really stick Microchip bricks onto players? I lied! You've had a microchip inside of you all along, and I've programmed the logic gate circuitry to force you to read my blurbs forever! Jokes aside, the possibilities of what you can do now with game modes with the newly added functionalities of the wires system with Wires V2 in reference to the new gates that are planned, in addition to what you're able to do with the new Microchip brick is fairly promising. No more will you JUST have deathmatches or pictionary-themed games!

Knowing all of this, I would like to hope that the developers plan to make some premade game modes for players to try out right off the bat without having players resort to making certain, basic game modes themselves.

Lastly...

A tutorial world! A huge step up from the UI "tutorial" given to players on the demo release. That's right, for Early Access release, there will be a fully functional tutorial world that will allow the player to learn and use the different features that Brickadia provides for building. My biggest hope is that the tutorial is fun and creative. You can't really make the perfect tutorial, but you can make one that's enjoyable and memorable. Which is why I'm hoping that the tutorial world features things like one-off characters made using physics mechanisms and the like. It's not something you see every day, but brick-made characters are always a neat thing to see!

And now we've gone through everthing. What a blog post! Skimming through the after-content, we find out that apparently, 5 people won Early Access Steam Keys for when the game launches as a result of their participation in the demo survey giveaway. I should've opted in, I didn't know about it!

So what's the take away from this blog post? Despite whatever ill-feelings you may have regarding this game (having delay after delay wading waist-deep through the bog of the ubiquitous indiedev marsh), it seems like a large majority of people, based on those that tried the survey, liked it! There were some particular criticisms regarding the game, mainly in reference to vehicle physics, wires, minigames, the lack of physics prefabs, a bad tutorial, and the ease of griefing. Despite this, the developers have plans to improve every one of these areas thoroughly, in addition to entirely new features with these things! All this, we'll be expecting in July of this year. Yowza!

The big question, however, is can they do it? Will they be able to launch on time with all these fixes and changes? We'll get into that, on the next blurb! I am now programming the microchip I have implanted in all of you to stick around till the next blurb so we can delve into that topic.