Hello everyone!

The time has finally arrived for us to announce our third major update for Brickadia! On top of that, Brickadia will be going on sale during the Steam Summer Sales, starting June 25th all the way to July 9th!

This update has been in the works for a long time, and we all hope you're as excited as we are for when this update drops on July 3rd, 2026. Thrusters, game modes, new vehicle physics, new logic gates, huge performance improvements and so much more are on their way!

If you don't have Brickadia in your Steam library already, now's your chance to get in on the brick action while the game is 50% off:

Additionally, if you haven't done so, you can stay updated with Brickadia by following us on social media and by joining our online communities: Bluesky, Twitter/X, TikTok, YouTube, Instagram, Discord, Reddit.

Stay tuned for further content in the future!

Hello fellow Brickadians! We've been super busy working on the next version of the game that will have scripting, voice chat, new wires features, performance improvements and more! But first, an announcement:

Brickadia is taking part in the Steam Spring Sale! The game will be 25% off all through the sale. If you want to pick the game up at our lowest ever price of $15, now is the time!

Overall Goals

Brickadia is a great building game, with some of the most robust and advanced tech powering it (in our opinion!) But with it's current feature-set, building is still the one primary way players play the game. It's very rare to see other kinds of servers beyond your classic freebuild server.

Our goal with EA3 is to turn Brickadia from one of the best building games ever to one of the best games ever for building and playing. In other words, give Brickadia gameplay!

We want you to be able to make tycoon games in Brickadia. We want you to be able to make Battle Royales in Brickadia. We want you to be able to make procedural dungeons in Brickadia. We want you to be able to make Prop Hunt. And Trouble in Terrorist Town. And deathruns. And so much more.

While some of these games sort of exist in the current version of Brickadia, they usually employ a ton of tricks and hacks. Most are unfinished due to a lack of tools to let creators cross the finish line.

Like last time, there is a lot we are doing. Let's talk about it!

Proximity Voice Chat

Brickadia will soon have proximity voice chat. Speak to your friends as you would in a Discord call, but in 3D space!

It will be highly configurable. Servers can enable and disable it, players can mute others, and it makes everything just a bit funnier.

New Wires Features

Everyone trying to use wires has the same three problems:

• Wire contraptions take up too much space.
• There is a lack of useful gates.
• They are super annoying to edit once they've been built.

Let's fix all of those at once!

Microchips

You'll soon be able to collapse your infinitely complex circuits into a single brick with Microchips. You can put a microchip anywhere: inside your arcade machine, inside your car, even inside another chip!

We are working on further features for microchips, like inputs and outputs, gamemode integration, and player microchips, prior to release. Stay tuned on this one! It's going to be big.

New Gates

We're adding a bunch of new gates to the game and have a bunch more on the way. Our focus with the gates we're adding is the same as it is for the update overall. We're fully invested in drastically increasing the scope of what Brickadia can do gameplay-wise.

One of the reasons we haven't added very many gates in the past few updates is because it actually involves quite a bit of stuff: Programming a gate involves quite a lot of boilerplate code, and art pass where the final gate was modeled by hand. Over the holidays, we've streamlined this!

We're now procedurally generating our gate models. This has allowed us to speed up our iteration times by decoupling the need for a gate model from the final art pass. We also decided to update the base model for gates to try and make it slightly easier to read connections and layers of gates. It now only requires us to manually add the icon to make the gate shippable!

Icons are now textured icons, rendered using an MSDF-encoded texture. No longer are the icons 3d modeled and baked into the gate mesh!

Vectors are now a supported wire type. All of the existing math gates will support it, and we're adding new gates to complement them!

We're also finally adding support for strings! All of the existing gates that accept a text/string input will be upgraded to have a wire port for the field. We're also adding gates for manipulating strings: formatting, combining strings, etc. And of course, there will be new gates to display text, including one that will let you place text and icons anywhere on your HUD.

So far, a lot of the changes have been back-end changes, but we did still manage to cram in a few new gates. We still plan to add a huge number of useful gates before the update launches, so if you have any suggestions, please let us know through our usual channels!

Moving

The resizer will soon be able to move and rotate bricks. Meaning you can now move and rotate your gates without disconnecting the wiring:

You can even move multiple bricks around at once:

We hope this will make wiring a bit less painful than it is currently!

Scripting with Luau

Scripting has waited long enough, and is now officially in production! The next version of Brickadia will feature Luau, a high-performance scripting language, complete with a REPL accessible via chat and the console.

Luau scripting is intended to have a lot of control over the game. For that reason, we're gating script usage behind a special permission. It is also server-side only, but we will be augmenting it so you can do more client-specific tasks like UI. Worlds and Gamemodes can include scripts, and they can be shared on the Gallery.

This prototype version uses auto-generated bindings based on Unreal Engine's API, so there will be many changes to make scripting easier and friendlier.

Here's some things people have already done with our initial prototype!

There is still quite a bit to do, but even in this state it can do quite a lot.

Performance Improvements

For every major update we try to make your game run a little better, and this one is no exception. Off the top of my head, here's everything we've done so far, and there might still be more to come:

• We've upgraded Unreal Engine to 5.7, which required solving several hundred rebase conflicts to integrate all our custom changes into the new version (it turns out Epic also likes to change the engine a lot!),
• We've fixed a major performance flaw in the Iris replication system that was causing it to poll sleeping and frozen entities every frame, only to discover that they did indeed not change,
• We've implemented a new fast rendering system that makes use of a new engine feature to render meshes while completely bypassing all the overhead that comes from using heavy primitive components to draw them, now in use for brick cluster meshes and character parts,
• We've implemented a new tick manager for brick components that only sometimes require ticks to update every frame, such as wheel engines that can go asleep when no one is driving the car and the steering has returned to idle,
• We've moved the final remaining part of the weapons system that was using Open Alpha-era barely functioning server side hit detection (melee weapons) to the new system of client predicted hits, which then allowed us to completely disable evaluating player animations on servers and only do it when the player is actually visible on clients,
• We've nativized more parts of old character blueprints like updating the nametags on screen that was taking up a lot of time, and optimized some redundant logic for bot controllers,
• We've made buoyancy computations roughly 10 times faster while also parallelizing it, now making it so fast that we could also enable buoyancy for all entities such as wheels,
• We've fixed that light components did not correctly apply the radius clamp from brightness when loading a map in single player or as a listen server (the issue did not occur as a client),
• We've refactored the brick cluster mesh system to now allow merging geometry across chunks when the world contains many sparse bricks over a large area, though it cannot yet combine meshes across different grids,
• We've removed all unnecessary access to physics scenes from background threads, which now allows us to run PhysX without the scene locks on every API call, removing a lot of overhead on basically everything,
• We've started compiling our "shipping" config binaries with Thin LTO, allowing the compiler to remove many unnecessary virtual function calls and inline small functions even across different files and modules,
• We've fixed that physics wasn't parallelized at all on typical cloud servers with two cores, previously it only worked on three cores and up,
• And more that wasn't worth mentioning here...

Client Performance

Wew! That's a lot! So what did we gain? Are we writing all this fluff for 5% performance gains? Well, let's compare EA2 to the current main branch. We'll use a version of the world "Pinkadia" for comparison, which is one of the most complex worlds ever created in the game:

Since most players would see this as a client on a server, we've also joined a server as a client. These screenshots are taken on a system with a RTX 5090 and Ryzen 9950X3D, but relative improvements are similar on other computers.

This world seems to perform terribly on a very high end computer. Let's see if that runs any better in the new version so far.

We've certainly made progress here!

There is more to come for optimizing the client - we'll soon introduce a new kinematic joint to connect multiple grids together rigidly, while allowing it to rotate with interpolation when controlled by a wire. This will allow you to replace slow physics based doors with much faster kinematic grids, and in the case where the angle is not controlled by a wire, we will be able to merge meshes across subgrids, making builds with a lot of rotated decorative grids massively faster.

And we haven't even started optimizing the GPU memory usage yet - the core brick renderer is still from Open Alpha days where builds mostly fit in VRAM and ray tracing was something far off. There are plans for streaming brick clusters so only the ones within the view distance must be resident in VRAM, and a new way to organize brick vertex data that should reduce its size by roughly 5 times (sadly, that will not apply to the separate ray tracing data, but it should help low end computers who will not be using ray tracing anyway the most).

Server Performance

Dedicated servers are now also much faster. Before, most of the time was spent on useless things, which we've now removed. For example, here is a direct comparison of a server frame running Pinkadia with a single client connected. To capture this trace, we have to use an instrumented build, so it's a little slower, but watch the difference in timings of the sections:

Running the server with tracing capability adds a lot of overhead, so let's also just compare the final frame rate the server is able to achieve, by joining it as a client and viewing this beautiful tps counter made out of bricks and gates and wires:

In the proper "shipping" configuration of the server we can now also see the performance impact of using Thin LTO to let the compiler optimize across the whole program, making it even faster than the previous comparison.

A listen server runs both the client and server code each tick, so if you are hosting a large world locally, you should expect performance increases somewhere between the two above.

Oh, and we've also made some tools so you can make your own builds and servers faster rather than waiting for us to find a way to do it by magic!

Performance Debug Views

Previously, whenever we tried to implement debug views in the engine, the performance left something to be desired:

But recently, we've gained a super fast new debug drawer based on the excellent work in the VoxelCore plugin:

So naturally, we had a solution and went looking for problems to solve with it...

For those interested in finding laggy contraptions in your servers and improving the performance of your worlds, we now have several useful debug visualizations you can use, all of which also include statistics for you to look at and use to track down performance issues on your servers.

Entity Debug View

This makes it easy to track down rogue entities, like physics grids, that may be contributing to server tick rate issues. It can be enabled with BR.DrawDebugEntities 1.

Watch out for red entities. Those are actively moving in the simulation and processed by physics and replication.

Light Debug View

A very common performance pitfall many builds suffer from is from overlapping lights, and this visualization makes it very easy to spot. It can be enabled with BR.DrawDebugLights 1.

If you have many overlapping lights at some location, and you get close to that location, all those lights are going to cover your entire screen, which is very slow.

So we thought it'd be useful to show how much overlap there really is, counting up for every light how many others touch it, and coloring them from green to red depending on the number, which ended up being a lot more difficult than expected.

Quiz: How do you determine which of 15,000 lights overlap each other in under 0.5ms on a single core?

Replication Debug View

It can be difficult finding specific contraptions in your world that may be contributing to network performance issues. Thankfully, we have a colorful solution! This can be enabled with BR.DrawDebugClientUpdates 1 in the console.

Collider Debug View

We've had this view before, but it has now been upgraded to visualize the origin, center of mass and intertia tensor of the object, letting you see whether your custom masses had the intended effect. It can be enabled with BR.DrawDebugColliders 1 in the console.

Brick Cluster Debug View

This one shows you how the brick engine groups the brick geometry to render. It can be enabled with BR.DrawDebugBrickClusters 1 in the console.

Other Goodies

Characters are finally present in the ray tracing scene, and the quality of ray traced reflections is also vastly improved with the new engine version.

We've fixed replication of sleeping object positions. No more will you load into a server, approach an object, only to learn that it did in fact not exist at that location, and see your character teleport 50 studs to the side.

We've added a network lag indicator that shows up if your average latency is too high or the server hasn't sent any message at all within a short time frame. There's also a similar warning for getting close to maxing out your system VRAM.

...And more.

There is so much else that we could have covered, but we have to get back to work! If you want to see further highlights, we highly recommend joining our Discord to get the latest and greatest news in one place.

Thanks for reading! Stay tuned.

Hey everyone,

We've been reading all your feedback since the Early Access release, and one thing that's come up very often was the price of the game. Many of you felt that $29.99 was too high a price while the game is lacking the last major features, and was making it difficult for you to get your friends to try it out with you.

We are confident that $29.99 reflects the value of the full 1.0 release, but we want the price to reflect the Early Access journey we’re on together right now. To make it easier for you to invite your friends and grow our community, we’re lowering the price to $19.99 for the duration of Early Access. Regional pricing will apply as before.

To those of you who have already jumped in at the original price point: Thank you! Your early support has been instrumental in keeping development moving at this pace. We've always said that our community is the most important part of this project, and by making the game more affordable now, we hope to see your servers feel a lot more alive.

What's next?

We have a large content update following soon after with many new additions to the logic system, giving you greater control over your gameplay. Stay tuned!

This is our first major update! We've cleaned up all major bugs and fixed a lot of stuff that was broken since EA1. If you encounter issues, please let us know in the bug-reports channel of the Discord or the Steam forums.

Winter Sale

Brickadia is taking part in the Steam Winter Sale! If you haven't bought the game yet, now is a great time:

Major Features

Customizable bots to give life to your maps! Give them any weapon and customize their settings like aggression or 360 degree vision. You can use them without weapons to create wandering NPCs, give them swords to make an army of warriors, or give them all guns to create a deathmatch server. They look the same as a player, and you can give them your avatar settings.

We've fully reworked the prefab system. The new prefabs live in your catalog! Save entire cars, contraptions and other interconnected objects locally for easy reuse. Grab a vehicle from the gallery and place it, instantly, anywhere you have permission. Copy things from the world into your real clipboard, and paste them into Discord or another running instance of the game.

The selector has been completely rewritten with a new connection mode. Grab a complete physics contraption with all connected grids and entities in a single click.

Four separate player collision channels let you create invisible walls that only certain teams can pass through, opening up new possibilities for minigames and maps.

A new component that lets you dynamically change a brick's visibility, collision, and color through wires. Perfect for hidden doors or interactive displays.

The Applicator and Connector now have an X-Ray mode, letting you edit components on bricks hidden behind other bricks and entities.

Full Changelog Since EA1

Gallery

• Renamed "TOP" and "TOP ALL TIME" categories to "HOT" and "TOP".
• The "HOT" category now also shows older files on the next pages.
• The browser page no longer reloads every time the dialog is shown.

Worlds

• You can now save the server world to your client if you have any building permissions.
• You can now upload worlds to servers with extended permissions. The server will be in read-only mode with autosave disabled.

Prefabs

• A new prefab browser is now integrated into the catalog, letting you save your creations and add them to the inventory to place much like bricks and entities.
• Prefabs now have automatically generated thumbnails that look the same as bricks and entities, no longer requiring you to get a nice screenshot.
• A new prefab gallery is also available, letting you share your creations, and browse the ones others shared to use immediately or save for later.
• Copying things now stores a prefab file in your clipboard, letting you paste it in another game client or share it through applications like Discord.
• The legacy prefab system and its associated dialogs were removed, but a button exists in the prefab browser to convert any legacy brs files you may have.
• The Max Selected Bricks default value is now the same as Max Prefab Bricks.

Physics

• There are now 4 separate player collision channels, so you can make invisible walls that only some teams can pass.
• Can choose which channel to use on a per-team basis, as well as which channels players on those teams collide with.

Selector

• The selection system has been rewritten and now supports tracking an explicit selection of bricks and entities.
• When using a selection box, in addition to immediately copying/cutting that box as before, you can now also add/remove the bricks inside to your selection to refine what you have selected in multiple steps.
• The selector now has an alternative connection selection mode that selects adjacent bricks, such as a whole house on its baseplate.
• The connection mode also supports selecting an entire physics contraption including all connected grids and entities.
• Added entity and brick count limits to the selector.
• The mode switch binding has been changed to C.

Applicator

• You can now press R to toggle X-Ray Mode, which will edit bricks that have existing components through other bricks and entities.

Connector

• The connector now also has an X-Ray Mode that only interacts with bricks that have components.
• The gate brick will now be highlighted when hovering a physical port.

Painter

• The painter can now paint and pick the color sections of entities, such as making wheels have differently colored tires.

Building

• High friction tires is now the default for newly placed wheels.

Components

• Added a new component, the Brick Property Changer. Can be used to change the visibility, collision channels, and color of a brick using wires.
• The ancient per-type component quota has been removed. There is now a single per-user quota of active components (lights, audio, item spawns, engines, etc) which can be adjusted in server settings.
• The Seat component can now be manually attached to all bricks, in case you want to fit custom seats in tight spaces.
• All the uncategorized components have been organized in the list.

Bots

• Bots can now be given weapons and use them, attacking with melee weapons or shooting guns, reloading them when appropriate.
• Bots can now wander around freely on the map or walk towards goal points, jumping over obstacles.
• Bots can now be given character skins by copying the current skin from your character.
• Bots can now damage players in the default minigame and join teams by coloring their spawns the same as the team color.
• Bots are now considered for win conditions like last man standing.
• Bots can now spawned and despawned by wires.
• Bots have a lot more settings than we are able to list here.

Weapons

• Return of Crystal Kalis which was accidentally disabled.
• Added Laser Cleaver.
• Added Laser Axe.
• Added Medi-Syringe, an item which quickly heals 50 health when used.
• Added Spear, a melee weapon with a fast underhand stab and a slow overhead stab.
• Added Bandage, a slow self healing item that restores 25 hp.
• Added Basic Claws, Sharp Claws, and Shadow Claws, fast melee weapons intended for zombie bots but also possible to use yourself.

Cosmetics

• Added Twintails
• Added Snout (multiple variants)
• Added Shaggy Swept hair (2 variants)
• Added Wings
• Added Back Valve
• Added Robot Paw
• Added Robobunny Ears
• Added Secured Bag
• Added Employee Card

Sounds

• Tool audio has been reclassified under Item audio.

UI

• The world browser and catalog now remember the last used tab between sessions.
• Pressing Ctrl F in the My Worlds or My Prefabs tabs will now focus the search box.
• Clicking the current folder breadcrumb will now reload the listing to see external changes.
• The pause menu now has a button to open the server list when on a server as a client.
• The unimplemented admin button has been removed from the pause menu.
• Added the ability to search for worlds. Search also includes files in subfolders of the current folder.
• Added the ability to delete worlds.
• Added a dialog when failing to create a folder.
• Removed the defunct controller column from the key binding menu. This never functioned correctly once we began implementing chorded bindings for tools. The intended way to configure controller mappings is to use Steam Input settings.
• Removed the defunct help menu.
• Removed unnecessary "Release-" text from the version display in the top right.
• The folder tiles in the world and prefab browsers now show how many files and folders are inside them.

Servers

• Improved /BrickCount output to include entity counts.
• Removed /DestroyAllGrids, which was an obsolete test command.
• Added /ClearAllEntities, which removes all entities in the world.
• Added /ClearEntities, which removes your own entities.
• Added /ClearEntities [player], which removes someone elses entities.
• Added /ClearAllLooseEntities, which removes all entities not attached to at least one more entity.
• Added /ClearLooseEntities, which does the same but only for your entities.
• Added /ClearLooseEntities [player], which does the same but for someone elses entities.
• Added /ClearAllFarEntities [distance], which removes all entities further away than some distance in studs.
• Added /ClearFarEntities [distance], which does the same but only for your entities.
• Added /ClearFarEntities [player] [distance], which does the same but for someone elses entities.
• Added /BrickCount [player], which shows how many bricks, entities and components a specific player has.
• Updated player admin actions drop down to include Clear Entities, Clear Loose Entities, Clear Far Entities (defaults distance to 10000 studs).
• There is now a permission for whether players can use X-Ray mode, intended for Tutorial but can be used by players too.

Performance

• Optimized building and share zone checks when modifying bricks.
• Optimized zone checks when characters move.
• Optimized manipulator searching for possible joints to attach while holding entity.

Engine

• The experimental Behaviors code has been removed in preparation of integrating the new Lua scripting engine coming in a future update.
• The world boundary no longer instantly vaporizes your vehicles and simply keeps them inside.
• Some improvements to player movement prediction when walking on large frozen physics grids.
• Refactored how the game accesses worlds and prefabs. File handles are now automatically closed and databases unloaded after a few seconds of inactivity, allowing external access to the files.
• The Test executable is now included with the dedicated server deployment.
• Updated PhysX to the newest patch release of version 5.6.1.
• Updated DLSS plugin to version 8.3.0-NGX310.4.0.
• Updated FSR plugin to 4.0.2b, improving performance and stability.

Localization

• Updated Spanish localization with reviewed strings.
• Refreshed strings.

Servers

• The server log file now logs when a user is unbanned.

Bugs

• Fixed crash auto toggling tool with controller.
• Fixed crash joining server while using a controller.
• Fixed crash when creating a very (very) long chain of rerouters or logic gates.
• Fixed several crashes due to unused quickbar ranges legacy code.
• Fixed crash when recreating output wire with a new type.
• Fixed crash when taking a screenshot with HDR.
• Fixed crash when grenades explode after a garbage collection.
• Fixed clients crashing when homing missile hits a physics object.
• Fixed crash when dedicated server is left alone for a while due to iris replication not ticking.
• Fixed crash running out of replicated objects when playing alone in a listen server.
• Fixed crash when loading specifically crafted world file.
• Fixed crash when applicator dialog is viewing a brick component while replicating additional components.
• Fixed crash when equipping a tool while loading into the server.
• Fixed crash when undoing deletion of a brick tried to revive a brick grid that was deleted.
• Fixed crash due to incorrect check for sync state in async serialize function.
• Fixed crash setting minigame inventory size to 0.
• Fixed crash when placing, resizing and deleting bricks too quickly.
• Fixed crash when trying to load an old world file with components that no longer exist.
• Fixed crash when destroying brick grid entity with a building zone attached to it.
• Fixed crashes caused by being able to attach invalid components to bricks.
• Fixed check against NaN object positions not actually working on world load.
• Fixed rare crash due to use after free in legacy save file loader.
• Fixed rare crash in wire type propagation logic related to placing prefabs.
• Fixed brick replication deadlock in rare case where the first component in the update list generates a message of a specific size.
• Fixed trace scene corruption when trying to set the velocity of a frozen entity.
• Fixed broken overlap check allowing certain cases of intersecting micro wedges to be placed.
• Fixed very rare bundle corruption due to background file write tasks executing in incorrect order.
• Fixed being able to pick up multiple pistols.
• Fixed clients not being able to switch to precision mode on paste when copying bricks from physics grids.
• Fixed chance of mysterious 1 unit offset when using switch to precision mode on paste.
• Fixed Painter getting stuck in "Paint Only Material" mode if put away while ctrl is held.
• Fixed selection outlines not rendering in simple shading mode.
• Fixed hologram and translucent plastic brick materials causing Lumen to render an extremely slow ray traced reflection which cannot be seen.
• Fixed broken depth bounds for fog rendering causing it to cut off on surfaces close to the camera.
• Fixed Z fighting of brick previews when overlapped with the original bricks in precision mode.
• Fixed ugly one pixel visual seams along the edges of brick previews.
• Fixed race condition causing the options button on the escape menu to not function sometimes.
• Fixed non-deterministic vehicle behavior due to wheel engines not applying some settings on servers.
• Fixed non-deterministic joint behavior due to not updating average mass on modifying attached objects.
• Fixed contraptions exploding when deleting a set of jointed bodies and undoing the deletion.
• Fixed re-attaching objects to joints not correctly restoring the relative transform if the joint was bent.
• Fixed re-attaching objects to joints not correctly moving further attached child objects.
• Fixed incorrect mass calculation for bricks grids since the ability to disable collision was added.
• Fixed incorrect joint behavior after re-attaching a wheel to a wheel joint connected to an engine.
• Fixed deleting an entity and undoing the deletion not restoring any changed properties.
• Fixed deleting a frozen object and undoing the deletion failing to re-freeze it.
• Fixed having wheel joints connected to an engine preventing idle physics contraptions from sleeping.
• Fixed being unable to create multiple levels of folders for worlds.
• Fixed client predicted hit markers showing for objects that cannot be damaged.
• Fixed extra physics grids and entities attached to the vehicle you are in blocking the camera.
• Fixed loading a world in single player not waiting for meshes to upload before hiding the loading screen.
• Fixed wrong formatting for the message when using /clearbricks [name] as server.
• Fixed distance to target output not working when a teleport target wire is connected.
• Fixed server settings defaulting to the permissions tab.
• Fixed broken "at target" output on servo bearings.
• Fixed various correctness bugs in world serializer.
• Fixed being able to redo undone actions if the permission to do them was since removed from the client.
• Fixed being able to load nan values through presets in the applicator.
• Fixed being able to place more bricks in a single chunk that the world serializer will allow to load.
• Fixed brick grids teleporting into space when attaching a socket to a bearing.
• Fixed firing weapons in first person while crouched not hitting the correct target on the server side.
• Fixed being able to upload to the gallery from the downloads tab.
• Fixed lives counter not updating for clients in minigames.
• Fixed connection not being aborted if client fails to insert a replicated brick into the designated chunk.
• Fixed gallery viewer scaling incorrectly when there are very long titles.
• Fixed long gallery descriptions breaking the layout of the details page.
• Fixed buttons remaining held when clicked too fast.
• Fixed input splitter being shown in add component list.
• Fixed "Failed to insert brick in chunk" log spam.
• Fixed being able to get stuck in freeze camera mode when entering a minigame.
• Fixed not leaving the current seat when trying to use the teleport command.
• Fixed seats showing the sit prompt in third person when occupied.
• Fixed brick delete sound playing in wrong location when removing bricks from physics grids.
• Fixed "Reselect Last Port" on Connector not being rebindable.
• Fixed "Johnny Ledger" music tracks missing in minigame music selector.
• Fixed inaccurate tool traces against wheels attached to wheel joints.
• Fixed aurora setting in environment not functioning.
• Fixed a case of precision mode on paste selecting the wrong grid.
• Fixed water effects and damage not working when standing in low water.
• Fixed Missile Launcher still being able to fire when out of ammo.
• Fixed flying against a wall accumulating velocity incorrectly.
• Fixed gibs and detached hats affecting physics contraptions.
• Fixed being unable to kick gibs around.
• Fixed hitmarkers playing twice on clients.
• Fixed Manipulator not aiming correctly in free mouse mode.
• Fixed wires not respecting render distance limit.
• Fixed additional bugs that were not correctly tracked.

Brickadia is taking part in the Steam Autumn Sale! If you haven't bought the game yet, now is a great time:

EA2 Preview

At the same time, we're releasing a preview version of our first major update on the unstable branch so you can try it a few days early. This has two long-awaited major features:

We've fully reworked the prefab system. The new prefabs live in your catalog! Save entire cars, contraptions and other interconnected objects locally for easy reuse. Grab a vehicle from the gallery and place it, instantly, anywhere you have permission. Copy things from the world into your real clipboard, and paste them into Discord or another running instance of the game.

Customizable bots to give life to your maps! Give them any weapon and customize their settings like aggression or 360 degree vision. You can use them without weapons to create wandering NPCs, give them swords to make an army of warriors, or give them all guns to create a deathmatch server. They look the same as a player, and you can give them your avatar settings.

Watch the video below for a sneak peek:

You can read the full changelog on Steam.

Hello again! After our previous car building tutorial we promised to release a second part dedicated to car tuning, and here it is!

Got a car built and driving, but you're struggling to get it controlling well? Wheels bouncing all over the place, or your car flips over all the time? This tutorial guides you through the most important settings to tune your car properly, providing far better control and stability.

If you're not sure how to build a car in the first place, check out our beginner's car building tutorial.

You may note that we don't give concrete "recommended" numbers in this video to use - this is because everyone's car can be so wildly different! They can be small, massive, super long, super wide, carrying a whole lot of cargo, wielding a massive robotic arm, or even more. So, we encourage experimentation on your specific vehicles to find the right calibration for the kind of handling you'd like.

Thank you all for your feedback on our previous tutorial video - let us know what you'd like us to teach next!

Hey all! We've been loving your enjoyment and feedback of our in-game tutorial. We definitely want to build more in-game tutorials for more specific features, but we've also decided to start a new series of video tutorials too!

Our first video tutorial is on how to build a simple car in just one minute:

The next Brickadia video tutorial will be about vehicle tuning - guidance on how to create cars that are more fun to drive. Our video tutorials are going to always be uploaded in full on our Youtube channel with shorter versions on all of our other social medias, so follow and subscribe to become the most skilled builder around!

So, it happened. After quite a bit of time, Brickadia Early Access is available for people to play! We still can't really believe it.

We've been loving your creations on the Gallery. We saw a concurrent player peak just a little higher than what we had in the free demo, which is amazing for day 1 of the paid release! We also saw a really nice amount of engagement with lots of servers being put up and plenty of players running around doing things.

Short Term Roadmap

Bugs

It turns out the best way to find out how many bugs your Early Access game really has is to launch it! While we've tracked and fixed dozens of bugs during the closed beta, there are still a few more we didn't manage to get to in time.

Notably there are lots of crashes coming in from AMD. For now we've made the game switch all AMD users to DX11 by default as that seems to not crash. We've also bought one of the affected AMD GPUs and began debugging it, but it only arrived today, so it will take a while to fix the DX12 mode.

We're going to address the most critical issues as they pop up while we work on the new features. The first hotfix went out today, with more coming over the next weeks.

Gamemode System

The Minigame system we currently have is causing a bunch of problems and badly needs an update. It was made for Alpha 4, where it wasn't really possible to make any kind of real gamemode, and was meant more to help players mess around together in an otherwise building-focused server.

Over the coming months, we'll be working on a Gamemode system that will replace it. There will only be one Gamemode supported in a server, but Gamemodes will be much easier to use than Minigames and much more powerful. Crucially, they will be much easier not to use incorrectly, resulting in people who downloaded your world spawning outside it and other issues.

It'll be designed for hosts, rather than random players who want to deathmatch in the middle of a server hosted by someone else. In addition, once your Gamemode is done, you'll be able to put it on the gallery alongside all its internal wires, due to a feature called Gamemode Microchips we'll talk about in the next section!

Don't worry for your existing worlds with a default minigame set up - everything should port over sensibly. In fact, due to the removal of the "included bricks" system, many worlds that are currently broken will immediately be fixed!

Wires V2 - Come on... More Stuff!

Wires V2 is an upgrade we made to the wires system for EA. It turns your wire contraptions into a graph that is stored on the server, like this:

Wires are now automatically organized into a dependency graph so we can update all gates in the correct order in a single step. This means you can build arbitrarily complex circuits without having to deal with any of the problems getting multiple signals to arrive at the same time like in the demo! The new system is also massively faster.

This does add a new restriction - the graph can't have cycles, so you need to break your circuit up with delays. But it also means things that were slow in the NextFest demo can suddenly run very very fast:

It also means that there are no more "false" states. Unlike the demo, wire circuits fully update when an input changed, rather than signals taking 1 tick to propagate.

The new system has allowed us to add something called Exec wires. Exec wires make wires into a scripting system, by passing along a pure "update" signal rather than data. Any data passed into an exec port becomes an update signal if it changed to a nonzero value. Unlike the demo, this lets actions run in a chain:

Unfortunately, making the system itself took so long that we could barely include any gates aside from rewrites of the ones we already included in the NextFest demo! Which is a shame - because once those are in, Wires V2 will really start to shine.

Our plans for the following weeks are thus:

• Microchips - compress your logic circuits into a single 1x1f brick. Create entirely custom gates by combining the gates that come with the game!
• Variables and Branching - Store, read and write values when your wire nodes run. No more manually building flip flops or using the blend gate to store data!
• Proper Gamemode Support - MANY more gates for responding to minigame events like new rounds, custom chat commands, entity manipulation and more!
• Gamemode & Player Microchips - Store information on your gamemode/minigame and on players via microchip grids that save and load. Create callable circuits and build a fully reuseable gamemode - just with wires!
• Implicit Input Combining - Wire multiple things into one input. Booleans implicitly OR, numbers implicitly add, execs implicitly union. In some cases, save tens of gates!
• And Much More - Array variables and iteration, queues that can wait for many events with parameters, loops, data displays, strings, kinematic joints, entity homes, and more...

New Prefab System

This sadly didn't make the cut for the initial Early Access release, but we're very close to having our new prefab system completed.

The new prefab system finally replaces our legacy "brs" save files from the first alpha version, which can only store bricks from a single grid in a very inefficient manner, with a completely redesigned one based on the worlds format. We will include a brs -> brz converter with the release so old builds can still be loaded in.

Prefabs will then be able to contain full physics contraptions, properly tuned cars (including their wheels!), logic computers, and whatever else you can think of.

They're going to be integrated with the main catalog UI, so you can put prefabs in your hotbar the same way you do with bricks and entities. And we're adding a gallery for them so you can share them with others.

Bots

This was actually one of the most requested features to the game that we've been able to see, with lots of players having a strong desire to use bots to make zombie servers, or simply adding ambient NPCs that roam about the map. We didn't have strong plans for this, but we think it'll be cool to throw in as soon as we can especially with our focus on adding more gameplay features.

The initial version of bots will be ready soon, letting them hold different weapons, move around randomly, and be controlled through wires. This is only the starting stage, but we'd like to get this out the door quickly so that people can start experimenting with them. Here's a preview:

They will be improved over time, with features like smarter navigation, direct wire controlling, and a special bot type to replace players that disconnect from a minigame. These features might take a while to get to, depending on priorities once the first version is released.

Sounds

A much smaller but still prevalent complaint that was brought up, presumably from the excess of deathmatch servers, was the difficulty of hearing other players when they were walking around. If someone was sneaking up on you, you could barely hear them!

We'll be adding a bunch of smaller features to try to allow hosts to set up exactly how they want such things to work in their server. This requires certain systems to be rewritten first, but we'd like for the game to support dynamically changing how loud and how far certain sounds are on a team basis for minigames. You should also be able to change how a team perceives sound, such as making teammates sound quieter than enemies.

This is one of the lower priority changes, so we have no ETA on when that will happen. In the meantime, more sounds are going to be added to the audio components, as well as the environment settings. If you've got any desires, feel free to suggest them in the Discord!

And More...

• Aircraft - We've been experimenting in the last 2 days with tools for making aircraft. There is nothing that is showable yet but we expect this feature to develop quite quickly, so I've included it here.
• Better Admin Tools
  • Finder tool server admins can use to see a tree view of all entities in the world and find hidden or far-away spam entities.
  • "Home" positions for entities that they return to when respawned, leave the world, or when the gamemode is reset (mentioned with wire changes above).
  • Better, more in depth permissions for players - we've already started on this one!
• Avatars on the Gallery - It's coming, folks! We're just working on what the UI looks like.

Long Term Roadmap

While it's too early to fully get into details, we have quite a lot of other features we're interested in adding to the game, over the next year.

• Editable Voxel Terrain - Building terrain is super hard! It's so difficult and tedious for even experienced builders that it causes them to not try to build things. Unfortunately, if you don't build any terrain, Brickadia currently imposes upon you a very heavy visual punishment - the sight of bare plate as far as the eye can see. Terrain would fix this.
• Destruction - You've probably tried blowing up a wall of bricks with a rocket and noticed that nothing happened whatsoever. So lame! Luckily we're going to do something about it.
• Scripting - We're moving into prototyping for this. Luau is currently on the table, but research is ongoing. Stay tuned.
• Custom Content (Modding) - We have existing plans for how common types of custom content can be added to the game and automatically replicate to players joining servers. It's very much on our minds still!
  
  PS: We have removed all technical measures preventing modification of the game such as package signing and obfuscation. These were leftover from the Open Alpha and never intended to ship in the release. While we don't think this is the correct approach for a multiplayer game in the end, feel free to mess around locally in the interim. There will be no support.

Anything Else?

We'll be keeping our ear to the ground on what our players think is vital to add to the game. The things that we prioritize will change over time, so make sure to provide your feedback on what you think is most important, or if there's anything we haven't yet mentioned you want to see.

That's it for now! If your game doesn't work, let us know and hang tight, we'll fix it. Otherwise, we hope you are having fun! This is just the beginning of our journey.

Hey, everyone!

After this long journey of development, we first want to thank you all for joining us on this incredible adventure that has been the creation of Brickadia. We’re beyond excited to finally announce that Brickadia Early Access is NOW LIVE on Steam! To celebrate, we’ve put together a launch trailer made entirely with in-game footage, check it out below! 👇

This isn’t the typical Early Access release, Brickadia Early Access already feels like a full game, completely polished and content-rich. With constant updates planned based on your feedback, it’s only going to get better from here.

What are you waiting for? The world of Brickadia is yours to shape, one brick at a time. Join Early Access now and unleash your imagination!

https://store.steampowered.com/app/2199420/Brickadia/

As always, thank you for being part of the journey as we build Brickadia together ♥️. 

We can’t wait to see the game in your libraries and your creations on social media with #Brickadia!

Look for Brickadia on Bluesky, Twitter/X, TikTok, YouTube, Instagram and join the always growing community on Discord.

Welcome to a new little blog series we're doing in the run up to Early Access. We currently don't have time to write huge technical dev logs like we did in the past, but there are still a lot of new features to talk about! So, we decided to instead post a bunch of little blogs whenever something is ready without losing ourselves too much in the details.

Today we'll talk about a few optional graphics enhancements you can use if "Ultra" just isn't good enough for you and you would really like to use your GPU for heating your room in the winter.

Introduction

Before we start, you can watch this video demonstrating what it looks like with all the features enabled. We had to wait over a day for YouTube to process the video and actually make the 4k60 HDR option available. Isn't that crazy?👇

HDR Output, Episode 2

If you remember our post from a year ago, we actually talked about this before.

The only problem was that since that previous post, we had upgraded to Unreal Engine 5.5 just before the demo, and naturally Epic had managed to somehow break the HDR in the new engine version. This is what were greeted with after the update when a user enabled HDR and opened any UI:

Luckily, this turned out to be easily fixed after some investigation in RenderDoc. They had merely forgotten to clear a render target before using it, causing all this garbage data to be displayed on screen.

There was also a second issue where having the avatar editor on screen turned the background black. That one was more involved, but is also fixed now - to render the avatar editor we now first blur the background in HDR, render most of the UI, render the avatar background on top of the blurred HDR render target and cut a hole into the UI where it should show, and finally composite everything back together into the final output.

These images were captured in 4k HDR using Xbox Game Bar on Windows 11, which writes a JPEG-XR file, and then converted to AVIF using this tool I found, so they can display in the browser. On my computer, the version in the browser looks exactly the same as the game, but I have no idea if that works for you too.

Some troubleshooting if the images don't display correctly:

• If you don't have a HDR monitor, you can't view them.
• If you have HDR disabled in Windows, enable it.
• If you are using Edge or Firefox or something else, use Chrome.
• If you are using Chrome but the images are too dark, change the HDR brightness balance setting in Windows, or change the dynamic tone mapping setting on your display's menu.
• If you are not using Windows, I can't help you.

Lumen & Hardware Ray Tracing

Remember how we implemented support for hardware ray tracing bricks a long time ago? That code had gotten a little scuffed up over the years and was no longer functioning in the demo, but I just fixed it up. Hardware ray tracing is now back for Early Access, it's also quite a bit faster since back then (but still slow...).

In the mean time, Epic had made lots of progress on Lumen. Since we are now on Unreal Engine 5.5, I thought I'd give it another try. We still don't have distance fields to be able to use software ray tracing, but what if we could make the hardware ray tracing path work?

Naturally the first attempt did not work at all. We weren't getting any information from HWRT to Lumen whatsoever:

Since I had never really worked with Lumen before, I opened up an Unreal Engine example project to see how this view should look, and theirs is... quite different, wouldn't you say?

Turns out most of that was just because I had purposefully broken the lumen scene some time ago while making Proto Lumen. Let's revert that change so it only applies when we are actually running in Proto Lumen mode...

The bigger problem is that our bricks are still broken.

It turns out Lumen requires something called a Surface Cache to work properly. Basically, we have to cover our meshes with planes onto which it will render indirect lighting. Of course the code Epic made to do this for normal meshes only works in the editor and is extremely slow as it is intended for offline processing.

How do we do this? We could just write a more optimized version of their code that works at runtime. They are doing ray tracing against the meshes on the CPU side and it can take like half a second to process a single mesh this way. When we build clusters for a large build, we have thousands of meshes.

To do it at runtime, we'll do all of the following:

• We will use the embree4 library to trace the rays, making full use of its capability to trace 8 rays in parallel with AVX instructions.
• We will use our low detail mesh as input for each brick cluster.
• We will use very few rays, accepting a mediocre real-time result.

The full algorithm ends up as the following: it will take the low detail mesh we build for the brick cluster, convert this to an embree4 scene to be able to ray trace it on CPU, overlay a 32x32x32 voxel grid, then for each face of the grid (6) it will trace rays through the grid to hit the mesh, generating layers of surfels at the hit surfaces, trace additional rays to determine if some hits might be "inside" the mesh only and useless, then cluster those surfels to finally end up with the set of most significant surfaces to output as cards.

Our implementation of this is now so fast that it barely increases the time it takes to generate brick clusters.

In real builds, it looks significantly more cluttered, but it works surprisingly well. We don't always cover every surface since the brick clusters may randomly include multiple hollow structures, but we get most of them which is enough for the whole system to work.

Almost every build I've tried had ended up with a usable surface cache.

Let's get rid of those annoying debug views so we can appreciate the glory.

Yes, it does ray traced reflections too.

Almost feels like a real-time photo mode, rivaling the old path tracer we used to have. I've never seen a building game capable of looking this good before...

The memory usage and performance of this mode can be quite heavy. Epic has several performance optimizations in Unreal Engine 5.6, but we won't be able to get that in before release. If it doesn't currently run well on your computer yet, maybe it will once we upgrade to that.

Well, that's all for this preview. There are going to be many more before we reach Early Access. Stay tuned!

Hey everyone!

You’ve been asking us everywhere, and we can finally say it: Brickadia is launching in Early Access on July 11, 2025, on Steam - We can’t tell you how excited we are to finally write those words!. And we’re making this announcement in style, with a new montage trailer made entirely from in-game footage. Check it out below 👇

Here’s what we can share right now: the Early Access version will feel like the full game experience from day one, with the extra-benefit that it’ll come at a lower price than the final release. It’ll be your chance to jump into Brickadia early and be part of something big as it evolves. So for now, don’t forget to wishlist the game on our Steam page.

As always, thank you for being part of the journey as we build Brickadia together. We can’t wait to see the game in your libraries, we're almost there!

For more regular updates, join our Discord!

And to make sure you don’t miss anything, let us remind you about our official Brickadia newsletter - in it, you’ll get everything from the latest game updates to behind-the-scenes news, and even a chance to be selected for an exclusive closed beta ahead of Early Access!

Sounds interesting? 👇 

Hey everyone! With Steam Next Fest wrapped up, we're now full steam ahead, working toward our Early Access release. From the bottom of our hearts, we want to thank everyone, especially our amazing community, for participating in the Demo!

We loved playing with your different worlds and meeting new players and veterans alike. The creativity on display is genuinely beyond our imaginations! Seriously, thank you. We love this community❤️!

Survey Results
Feedback
 Horrible hit detection
 Vehicles are hard to control, slip, and clip often
 No prefab support for physics grids
 Griefing physics contraptions is too easy
 The Tutorial is clunky, unclear and confusing
 Limited gameplay gate options
Plans for EA
 Improved tools and prefabs support
 Improved combat and hit detection
 The Gallery
 Improved physics and vehicle handling
 Wires V2
 New Game Mode system
 Tutorial World
Key Giveaway
Community Showcase

Survey Results

Near the start of the demo, we put out a survey to help us gauge where we are doing things right, where we fell short, and where we should aim our development goals toward. Nearly 2,000 people submitted their surveys, and there are some interesting findings! That is roughly 5.5% of demo players submitting the survey. Thank you to everyone who submitted one.

First, some fun statistics (unfortunately, non-interactive on here).

Roughly half of players who filled the survey indicate they played the Open Alpha. This is interesting, as only about 10% of total players linked an Open Alpha account:

We have an overwhelming majority of male users:

Our main audience appears to be young adults currently:

The majority of players prefer playing in small friend groups:

During the demo, most people focused on dressing up their avatars and exploring existing worlds, which is about what we expected:

Surprisingly, the most liked built-in world was Officecorp Inc! We didn't know we had so many single player puzzle enjoyers among us:

Most of you were happy with the visuals and performance of the game, but we can still improve on making the interface easier to use:

The avatar editor was well liked in general, though some people are still wishing for even more options, despite us already having hundreds of parts!

It's very interesting how the mouse controls and keyboard controls were rated nearly the same. I think there is still room for improvement here:

Using the hammer to delete bricks is the easiest tool to use. Who could have thought?

Most of you prefer the streamlined mouse building control scheme:

We experimented with a lot of ways to integrate removing bricks into the builder, but it seems the hammer is still the most popular:

We are frankly surprised by how high you have rated the stability of the physics in the demo. Are our standards too high?

Most of you said you were able to figure out some basic contraptions:

Everyone figured out how to drive a vehicle but it was much harder to make a new one that drives well:

Your most desired future features seem to already align with our goals for Early Access and beyond:

It's clear that those of you who filled the survey were already very invested in the game:

Feedback

There was a ton of amazing feedback posted on the survey, on Discord, and on Steam, and we've been reading all that we could. Here's a list of things that you all made very clear needs improving (in no particular order):

Horrible hit detection

Hit detection has degraded noticeably from Alpha 5 (which already had subpar hit detection).

The Alpha 5 version of hit registration is based on an unfinished rollback model, where the server validates hits by rewinding time to see where you hit the enemy on your screen. Unfortunately, the solution implemented isn't perfect due to many factors, and it has seemingly gotten worse due to latency issues from EOS P2P and bugs from engine upgrades.

Another issue with weapons is that bullets come from the muzzle of your gun. Seems realistic and reasonable, but in practice, it is very easy to hit obstacles blocking your shot instead of your target in first person. It makes gun fights in corridors and nearby obstacles very annoying.

Vehicles are hard to control, slip, and clip often

One of the more common problems faced in the demo was vehicles flipping over and having little traction. Plus, since we're using actual physical wheels that actually spin, there's quite a bit of unstable behavior that occurs (especially at lower frame rates!). Additionally, climbing up plate bricks is a bumpy ride.

There were also many cases of "clipping" that occurs when two brick grids interact on a seam. You may have ran into this going up ramps or roads on vehicles where the chassis is low to the ground. This is an inherent limitation of how contacts are generated with physics. This has been mitigated with wheels, but not with brick grids. You can see the core of the issue here:

No prefab support for physics grids

The demo still employs the same old saving system from Alpha 5, which never supported multiple physics grids or entities.

Additionally, the Selector tool is still functionally similar to the one in Alpha 5, with the addition of working with brick grids and some usability updates (like splitting grids apart). However, it's not possible to copy/paste an entire contraption at once!

Griefing physics contraptions is too easy

The demo was intended for playing with trusted users only, and therefore barely had any restrictions on physics objects or their interactions. A few brave souls who dared to host a public server soon found out that there is a reason why we did not include the server browser at first as their creation became permanently covered in thousands of wheels and their vehicles lost to outer space.

Another very common request was to be able to define home positions for contraptions and vehicles so you can reset them with the minigame (or even through wires).

The Tutorial is clunky, unclear, and confusing

The demo became super invaluable for us in improving this area. Tons of new users struggled with not only the content of the tutorial, but also in the way the tutorial is presented. It is very clunky to press "M" on your keyboard to free the mouse, just to be able to interact with the tutorial. We've seen many screenshots where the tutorial widget is still stuck on in the player's HUD, no good!

We quickly added some UX improvements during the demo, such as the third-person interaction prompts to tackle some of the low-points, but there is still plenty to improve here.

Limited gameplay gate options

Wires and the new logic/gameplay gates have opened tons of possibilities for players (and you all have done some insanely creative things with just the ones available!)

There is definitely some room to improve here, especially when interacting with Gamemode features. For example, it's not possible to join a team using wires, detect when a round of deathmatch ended, add score, compare score... etc.

In the Demo, it wasn't really possible to make anything too groundbreaking when making gamemodes. (Though, there were some creative usages of physics and wires to make games like payload and survive-the-falling-cars!)

Plans for EA

We want the launch of Early Access to have the right foundations and the best possible user experience we can muster, but we also don't want to launch the game next year. So, the changes below from what you saw in the demo are our MVP for Early Access, and we are currently targeting a release in July 2025.

Improved tools and prefab support

Tackling the issue of saving vehicles and other physics contraptions, we will be upgrading the prefab system to support the new features that BRS did not.

The Selector will also be getting a big upgrade, such as being able to select or deselect individual bricks, and select by brick grids, which should make the Selector much more powerful than just only being able to select a box-volume.

Improved combat and hit detection

Improving the hit detection has been fairly tricky, and originally we wanted the combat system to be very precise. On the technical side, it implements a rollback system (similar to Counter-Strike 2) to ensure hits happened where they happened on your screen. At least, in theory, that is supposed to be what happens.

Due to various factors like Unreal Engine missing fixed-tick character movement, network replication and compensation, the implementation isn't very effective. We will likely move towards favoring client hits, with less aggressive server-side "sanity" checks and/or simplifying the implementation.

And another small but impactful change: the physical muzzle of your gun being blocked will no longer stop bullets the way it used to. Makes it much simpler to build maps that work correctly in first person.

The Gallery

The Gallery is a new feature coming to EA, where you can share your creations with others. It comes with full in-game integration, enabling you to easily find and upload content for all things Brickadia.

We will likely have a blog post detailing all the features and goodies that the Gallery adds, stay tuned!

Improved physics and vehicle handling

As mentioned earlier with clipping, this issue is unfortunately a limitation of physics engines. But, there are things we can do to (hopefully!) fix this, such as implementing sweep-based vehicles/wheels. Definitely stay tuned for a future blog post on this!

We plan on adding various weight bricks / the ability to change your vehicle's center of mass, which should help improve vehicles from tipping over. Increasing the tire friction is an obvious next step after improving these, and improving the handling of vehicles, especially at high speeds.

Wires V2

One of the limitations of gates in the version of wires that shipped in the demo was the reliance on brick components to implement their functionality. This puts many limitations on what gates can do, like having a variable number of ports, or supporting different wire types.

Wires v2 introduces "generic" gates, allowing us to implement gates for many different wire types. This is particularly useful for math gates that support integer and float/double math. Additionally, logic gates will benefit by having any number of inputs/outputs, and will let us design new types of gates such as selectors that need the flexibility.

Anyone who tried creating a complex contraption will likely have noticed timing issues where signals take different time to propagate down paths of different lengths, or even managed to get your gates stuck flickering in a loop for seemingly no reason. While this might be neat in a hardware simulator, it is extremely annoying if you are trying to make things just work. For the new version of wires, the system will correctly order the gates by their dependencies and propagate everything in a single tick.

A new gate, the Microchip, will also allow you to compact entire logic gate circuits into a single gate. A great utility of it is being able to modularize your wire circuits and share them on the Gallery! Plus, there are some really exciting things Microchips enable, as you'll read below.

New Game Mode system

We will be replacing the ancient minigames system with gamemodes! Functionally, they will work very similar, and our plan is to keep as much familiarity between both as possible, while improving the UX and confusion around setting up minigames.

Game modes will be able to be packaged up into a bundle that you can activate independently from the worlds, so you can easily combine different maps with playing different modes on them.

Problems with the old minigame system included figuring out which bricks/entities should be part of the minigame and unclear configuration, which leads many users (even experienced ones) to wonder why things just don't work the way they expect when creating minigames.

Once we're happy with the new UX, we're expanding the power of gamemodes in a dramatic way.

As mentioned before, we're adding the Microchip, a useful tool in the wiring arsenal for compacting circuit designs. In the context of gamemodes, they get a whole lot more powerful and interesting:

Microchips can also be attached to players, or directly integrated in your gamemodes to add new logic. Originally, we wanted to wait on Behaviors (our scripting language) to bring this ability, but it seems obvious that wires are a great fit here too, so we're adding it for EA!

We will be adding onto the collection of gates available, allowing you to do even more powerful things, like listen to game mode and player events, and do things with those events when used in conjunction with the Microchip.

Tutorial World

The tutorial widget we had in the demo, while it helped a little, definitely left many users confused. For EA, we plan to include a detailed Tutorial world that guides you through many of Brickadia's building features, one by one, in an approachable manner.

If your favorite future feature isn't listed yet, don't worry! This journey continues on far beyond Early Access.

Key Giveaway

For those who opted-in to the key giveaway in the survey, we've gone ahead and emailed the randomly selected 5 winners a Steam key. Congratulations to the winners, you will be able to play the game as soon as it releases!

Thank you!

And to everyone that had a chance to play the demo, thank you! For those who haven't seen any of the amazingly creative builds users have built, here is just a handful of ones we picked from our Discord and socials:

And finally, some crazy devices that employ sound. Take a listen!

We’re really excited about what’s coming next, and we can’t wait to share more with you soon. As always, thanks for all your feedback and support—it means the world to us! If you have additional feedback, you can always drop by our Discord (we're active there!), or send us a message through any of our social medias.

And lastly, Happy Frog Day! Wait, what do you mean it's not Frog Day anymore, and it was last week? Oh well, have this frog anyway.

Hey everyone, a short post for once! We're extremely happy to announce that the Brickadia Next Fest Demo is now available for download through Steam for a limited time! If you're here to play the game, you can click here for the Steam page to download the demo. For everyone else still here (you should go play the demo instead!), read on.

Our Next Fest Demo includes almost every feature we've been cooking up over the last few years, including physics contraptions, drive-able vehicles, wires, and our world system, and of course our brick-building system that supports millions of bricks at the core of it. If you haven't seen the brand new trailer for this demo, it was filmed entirely in-game in this demo!

What does this demo not include? Behaviors, the new gamemodes system, and the Gallery. Our planned Behaviors scripting system is on the back burner at the moment as we have been focusing on wires and logic gates first! This demo currently has the same old "mini-games" system as our old Alpha had - this system is planned to be replaced with a simpler, more flexible gamemode system in Early Access, but currently this hasn't been implemented yet for this demo. Our Gallery is also not ready yet - but we do really want it to be part of the proper Early Access release as it will let everyone properly share their creations and instantly load into other peoples awesome worlds.

A very exciting day for Brickadia indeed! This isn't our full Early Access release yet, but releasing a brand new demo showcasing the current state of our game is still a giant leap forward for us. We really look forward to seeing what you all create in this demo - please post your creations in our Discord, on social media, and in the subreddit. We love to see them!

We will have a survey available towards the end of the Demo. Please give us your honest thoughts and suggestions as that will shape the direction we take the first Early Access release.

As always, thank you for reading. And go play the Demo! Stay tuned.

Today we're going to be dipping our toes into two big Early Access features that haven't been discussed much on the blog: Wires and Vehicles. We'll also go over all the other cool stuff that the team did in 2024!

But before all that, we have an announcement: In February, we'll be joining the Steam Next Fest with a time-limited demo! During the fest, you'll be able to get your hands on an early preview of all the new creative features we've been cooking for the past few years!

The Next Fest build will be our Creator Demo, a build of the game that will focus on building and creators. The demo will be available from February 24 at 10 AM Pacific to March 3. We'll share more on this demo as we get closer to the Fest!

To be notified, add Brickadia to your wishlist on Steam.

Building Tool Improvements
 Offsetting From the Plane Lock Plane
 Follow Mode and Precision Mode
  New "arcball" rotation controls
  Reorient rotation still exists
  In follow mode, player now faces the brick
 Negative Spacing
 Upgraded Pie Menu
 Default "Loadout" of Bricks
 Correct Grid Snapping (To Edge/Over Edge)
 Align Half-Plate Thick Bricks To Surface
 Inventory is Single-Quickbar Again
 Entities
 Improved Catalog Organization
Wires
 The Solution
 The Connector
 Buttons, Targets and Switches
 Logic Gates
 Wire Types
 Various Examples
Vehicles and Contraptions
 Joints
 Joints Being Used Ingame
 Seats
 Driveable Cars
 Various Examples
Other Stuff!
 Procedural Brick Generation
 Weapon Resources
 Homing Missile
 Pole Resizable in All Directions
 Other New Bricks
 Skirts and Dresses
OK That's Everything

Building Tool Improvements

I really should write a full blog on how these work but here's an outline of what I have at the moment.

Offsetting From the Plane Lock Plane

Plane lock was added back into the new mouse building controls with a new feature: You are now able to offset from the plane lock plane in plane lock by scrolling the mouse.

This creates this cool line between the actual lock grid and the raised one. It has a bunch of uses.

Follow Mode and Precision Mode

In a huge surprise to absolutely nobody, I remade Orbit Mode and Detached Mode. They are now renamed to Follow Mode and Precision Mode. These modes share essentially the same codebase with different keybinds. However, several things work much better:

New "arcball" rotation controls

The rotation in follow and precision mode now offers an "arcball" rotation scheme when you hold ctrl, inspired by that offered by games such as Space Engineers. What does "arcball" mean? It means rotation is now relative to the surface you're looking at. Left/Right/Up/Down will all rotate the surface 90 degrees to point in that direction without affecting other axis, while the additional rotate buttons will turn it counter-clockwise and clockwise. Take a look:

Reorient rotation still exists

Holding R still gives you reorient controls. Tapping in a direction will rotate your brick to face in that direction, exactly as is offered by the mouse controls:

In follow mode, player now faces the brick

Finally, as a last little polish feature, your player will now "look" at what you are doing while you're in follow mode. Other clients see this too.

Negative Spacing

A very oft-requested feature since we added the ability to row-drag templates, and especially since we gave testers the ability to grid and volume-drag them has been negative spacing. Negative spacing allows you to overlap instances of the template you're dragging, making it possible to place a template that interlocks with itself.

The simplest example of course is a brick wall like here.

But there are more advanced cases, especially when you're placing wires (which we'll talk about in a bit) which auto-attach when overlapped with the same brick type attached within the template:

Upgraded Pie Menu

The tool pie menu now has descriptions.

When you select the Placer from the pie menu, you'll select the last brick you had selected, or else the first brick found in your inventory, or else a 1x1f will be thrown in the TEMP slot and you'll select that.

Default "Loadout" of Bricks

The quickbar now has things in it without you having to open the catalog and add them, which greatly confused people who came by our booth when we showed the game at a convention in November.

The default loadout is very transparently the minimal kit for building a car (don't worry, we'll get to cars):

Correct Grid Snapping (To Edge/Over Edge)

In alpha 5, when you are in one of the keyboard building modes (follow/precision as they're now called) your brick has never actually moved or aligned to the grid properly. Thankfully, the only way to notice this was to try and use a micro-brick, or some other brick that wasn't large enough to align to the grid.

In mouse mode, Alpha 5 can align your brick the way we intended - to the nearest edge of the aimed-at grid cell. It's only follow and precision mode that are broken (actually, quite a lot of the Alpha 5 building is broken).

What follow and precision mode actually should have been able to do was move bricks that are smaller than the grid cell on the move axis "to, then over" the grid cell's border, which oftentimes is an uneven movement per button press and so can't be done by simply offsetting the brick each key press. This corrected "to, then over" movement is how it works in Early Access.

Align Half-Plate Thick Bricks To Surface

When you have the plate grid alignment mode selected (you literally must give it a try!) try aiming at the surface of a micro-brick or some other surface that does not align to that grid in Alpha 5. Your brick will float.

What's worse is that this can be hard to notice from a distance, so you get done building something and then find it floating an uncorrectable (1-2 unit) distance off the ground.

In Early Access, your brick aligns to the depth of the surface you're looking at, even in Plate mode, as long as it isn't inside the bounds of a brick. So your micro-brick will actually place against off grid surfaces in Early Access:

Also notable here, but easy to miss - resize dragging moves the size up to the first grid edge for the first resize increment, then expands to fill further grid cells.

Inventory is Single-Quickbar Again

Many of you commented on the section of the last blog post saying that the multiple quickbars and increased inventory size may be difficult to deal with for new players. This is exactly what we found during testing, so they've been removed.

Entities

Since adding entities, we have added exactly two (2) entity types so far.

The first is a ball that can be painted and resized. As always, I forgot to add a size limit.

But then we have the current main use case of entities: Wheels. Wheels make perfect sense not to be bricks - they get to have proper analytical collision and they do not waste the server's processing power managing another brick grid. There are countless wheels in the game so far and here are a few of them:

Improved Catalog Organization

Confidentbottle has improved a bunch of stuff relating to the organization of the default catalog. First and foremost, the Entities tab is gone as there were not enough entities in the game to justify it. Instead, the Bricks tab is now an Objects tab:

Categories have been reordered to make more sense, with bricks you'll want to use first prioritized rather than the alphabetically ordered sets of Alpha 5.

Also, Micro-Bricks now have their own tab and are actually ordered sensibly, meaning you don't have to scroll right to the bottom to get at the regular cubes.

All the magical gameplay bricks and entities are spread across 3 categories, rather than ending up hidden in Special;

• Physics stores bricks and entities meant for making physics contraptions.
• Mechanics stores bricks and entities meant for making interactive machines or experiences.
• Logic Gates stores the logic gates provided to users of the wire system.

Wires

Back when we were thinking about the design of our still TBA scripting language, Behaviors, we very quickly realized that most of our players wouldn't want to have to use it to do simple things. No matter how approachable you make your scripting system, the more it can do, the more complex it has to be - and the more daunting it becomes to beginners.

But why should they have to learn what a function is, what bindings are, what symbols and variables and booleans and parameters are, just to make a switch open a door?

Or even to make the correct combination of switch values open a door?

These are use cases so simple that they shouldn't even have to go through scripting at all.

The Solution

If you've read previous blog posts, you already know this bit, but for new people I'm going to go over it again;

Conveniently, everything in Brickadia is data-driven - i.e. has a state that can be controlled very directly by reading and changing variables. Let's simply designate some variables outputs, and some variables inputs, and let players designate "links" between a given output and multiple inputs somewhere else. When the output variable changes, linked input variables are set to the same value.

This "link" is all a wire is.

The Connector

To attach wires, we have this tool, the connector. The connector lets you connect wires between physical ports in 2 clicks. For bricks without those, you can select your source or target port from a list instead:

As always, we've added a bunch of QoL features to the Connector to make it super easy to work with. You can hit R to restart connecting from the last port and hold Ctrl to multi-connect. The GUI has a quick fuzzy find search where you can press enter to choose the first port in the current results.

You're probably wondering if there's a way to organize these wires better. There is! Rerouter bricks. With the Rerouter brick, you can always organize your wires super nicely.

Buttons, Targets and Switches

We have 3 inputs to the wire system right now, none of which support animations yet:

Switches can be clicked to toggle their output signal between off and on. There are a lot of use cases.

Buttons emit an on signal while your mouse is held and an off signal otherwise. Originally, they had an on-off time, but the "holding" functionality is far more versatile. For advanced use cases, you can even get a count for how many players are holding down one button.

Targets emit an on signal for a certain amount of time when shot with a projectile or hit with a melee weapon. If hit while on, their current "on" signal will be reset to that amount of time instead.

Logic Gates

There are a ton of gate bricks with physical ports (most of which you see in the catalog above) that you can route your wires through. The system is turing complete, and you can use it to do most things.

As an example, we can use an AND gate to make a door that opens only when two switches are flipped.

Or an OR gate to make an item collectable when one of two buttons are held.

Wire Types

You've probably noticed all the wires are red. Can they be other colors? Yes, they can!

A wire's color is determined by the type of data it carries. Red wires carry booleans, i.e. an on/off signal. But since wires can carry any property type, you can also send decimal numbers and do operations on those.

Since wires automatically convert between all the basic types, you can send boolean values into ports that take numbers (as 0 or 1) and vice versa (!= 0 is 1).

In addition to this, and as you saw above, everything always converts into a string - which is how we can display the value on interact at the end.

With integer numbers, you can do bitwise operations. So here's something more advanced that most of you won't ever need to do: With a bit of work, we can send 8 different booleans as a single integer value.

Various Examples

You can make lots of things in Brickadia with just wires and no scripting. Eventually, though, wiring contraptions together becomes more of an art itself. There are some things you really should be doing with scripting later. But of course, you don't have to, so maybe, just for fun, you don't.

The UX of wires is basically finished with just some polish and additional features down the line.

Vehicles & Contraptions

You are all long overdue for an explanation of our plans for this, but there is a lot to go over so I will try to be concise here.

Joints

The first part of vehicles we implemented were the basic bearing joints, which currently remain the only joints in the game. Right now, they come in 3 flavors; Bearing, Motor, Servo. To attach a brick to a joint, you simply place it on top of the joint.

The Bearing (left) simply rotates freely with customizable damping (damping is the force with which the joint tries to slow to a stop while spinning). It's good for making hinges for doors, windows and other things, but it can't do anything advanced.

The Motor (center) is your workhorse powered joint. When enabled, it will spin with constant power you set. You can make something that spins constantly such as a platform or part for a total wipeout course, and you can even combine it with wires to make things like deathrun traps, fairground rides, and mechanisms.

Finally, the Servo (right) is what you use when you want something to move to a specific position and to try with user-specified force to stay there. It can be used to make suspensions but is most useful when paired with wires, which you can use to make automatic doors, spinning counters, all sorts of things.

We have micro joints too!

Joints Being Used Ingame

There are lots of use cases. Here are some images and videos from recent dev media.

Seats

The obvious next thing to make was some way to sit down and be attached to whatever ride/pseudo-car/other miscellaneous deathtrap you made. That comes in the form of the Seat, which you can click on to sit in.

There is not much else to say here. If you put one on a physics contraption it works as expected.

Driveable Cars

Again we are left with the problem of how to make versatile behavior possible without forcing the user to do a lot of work. And just so we're on the same page, programming good vehicle control is hard, easy to do wrong, and not even the first problem we need to solve.

The first problem we need to solve is how to allow a player set up their car, which they have built out of a lot of small little bricks, to drive in a way that resembles sensible.

To demonstrate the solution I came up with, here's what we want to drive:

It would certainly be quite a stretch to call this a "vehicle", but I'm going to anyway.

We need to mount the wheels, but there's immediately a problem. If we put our wheels on the car with a Motor, they wouldn't be able to steer. Motors only turn.

Enter the Wheel Joint, which can steer and turn. It even has a built in suspension.

Already this is starting to look more like a car. We still can't drive it, though. Nothing is controlling the wheel joints.

There are many different schools of thought in sandbox games for how you tell the game how the player's controls control the car, but me? I'm partial to the approach taken by Robocraft and Spore (a creature is technically a vehicle, right?). That approach being: The game should figure out as much about how to drive and steer your creation as possible on its own, without you needing to be involved in every little decision.

But this is Brickadia, so we also want modularity. We want to be able to entirely exclude functionality we don't want, like gear switching and air control. And we want to be able to tweak things that make sense to tweak, like acceleration, braking force and top speed.

This means that first of all, we should add the least additional functionality to the Seat as possible. We should simply have the Seat emit a Control signal that we can use (or decompose into wire outputs) somewhere else.

What do we attach it to? Introducing the Wheel Engine.

The Wheel Engine's placement designates the forward direction for our vehicle, and also where the engine noise comes from. This means that even if the seat were placed like this:

The vehicle would still drive correctly. In fact, to make sure, let's leave that there. We'll put another one on the other side. For balance. And we'll also wire up the driver's seat.

The driver sits on the left side, so they're not in danger of being hit by traffic. I'm so glad we found a way to solve that design problem.

By the way, you don't have to use this big bulky engine if you don't want to. There is a small alternative that has all the same features.

The engine gets very happy when we sit down in the seat and makes a noise. But we can't drive yet because we gave it no control over the wheels.

How do we do that? It's easy. The engine takes the seat's input signal and translates it to a wheel control signal that we can wire into the wheel joints.

Let's do that now.

And now it drives!

And no, extremely keen eyed readers, you eyes are not deceiving you - the engine is calculating a steering box containing all the wheel joints and doing Ackermann Steering, which reduces wheel slipping and is what you find on most vehicles in the real world:

All this, too can be combined with wires. The engine is fully wire controllable!

Various Examples

The testing team have built vehicles that are, somehow, even better than mine. Here are some videos of their adventures:

Other Stuff!

Procedural Brick Generation

I have just finished the brick composer, a dev tool we can use to create new procedural brick types.

Without going too deep into detail, the brick composer is able to take a few carefully made mesh parts parts in blender, like these:

And by arranging them and retexturing them, create a fully realized resizable brick.

This generator is super powerful. It can already be used to make all but 3 of the 28 procedural brick types currently in the game. Of that 25, 16 (including all of the micro-bricks) can be made simply by opening Blender, cutting up the default cube a little bit and throwing some Dyn texture markings on its faces:

We plan to use it for many more bricks including the resizable slider joints.

Weapon Resources

Weapons now have a "resources" system.

There are several types of weapon ammo in Early Access:

• Arrows, used for Bows and Crossbows.
• Black Powder, used for old timey weapons like the Flintlock Pistol.
• Explosive Ammo, used for the Rocket Launcher & Grenade Launcher.
• Light Ammo, used for Pistols, SMGs and others.
• Medium Ammo, used for Assault Rifles, Machine Guns and others.
• Heavy Ammo, used for precision rifles.
• Magnum Ammo, used for Magnums, Revolvers, and the LAR.
• Plasma Ammo, used for heavy energy Sci-Fi weapons.
• Pulse Ammo, used for low energy Sci-Fi weapons.
• Shotgun Shells, used for shotguns.

But the resource system is made in such a way that weapon resources aren't just limited to ammo. Weapons can have individual resource values that they track to influence behavior - heat, charge, and more. There are no examples yet - for now, as a task, ammo is large enough.

Homing Missile

I saw a cool implementation of speed-conserving proportional navigation, a homing algorithm for projectiles, on the UE5 marketplace. It made me want to program my own from scratch, so here is Brickadia's very own homing missile in action:

Speakers

These come with an audio component pre-attached. Get some tunes on!

Pole Resizable in All Directions

I decided to unlock the pole's resizing and see what would happen. I expected the brick to break but with a few tweaks to the vertex count generation it's actually fine. So I've left it unlocked:

Other New Bricks

We have (a few) new decorative bricks that don't do anything at all!

Skirts and Dresses

OK, That's Everything

For more regular updates, join our Discord!

My favorite thing to do in Brickadia is watch other people build.

I'm always interested to see the cool things people are making, but I'm most interested in the techniques they use. How they make use of the tools we made - and how they don't. What I found out was in some cases surprising, and has fed into a lot of the new design decisions I've made.

Before we go further, make sure you're not browsing on mobile data! Here's a table of contents for this post:

What Needs Improvement?
Resize-Dragging rather than Row-Dragging
Unusable Brick Reorientation
No Visual Metrics
Bad New Player UX
Complicated Dual Inventory System
Too Little Inventory Space
Unable to Start Floating Builds
More Extensibility Desired
Rewrite the whole building system??
Upgrading the Inventory
Extensible Inventory Slots
More Inventory Space
Keeping your Character Inventory
Selecting Inventory Slots
Upgrading Building
The Core
Aligning Bricks with the Mouse
Placing Floating Bricks
Gizmos and the Preview Grid
Dragging Brick Rows (Old)
Dragging Brick Rows (New)
Resize-Dragging
Rotation and Reorientation
Tool Widgets
Tool Bind Hints
Selection Highlighting
More to Come!

What Needs Improvement?

First, let's talk about what we can learn from how players built in Alpha 5, and how we can use that information to improve the tools for Early Access.

Resize-Dragging rather than Row-Dragging

Years ago, we built Brickadia's original mouse building around point and click placement of bricks, and - as an afterthought intended for people making regular patterned things such as brick walls - made it so that if you click and move the mouse without releasing it, you drag out a row of bricks.

You can do the same thing with a brick template.

This is super efficient for placing rows of the same brick.

Brickadia also supports resizing bricks. It's a separate tool, here.

You can resize any brick to any valid size. If you like a certain size, you can pick it into the quickbar with Ctrl-MMB. You can have up to 10 bricks in your quickbar, which seems like enough for most tasks we can think of. And the resizer has quick binds for resizing to the minimum and maximum size:

And so, our thinking went, now all our builders have everything they need to make cool structures quickly. We released these features in the Open Alpha.

Here's how people actually used them:

First, you place a very small brick. Usually a 2x2x2 micro brick, sometimes larger. It's the only thing that's useful to have in your quickbar with this style of building, ever. The size it needs to be is your lowest common denominator - the smallest gap you'd ever need to fit it into, meaning smaller is better. Then, you switch to the resizer. You resize your very small brick to the size it actually needs to be. Then you start over.

At first this is clumsy. It feels bad. It feels like the game is broken. Slowly, though, you grow used to it. You bind the resizer to its own key. You go through this process tens of times, then hundreds of times, then thousands of times. It becomes muscle memory. You learn to do it without thinking. One building away, I'm standing on a roof, watching you. Horrified.

The problem here is that our iterative improvements to the game created a contradictory user experience:

• The placer is designed for a building experience where players build things by arranging non-resizable shapes of different sizes.
• Most of the bricks in Brickadia became dynamically resizable when the resizer was added in Alpha 4.

These players aren't doing this constant switching between the Placer and the Resizer to be annoying contrarians. To actually be able to leverage the resizability of almost every brick in the game, they're forced to do it. The placer tool doesn't let them do so on its own. To add insult to injury, the resizer doesn't snap brick sizes to the current alignment grid, so if you want plate sized micro-bricks you're forced to strain your wrists doing it carefully.

Resizing bricks directly as you place them would make a lot more sense. In reality, there are many more cases where you'd find it handy to resize a brick as you place, than cases where it's helpful to place a row of the same brick.

Therefore, clicking and dragging shouldn't default to row placing. It should place one brick, which resizes according to your drag. In addition, you should be able to resize the brick on all of the axes in one go, so you can make any size you want without ever needing the Resizer unless you want to modify an existing structure.

Obviously, the resizing should snap to the lines of the current placement grid too.

Unusable Brick Reorientation

This one is not that hard and we should have gotten it right the first time.

For most of Brickadia's lifespan it has been a pain to orient bricks to rotations where they are not upright. In Alpha 5, you do this using a horrible keybind called Cycle Brick Orientation (default keybind: Numpad /) that cycles through every possible brick orientation in an apparently random order;

You might notice I miss the orientation I wanted to stop at the first time and have to go through them all again. This is a result of years of training - most people miss the orientation they want at least twice.

This was actually an iterative improvement, because we only gave it a dedicated keybind in Alpha 5 - before then, you had to use advanced trickery with side studded bricks if you wanted to reorient a brick.

Let's get some insight into what's happening here. Brickadia stores which way your brick points in an enum (called EBrickDirection), with 6 possible values:

/** An axis aligned direction. */
enum class EBrickDirection : uint8
{
	X_Positive,
	X_Negative,
	Y_Positive,
	Y_Negative,
	Z_Positive,
	Z_Negative,
};

Cycle Brick Orientation might seem disordered, but it actually is ordered; it's going through the values of the EBrickDirection enum. This seemed like the way to go at the time, but the order it goes through orientations is actually so confusing that the Brickadia programmers are still the only people it makes sense to.

The fundamental problem is that it is meaningless to tell your players something is X+, Y-, etc, to try to come up with any "natural" order to cycle through the different directions, or to ask them to "set a direction" given a list like the one specified in EBrickDirection. You must let them point in a direction, and then resolve the axis and sign they wanted from that - you must translate how the user understands space to how the computer does.

No Visual Metrics

In the same vein, it's quite strange that not just Brickadia, but so many advanced creation tools find it sufficient to simply display measurements for things only on the HUD, when you're doing something in the world.

I recently watched a GDC talk called Keeping Level Designers in the Zone Through Level Editor Design, which for some reason is now unlisted. A lot of the talk is about texturing and pivots and other things not really relevant to Brickadia.

I found one specific point very interesting though: In Hammer, moveable brushes are positioned as boxes, where we instantly see the measurements of each edge displayed as text on that edge. Not as some "X by Y by Z" formatted size that we have no idea how to translate to the world.

By comparison, the information Brickadia shows you when resizing a brick is completely worthless:

Clearly we can do better here, as well.

Bad New Player UX

The HUD meant to teach users how to use the Placer is, to put it bluntly, programmer UI:

It uses only text, and it doesn't include certain key functions, like picking, at all. It's hard coded to display the default keybind rather than displaying the currently bound key name. In a particularly egregious case - the detached mode controls - it simply tells you to move the brick by using "Numpad".

In addition, prompts for keys aren't unified in any way. Down here is a little set of mystery icons meant to show new players how to open the inventory, use tools, use bricks etc, which do change to reflect your current bindings:

Painting has its own style of control prompts again. These, again, don't change to reflect your key bindings, but do change contextually as you navigate the menu.

And like the Placer, these are missing things like fill paint, which people have requested me to add to the game at least 15 times not knowing it's already there (alt-click with the paint tool) because there's no hint.

In Early Access we should show control prompts in a way that is more prominent, digestible, consistent, complete and reactive.

Complicated Dual Inventory System

This one was a little contentious. Basically, in Alpha 5, there are two character inventories. We have the brick inventory:

And the item inventory:

This pretty much always confuses new players who don't realize that they have two inventories and need to use Ctrl+Q to switch between them. They should be merged into one inventory which can contain both bricks and items, like Minecraft, Space Engineers, Stardew Valley, or basically any other game do.

Too Little Inventory Space

The inventory needs more space than just the 10 slots if we want people creating RPGs, salvage gamemodes and other experiences! This is doubly necessary after the last change as items now share space with bricks. Something that has been requested a lot is more than one quickbar, which advanced users could find very helpful.

We can design things so that only the currently selected quickbar is considered for adding new items, eliminating cases where new users might otherwise "lose" an item in a different quickbar.

Unable to Start Floating Builds

People often want to place things in mid air. Brickadia is supposed to be a game that is okay with you placing things in mid air. However, regardless of mode, the controls make this unreasonably hard. I always feel slightly embarrassed watching what people have to do to hoodwink the game into letting them do so.

To explain, let's say I want to start building an airship here:

My best options are:

• Aiming at some wall on the ground, plane locking and aiming up (the fastest way, but don't tell the mouse mode haters).
• Going into orbit mode on the ground and holding the "move up" button for an obnoxiously long time.
• Going into detached mode on the ground and holding the "move up" button for an obnoxiously long time.

You should just be able to position bricks in mid air at a set distance from your face. It should work like this: if you hold a 'float' key while in mouse mode, your ghost brick starts hovering at its current distance. If you're aiming at something too far away (like the sky), it will hover at a preset default distance instead.

More Extensibility Desired

This final new requirement is that the building system should be implemented in a modular way. That means the core Placer code should do very little, almost all functionality should be inside modes which are added on to it.

We currently have three types of modes:

Control Modes will implement the UX for handling user input and displaying output on the HUD. They will register a set of control hints to display on screen and can show or hide them from the HUD at any time.

We will continue to have three: Mouse, Orbit, and Detached mode. Implementing them as entire separate modes allows us to implement each mode more robustly as a state machine.

Alignment Modes will decide the behavior of the placement grid in all cases. At present, we have Plate, Half, Fifth, Tenth, and Brick.

Later we might add new alignment modes, or better yet, let the player define their own alignment grids for certain building styles like cube terrain.

And finally, Placement Modes will decide placement behavior. At present, we have Resize-Drag and the old Row-Drag.

Future placement modes could include a Circle-Drag or Frame-Drag. The way the system is designed will make it easy to extend, and all placement modes will work in all control modes.

We have our work cut out for us. Time to rewrite the whole building system!

Rewrite the whole building system??

There are many reasons we chose to rewrite the building mechanics in this case, even though we want to release the game some time this year still:

• The code for both the old inventory and building systems is almost entirely written in Blueprint prototypes (Unreal Engine's artist targeted visual scripting language), because we didn't really know what we were doing back then. Over the years this turned into literal spaghetti code, Blueprints are incredibly slow to refactor, cannot merge or version properly because of binary files, and there are no good tools to edit them other than Unreal's very clunky editor.
• There are now special bricks and other objects such as physics joints that you can place. Many of them need custom placement behavior. With the old Blueprint code, this was impossible to do in a reasonable way because the code is highly specialized to ordinary bricks.
• Important parts of the inventory system's "state", such as the brick inventory in its entirety and the current selected slot, were stored entirely client-side. This meant the server could never do things like know what bricks you have or what you have selected. This prevented us from implementing many long-desired features such as letting you put prefabs from the Gallery (more on that in later posts) in your quickbar.
• There was no modularity or real separation of the control modes (mouse, orbit, detached) and shared behaviors (alignment grid). Everything was either implemented multiple times for each case, or done by a shared function that had to be branch-heavy to the point of unreadability because of all the special cases. Nobody knows what parts you'd have to change to do X! And even if someone did...
• The blueprints were impossible to navigate and maintain, because there were so many functions and variables, and you can only view one at a time:

Why didn't we just buckle down and try extending this rather than a rewrite? Well, we sort of did, but it quickly became obvious it wasn't the way to go.

If you've been following the project for a while, you may have seen the recent Ferris wheel video in our #dev-media Discord channel, and the not-so-recent Physics Trailer. Those were made with prototype tools that were created by modifying (bodging) the building manger. And those prototype tools were not very good.

Here's me trying to build the Ferris wheel with them again, as a demonstration of how terrible it was the first time:

All the problems worked together to make the prototype UX this bad. It was slow for Zeblote to work with, and he had to really fight the fact that the building manager is written only for bricks, and has spaghetti-like code that is essentially working for every one of the neatly separated "modes" we designed above at once. Even if it were fully written in C++, this would have been very tiresome and resulted in wiping out most of the original code either way.

At the end of the day, addressing this kind of technical debt is something that just can't wait.

So let's get it done!

Upgrading the Inventory

Firstly, you will often see me use the expression "the inventory". But in Brickadia, at least in the Open Alpha, you really had three inventories: the Item Inventory, the Brick Inventory (client side only), and the Tool Inventory.

The Item Inventory lives on your character. It defines what appears in the quickbar, and in Alpha 5 it can only contain items. Because the character inventory lives on your character, it's fully lost when you die.

The Brick Inventory holds all the bricks you want to build with.

This inventory has a special extra slot in it called the TEMP slot. Something can be held in it temporarily, until you switch to another slot, at which point the TEMP slot is destroyed. This was mainly used for picking bricks from the world.

The Tool Inventory lives on your player controller, which can be seen as the "soul" that inhabits characters you control in Brickadia. Unlike the character, it's not recreated when you respawn - it's created once when you join a game, and deleted only when you leave. In addition, the tool inventory being here means you don't lose your tools when your character dies - they're kept.

We display the tool inventory via the tool pie menu:

The tool inventory can technically be edited by game modes, which will change what's in the pie menu! There's no particular reason it can't contain guns or, in the case of our new inventory changes, bricks. We just haven't added a way to do so.

Extensible Inventory Slots

In Alpha 5, inventory entries always store references to item actors. The game spawns item actors in the world when they are added to someone's inventory and hides them under the map until they're held, at which point it welds them to that player's hand(s) and plays any relevant animations.

We can visualise that inventory design like this:

You will notice it seems like this can't support bricks, even though we had a Brick Inventory in Alpha 5. That's exactly right! Alpha 5 only works because the Brick Inventory in Alpha 5 isn't real. It's a bunch of Blueprint hell where we create 11 widgets and store a brick reference on each one, and the UI widget calls a function on the building manager to change the current brick being placed. Which means the server has no idea, or authority over, what bricks you have!

The first thing we are going to do to fix this is throw out this separate, "fake" Brick Inventory and merge it into the Character Inventory. To do that we'll need to adapt our inventory to store bricks in it, which means we need a layer of indirection between the inventory and the different things you can store in it. Like this:

Entries point to an item that should be put in the player's hand when that entry is selected. As selecting a brick still needs to put the placer in your hand, we'll do something broadly the same as what A5 did - we'll create a placer instance with every player that joins the server, and put it in their hand when they have any brick selected in the quickbar.

More Inventory Space

Currently, our quickbar widget can only ever view the first 10 slots of the inventory - adding more doesn't work. But we can upgrade it to view specific ranges instead.

Here's what we do: When the widget is initialized, it takes the total inventory size and divides it by 10 to compute the quickbar count (i.e. 10). Now, you can switch between quickbars in order by CTRL-scrolling:

Or, you can press CTRL-[0-9] to go directly to a specific quickbar:

Keeping your Character Inventory

Doing all this has foregrounded an issue that already existed and was quite annoying in Brickadia's creative mode - when you die, either by physics damage or self destructing for a joke, your character inventory is cleared. The new problem? This now clears all the bricks in your inventory, too.

To fix this, I've added one more new feature: Keep Inventory. If you are in a minigame where this is on, or if you are not in a minigame at all, this feature will cause your inventory to be copied to your new character when you die. This means you don't lose your bricks, or any guns you spawned in for fun.

Selecting Inventory Slots

This mostly only exists for historical reasons at this point, but it seemed like an interesting tidbit nonetheless. When we were setting up the inventory system years ago, we wanted client side prediction for switching and firing weapons.

That meant the slot selection had to be routed through the character movement component in Unreal Engine. This wasn't easily extensible, but we had one free byte that could be used.

How do we select something out of two inventories and a TEMP slot using a single byte? Simple, we encode the current inventory selection in an int8 - a signed integer with 256 possible values, ranging from -128 to 127 - which we call an inventory index. We map inventory slots to the index like this:

• 0 is a special case. It means the player sending this index is not holding anything from any inventory.
• -1 is a special case. It means the player sending this index is holding whatever is in the TEMP slot.
• 1 to 100 select inventory items from the character inventory - you can get the index of the item in the character inventory by subtracting 1.
• -2 to -101 to select inventory items from the tool inventory - you can get the index of the item in the character inventory by removing the sign, then subtracting 2.

This fits 126 entries in each inventory, of which we'll only use 100.

Upgrading Building

Building has now been mostly rewritten in C++. It's nicely modularized and much easier to extend and debug. Here are the cliff notes of how it works!

The Core

With a lot of checking back to the building manager, I started by making the Placer's core - its state machine for the control mode, as well as selection for the alignment and placement modes.

Things that work exactly the same way in every mode can be implemented on the Placer itself, so we'll implement the controls to switch between placement and alignment modes here. C switches alignment mode, J switches placement mode. Holding C selects the special "super" alignment mode.

Of course, even though you can select bricks from the Quickbar, you can't actually place a brick yet at all. Or see anything happening when you swap the modes. We're about to get to that. Starting with...

Aligning Bricks with the Mouse

The second most complicated part of building is the code that uses the position of your mouse to determine where the brick you're aiming should go. It seems trivial but it's not. The tool trace hit position must be resolved into a brick placement location, where:

1. The resulting placement must be positioned on the grid that was intersected, or if none the global brick grid (and the placement preview should parent itself to that brick grid, so there's no jittering if that grid is a moving vehicle);
2. The resulting placement must not be positioned in a way that causes it to intersect the surface it was aimed at;
3. The resulting placement must treat hidden or noncollided bricks like regular bricks;
4. The resulting placement must respect the placement alignment grid, meaning that the placement's edges must be aligned to a minimum of 3 faces of one of the alignment grid cells it lies inside (which is why bricks smaller than the alignment grid align themselves to corners);
5. That alignment grid's origin and oriented cell size must first be resolved from considering the orientation of any hit anchors (such as studs or stud inlets) or else the orientation of the surface on the brick that was hit by our raycast - i.e. if you aim at the side of a reoriented brick, or a stud grid, you get a rotated alignment grid;
6. The resulting placement should also orient itself to any anchors (such as studs or stud inlets) unless a specific direction is requested - i.e if you aim at side studs and you haven't manually set your direction, your brick should turn sideways to place on it, and;
7. The specified user rotation, and, if set, direction, should otherwise always be respected.

In other words, firing the correct raycast given the position of the cursor is the easy part.

How do we tackle this?

Let's start by grabbing a bit of information from our hit result. We'll grab:

• The brick grid we hit, or global if we hit the map.
• The EBrickDirection of any anchor (stud or inlet) we hit, or the global up direction (Z+) if we didn't hit any.
• The type of anchor we hit, or none if we didn't hit one.

We can already compute our alignment grid's origin and cell size from this information combined with our current alignment mode. The origin is the position of any anchor we hit (or the brick grid's position if we didn't hit one), and the cell size is our alignment mode's cell size rotated to our up direction.

We can now snap our brick to some kind of grid and rotate it to anchors' orientation.

But of course, as soon as we try to place something other than a 2x2 micro brick, it's obvious that something is still very wrong - even when we align the placement point to the grid, the brick ends up wrongly positioned.

Positioning the brick properly requires understanding that what we are placing is not a point, but a box with a size. Placing it like that means we can use the box extents to de-penetrate it from the surface we hit and the nearest 3 grid cell faces, which gives us way better results:

And because of what we did before, it'll even rotate to face away from studs or towards inlets.

Unfortunately, it's still a bit difficult to work with. To explain why, let me demonstrate with this extremely long, tall ramp.

This isn't very usable for building with unless I'm placing it on the floor of the map. For most other use cases, like placing them corner to corner, I need the origin to be where the stud inlet is. I need a pivot.

So let's upgrade our size to a full pivot - a box with a relative offset and a size that is calculated within the bounds of the brick being placed. We can use the existing code from the old building system, which per-calculates several of these, and we can choose a pivot to use based on what our ray cast hit. We'll add:

• A "Bottom Studs" pivot, which records the location and size of the first found bottom stud grid. We'll choose this one for aligning to top studs.
• A "Top Studs" pivot, which does the same for the first found top stud grid. We'll choose this one for aligning to bottom studs.
• An "Expanded Studs" pivot, which takes the top studs pivot and expands it to the other end of the brick. We'll choose this one if we're aligning to the side of a brick with our rotation or aligning against the map, since it helps us cull parts of the brick from the placement calculation that are irrelevant.
• A "Bounds" pivot, which when used produces behavior identical to what we were doing before we used pivots - an unmoved bounding box that encapsulates the entire brick. We'll only choose this one if we're aligning to the side of a brick with a different rotation to our previewed one, and we can't reorient to match it. We can also use it for other placement calculations, such as the origin of the brick in the next section.

All sorted!

Knowing where the stud grids are also lets us do stuff like this.

And even if we locked the orientation, we can still line things up relative to the brick being placed on.

Placing Floating Bricks

We wanted a floating placement mode that lets you place your brick in front of your face while holding ALT.

We can do that fairly easily - take the origin and direction of the cursor ray and the distance from it of the current preview brick (or a sensible default distance if there is none) and compute a location. Now, continuously move the brick's origin to the grid cell nearest to that location:

We can improve it further by binding the mouse wheel to changing the distance, so you can move the brick closer or further away.

Gizmos and the Preview Grid

You've been seeing a grid in the last few videos. That grid is not the same one from Alpha 5 - it's been re-implemented as something called a gizmo.

A gizmo is a rendered element that provides interactivity and/or feedback when working with 3D scenes. You may have seen these before:

These are common gizmos you'll find in engines like Unity and Unreal, as well as modelling tools like Blender. And soon you'll find them in Brickadia. But more on that in another post.

Unreal's Interactive Tools Framework provides an entire system for displaying arbitrary gizmos at runtime, and previously, Zeblote has done work that allows me to draw things in the engine's Editor compositing layer at runtime too. It only makes sense to make some use of it!

I started by creating a gizmo manager which we'll provide with some materials to draw gizmos with. You can register gizmos with it, and gizmos are allowed both to control actors, and do manual drawing with ITF's gizmo elements. Let's do some quick testing to make sure it can be configured to draw things on top of everything else:

Dragging Brick Rows (Old)

Do you remember when I said that previewing brick placements was the second most complicated part of building? This is the most complicated part. We need to determine, with only a world start location and a camera angle as our inputs, which direction the player wants to drag their brick row - up, down, north, east, south, or west - and how long they want it to be. To recap:

In Alpha 5, we already had an algorithm to do so that worked roughly like the following steps:

1. We convert everything to local space relative to the position the row starts at. From there, imagine lines extending in the direction of the 3 axes. The crosshair can be converted to a ray from the camera origin into the world.

2. Now, we construct 3 axis aligned planes between each pair of axes, then intersect our ray with each of them. This gives us up to 3 intersection points.

3. For each plane, we determine how close the intersection point is to the axes.

4. From these, we select the intersection point that is closest to an axis overall. The nearest axis will then be used to drag along.

5. From there, we simply have to snap the distance along the selected axis to the grid cell size and return the result.

This algorithm produced mostly sensible results in most cases, and worked well enough for the Alpha. However, there are many annoying edge cases that we could never figure out how to solve with this approach, such as:

Dragging Brick Rows (New)

The problem is this existing algorithm is not very good at the transitions between planes. It constantly annoyed us by randomly jumping around as it selected a different plane to be closer and produced unintuitive results. So after I pushed the first building changelist, Zeblote rewrote this function to select the closest axis to your cursor in screen space instead.

1. We start with the same axes and crosshair:

2. We project those world-space lines to screen-space lines. This sounds trivial at first, since Unreal Engine already provides a ProjectWorldToScreen function. All we need to do is pick two points on the line (such as the origin and one unit away) and we'll have screen space points defining our line in 2D.

However, there's a problem with that approach. In some cases, you might want to start dragging a row and then move or turn your camera far away, until the start point of the line is no longer on screen at all. This then breaks the projection.

So we need a more robust way to construct screen space lines. There is a simple solution in theory, we need to find two points on the axis that are actually on screen, but how can we do that reliably?

One way is to clip the line inside the view frustum, so we end up with a line segment that is entirely on screen. In the above image, this would effectively select the point at the bottom left corner and the point at the horizon.

We can then extend the line segment again to make sure it reaches the edges.

3. We select the line that is closest to the cursor in screen space. This effectively divides the screen into up to 6 zones that will select one of the axes, but they're not necessarily the same size.

4. There's an additional filter to reject axes that are very steep when multiple axes are near the crosshair at the same time. This fixes the issue of extending the row into your face when you are looking at the brick from a steep angle.

5. Once we have our chosen point on the screen space line, we need to convert it back to a world space point so we can calculate how far along on the axis it actually is. We could attempt to do some linear algebra here, to figure out what distance along the screen space line equals what distance along the world space axis, but that seems annoying given the perspective view.

So we just use the existing DeprojectScreenToWorld function in the engine to construct a ray from the camera origin going into the scene. By finding the closest point on the world space axis to this ray, we've finally got the point we wanted. What an ordeal!

Also, there's one more edge case to take care of, if we're looking away from the axis (even though it is on screen), that trick won't work, because the ray will diverge from the axis. So we detect that special case and just drag a row to the maximum length along the chosen axis.

Once we picked an axis and world space point, we figure out the row length the same way as before, and we finally have row dragging working again. It's much more robust now, and the edge cases we had above no longer happen.

It's trivial to add in spacing too.

But we're not done yet - Let's take advantage of our gizmo system to display a line on top of everything showing the drag start point and both ends of the row. Near the active end, we'll display a row length in-world.

Resize-Dragging

Resize dragging is a simple extension to row dragging, it mainly involved changes to the very last part of the row dragging math. Instead of resizing the brick in increments of the brick size, as if we were row dragging, we resize in increments of the alignment grid size, skipping increments that don't line up with valid dimensions for the brick type. That means we resize on our grid, like this:

We can still resize in increments of the brick size, if we change the grid size:

One note; we need a special case if the brick's starting size does not entirely fill the grid cells it's in. In this case, for the first increment we want to size it up slightly less, so we only resize up to the grid line:

But what use is being able to resize only in one direction? Let's quickly add the support for switching axis with RMB. The row dragging math only needs a few more branches to filter out axes that we've already locked in.

We can easily allow this in row dragging mode too to create "grids" and "volumes" - 3d grids of the same brick with arbitrary spacing.

Rotation and Reorientation

It's easy to make tapping R rotate our brick clockwise, as before. But remember how we wanted to reorient bricks to the closest direction to the cursor? Well, that's exactly half of how row-dragging and resize-dragging already work.

We'll activate this new behavior if the player holds R for more than 200ms and moves the mouse, then finalize the orientation once they release it. While reorienting, we simply make the brick's up direction point towards where the mouse is.

And of course, we made a gizmo for this too.

Tool Widgets

Our HUD is looking quite bare with the new placer.

The old one modified some text that was manually added to the A5 HUD - but that text has been removed from the EA one, depriving us of some important information the old placer, resizer and other tools were able to report by modifying it.

Actually, doesn't this case happen a lot? There are two other tools I can think of that put information on the screen - the Painter and the Resizer - and yet we manually modify the HUD to add their widgets every time, then just make the tool unhide them. Shouldn't we have a better system? We should, right?

Here's that better system: All tools can now add an arbitrary "large" tool widget to the bottom right corner of the screen, and a "status" tool widget to the area above the quickbar. For the placer, we'll use this to display more measurements onscreen.

Tool Bind Hints

The new system is working nicely, but it needs learnability! We're in need of a means to display our new controls to the user in a way we can dynamically update in real time, because we want to display all the controls the user can use right now - and hide ones that aren't relevant until they are.

First, we needed a nice way to show any input. This CC0 pack by Kenney fit great into our new UI style, and they even fixed a bug we reported quickly. Can definitely recommend these for your project!

We then (manually, ugh) wrote a big table that would translate Unreal Engine FKeys to an icon texture reference from the Kenney pack, and a widget that given an Input Action or Input Axis name, displays the icon for the key bound to that action. Or sometimes multiple icons for chords like Ctrl+C.

Now that we had a way to display keys, we created a system called Tool Bind Hints. All tools are allowed to register them, and they look like this:

How it works is that all tools define a list of bind hints they display in any order they choose. For example, the placer defines this list:

Bind hints have tags, and the game chooses what bind hints to display by determining if they have any tags that are currently shown. For example, here's how the placer uses its tags:

• Previewing is set while the placer is previewing a brick position.
• Placing is set while the placer is dragging a brick row.
• SwitchAxis[123] are used to show the various switch axis prompts (this might be upgraded to a better solution later, bear with me)
• BuildingSpacing is set if you're placing in a placement mode that allows the usage of spacing (so we hide the spacing hint in resize-drag mode)
• FloatBuilding is set if you're using floating building (to show the scroll prompt).
• Reorienting is set if you are reorienting the brick.

And finally, here's a demo of its hint UI updating in real time as you place stuff!

Selection Highlighting

One more thing, we added a system to highlight specific bricks and objects with selection outlines in various colors. For example, the Hammer now shows you which brick is going to be deleted with a red highlight:

Placing new bricks also uses a selection outline around the preview, except it's white. Did you notice it in the videos above?

More to Come!

That's all I have for you today, but there's more coming soon. We'll show the new modes for building physics contraptions. We'll look at the new locking modes, which will bring back the plane locking functionality you can get by holding ctrl, and then some. We'll also be getting into the new orbit mode for building on a controller or Steam Deck, and some new detached mode features.

I look forward to seeing you then. Stay tuned!