Exofactory Dev Blog

New Demo, New Buildings, New Architecture

Unknown — Sun, 06 Sep 2026 00:00:00 +0000

Overview

Lots of work was done over the month. Proper architecture was added, including walls, doors, ladders, roofs, and floors. This really brings the game to the point where players can build "factories" proper. Additionally, a few buildings were added. These buildings, along with the architecture, "complete" the vertical slice I am targeting here. In this post I cover these new systems, buildings, and how they all fit together. Robot (Exoframe) navigation was very interesting to implement given the above-mentioned ladders.

Naturally, this vertical slice is a good break point for a new public playable version of the game. I am aiming to release a public "Demo 2" in early November 2026. More details below.

If you are interested in playing Demo 2, or if you find this post interesting, I would recommend wishlisting Exofactory on Steam. It helps a ton.

Wishlist on Steam

Demo 2!

With the work done in August, the game is "mechanically complete" as far as the currently scoped vertical slice goes. Just in case you don't know (I didn't know until more recently than I would like to admit), a vertical slice is a type of milestone, benchmark, or deadline, with emphasis on demonstrating progress across all components of a project.

In the case of Exofactory, this means that the player should be able to:

Build deep, complex, and emotionally satisfying (in and out of the game) factories.
Learn more about the AI that the player plays as, starting to establish wants, needs, and moral values based on what is done in game.
Play with friends, working together or apart, coming and going without issue.
Learn more about the world the player finds themselves in.

This being said, a "mechanically complete" vertical slice does not a fun game make. Over the next two months, much polishing, testing, playing, and refinement is to be done.

Demo 2 is targeting Linux and Windows via Steam, and, if possible, Linux via Flathub.

Of course, there will be aarch64 and RISC-V builds as well for Linux.

Architecture

The new architecture elements really add a lot of life to the game, to the point where the trailers, screenshots, and press kit will all need to be redone. I would even say that in most 3D factory games, migrating from machines under the open sky to buildings is THE milestone that separates the very beginning from early to mid-game play. Really cool to see this now in Exofactory.

Walls & Doors

We can build walls in groups, on a platform or on the ground.

From a coding perspective, adding "raw" walls to the game was not too hard. I extended the preexisting baseplate code to support vertical "walls". I am a huge fan of Bevy's relationship system, and by using it here and in the baseplates, we get bulk deletion, groups, and group joining/splitting all for free. Really convenient. Technically, when you build a segment of wall or baseplate, there is an entity that forms a relationship with the grid of placed wall or baseplate segments. When you go to delete that wall, you can get the entity of the wall section that the selection raycast hit, then get the relationship to the "complete" wall entity, then get all its members through those relationships. Then you can delete, merge, or do whatever you want with all members.

Simple doors are basically holes in the walls. For both exoframes and belts.

Doors are pretty simple. They're just walls with a hole through them, sans all the components that let walls do the fancy wall stuff.

Both the walls and the doors are my custom, definitely unskilled Blender work, and these assets are temporary filler assets.

Here we can see the Avian3D sensors.

There was an interesting hitch I did have to address, though. When constructing a building, you often can't directly see the face of the surface you want to extend a floor/wall/ceiling from. As the code stood, you could only extend from a surface whose relevant edge you could see.

The solution was actually quite elegant. Along relevant faces, as the architectural elements are placed, we use an extended Avian3D Sensor along with more relationships to allow the player to extend their building without too much frustration.

Ladders

Ladders now work, and aren't visibly for humans.

Ladders were shockingly fun to design. The principle here, as with all the assets, is to ask how an AI created by humans, but not human itself, would design such a thing without human physical constraints.

In machines, this means no control panels, or human-sized access hatches, or safety systems built around protecting squishy human bodies.

Climbing ladders is done just by walking into them.

Here with the ladder, this principle applies. The ladder is built around the needs of the base Exoframe worker robot with its four legs.

While designing the ladder was fun, there was a lot to learn on the implementation side, particularly around the Tnua character controller's climbing functionality and wiring it into bevy_landmass for autonomous navigation.

The issue is that in a building with many floors connected by ladders, there is an "archipelago" of navigable regions. Each floor is isolated from the others.

Autonomous Exoframes can use ladders too using the same underlying systems.

Landmass provides animation links for exactly this. Basically, I define an entrance and exit at either end of the ladder connecting two islands in the archipelago and Landmass can include it when planning a route.

When an Exoframe reaches the link, I add a UsingAnimationLink component to take over, then feed the approach and climb inputs into the existing controller. Tnua's obstacle radar finds an anchor point on the ladder collider, and its climb action moves the robot up or down. The actual climbing code is shared between manually controlled and automated Exoframe robots.

Once an Exoframe is off a ladder, the UsingAnimationLink component is removed and Landmass resumes the trip.

Buildings

My plan was to add as few new buildings as possible to the game. After thinking through what is essential to really highlighting Exofactory's unique systems, I narrowed it down to 2.5 buildings.

With these, I think the demo will have enough evident (and emergent) complexity to be a fun game on its own.

Resource Bank

The resource bank. A very temporary-looking asset.

The Resource Bank is another temporary asset I created to enable a core bit of functionality in the game.

In the game, sending items to the resource bank brings about a sense of security and wellbeing. In the Freudian self-actualization framework of the game, sending items to the resource bank satisfies a longing of the Id and frees up the resources of the Ego to do things the player might appreciate.

The resource bank interface. You can see what is being banked and what unlocks are available.

Mechanically, outside of the lore / game design, the resource bank unlocks quality-of-life features based on what is being sunk. Uniquely, though, unlike other factory games, these unlocks are only retained for as long as the sink rate is met. If the production chain breaks, you can lose those quality-of-life benefits.

Integrator

The integrator. This building lets you automate recipes with 2 inputs and 1 output.

The second building is the Integrator, a.k.a. the two-input, one-output building. In the demo, the only way to craft Galvanized Iron was by hand. It requires structural iron and zinc ingots to craft.

This machine, while not a filler asset created by me, is not one I am fully happy with and is subject to change.

Adding this lets the player fully automate all available recipes.

Tier 2 Belts

The green tier 2 belt on the right runs at 128 items / min. The tier 1 belt on the left runs at 64 items / min.

The final half building is a faster 128 items / min belt. For now, it's the tier 1 belt with a different color. This was added because you can't really build a proper factory of any size with only the base 64 items / min tier 1 belt.

What's Next?

While the mechanics for Demo 2 are fully in place, the game is not nearly ready. There are two areas that I intend to refine, namely the pace of the intro and the terrain.

Feedback from Demo 1 and from friends and family testing showed that the intro and tutorial sections were painfully slowly paced. Cinematic and mysterious for sure, but painful. The goal here will be to rewrite those sections such that they don't feel so slow or forced. The challenge will be balancing the needs of veteran factory game players and those of first-time factory players.

The second area of focus will be the terrain.

The current terrain v3 "engine" that I built in 2025 should suffice here. The issue is the terrain itself is pretty bad.

Some time ago, but after the current demo map was created, Exofactory fully moved away from voxels. The current map was designed fully around focusing on avoiding voxel issues.

Now that I don't need to worry about flatness or lining up buildings on a grid, I think designing a map that is aesthetically interesting, pleasant to explore, and full of surprises should be ~~easier~~ possible.

I suspect the majority of the work over the next several months will be focused around terrain design.

Conclusion

Mixed feelings about reaching this milestone. On one hand, the game dev in me is really proud to get to this point. On the other hand, the backend dev in me is sad to see the hiatus in my favorite type of work (a.k.a. fun new prototype features).

Overall, though, I'm really happy to be at this point. Polishing will be all about building and refining the feel of the game. The experience and feel of the game are really what it is all about in the end.

Once again, if you are interested in playing Demo 2, or if you find this post interesting, I would recommend wishlisting Exofactory on Steam. It really does help.

Wishlist on Steam

Bevy 0.19 Migration & Better Buildings

Unknown — Sun, 02 Aug 2026 00:00:00 +0000

Overview

Over the last month a large amount of work was focused on migrating Exofactory from Bevy 0.18 to Bevy 0.19. Beyond an additional cursed "I implemented a worse version of a feature before Bevy implemented a better version x months later" situation the port itself went swimmingly.

The HUGE win of Bevy 0.19 is bsn! I did a lot of work here and cover it below.

Additionally I did some work in Blender with Skein to fix a few visual bugs, also addressed below.

Overall, I did wish to get more done, particularly with the Steam's October Nextfest once again quickly approaching. This being said it couldn't be avoided. More than a week was spent at Bornhack 2026, an amazing hacker campout. Too many fun distractions to be seen and too much to do. This being said, I did manage to sneak in a fun little Bevy workshop while I was there.

As always, if you find this post interesting, or if you are interested in the game, I would recommend wishlisting it on Steam. It helps a ton.

Wishlist on Steam

Proper Building Shadows

Item entry/exit points no longer react to light and shadow.

If you've ever played a 3D factory game you may be aware of the "item coming out of a dark tunnel/portal/hole" trope. Exofactory also uses this.

The issue was that these item entry/exit points interacted with light and shadows normally. This resulted in emotional disconnect when a shadow passed over the point or when harsh bright light shined over said surface.

It looked like an item was passing through a solid surface of the building. Not emotionally nice.

The solution was to change the material of said surface to not interact with light. Given that I prefer to go with a data oriented approach whenever I can I opted to open up Blender, modify the building asset files, and add the appropriate Bevy Components via Skein to the freshly isolated surface.

If you are working on any 3D Bevy game and use Blender I strongly recommend using Skein. It eliminates a ton of boilerplate code.

Bevy 0.19 Migration

Ok, funny story. I seemingly have a cursed situation where I implement a feature only to find out that a better version of said feature will soon be added to the Bevy engine natively.

Here this happened with Bevy's new 0.19 resources as components.

Exofactory's multiplayer functionality is largely based on syncing of components via the excellent bevy_replicon.

A limitation of replicon is that it EXCLUSIVELY syncs components. Not resources. Resultingly it did not sync resources prior to Bevy 0.19.

What I had been doing is using semi-cursed Bevy component singletons as pseudo resources. For any "resources" that need to be synced from the server game instance to client instances.

I would then access these pseudo resources in systems and would treat them as if they were resources.

With Bevy 0.19 this is a bit redundant, but I thought it was funny enough to share. For now I am keeping the pseudo resources that I have, but going forward things should be simpler.

BSN Boiler Plate Reduction

This is where I spent most of my time. Prior to Bevy 0.19 when people would ask me what it's like to work in Bevy I would say:

"Bevy is amazing, but the Bevy UI system is ~~miserable~~ very unfun to work in."

Prior to Bevy 0.19 I would have described it as the verbosity of Rust mixed with the alignment fun of CSS. Now it's just the CSS part which frankly is acceptable once you drop the verbosity element.

How much of a verbosity difference do you ask? Well for Exofactory my codebase was 7,364 lines of code smaller after switching to bsn. Just under 10% of the total code base.

20,673 lines of imperative UI code swapped out for 13,309 lines of descriptive bsn. Amazing.

git diff 837c64ca...01bb5769 --stat-width=55
 Cargo.toml                          |    4 +-
 assets/fast.assets.ron              |    5 +-
 crates/exo_base_ui/src/lib.rs       |    4 -
 .../src/ui/control_guide.rs         |  463 +--
 crates/exo_base_ui/src/ui/mod.rs    |  104 +-
 crates/exo_base_ui/src/ui/topbar.rs |  405 +--
 .../inventory_grid/buffer_ops.rs    |   30 +-
 .../widgets/inventory_grid/mod.rs   |    6 +-
 .../inventory_grid/spawning.rs      |  250 +-
 .../src/gas_extractor.rs            |  189 +-
 crates/exo_building_ui/src/lib.rs   |  343 +-
 .../src/logistics_inventory/mod.rs  |    6 +-
 .../logistics_inventory/scroll.rs   |  101 +-
 .../logistics_inventory/transfer.rs |   18 +-
 .../ui_builder.rs                   |  505 +--
 .../src/mining_machine/layout.rs    | 1329 +++----
 .../src/mining_machine/mod.rs       |   11 +-
 .../src/power_grid_rows.rs          |  166 +
 .../src/power_relay/grid_display.rs |  202 +-
 .../src/power_relay/interaction.rs  |   15 +-
 .../src/power_relay/layout.rs       |  707 ++--
 .../src/power_relay/mod.rs          |    7 +-
 .../grid_display.rs                 |  241 +-
 .../power_substation/interaction.rs |   15 +-
 .../src/power_substation/layout.rs  |  681 ++--
 .../src/power_substation/mod.rs     |    7 +-
 .../src/production/navigation.rs    |   37 +-
 .../src/production/scroll.rs        |   37 +-
 .../src/production/tabs.rs          |   27 +-
 .../src/production_components.rs    |   27 +-
 .../close_button.rs                 |   52 -
 .../header_status.rs                |  426 ---
 .../production_layout/materials.rs  |  114 -
 .../src/production_layout/mod.rs    |    9 +-
 .../production_mode.rs              |  240 --
 .../production_tab.rs               |  893 -----
 .../src/production_layout/root.rs   |  100 -
 .../src/production_layout/scene.rs  | 1100 ++++++
 .../src/tier_1_core/crafting.rs     |  102 -
 .../src/tier_1_core/inventory.rs    |  179 -
 .../src/tier_1_core/io_panel.rs     |  574 +--
 .../src/tier_1_core/layout.rs       |  419 +++
 .../src/tier_1_core/mod.rs          |   66 +-
 .../src/tier_1_core/recipes.rs      |  412 +--
 .../src/tier_1_core/screen.rs       |  705 ++--
 .../src/tier_1_core/scrolling.rs    |   16 +-
 .../src/display_dialogue/mod.rs     |  317 +-
 crates/exo_exoframe_ui/Cargo.toml   |    1 -
 .../src/exoframe_mode_ui/mod.rs     |  704 ++--
 .../src/fleet_ui/layout.rs          |  285 ++
 .../src/fleet_ui/mod.rs             | 1073 +-----
 .../src/info_ui/layout.rs           |  422 +++
 .../logistics_settings/layout.rs    |  755 ++++
 .../logistics_settings/mod.rs       | 1819 ++--------
 .../src/info_ui/mod.rs              | 1420 ++------
 crates/exo_exoframe_ui/src/lib.rs   |   29 +-
 .../src/name_editing.rs             |  221 ++
 crates/exo_exoframes/src/lib.rs     |    4 +-
 crates/exo_exoframes/src/mining.rs  |  387 +-
 crates/exo_fast_assets/src/lib.rs   |    2 +
 .../exo_global_mode_ui/src/lib.rs   |   75 +-
 .../exo_loading_screen/src/lib.rs   |  153 +-
 crates/exo_main_menu/Cargo.toml     |    8 +-
 .../src/crash_report.rs             |  481 +--
 .../src/join_game/direct_connect.rs |  624 ----
 .../src/join_game/focus.rs          |  455 ---
 .../src/join_game/lan.rs            |  630 ++--
 .../src/join_game/layout.rs         |  753 ++++
 .../src/join_game/mod.rs            | 1345 ++++---
 .../src/join_game/steam.rs          |  369 +-
 .../src/join_game/tabs.rs           |  242 --
 crates/exo_main_menu/src/lib.rs     |  139 +-
 .../src/load_game_ui.rs             | 1749 ++++-----
 .../src/main_menu_screen.rs         |  672 ++--
 .../src/build_status_hud.rs         |  338 +-
 crates/exo_placement/src/input.rs   |   13 +-
 crates/exo_placement/src/menu.rs    | 1021 +++---
 .../src/menu_content.rs             |  771 ++--
 crates/exo_placement/src/plugin.rs  |   46 +-
 crates/exo_placement/src/states.rs  |   52 +-
 .../src/assessment.rs               |    2 +-
 .../src/build_status.rs             |    2 +-
 crates/exo_save_runtime/src/lib.rs  |   77 +-
 .../src/navigation.rs               |    1 +
 .../journal/mod.rs                  |  597 ++-
 .../journal/scroll.rs               |   31 +-
 .../in_game_main_menu/mod.rs        |  900 ++---
 .../multiplayer/direct_connect.rs   |  643 ++--
 .../multiplayer/input.rs            |  768 ++--
 .../multiplayer/lan.rs              |  630 ++--
 .../multiplayer/mod.rs              | 1299 +++----
 .../multiplayer/steam.rs            |  196 +-
 src/core_game/mod.rs                |   27 +-
 src/lib.rs                          |    2 -
 src/splash_screen/mod.rs            |   83 +-
 95 files changed, 13309 insertions(+), 20673 deletions(-)

full_git_diff_width.txt

What I am REALLY looking forward to is separate .bsn files along with hopefully, an appropriate LSP.

I imagine I could do a further 13,000 line of code "reduction" simply by moving all of my bsn! macros to *.bsn files. Playing around with .bsn files could be done recompile free. Additionally .bsn files could make game modding ergonomically feasible. Whole levels, scenarios, settings, and the like could be player defined in hot loadable community written bsn files.

BSN UI Ergonomic Improvements

Line of code reduction alone isn't the only benefit though. Once you have bsn you can write performant retained mode (UI retained between frames) UIs with the ease of immediate mode (whole UI regenerated every frame) toolkits like bevy_egui.

As of Bevy 0.19 I don't think it makes sense to write any immediate mode UIs unless you have a very special use case.

// Bevy 0.18 "traditional" UI
fn setup(mut commands: Commands) {
    commands.spawn((
        Button,
        Node { width: Val::Px(150.0), height: Val::Px(65.0), ..default() },
    ))
    .with_children(|parent| {
        parent.spawn(Text::new("Press me"));
    });
}

fn button_system(
    query: Query<&Interaction, Changed<Interaction>>,
) {
    for interaction in &query {
        if *interaction == Interaction::Pressed {
            info!("hello");
        }
    }
}

Above we can see that pre Bevy 0.19 UI code can be pretty boilerplate heavy and tedious. Less fun.

// bevy_egui style UI
fn ui_system(mut contexts: EguiContexts) {
    let Ok(ctx) = contexts.ctx_mut() else { return };

    egui::CentralPanel::default().show(ctx, |ui| {
        let press_me = ui.add_sized([150.0, 65.0], egui::Button::new("Press me"));

        if press_me.clicked() {
            info!("hello");
        }
    });
}

Above we have an immediate mode UI. Much more ergonomic than traditional 0.18 style Rust but re-generated every frame.

// Bevy 0.19 with bsn! macros
fn setup(mut commands: Commands) {
    commands.spawn_scene(bsn! {
        Button
        Node { width: px(150), height: px(65) }
        on(|_event: On<Pointer<Press>>| info!("hello"))
        Children [ Text::new("Press me") ]
    });
}

Lastly we have our bsn! macro. I would say this is simpler and even more intuitive than bevy_egui. You get the ease of simple UI without the need to regenerate the UI every frame.

The built in observer style on(...) syntax makes making the UI properly interactive easy.

Bevy Scene Notation is really a nice jump for Bevy devs. I see why stabilizing it has been the priority as a prerequisite for a lot of upcoming Bevy work.

Conclusion

The past month was a bit less feature driven than I would have liked to have seen, but essential work has been done regardless. I think part of working with Bevy is accepting that as you work on your game new Bevy releases will happen. Personally I think that the "tax" of migrating and modernizing your game, like certain real world taxes, is worth it. I think not migrating to the latest release of Bevy only puts Bevy games at risk of failure. That and you miss out on the latest ergonomic niceties that make Bevy ever nicer to use.

And once again, if you found this enjoyable, informative, or just like the game, I would suggest giving the game a wishlist.

Wishlist on Steam

Exoframe Autonavigation and Refactoring into a Workspace

Unknown — Sun, 05 Jul 2026 00:00:00 +0000

Overview

The past month has been full of excitement and tedium. Excitement due to a very cool, essential game feature being added. Tedium due to the massive amount of work that was needed in order to refactor Exofactory from a single crate to a workspace-based project.

On top of this, I did plan to do a bit more, but with the massive historic June heatwave it was difficult to muster the will to do more than the "don't starve today" work in a hot office in which the overworked, underpaid AC was not keeping up.

Regardless, the Exoframes as Agents feature, I think, counts towards the quality-over-quantity style of blog post. I'm pretty proud of it.

In addition to this, I cover the efforts I made in refactoring the game from a single Rust crate into a workspace. I cover the steps I took, why I took them, how I took them, and I give my thoughts on how others might go about it.

As always, if you find this post interesting, I would encourage you to wishlist the game on Steam.

Wishlist on Steam

Exoframes as Agents

The Exoframe UI. Now with custom naming ability!

In Exofactory, quality-of-life upgrades are unlocked as the player makes progress building up their infrastructure.

In a previous post, I covered placing buildings in global mode. Having Exoframes act as agents is a class of quality-of-life upgrades that can be unlocked as things proceed.

Basically, Exoframes can be tasked to do several things automatically, navigating the world and interacting with it without the need for "conscious" control.

Technically, this was done with the help of two excellent Bevy ecosystem crates, namely bevy_rerecast and bevy_landmass.

Bevy Rerecast builds and updates a navigation graph based on the recast algorithm and, amazingly, can just straight up use the existing Avian meshes. Mind-blowingly convenient.

With the navigation graph "solved," the next step was to actually use this graph to move things around.

Looking again at the ecosystem, I considered two potential libraries: vleue_navigator and landmass_rerecast.

To the best of my understanding, vleue_navigator is a lower-level navigation library giving fine-grained control, while landmass_rerecast is a higher-level navigation library that abstracts the control away into a higher-level "agents" concept where the user of the library focuses more on goals and destinations rather than the details of navigation.

Given the name and heading of this section, you may have correctly guessed I went with landmass_rerecast, because it matches the approach I wanted to take while fitting the in-game understanding of how Exoframes might be controlled. (aka subconscious subprocess agents)

It worked quite smoothly, even wiring properly into bevy-tnua. It's cool because that means agent Exoframes navigate and move around using the same code path as players would.

From here I wired up some simple components to mark Exoframes that should act as agents and did some testing.

Exoframes can be summoned or moved automatically.

Progress.

From there, item fetching and requesting was implemented along with a basic UI around it.

We can request goods in some Exoframes and have them delivered by others.

Then the last bit, a new dashboard where players can configure all existing Exoframes. Hopefully this will be the last UI I ever write without Bevy Scene Notation, aka BSN.

We can toggle Exoframe settings globally.

In the end, we can now summon, request, and designate a pool of Exoframes to be switched around to or used as fetchers.

Exoframes can deliver resources to other Exoframes.

This is all very cool for sure, but I think the main takeaway point here is that all of this work was only possible because of the excellent, highly interoperable Bevy ecosystem. Crate authors know of other crates and work to ensure there is a smooth, highly ergonomic developer experience.

Even if an Exoframe moves, that is handled.

There are a ton of amazing Bevy crates out there. I recommend you explore them through either the official Bevy asset site or, secondarily, my personal BevyDex project.

Codebase Refactor

The other large chunk of work I did revolved around a major refactor of the game from a single crate to a workspace of crates. The reason why I did this was because I got to the point where even making a small change, even a single const change, would result in annoyingly long compile times, even with dev builds. You can only wait 45 seconds for a dev build while tuning walking wobble constants so many times before you decide something needs to be done. Make that 1:10 for release builds to actually confirm that those consts look good.

Feels even worse seeing all of the idle cores sitting there while one is pegged at 100%. Feels like a waste.

Below is a simplified description of the approach I took to address this.

My Strategy

My plan was to just pull out each of the "root level" Bevy plugins into its own workspace crate. I had been focusing on proper root-level plugin isolation so most of the plugins were pretty easy to move. Just a lot of import changes.

The issue was that there were several sets of Bevy plugins that imported components and resources from each other. The above is an example of the sort of thing I would see. These exceptions that I made were the cause of much pain and suffering. There were a few potential circular dependencies that needed to be prevented. BUT I really wanted to allow as much parallel compilation as possible so I wanted to keep the workspace as flat as possible. Workspace crates should have the absolute minimum intra-workspace dependencies.

Here I took a staged approach. Stage 0 was to just move all the easy, no-changes-needed root-level plugins into their own workspace crates.

Stage 1 - Isolate Shared Components

The first step was to move the shared components/resources/message types, etc. out of the plugins into their own workspace crates, just modifying imports as needed. I did this because I wanted to incrementally split things out without needing to break the game for a long time.

I added the workspace, added the exo_* crates, and moved the relevant items over.

Stage 2 - Move Systems

Here things got a little tricky. I needed to move the systems out of the main crate. The issue was that the shared components would still be needed everywhere, resulting in reduced parallel compilation.

The result I went with was to keep the highly shared components in the relevant crates and to just add dependencies for them everywhere as needed. As long as I don't change these on sequential compiles I still get that parallel work. Given that these core components don't change often (or at all in some cases) this was acceptable.

The plugins and systems that are more subject to change were moved into exo_*_runtime crates.

This resulted in a small handful of Bevy plugins that were split across runtime/non-runtime crates, which feels annoying, but it's a compromise I was ok with.

Also, notably, the workspace crate dependency graph is definitely not flat. I did aim for as flat as possible, but I wanted to avoid rewriting too much. It's definitely MUCH better though.

Post Refactor Results

The above graph is a fresh rebuild after a cargo clean. Down from 1:10 to 45 seconds for a full release build from scratch. Since recording these compile times, even more has been split out of the "main" Exofactory crate, but I have since added features so it's less apples-to-apples.

The bigger win, though, comes when doing actual work on the game. It's rare that I ever touch more than one, or at worst a few crates at a time when working. This means that I get dev builds in a few seconds and release builds in a few more seconds.

A huge quality-of-life improvement. That and it lets me actually get work done on my much weaker laptop.

I'm not sure I went through this refactor in the most efficient way, or even in the way that produced the best possible results. If anyone sees anything dumb I did, please let me know. This all being said, I did meet my goals, these being:

Fast compile times
Minimal logic changes
Crate separation at the Bevy plugin level (mostly)

My Advice

Keeping the caveats above in mind, if I had to give advice to my earlier self (or others) I would narrow it down to:

Start with one crate and do everything there. No need for preemptive optimization.
Be 100%, fully, completely, no-joking-around strict about plugin isolation. No plugin should import anything from any other plugin ever.
All plugin imports should be from either that plugin, or non-plugin, independent structs that are independent of other plugins.

Doing these three points would have let me work on the game at the velocity I wanted while allowing me to refactor the game into a workspace at a later date without pain.

As for when to migrate from a single game crate to a workspace, I think the main thing is to not overthink it. When compiling and testing feels annoying it's time. You know it when you feel it.

Conclusion

Really cool to see the little Exoframes moving around in the game. For me, it was a "This is really cool" moment. I think the interplay between all of the Bevy ecosystem crates made it much easier than it had any right to be.

Really glad to be done with the refactor. I'll be coding, camping, and running a Bevy workshop at Bornhack so it's a good time to be able to work on the game from my laptop.

If we see each other there say hi!

Last off, once again, if you think you are interested in the game or just want to show your support for the game, wishlisting the game on Steam helps a ton.

Wishlist on Steam

A Really Big One: Exoframe Feel, Finished Belts, & Baseplates

Unknown — Wed, 03 Jun 2026 00:00:00 +0000

Overview

This was an inspired month and I think it shows.

A ton was added, from finishing up proper-looking spline-based belts, to a very nice building snapping implementation, to a new unique power system that I think Bevy uniquely enables, to a lot of additional "feel" that really enhances the emotional feel of the game. FYI, the belt section is more technical. If that isn't your thing, it might be worth skipping.

Additionally, there is more detail below, but I will be giving a talk and running a workshop at GPN24, so if you are interested take a look.

So without further ado here we go.

As always, if you find this post interesting, or if you are interested in the game, I would recommend wishlisting it on Steam. It helps a ton.

Wishlist on Steam

Fully Finished Spline Belts

Left: straight belt, center: slight 's' bend, right: 90 bend with complex curve.

After a lot of work, I can finally say I have a belt system that I am happy with. Pretty important in a factory game.

The best part of it is that the belt routing system behaves predictably, preferring 90-degree turns and straight runs, while at the same time being able to handle odd angles and tight placement. The belt router will even bend its own rules to ensure players can connect to buildings under almost any circumstances.

That and the belts looking nice is just icing on the cake.

Proper Geometry

I am very happy to have excellent-looking spline-based belts based on the original tile-based belts. It took a few shots, but it turns out I could not avoid the "correct" approach regardless of my efforts.

The first approach I took (as seen in the last blog post) was to just take a "slice" from the original tile-based belt and build geometry on it. Easy but looked really bad.

The next approach I took was an evolution on this whereby I would take multiple "slices" or profiles from the original at key points and loop them along the spline, constructing triangles along the spline to hook everything up. This was much better, and if you were at the RustWeek Bevy Workshop you saw these in action.

The issue here was that the textures would look okay in some circumstances, but were misaligned in other circumstances, particularly on longer sections of CubicHermite spline with changes along multiple axes.

The hopefully final, and likely "correct", approach was just extracting the triangles, baking them into a custom *.belt_geometry.ron type, and reconstructing the mesh along the spline manually.

We have the original good mesh from Blender, and we just adjust the whole thing, normals and all, to be consistent with the spline. The only downside is that sometimes the last repeated "segment" of belt can look squished. But at this point I am happy.

The cool thing is that since we have *.belt_geometry.ron, adding additional faster/better belts will be easier. I can ask an artist to just make a 1m segment of the new proposed belt and I should be able to rebake it.

I did something similar for the legs and feet of the belt, but used Avian3D raycasting to ensure all feet touch the ground even on uneven terrain.

Item Alignment

Items on the belt now follow the surface smoothly, even across compound curves.

Shorter one, but with the compound curves in the belt this just looks so elegant. (Or so I think at least.) After the belt stuff, this was easy: just keep the things on the belt tangent to the spline that defines the belt.

Belt Elevation

We can now change the belt elevation as we place them.

Lastly for belts, we can now adjust the belt elevation as we place them. Adding the UI was simple, but adding elevation rules was trickier than one might think. We can't just check for validity based on a downward ray cast. What if we are crossing a deep but short gap?

The solution I implemented boils down to IF all other conditions are met except for elevation_too_high, AND both ends of the belt are connected to an existing structure THEN we place the belt anyway. All legs that would be too long under the elevation_too_high rule are not generated

The in-game justification might be that the belt is supported by the connecting structures.

Building Alignment Snapping

Buildings can snap not just to themselves but to any input or output of any building.

This one is a cool quality-of-life change that really makes building organized and clean-looking factories possible.

Having played many 3D factory games I wanted to make it universal enough to handle things like snapping to inputs or outputs or both, or to enable snapping inputs to outputs and vice versa.

I think the goal was achieved pretty well.

While I did consider taking an Avian Raycasting approach, I went with an ECS approach where we query for input and output ports and just match against the potential building's input and output global x, y, and z locations + margin.

This lets us do clever things like prioritize "stronger" lineups and the like. I'm not doing anything that fancy yet, but I could foresee a world where you get your local snaps, but also snaps against 40 machines even if the nearest one is 200m away, just because 40 machines all in a line would be a meaningful signal.

All in all the building snapping system is what I would want in a factory game. That being said, once people start testing it, I suspect changes will have to be made.

Fully Working Baseplates

Placing a grid of baseplates all at once.

So far the game has involved placing factory machines on the ground. While on the perfectly flat ground of the small demo world this might be okay, as you scale your factory more organization becomes necessary.

The game now lets players place a grid of baseplates, grow the existing grid, or shrink it, all with snapping and the like working as one might expect.

What makes baseplates special in Exofactory is that they are not just "something to build on". They also act as power transmission for all buildings on top without the need for wires and manual hookup.

A grid of baseplates is also an independent power grid that hooks up to the "traditional" power grid via a number of substations that can be placed on the grid. Unlike traditional power grids, these substations can only transfer so much power to the baseplate grid. If you have only a few buildings you may get away with just one, but as more and more buildings are placed on the grid, more substations will have to be placed to keep up.

The temporary Power Relay and Power Substation assets.

This brings up my "clearly made by a backend dev" new assets. After finishing the classic Blender doughnut tutorial I set out to make temporary assets that would not actively detract or distract from the feel of the game. This is what I made. The Power Substation and the smaller Power Relay.

I do intend to replace these eventually, and I would rather work with someone who knows more about Blender than I do, but due to outside circumstances resources are tight.

The game must go on, so self-created assets are the way. (For now.)

Under the hood this is all ECS and Bevy-idiomatic code. When we place or delete a baseplate, we add components that define a Bevy relationship between that baseplate and a baseplate grid entity.

This way we can easily query for the set of relevant baseplates, even when there could potentially be tens of thousands or more.

Buildings placed on top of the baseplates in turn get a relationship with that baseplate grid.

The baseplate grid power UI shows the buildings powered by that grid.

For power calculations, we just query the relevant relationships. Fast and idiomatic. What I really like is that the power UI for a baseplate grid shows all of the building details, but if you look in the "main" grid you only see the power draw of the substations.

The main power grid UI only sees the substations feeding the baseplate grid.

I haven't added it yet, but I could imagine being able to name baseplate grids and for that name to show up in the main power grid stats. Something like Screw Factory 1: 18.5MW/30.0MW, and in order to see the fine details you would need to check the UI of the substations.

Major Game Feel Improvements

During RustWeek 2026 (strong recommendation by the way) I volunteered to help with the Bevy workshop. As part of that workshop I ended up giving an impromptu demonstration of the game.

As a result, I got a ton of feedback from new and experienced Bevy devs, and new and expert game devs. Really useful, informative stuff.

Mostly it broke down to the following:

Play around with BEING the little robot guy. The game should visually and auditorily signal this to players. You should feel a little connection to it.
The global mode needs to be more visually distinctive; a little dialogue in the beginning explaining it is not enough.
The transition between the two should be distinct and meaningful.
Add some signals as to what the player can do, even if it's "new speed record achieved" when you run on top of a belt.

There was much more, but these are some of the bigger things.

Entering global mode with the new transition effect.

For the global mode I worked quite hard on several fullscreen material shaders and a few easier add-ons. Now we have a very cool loading effect when you transition. The goal is to sort of show the digital nature of the mode.

I noticed something when I was playing Silksong that I implemented here. In Silksong, when you first load up the game or fight a boss for the first time in a while, you get the full boss fight start animation. When you are losing the fight and try over and over again, that intro animation is skipped.

I do something similar here. If you haven't switched in a while, you get the full transition effect. If you are switching frequently you get a MUCH shorter one. Out of game, this leads to less annoyance. In game, I imagine it's that the rendering is still cached.

Quite happy with it so far. But more is still to be done.

Entering the Exoframe with the full transition effect.

For the Exoframe (robot mode) we already had chromatic aberration, but I also added lens flare in the shape of the Exoframe lens, some camera grit, some lens focus animation, walk waddle, an Exoframe-specific HUD, and more distinct sounds.

We can walk around in the exoframe and the HUD shows some info. More to come for sure.

This all REALLY makes the Exoframe feel more connected. With the Silksong-style animation cooldown it's all upside and no downside.

When we switch between the global mode and entering an exoframe rapidly the effects are shorter.

Once again thanks everyone who gave feedback.

RustWeek 2026 & Upcoming GPN Presentation

All of the feedback above was given at RustWeek 2026, and despite some social exhaustion on my part, it was a ton of fun. I had the chance to work with the excellent Chris Biscardi and hash some things out on the glTF code I want to contribute to Bevy.

Hopefully we should see some fruit there soon.

If anyone asks me "Why did you choose Bevy? Isn't that a risk over Corpo-engine?" I would respond with, "Bevy is the only game engine I know of that has a culture wherein I can spot a problem, submit a patch and have it fixed upstream in under a month." It's the only engine where I, an indie dev, can submit an architectural change, have that change reviewed by the core team and submitted without a ritualistic dance.

Stepping back though, I do plan on being at GPN24 from June 4th through June 7th and will give a talk on writing games in Bevy in Rust and run a workshop. Details can be found at:

If you are interested, I encourage you to come.

Conclusion

RustWeek was a source of inspiration and drive, even as a relative introvert. Super happy with the progress I made and excited to contribute more to Bevy. Exciting month for sure.

And once again, if you found this enjoyable, informative, or just like the game, I would suggest giving the game a wishlist.

Wishlist on Steam

Technical Rework of Belts, and Global Planning Mode

Unknown — Sun, 03 May 2026 00:00:00 +0000

Overview

This month a few important developments were brought together.

The first of these is that "purpose" was, in a sense, introduced to the game. The October 2025 demo did receive some feedback around players not knowing what to do, even if they understood the game mechanically. This was valid and, to a point, expected. How does one self-actualize as an AI in a game, and how is that reflected mechanically? By adding the global planning mode, we address both, and there are details below.

The second of these was addressing the inherent tension between the tile/voxel based approach taken between the belts, the buildings, and the world. The strongest personification of this being "How do we build a factory on a smooth organic hillside if belts are tiles in a voxel-based space?" After avoiding the topic for too long, the answer, I suspect, is that we can't. Below is an overview of the new (not fully done) spline-based system.

As always, if you find this post interesting, or if you are interested in the game, I would recommend wishlisting it on Steam. It helps a ton.

Wishlist on Steam

Global Planning Mode

Placing buildings in Global View mode and building them in the Exoframe.

In Exofactory there is the spider web tech "tree" that you grow into based on how you play. But there is also a quality-of-life tree that is climbed as the player ascends the AI's hierarchy of needs.

Global planning mode is the first of those quality-of-life unlocks. It allows the player to place and plan factories in the unconstrained global view mode. Then, after entering an Exoframe, those plans can be quickly turned into real buildings and production chains.

The exact conditions of the "unlock" are a cool story moment that I think is worth experiencing unspoiled. I will say that maintaining access to global planning mode requires, among other things, a consistent 64/min of structural iron be available.

Excited to see people experience this.

Stranger 2.5D Belts in a Strange 3D Land

Back when Exofactory was a 2D prototype.

Exofactory has always had a sort of internal tension between the free-flowing organic world and the internal voxel-based grid system that belts, buildings, and basically everything use. To a degree, I think all factory games suffer from this tension, but with Exofactory, this really was a growing problem that needed to be addressed.

Thought Process

Exofactory initially started as a 2D prototype factory game based around the excellent bevy_ecs_tilemap. As time went on and the game went from 2D prototype to 3D game, a lot of the initial logic was preserved (and, at the time, effort saved) by moving to a voxel-based system.

This works quite well as long as the terrain is flat, or is voxel-based itself, Minecraft-style. The problem was that I didn't want the terrain to be flat or voxel-based.

When playing with even slightly not-flat terrain, things got really bad. In order to have everything fit in the voxel grid, buildings would either float in the air or sink into the ground.

I did consider a few options, namely shrinking the voxel height to be smaller so the effect would be less bad, only having a horizontal grid and no voxels with additional vertical checking code, having dynamic voxel splitting/joining, or a few other frankly worse ideas.

After some tests and reflection, ultimately I decided that any solution around voxels would just be a hack given the game direction.

Going forward, the voxel system will be gradually removed and replaced with more 3D-native approaches, namely Bevy splines, avian3d colliders, sensors, and the like.

Spline Belt Work

The first area where I did this was with the belts, namely because without spline belts, unless the buildings are exactly 1m offset vertically, or on mathematically flawless level ground, they would be impossible to connect.

I took a step-by-step piecewise approach to this.

Step 1 - Most Basic Spline Belt Possible

Simplest Spline Belt Possible

This is as simple of a spline belt as I could manage. The head of the spline is the first click, the tail is the second. As you move the focus point around, the spline tail snaps to the nearest grid point. I generated a few basic rectangles, then used Bevy's Mesh Builder to "extrude" the mesh along the spline.

At this point everything is just visual. Most of the work here was done around adding the boilerplate for a new building, etc.

Step 2 - Refine Belt Visuals & Geometry

The updated belt surface and profile with a clean bend.

Next up I refined the belt extrusion profiles to match the profile of the old tile-based belts and added some special belt head/tail logic so we don't just have square ends. I wanted to use the unmodified textures from the old belt, so matching the geometry was necessary.

Being better with FreeCAD than I am with Blender, I actually opened the old belt glb file in FreeCAD, took a cross section, and used the FreeCAD measurement tools to get the dimensions.

I modified the old shader I used with the old belts to get the belt surface working correctly and began work on the belt rail texture. I need a bit of clarification on the belt rail texture, so that is yet to be done. For now we have default gray rails.

The geometry is where it gets interesting. I wanted the default Exofactory belt to be one that looks clean when you place a lot of them together. Visual satisfaction is the goal. The case I tested against is that if you have 12 belts placed on a platform above the ground, you should be able to extend them through a 90-degree turn while descending in a clean way. They should all line up next to each other in a predictable pattern with no clipping. Happy with what I have here.

Technically speaking, horizontally, the belt is a cardinal X/Z route with a clamped Hermite quarter-turn and a minimum bend radius. Vertically, it is a smoothstep ramp layered on after route construction.

The final meshes are produced by sweeping a 2D cross-section along the spline through the 2D profiles.

At this point the belt is looking a lot better but is still just visual.

Step 3 - Making the Belt Do Belting

A working belt carrying ore along a complex path.

Here major work was done. The good news is that I could reuse many of the components (with their corresponding logic) that were used by the old tile belt chain system.

Ironically enough, this was a VAST simplification. No longer do I have to worry about placing chains of belts, splitting or merging chains, updating the motion spline of items across many chains, or keeping those motion splines in sync with the underlying (rather complicated and full of relationships) chain component mappings.

Now each Belt has a single authoritative spline that everything is deterministically driven from, including item motion across the belt. Between that and a few other basic spline belt components, things are much easier to maintain and debug.

I did need to do some refactoring around building inputs and outputs, which had used voxel-based logic to check for valid connections. While in buildings, they still use voxel logic to determine where input and output ports are and how they should be oriented, actual connections are checked via a combination of avian sensors and component checking. Once the connection code marks a valid connection, we build a relationship that makes placing and removing things from the belts performant and ergonomically simple from a coding perspective.

Belt cost went through a minor rework. Instead of costing one iron per belt tile, belts cost 1 iron per meter rounded up. Same with checking belt capacity, but rounded down.

After adding a few things like maximum allowed belt build length and maximum belt grade, we have a working replacement for the old tile-based belts.

Removing the old belt tile system was very satisfying, to say the least, after this.

Work to Be Done

The spline-based belt system is working, but it isn't fully done yet. At least I want to:

Use the actual texture for the belt rails. Simple in theory, but annoying to do cleanly.
Add belt supports. Right now the belts just float. I suspect this won't be toooo bad. I just need to do a bit of design work.

Conclusion

Really happy with finally addressing the internal 2.5D/3D tension of the game. I have been stalling on fixing it for too long.

Also super happy to have my first cool in-game story element fully coded out. Feels weird to not give all the details.

Regardless, not a bad month. And once again, if you found this enjoyable, informative, or just like the game, I would suggest giving the game a wishlist.

Wishlist on Steam

Building Animation, Trailer, & Pitch Deck Stuff

Unknown — Mon, 06 Apr 2026 00:00:00 +0000

Overview

The past month has been a mix of a little technical work and a lot of pitch deck work, planning, and legal compliance. I am not in a place where too much can be said yet, but work is being done here.

So while I have less to show than usual, a lot of underlying work has been done. I do have two cool things to show off though. This month I added a new building animation when placing buildings, and put together a new more gameplay focused trailer.

If you are interested in the game I would encourage you to consider wishlisting it on Steam.

Wishlist on Steam

New Building Animation

The fabricator being spawned in.

I really wanted to have a "building" animation that reflected the digital nature of the AI you play as. I had considered a few things including pixelation, "spawning from the void", and a matrix inspired approach. Ultimately, I went with something partially inspired from the Revelation Space sci-fi series, particularly my interpretation of how the "Inhibitors" (spoiler warning) might have looked. That mixed with some of the skin shader logic I have been playing around with led me to an effect that I think is quite cool, and uniquely Exofactory.

Larger buildings take longer to spawn and smaller ones take less time. It ends up being a pretty elegant shader/loading system.

Short belt segments have no spawning animation, long do.

The effect scales really well to belts too. Pretty happy with it. The good news is that shorter belt segments do not need any loading animation, so worry not.

Trailer

As part of the pitch deck work, my partner helped me put together a new faster paced trailer that shows off gameplay and highlights the narrative elements in a more clear way. Much better I think, and definitely needed for the pitch deck.

Publishing & Resource Management

Most of the past month was dedicated to working on what I will call "pitch deck stuff". Definitely not an area of my specialty, but I think I now have something that reflects Exofactory in a fair way.

Also I have started a bit of work around legal compliance. Not too exciting, but a necessity, particularly in Germany. Hopefully soon we should have a small GmbH that will become the indie studio.

Conclusion

Not too much to be said in terms of technical advancement beyond the cool shader, but a lot of important background work is now in motion.

Optimizations, PRs, Tooling, & Funds

Unknown — Thu, 05 Mar 2026 00:00:00 +0000

Overview

The past month has been full of a diverse set of work. From major optimizations, to a few issues found in those efforts, to new tooling, to the official start of work in looking for a partner publisher / investor a ton of programming and non-programming work has been done.

If you find this interesting and find the game interesting I would encourage you to give the game a wishlist on steam. It helps a ton.

Optimizations

The main technical area of focus this month was around optimization. Over the past year a combination "don't preemptively optimize mindset" mixed with a (un?)healthy dose of me missing Bevy domain knowledge, mixed in with a few genuine bevy bugs has resulted in an extremely unoptimized game when it came to memory usage.

Looking at the last pre-optimization build of the game we were looking at 7GB of system memory with just about the same amount of VRAM usage. (hint here) Given the complexity of Exofactory I knew the game would never be one of those 200MB runtime games, but this was atrocious, and frankly embarrassing. It was to the point where I could hardly run --release builds on my (admittedly old) 11th Gen Intel Framework.

Given this situation I set out to learn tracy and how it works in bevy, and to take the time to actually clean things up.

Long story short I somewhat know how to use tracy even though I would describe myself as a total beginner. But I also fixed the issue, the process basically boiled down to these 4 areas:

Storing Everything in System Memory

By default when you do a asset_server.load("my_thing.png") the asset is loaded into system ram and when spawned it is loaded into VRAM. With a smaller image this isn't too bad, but when you load a complicated .glb/.gltf file things can get heavy fast. If you have a GLB with 6 RGBA 4096x4096 textures in it. (i.e. norm, metallic, roughness, etc) that would use ~384MB of system memory. With mipmaps make that ~512MB per GLB asset. This alone was responsible for the GREAT MAJORITY of the crazy amount of RAM Exofactory was using.

The good news is that you don't have to store this all in system memory. In Bevy you can store things in MainWorld or in RenderWorld or both. MainWorld is the the game as you might think of it. Just everything all in system memory. RenderWorld on the other hand is a sort of tag that marks things such as to only live on the GPU.

I could reduce system memory usage by simply not storing textures outside of the GPU when I don't intend to do anything with them.

Bevy has several ways to do this, but the simplest for me was to use .meta files.

In Bevy, .meta files sit alongside your assets and let you override how the asset loader handles them. They use Bevy's RON-like format and are named after the asset file they configure. So for fabricator_01_icon.ktx2 you would have a fabricator_01_icon.ktx2.meta file right next to it.

For a simple image asset the meta file looks like this:

(
    meta_format_version: "1.0",
    asset: Load(
        loader: "bevy_image::image_loader::ImageLoader",
        settings: (
            format: FromExtension,
            is_srgb: true,
            sampler: Default,
            asset_usage: RenderAssetUsages("RENDER_WORLD"),
        ),
    ),
)

The key line is asset_usage: RenderAssetUsages("RENDER_WORLD"). This tells Bevy to only keep the texture on the GPU, freeing up the system memory copy entirely.

For GLB files we can get more granular. Here is an example from one of the belt building models:

(
    meta_format_version: "1.0",
    asset: Load(
        loader: "bevy_gltf::loader::GltfLoader",
        settings: (
            load_meshes: RenderAssetUsages("MAIN_WORLD | RENDER_WORLD"),
            load_materials: RenderAssetUsages("RENDER_WORLD"),
            load_cameras: true,
            load_lights: true,
            load_animations: true,
            include_source: false,
            default_sampler: None,
            override_sampler: false,
            convert_coordinates: None,
        ),
    ),
)

Notice that load_meshes keeps both MAIN_WORLD | RENDER_WORLD. This is because I need mesh data in system memory for things like collision detection and raycasting. But load_materials (which includes the textures) is set to only RENDER_WORLD. This gives us the best of both worlds. Meshes stay accessible in system memory where we need them, while the textures that make up the bulk of the memory usage only live on the GPU.

The nice thing about meta files is that they don't require any code changes. You just drop them next to your assets and the loader picks them up automatically. One small fish script later and I was done.

Using non GPU native bitmap formats

The meta file changes above helped with system memory, but VRAM was still a problem. Exofactory was using PNG for standalone textures and embedded PNGs inside GLB files which was the root cause of the high VRAM usage.

Moving to KTX2 for textures was the solution. It's a container format from Khronos that can hold many GPU native compressed formats. Of the formats available I considered UASTC and ETC1S because of native Bevy support. They have different tradeoffs:

	UASTC	ETC1S
Quality	Near lossless	Lossy, lower quality
VRAM Usage	~1 byte/pixel	~0.5 bytes/pixel
Disk Size	Larger (with Zstd)	Much smaller
Transcode Speed	Fast	Very fast
Best For	Normal maps, UI elements, detailed textures	Textures where quality is less critical

For Exofactory I went with UASTC across the board mostly out of laziness. I should really be using ETC1S for textures where a lower quality would not be noticeable and the VRAM savings would be nice. That's a TODO for later.

Finding a bug in Bevy around KTX2

In moving to KTX2 files one of the bugs I noticed is that Bevy was not honoring the .meta files for ktx2 files. One small PR later and it was fixed. This fix will be included in Bevy 0.18.1

Using KTX2 properly in GLB files

A larger more serious problem I found is that Bevy does not properly support KTX2 textures in GLTF/GLB files. While you can just hack the ktx texture into the file and it will work in Bevy the problem is that the resulting file is not a compliant GLTF/GLB file.

The root cause of this problem is that Bevy is using gltf-rs as part of its GLB/GLTF pipeline. While the library is robust when it comes strictly to the official GLTF 2.0 spec. It is deeply deficient in those defacto mandatory extensions including ktx2 I have submitted a PR but the last code change was in November 2025 and I am not hopeful.

For now Exofactory is using my fork of the library, but a longer term solution needs to be found.

I am currently working on a document with a few ideas to be pitched to the Bevy core team based on a their request.

Results

After implementing improvements in the above 4 areas the game is massively more optimized. The game went from 7GB of system ram to under 1GB. From 7GB of VRAM to under 2GB. My old laptop now gets 60fps on low which makes mobile development possible again. It was a big push but totally worth it.

Tooling

As a small side project I worked on BevyDex.dev this month. It's basically a thin wrapper around the crates.io api and a postgres database.

But it's always up to date, shows important details and is lightning fast(tm).

It's a side project unrelated to Exofactory. But it was made so I could sort through the ecosystem and I hope others find it useful too.

Funds

Last but not least, Exofactory will soon officially be reaching out to several publishers. With recent personal events, while I can code, I can not finance the whole game on my own. Hopefully some interesting news comes out of that area soon. If you have any advice here I would be glad to hear it.

Conclusion

I like programming more than I like working on pitch decks. I prefer fixing bugs upstream when I can. And I am happy to put out things I think may be useful.

Multiplayer, Bevy 0.18, and Fosdem

Unknown — Wed, 04 Feb 2026 00:00:00 +0000

Overview

This month was basically solely focused on adding multiplayer functionality with a small break for a bevy 0.18 migration.

If you find this interesting and find the game interesting I would encourage you to give the game a wishlist on steam. It helps a ton.

I will say that I regret not starting the multiplayer code earlier. Like internationalization, and saving, multiplayer is something that should be architected for from the beginning. The good news is that the code was clean enough that it wasn't too hard to refactor.

In other news migrating from 0.17 to 0.18 was pretty painless. I had to drop a few more less maintained crates, but the core migration itself was simple.

Lastly, I took the time to head out to Fosdem to hang out with the Bevy community. While I didn't give a talk Thierry Berger gave an excellent one on mobile bevy game development.

Multiplayer

The game supports simultaneous Direct Connect, LAN, and Steam multiplayer hosting and joining.

For people writing games in Bevy I had been giving the advice to consider your internationalization, gamepad, and save stories early. I now regret that I missed likely the most important factor to consider early this being multiplayer and netcode.

So with that my updated list of things to consider early are your:

Multiplayer / Netcode Story
Gamepad Story
Save Story
Internationalization Story

Adding these later will be annoying and painful. (Ask me how I know! /s)

Exofactory Specifics

Exofactory is a Factory game where the player plays as an AI who interacts with the world via little robots called "Exoframes" that must be built by the player. While not occupying an Exoframe the player can zip around their factories in the global camera mode.

This leads to a sort of natural co-optative approach where players can join the game in the global mode where they can look around, and can configure existing machines. Once there is an Exoframe that is not being occupied the new player can "inhabit" it building and exploring the world beyond the factory sensor range.

This leads to a nice sort of multiplayer metaplot while at the same time providing a clear technical story about what must be done in the netcode these being:

Interact with the world in Global mode including building interaction.
Selecting and controlling one of a Pool of Exoframes.
Running the rest of the world to update the relevant components.
Ensuring the client sees the world in an accurate way.

Personally, I think this naturally leads to a server authoritative model. The server instance of the game runs the world, and the client instances just participate in it.

Picking a Library

At the time on Bevy 0.18 there seem to be two well supported crates these being bevy_replicon and lightyear

I encourage you to take a look at both as both have their unique advantages. In my (potentially flawed) understanding, lightyear adds more features like client side prediction, deterministic replication and interest management (only syncing relevant data), at the expense of initial overhead and complexity, while replicon omits these features by default, but is simpler to setup with less dev time overhead. If my understanding is wrong here I would be happy to correct this if anyone reaches out.

Edit: Someone did reach out! Turns out bevy_replicon does support deterministic replication and interest management. The features it lacks compared to lightyear are client->server replication, lag compensation, client-side prediction, and interpolation. Also lightyear is planning to re-use replicon for replication.

For Exofactory, given that the game is definitively NOT a twitchy shooter, and my planned pace of feature development, and my relative newness to game dev net code I decided to go with the simpler to set up replicon.

This all being said, I suspect that if your game architecture is already well structured switching later would not be a painful process.

From Single Player to Multi

At the heart of it replicon does two things. Replicate components, and handle network events/messages to/from clients.

In order to enable multiplayer I had to refactor several systems and logically group them.

Authoritative Core Systems

These only run on the server instance and update the world (all the components that store game state) for everything not directly manipulated by the player.

This includes things like the machine cycle that turns iron ore into iron ingots, what sounds should be played, and even the rate of mining that any exoframe is doing while the player watches. There are many many more systems but these are the type that run in the group.

These systems are allowed to write to components directly. Replicon automatically replicates these changes to the client instance of the components.

Player UI Systems

These run only on game instances where a player plays. These play the sound, show the building UIs, and let the player know the state of the world. These systems read the state of the world by reading the local components that are kept in sync automatically.

The part that required major refactor work is that in these systems no direct manipulation of components is allowed. The clients must send an event/message to the server which then manipulates the components on behalf of the client and updates the components which are replicated to the client.

Network Messages & Events

In the above diagram I only included one example, but in reality basically everything you do in the game beyond "looking at stuff" happens via event or message. This includes the player on the server instance of the game.

This I would say is the MOST important factor to consider when working on a bevy game that might eventually support multiplayer. If I had done this from the beginning adding the multiplayer functionality would have been easy. Even if you don't want to think about networking at the beginning, just ensuring all player manipulations of the world go through the native bevy event systems or message systems will save you time later.

Ramifications & Outcomes

There were two sorts of artifacts that came out of this. The first one, was something that I was planning on working on later, but due to said refactoring became much easier. That being a headless server instance that the player can self host in docker/podman etc. This would allow the factory to continuously run without anyone needing to keep the game running on their PC.

With the refactoring and a new feature based build of the game that uses MinimalPlugins instead of DefaultPlugins we get a clean lean headless server instance of the game that can run basically anywhere including most RISC-V SBCs!

This still needs testing but things are looking good. Above is a similar diagram but for the headless version of the game.

The second interesting outcome is that I am using way fewer Bevy resources namely because Replicon does not replicate resources. Resultingly I am using way more pseudo-singletons (aka an "empty" entity that just has the component that holds the data the resource used to.)

I am not a huge fan of object oriented design patterns, so it's a bit funny and feels a bit dirty.

Bevy 0.18 Migration

I have seen the light! For real though any Bevy game that has light should prioritize migrating. Major work has been done and the game looks notably better. This being said, even if your game does not use light you should still prioritize migrating.

Overall beyond a few shader bind group things (i.e. BindGroupLayout -> BindGroupLayoutDescriptor) and Atmosphere changes it was a simple migration.

Glad to see the release schedule back on track.

I will say though, with each upgrade I see more and more plugins falling by the wayside. This makes me appreciate the maintainers of plugins even more. Keeping up with Bevy's release schedule is a major task compared to any other game engine.

Fosdem!

Speaking of, I had the privilege to attend Fosdem a libre get together that is hosted in Brussels every year.

If you are interested in open source game engines, or in reality open source anything at all I would highly recommend going. There are a ton of fun and interesting talks, but the best part (in my book anyways) is being able to meet and see and hang out with the people whom you normally only talk to online. I know the Bevy dinner with Thierry Berger, Gee, Niklas Eicker, Firestar99 and several other charming individuals was very fun.

Conclusion

I thought I could get multiplayer done in a week, but it took a month as somehow expected. I am a better game dev for the experience. You can't just depend on back end patterns for everything.

Bevy 0.18 was simple to migrate to.

I strongly recommend going to Fosdem if you have the chance.

Real Time Settings, Save Overhaul, & a Wiki

Unknown — Tue, 30 Dec 2025 00:00:00 +0000

Overview

Happy holidays! This month a good amount got done bringing yet more quality of life changes to the game. Namely an overhaul of the saving system, logging, crash reporting, and live settings! Those along with a new but empty wiki.

I am quite proud of the live settings stuff. Like it's not anything I've seen elsewhere. If you find this interesting and find the game interesting I would encourage you to give the game a wishlist on steam. It helps a ton.

Also, I recently took the public demo down from Steam. At this point it REALLY does not reflect the quality and polish of the current state of the game. I eventually plan on putting up a "Demo 2" build on steam the reflects the work that will happen in the next upcoming months.

So without further ado here are the latest areas of work.

Save Overhaul

We can now continue the last game or load a specific save file.

The most demotivating thing that can happen in a factory game is that you get a ton of work done, then lose the progress. I had a few players experience this and I wanted to come up with a solid approach that works. I ended up keeping things simple and used a looping timer to automatically save the game every 5 minutes with a looping set of 5 saves each new save overwriting the last. This was pretty trivial to do with just a Bevy timer and a a baby state machine.

This auto saves the game while allowing for manual saves when needed.

Additionally the player can continue the most recent save OR manually pick an existing save. For now the load screen is just a minimal Bevy UI window. Lot safer to play for not too much effort in coding.

Right now the default is 5 saves each 5 min apart, but if you edit the config.toml file you can change that.

Crash Reporting & Logging Rework

The top feature I wanted as a developer was proper logging and crash reporting in production builds. While I have been trying my best to keep things clean, an area where I had neglected things was logging. I was using a mixture of print! println! eprint! eprintln! info! warn! error! all over the place. Debug prints became permanent output.

On the windows build you couldn't see half of it even if you launched the game from powershell. I took a three step approach to fixing this.

Drop all the stdout/err stuff except for info! warn! error! and panic!. Migrating one plugin at a time.
Added a non-blocking tracing capture system that appends the output to a log file.
Wrote logic around the log file. If there was no clean exit the user is given the option to automatically upload the logs as part of a crash report.

After detecting a crash we can upload logs.

The player now has logs the can check if they are so inclined, and the player can automatically upload those logs as part a crash report. I am sure legacy game engines have this sort of thing built in, but I am just happy to have it now. No more "what were you doing just before the game crashed?" discussions.

Lastly added a small library that shows panics in the GUI. Worst, worst case a player could copy paste the output.

Settings Overhaul

You can change graphics settings in real time.

This is the stuff I am super happy with. Before the most recent (internal) build you could not access the settings in the game, and changing and settings required a game restart. Not good.

I blame my backend programming history for that one. After hearing from players that the state of settings was not really acceptable I set off on overhauling it.

I took an ECS/Bevy centric approach and think it went well.

The way that settings work now is that settings are serialized/deserialized to/from the config.toml file and is represented in game as a series of Resource structs.

I added a few systems that run when those structs are created or change and update the components that reflect the setting that was changed.

For example let's consider changing ScreenSpaceAmbientOcclusion settings in the game.

In a ECS world this is easy. We find the global camera entity by getting entities with the Exofactory GlobalCamera component. Since the camera is just a bundle of components we can grab the ScreenSpaceAmbientOcclusion component as well and modify it in real time keeping it in sync with the graphics setting resource.

The same can be applied to any setting.

All settings are just properties in a resource struct that are mirrored onto specific components.

The result is that the player can edit any setting at and time in real time including language, graphics, window size/mode, along with everything else.

Language and everything else too.

Pretty cool in my book.

Wiki

The idea behind the wiki is to provide a community oriented wiki that is performant, available, and not exploitive. Unless anyone has a better approach, I aim to have the wiki licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

While I agree that it is a bit early to set up the wiki I wanted to do so because of:

A genuine need for documentation around the config.toml file.
A desire to short circuit any wikis being built on less community oriented platforms.

There isn't too much to be said except that as the game gets closer to launch the wiki will become even more useful.

For now account creation is closed, but will be open later as things become more playable. This all being said if anyone is a mediawiki theme specialist do reach out. The default theme is ok, but not exactly ideal.

Conclusion

ECS once again shows how cool it is. Going from reboot for every setting change to all changes being applied live was shockingly easier than I expected.

That and the save system WITH crash reporting is a really nice to have.

Quite happy and I am excited to get working properly on the much better demo 2.

Draggable Belts, Electricity, & View Modes

Unknown — Thu, 04 Dec 2025 00:00:00 +0000

Overview

This month focused on a few new areas these being major game mechanics, visuals, and major quality of life belt placement changes.

We are getting closer to implementing all of the October Nextfest feedback that can be fixed via pure programming and I think the game shows that.

I am super happy to add electricity. It's a core feature and while adding it wasn't too hard the visualizations was harder. But I think the shader based approach looks really cool. Super happy with the productivity/efficiency view mode shader below.

I will get a bit deeper in the relevant sections.

Draggable Belts

Dragging belts to connect buildings is now easy.

A good amount of time was spent on adding draggable belts. While Factorio belt-by-belt placement works, in playing the game I realized it gets old fast. The feedback I got was universally in agreement.

The interesting thing is that Exofactory uses a "tile" based belt approach so the spline based approach of other factory games wasn't really possible. After ~~playing a bunch of other factory games~~ doing a bunch of research I found that I could use an approach similar to Shapez2 adapted for 3d and the peculiarities of Exofactory.

Long story short you place the first belt segment and can drag out a straight or "L" shaped segment of belts of any length that you have the resources for. The only real technical limitation is that you can only have 1 bend per dragged out segment. Adding any more just adds ambiguity and unpredictable results.

Longer belt connections take way less work now.

This makes the game way less tedious to play and I am super glad to have it coded out.

Electricity

Building automatically connect to the nearest power source in range.

I also added power recently to the game. All buildings now consume electricity and don't function without it. Building in the range of a power source or extender will automatically connect and start consuming power.

Right now the Core generates enough power to build a little factory. Once I add fuels and piping properly it will be possible to really get the power cranked up.

From a coding perspective this was quite an easy feature to add. Just add some ECS components and you are good to go, buildings update their components as they cycle and power systems query for them accordingly.

The hard part was visualization. I'll cover that below.

View Modes

One piece of feedback I got was "What's the point of the global mode?" and to be fair in the demo the global view mode is less useful than it should be. The primary reason being that the view mode features were not there.

I am happy to show them off now. Good god did I have to learn a lot about shaders, stencils and skinning to get things to work.

The view modes can be accessed in the global mode with the tab button or relevant controller button.

Power

You can see the powered zones, and which buildings and wires are powered or not.

This view mode lets you see what buildings are powered or not. It also let's you see the powered zones and what wires are connected. Simple, fast and useful.

While the view modes are a feature for the global mode, when you place power extenders you can see the powered zones and the like, just for sanity preservation reasons.

Productivity

The color of the buildings shows their productivity. Green for 100%, Red for 0%.

I am quite proud of this and I think it brings something new to the factory game space. The productivity mode shows you at a glance the productivity of a whole landscape of machines. Red or yellow sections of a factory stand out clearly.

In the above video you can see the productivity level drop as the output buffer fills up. Like the power view mode this mode can be accessed via the tab key in global mode.

Conclusion

It felt really nice to finally add a new feature after so many bug fixes. Super happy with that. Now I just need to change the emotional core/dialogue system to reflect these new systems. Lots of fun and lots to do.

Real Factory Game Quality of Life Changes

Unknown — Sun, 16 Nov 2025 00:00:00 +0000

Overview

There were two driving forces when it came to the work done over the past month: feedback from the demo release and the porting from Bevy 0.16 to 0.17 as well as the switch to the Avian physics engine.

I will go over a bunch of the new quality-of-life features resulting from the feedback below, but first I want to cover why I decided to switch to Avian and the work that came with that.

Switching to Avian

Autogenerated Avian Collider Meshes

I had initially been using the venerable Rapier3D for physics but was unsatisfied for a few reasons.

High development latency. Given the rapid changes in the Bevy ecosystem and major improvements in each version of Bevy, this was a motivational killer. At the time of this blog post Rapier still does not support Bevy 0.17.
Non Ergonomic APIs.
No collider generation.

This all being said, Rapier is a solid physics engine and the work that dimforge does for the Bevy community is amazing. They are just not the best fit for me.

Switching to Avian addressed all of these issues and made things like raycasting a breeze compared to what I was doing.

That, and the amazing collider constructor system, sealed the deal. <3 ConvexDecompositionWithConfig

I did run into one snafu though: Avian does not have a native character controller like Rapier does. This being said, after reading the Avian FAQs, I settled on using bevy_tnua, an excellent replacement.

Time-wise the whole port took a day. Approximately:

2 hours for all the colliders and tuning the parameters.
3 hours to replace all the ray casting and to set up collision layers. (With enums, very pleasant to do.)
3 hours to rewire all the player controls through tnua.

Thanks to all the work done by Joona Aalto on Avian. I am super happy to sponsor him and if you like Avian you should consider it too.

General Quality of Life

We can now jump!

Given that the newly implemented tnua made it easy to add a jump, I opted to do so. With a little repurposing of an animation that will be fully revealed later, it was a snap.

Instead of the broken tool tips we now have the build costs shown in the build menu.

Here is where the first bit of feedback-based improvement comes in. It was made very clear that it is important that the cost of things should be made more explicit and clear, before, during, and when you can't build buildings. Now when you hover over or select a building in the build menu the cost is evident.

We now see the costs and the available stock when we go to place buildings.

Machine Productivity

The mining machine now shows us ideal and real outputs.

This is where most of the work went. Based on the feedback of factory game enthusiasts, I was made painfully and embarrassingly aware that I had completely forgotten a major element of the genre: that players should have a clear understanding of what is being consumed, produced, and where optimizations can happen in their factories.

Like, I play and enjoy Satisfactory and Factorio. I don't know how I missed this. That being said, it's there now.

I will say this was a pleasure to program with Bevy's ECS system. I don't think there is a better way to track and do the math than ECS. We can just query for machines whose statistics we should update in a system, process them in parallel, and move on with life. Beautiful.

The furnace shows what we actually need to input and what we are and should be outputting.

Settings

I will say part of why I was itching for Bevy 0.17 was due to the new/reworked UI using observers. This let me step away from the buttons for all settings setup and let me use sliders. Much cleaner. Using observers makes writing UIs less painful. With the latest release, the settings page is much better.

A major quality-of-life improvement I made was regarding the controller guide. Before, it would show keyboard and mouse controls unless you had an Xbox or Steam controller plugged in. This led to a few situations where players were not being shown the correct controls. That is now fixed. By default, the control guide shows what was used last. Yay!

Site Fancification

In progress, but part of the feedback I got was that the site simply didn't let people know anything about the game at all. In fairness, a plain text only site isn't the norm for video game sites. As part of ongoing efforts to make the site more informative, we now have an animated homepage.

I will be continuing to work on fleshing out the rest of the site with rich media over the next few weeks, so keep an eye out.

Conclusion

Lots of quality-of-life improvements based on lots of feedback, with lots more to come. Pretty happy with this. Going forward I am looking forward to adding new features.

Steam Next Fest Reflections

Unknown — Tue, 21 Oct 2025 00:00:00 +0000

Overview

Steam Next Fest was a success, although quite stressful. The good news is that I got a ton of feedback from players on Steam, Discord, and elsewhere, and a lot of edge case bugs were fixed.

I never knew that so many keyboards report to the operating system that they are Xbox-branded human interface devices. Crazy.

Based on all that I learned, I think I can solidify the timeline for the game going forward.

Next Fest Results

More Good Things

A ton of bugs were found and quickly fixed. Thank you very much to those who reported them.
A ton of interest was shown in the game, both in terms of wishlists and playtime.
Many ideas on how to fix and improve things were given.

Less Good Things

I didn’t foresee the diversity of hardware that exists in the real world outside of the soft-launched testers. Some players simply could not launch the game until several hot patches were released.
I thought the game was fully accessible for those who use accessibility devices and controllers, but from the feedback, I missed a few things.

Updated Timeline

Given the feedback from the demo and the very helpful advice from more experienced developers, along with guidance from people knowledgeable in producing successful games, I think it makes sense to adjust the timeline for the release of the game.

The Q4 2025 date was just unrealistic. Flat out.

Given this, a new plan is needed.

After consideration and reflection on what is best for the game, the plan is this:

Release a much more feature-rich and polished demo that can be used in a pitch deck and shows the quality we are aiming for in the game.
Consider options on how to fund the game further, whether that be Kickstarter, investment, or working with a publisher.
Aim to release the full game in late 2026.

As someone once said: "A delayed game is eventually good, but a rushed game is forever bad."

Meme or not, I do want to release a game I am proud of.

Conclusion

I am always learning and improving the game and my understanding of the video game industry. Next Fest, and those people who reached out to me, taught me a ton, and the game will be better for it. Exciting times ahead. I now have a ton of feedback to act on.

Demo Release and Polish

Unknown — Tue, 07 Oct 2025 00:00:00 +0000

Overview

A LOT happened over the past month, but the biggest thing is that the demo has been soft launched on Steam in anticipation of Steam Next Fest. If you want you can download it at the link at the end of this post. Linux and Windows versions are both available.

The amount of work that has gone into this has been a lot, and we cover a good amount of it here.

Steam Next Fest

Nice little Demo download button.

Big news is that we are officially participating in Steam Next Fest October. We finally have everything in place and approved. This was a shockingly difficult process and was more complicated than I thought. Turns out that you can't simply upload an ELF/.exe file to Steam and have them distribute it. You have to use quite a bit of Steam-specific tooling. Which to Valve's credit does run natively on Linux. It's just a lot to learn and process, particularly when you gave yourself a day to do all the packaging and uploading to Steam.

I will say a major piece of advice I have for programmers turned game devs would be to give more time to packaging than you think you might need. For me, packaging a game for Steam was more difficult than preparing an RPM or DEB distributable.

The good news was, in the end, the game made the deadline, but with intense timing difficulties.

Testing Mistakes Made

This leads to the next major point. If you signed up for alpha/beta testing you were not forgotten or passed over. Due to:

The unexpected (by me) delays in Steam approving the game.
The unexpected (by me) difficulties in packaging the game.
The sheer number of "breaking" bugs that I was crunch fixing found by friends and family.

I was not able to upload and get early testing keys before the Demo had to be soft launched for Next Fest.

My apologies. My plan going forward is to structure the game development process in a more streamlined way with dedicated feature, testing, and polishing time windows. So for the main game itself, we should have more structured testing periods.

Animations & Mechanics

Lifters, Belts, Splitters, and Mergers

This is where most of the crunch time was dedicated. I will say a disadvantage of ECS is that syncing independent animations is a bit harder. It feels like the world animations run on some Leibniz-style pre-established harmony. No linking or hierarchy to speak of. Just async systems running in such a way to give that illusion.

Long story short, the game now behaves like a game should, animations, sound, and all.

Demo Released + Trailer

Here is the fun part. While no emails have been sent yet, the demo can be downloaded and played. I may be able to squeeze one more bug fix build in before Next Fest officially starts, so if you see any bugs you can report them in the Exofactory Bug Report Discord Channel.

We also have a small gameplay trailer! In the interests of bandwidth and new YouTube accounts not being allowed to upload videos until they are verified, it can be watched on the Steam page.

Roadmap

The demo is just the start. The full game continues on with major improvements incoming. Among these are the following. This being said, I am open to player recommendations. You can provide them at the feature suggestion channel in Discord.

I will be providing a more detailed roadmap on this site soon. These lists are preliminary and VERY VERY incomplete.

Coming Sooner

Accessibility Prioritized Steam Deck and Controller Support

Full accessibility prioritized Steam Deck and controller support.
Terrain and foliage asset rework.
Massive optimization overhaul.
The first diverging branches of technology unlocks in the tech web based on your in-game choices.
A public wiki like a proper factory game should have.
Continuing work on the "real" terrain.
Real power use.
Liquids.
German.
Test ELF binaries for aarch64 and RISC-V if possible.

Coming Later

Game binaries for more Rust Tier 1 and 2 targets. (Anyone want to help test on the BSDs?)
Steam-free way to play the game Factorio style.
Officially supported Flathub / Flatpak images.
Continuing work on the "real" terrain.

Conclusion

The demo is out and I look forward to working on the full game. I am looking forward to seeing what people make.

Demo on Steam

Private Alpha, Steam, & Core Functionality

Unknown — Mon, 08 Sep 2025 00:00:00 +0000

Overview

Over the past 30 days the game went from "a bit worried" to "back on track" for release. I am happy to say we plan on participating in Steam Next Fest October! (more details below) A lot of the work was done on pure fundamental elements of the game from a coding perspective. So while the visuals haven't changed too much the code is now in a great state. Next month the demo should be full of new visuals and and also new sounds! The month of September will be focused on visuals, polish, and testing. Exciting times!

Private Alpha

I am aiming on releasing a small focused private alpha version of the game for player testing in the second half of this month. If you are interested you can sign up to test on the homepage. You should see a button where you can sign up there.

Just be aware, this will be a true technical alpha and may be full of bugs, UI, UX, and playability issues. If you are looking to play the game I would recommend waiting for Steam Next Fest. If you are interested in debugging and pointing out issues I welcome you to join.

Steam Next Fest

We plan on, and are on schedule for, participating in Steam Next Fest October next month. We were approved and just need to make sure that we have our final release build submitted before the end of September.

The plan is to release a free vertical slice demo of the game that people can play. The goal is to let people build out a factory how they like and to see how the story changes based on that factory. I am aiming for a short small demo, but depending on how and where you build your factory the tone, feel, and direction should be different. Unless you are scripting, every playthrough should be a little different at the least or very different depending on how you build.

This is all managed by the emotional core and it's pretty cool.

Just to set expectations though, this will be a shorter demo at about ~10-15 min if you play fast. The full game will be developed with the community via Early Access, with a full release sometime in 2026.

Belt Fundamentals & Logistics

The majority of the work on the development side was focused in this area. You simply can not have a factory game without a robust and performant belt and logistics system.

I think I did that. I never understood the pain that factory game devs felt when they talked about the pain of belt dev until now. Now I join that circle.

The cool thing is that I basically get performance for free with Bevy's ECS architecture. Everything is fully parallel and the game will use every CPU core you have to make sure your factory runs smoothly. Visually I suspect you could bring fps down if you crank up the settings, but factory size in itself should never be a problem.

Included here is a rough technical explanation of how things work under the hood. Feel free to skip this if you find it boring.

Fancy Belt Stuff

How Belts Actually Work

Belts auto-organize themselves into directed “segments”. Segments are made of chains of belts from anything that can output items to anything that can accept them. Each belt entity gets a component that marks what belt segment it is part of. This is all done via observers and only happens when you place/delete said belt.

To be clear there is no linked-list like structure anywhere. We are just tagging belt entities with a segment component.

Connections and Segment Formation

Buildings and belts declare their belt inputs and outputs on the grid. When you place a building or belt, the building IO points, look one tile in the facing direction, and only connect if the neighbor is oriented in a compatible way. If it connects, the building adds a sink or source relationship with said belt segment. Above you can see some very large debug cubes that show the watched tiles.

As you place belts or buildings, I reorder belts from true start to end so the chain is coherent, and I rebuild a “visual path” spline straight from each belt’s world-space center. If you remove a belt, I recompute the actual connected groups, split the segment if needed, and reassign connected buildings to the correct new segments.

This was like 95% of the work.

Item Movement

Items on a belt move along a piecewise set of CubicHermite Splines built from the location of the belts in the world. This is really cheap because all of the splines are pre-calculated. All we do is move stuff based on a timer which is also pre-calculated based on belt segment length and belt speed.

Capacity, Throughput, and Backpressure

Belt capacity was done ASAP (as simple as possible) aka one belt entity = one item. A 20 belt entity long segment can hold 20 items. Inserts only succeed if the segment has room. Machine sources hooked up to a belt segment push from a small output buffer into the segment whenever there’s space. If the segment is full, the buffer fills and production pauses naturally; when the line clears, it resumes automatically. A similar process happens with machine inputs.

Performance

This is all ECS and fully parallel. Because segments are fully isolated and Bevy is cool I can just set up an async pool as wide as your CPU core count is. Segments all process their items and try to send via the relationship based source sink system. Above you can see a series of buildings with their input and outputs highlighted.

New Buildings & Resources

We've added a few new buildings since the last dev blog and they're all pretty cool.

Mining Platform v1

Mining Machine In Action

This is the first resource extractor that the player has access to. It will extract ores from the planet just as humans taught.

Ancient AI Core

The core where you the player AI's mind resides. Where you have been... for quite a while.

Gas Extractor Sneak Preview

And here is a sneak preview of the gas extractor. Not everything is a mineral after all.

Music

Super happy to be working with Repto Eternef They are creating some amazing music for the game and will be helping drive the exofactory music engine which we plan on open sourcing in 2026 before the game releases.

Dialogue & The Emotional Core

Lastly, but certainly not least, the emotional core and dialogue system was added.

The emotional core is the heart of what makes Exofactory, Exofactory. Technically it watches what the players do by receiving and processing events that are triggered by any action the player takes. This includes all building, destruction, movements, production, everything. These along with looking at the totality of what you have built, how systems interact and how things don't interact inform the story direction.

The goal is to have a user driven story based solely on their factory. I never want to put up a "choose option A or B" popup to advance the story. The game should know your priorities based on how, where, and what you are doing with your factories.

This is most evident to the player via the internal monologue of the AI that the player listens to as the game goes on. The thoughts and tones and direction of the dialogue/monologue are given by the emotional core to the dialogue system which displays them and plays the audio. Currently I am examining open source TTS systems that can read the many many many lines of potential dialogue.

Conclusion

Lots of core progress was made and things are on track. I am excited to see how players use the systems I am working on. :)

Exofactory is now available on Steam! If you are interested in the game I would encourage you to consider wishlisting it there.

Wishlist on Steam

Animation, Motion, & Terrain v3

Unknown — Thu, 07 Aug 2025 00:00:00 +0000

Exofactory is now available on Steam! If you are interested in the game I would encourage you to consider wishlisting it there.

Wishlist on Steam

Overview

There were a few major goals that were met. The game is now animated, we have some resources, and the terrain system is getting closer to "done". Not the most productive time period, but we are moving forward.

Additionally, I did give a presentation at Bornhack 2025 about creating games in Bevy with Rust, but it is not yet available. When it is, I will include it in a future dev blog.

Animation

We now have animations in the game! Animating in Bevy was quite the fun thing to learn. The thing that saved the day (and a ton of work hours) was the bevy ecosystem, namely the excellent Bevy/Blender plugin Skein by Chris Biscardi. He is doing a ton for the Bevy community and I see his work everywhere.

Skein is both a Bevy and Blender plugin that enables the 3D artist to add Bevy components (if you are not familiar with Bevy, think of components as a sort of tag or label) to parts of the 3D asset. When the asset is exported as a glb/gltf file those components are exported with as part of the file.

Skein on the Bevy side sees those embedded components and makes them available in Bevy's Entity Component System. This saves a ton of time and boilerplate code.

Programmatic Control of Lifter Animation

We are using Skein to add components to animation "bones" so animation can be controlled in a programmatic way, reacting to game events instead of just going through an animation loop. We are using these primarily in the Lifters as shown above.

Motion Transitions

In addition to more interesting programmatic animation we are using Bevy's animation graph system. This lets us change from one animation cycle to another smoothly without jitter or visual artifacts. Above you can see the exoframe go from walking to idle in a smooth continuous way.

Resources

We now have resources! We are starting with iron and copper. Soon we should see some machines start to get to work!

Above we see copper ore and bars. This should be pretty common in game and will be used to make many things including low power wires.

Above we see iron. I quite like the details on the top of the bars. Given we play as an AI, I could see the AI liking the design too.

Terrain v3

The Bevy space is full of halfborn, unmaintained, and poorly documented terrain level of detail (LoD) systems. You will see a ton of terrain LoD systems everywhere but I found none that were maintained, had the features I needed, and were documented in a clear way. Resultingly Exofactory now has its own LoD implementation. It's relatively naive, but meets the base requirements I need. These being:

Spawning and despawning terrain based on the location of multiple cameras.
Swapping in higher and lower resolution meshes and textures based on the location of said multiple cameras.
Handling LoD for terrain details like foliage or stones.
Doing all of this in a performant Bevy native ECS way.

Level of Detail System Testing

Above you can see the test terrain I was using to test this LoD system. Green being the tile under the active camera, yellow being the higher resolution mesh tiles, red being the low resolution mesh tiles, and the red being despawned as it goes further away.

This is a MUCH stronger foundation for terrain, but sadly a lot of my past terrain work needed/needs to be re-written. Good news is that the terrain v3 system is very tunable for aesthetics or performance. Even on my old 11th gen intel laptop iGPU I was able to tune things to run at 60fps with the full view distance. This being said this will probably change as more gets added.

Terrain v3 with only base colors

Here we can see a more developed (although still very bare, texture-less, and empty) version of the reworked Terrain v3 system with full LoD functionality. The textures and other detail will be added on GPU via shader and that is not included here, but we have the base colors and that gives an idea of what textures we can expect. Once we add terrain details I think the terrain will look amazing.

Conclusion

Given the time frame I wish I could have gotten more done. This being said what I did do was impactful and makes the game more playable, and more importantly at this stage, more test-playable. No longer are we seeing stutters when crossing terrain tiles. It's smooth and pleasant. The animation is cute too and adds a lot of life to a formally still world.

Terrain, Animation, and Major Work Done

Unknown — Sun, 06 Jul 2025 00:00:00 +0000

UPDATE: We were approved and Exofactory is now available on Steam.

Overview

The past month has been full of a ton of progress. The terrain has been completely reworked (more on that later), we now have a ton of animated 3D assets thanks to Julef, and we have everything in line to get our steam presence up.

Also over the month I had the pleasure of attending GPN23 an amazing hacker/maker conference of the chillest (in vibe not temperature) order. I was tricked into giving a lightning talk on creating games in Rust with Bevy. If you are inclined you can watch it here. The cool thing is that this talk was received well enough that I could justify giving a longer extended presentation at an upcoming event.

As a bonus Julef shares a peek behind the scenes at her work on Exofactory in her first blog contribution.

More to come.

Animation

Where a ton of work shows is the animation and 3d work by Julef. I am super excited to add these to the game.

Wave Animation

Walk Animation

Idle Animation

Scene with Belts and Machines

Behind the Scenes with Julef

Hello, Julija here – Art Director and head of the full Art Development team for Exofactory.

I'd like to share a quick art update on the game.

Over the past month, we've been focused on refining assets and enhancing the terrain.

One of the key highlights: the Fabricator has received a complete visual overhaul with a brand-new look.

We added more belts with Level 1 and 2 and gave them a life. Things are starting to move!

The Exoframe also came to life with a working rig and animations – big thanks to Juan, who supported the rig setup and created the animation work!

<p style="margin-top: 0.5rem; text-align: center;">Walk Animation</p>

<p style="margin-top: 0.5rem; text-align: center;">Wave Animation</p>

<p style="margin-top: 0.5rem; text-align: center;">Idle Animation</p>

We successfully completed and submitted First Visuals for Steam.

And here you can see what is happening behind the scenes.

Terrain

Cait here agan! If the imaga above is terrain v2 below you will see v2.5.

The terrain system was overhauled. In the new system we have non-trash-tier terrain. But, I am still not happy with it. If this is terrain v2 I imagine we will need to get to at least v4 or v5 before things start to look okay. This being said, as I am reminded of constantly, terrain is one of the hardest parts of the factory game genre. If I am ever happy with it that would be a major win. So we won't stop working on this till it's at a good place.

More subtly, a new terrain loading system was added. It dynamically streams in assets and textures as the player navigates the world. This allows for a ton of potential like adding a "level of detail" system later on.

Steam Screenshots

The screenshots were the killer for me. I had initially planned to set up our Steam presence much sooner, but I just couldn't get the screenshots to a point where they actually represented the game.

Bevy, the engine behind Exofactory has no scene viewer, nor preview nor paint tool, or any GUI at all. Resultingly I had to build the factories in the screenshot by actually playing the game exactly like a player would. Given that thing like deleting building haven't been added yet, you can imagine how this went.

The good news here that this did help me find things I now want to change just for player quality of life. So that is a win.

So without further ado here are the in game images that will be submitted to Steam. We expect the game to be approved soon.

Conclusions

All in all a productive month. Great work was done all around, particularly by Julef.

The only downside that was by doing so much so fast a little brittleness was introduced to the code base. I am looking forward to doing some "pure" programming work to bring the code base to where I want it to be in terms of quality. After all, what's the point of writing a game in Rust at all if you let code brittleness work its way in.

This month was great and soon that greatness will be rock solid.

Our Art Lead, ESC, and the 3D Rework

Unknown — Sun, 25 May 2025 00:00:00 +0000

Overview

The last two weeks were full of a ton of work, most of it not programming related. The good news is that this work resulted in major changes (improvements to the game overall).

The largest of these changes is that Exofactory now has an art lead. So we should start to see some visual improvements soon.

Art Lead

The big news, as mentioned above, is that Exofactory now has an art lead. While the artist search was originally focused on finding an artist to create some assets for the game, after speaking with Julija, I was convinced that hiring an art lead who can help drive game art direction made sense.

I simply lack the skills and don't think the game would be best served by me driving the art direction.

We've been working together for a bit now and the game now has an aesthetic that we are aiming for.

I'm excited to work together and lots is to be done.

If you want to learn more about Julija, you can take a look at her portfolio here.

ESC

If the single reader of this dev blog is wondering why there wasn't an update last week, the reason was me being distracted by the Eurovision Song Contest!

The resulting party and extra long get-together may have also impacted the progress this week, but I'll just say it was worth it.

We're now 3D!

The major work over the past two weeks was porting the game to be 3D. Not terribly hard, but it was a lot of work. (Just FYI: these are not final art assets. So don't worry.)

Part of this work was writing a programmatic terrain generator. Regardless of whether the game will have an infinite map or a more limited hand tuned one, having the terrain be autogenerated lightens the load substantially.

Funnily enough, generating the terrain takes just enough time to justify adding a game loading screen. So we now have one of those.

Conclusion

Pretty happy this week. Lots of important work was started and the game now has an artistic direction.

Art and Artists

Unknown — Sat, 10 May 2025 00:00:00 +0000

Overview

This week was focused on primarily non-code work. I ended up focusing on an area where I am quite inexperienced, namely the area of finding, filtering out, and selecting an artist. It was a tedious and quite unfun task, but it needs to be done.

Art and Artists

I am a programmer, not an artist so I made a few mistakes. Namely focusing on 2d artists.

This was a mistake because as one of the artists I reached out to kindly told me, I would need to commission an entire new animation for each building for each orientation. That's a lot of work.

I was told that hiring a 3D artist and doing a UV map to a sprite sheet might be wiser. After a bit of research I agreed. This advice was appreciated and helped set me in the right direction.

Before I was told this though I did get some concept art that's pretty cool.

A bit too round compared to what I was looking for but cool for sure.

Quite like this one.

Sadly this 2D concept art can't really be taken further, but it helps define the game energy which is a good thing.

Conclusion

The week was full of new things for me, but I learned a lot. Now I am in the process of hiring a proper 3D focused artist and should have more to show you there soon.

Offsets, Menus, Accessibility, and 0.16

Unknown — Sat, 03 May 2025 00:00:00 +0000

Overview

Last week I had big plans to do a hard micro-crunch, and to put out a technical preview. Sadly due to personal issues, I couldn't put in the needed time this week. Resultingly I was not able to get the game to where I wanted it to be. I will probably submit the game for future consideration, but for the sake of sustainability I had to drop it for this week.i

This being said, major work was done this week, both behind the scenes, and user facing stuff. All of which is exciting.

Bevy 0.16

The first big task was porting the game from Bevy 0.15 to 0.16. I had 3 reasons for this.

I plan on starting work on belts soon. I plan on heavily using the new ECS Relationships feature to manage belt sources and sinks. Without this I would just have ended up writing "ECS Relationships at home".
I wanted to use the stabilized Input Focus feature. This is important for accessibility and gamepad support. (More details below.)
Bevy is a rapidly evolving game engine. To fall behind is death for Exofactory's future at this point. Once bevy becomes stable that may change, but for now upgrades are mandatory.

This wasn't too big of a struggle, mostly moving away from newly depreciated functions, and an small amount of refactoring. I took this as an opportunity to clean up some earlier code I wrote while I was newly learning Bevy, namely swapping out Queries for Single where I could. This let me delete a lot of if let Some(x) = style code removing a lot of nesting which is nice.

I had a few dependencies that hadn't updated yet, so I used either their 0.16 PR branches directly or release candidates where available.

Menus & Accessibility

The other big project this week was the new complete-ish build menu.

I waited till after 0.16 because I wanted to use the accessibility/focus feature. This menu is the first in the game to use it. I strongly believe that accessibility is best practice. Building in accessibility helps everyone no matter what. This includes developers. By doing this I make it trivial to add gamepad support. After all from the perspective of code, a gamepad, and specialized accessibility hardware/software are basically the same thing.

Conclusion

This week, I didn't do as much as I wanted to in terms of quality, but I am happy with what I did do. That and sustainability is important to me. Burnout is something to be avoided.

Building Menus, Gamepads, and Change

Unknown — Sat, 26 Apr 2025 00:00:00 +0000

Overview

This week started with a nearly completely different set of goals than the week ended with. Things changed when Pokinsson made a call for indie game submissions, in any state, finished or not. After thinking about it, I thought I would give it a shot. In essence, that basically means that I have until April 7th to polish what I have and produce a playable technical preview.

As a result, I paused work on the half-baked gamepad support and started working toward that goal. This leaves a bunch of half-functioning gamepad code, but that's a problem for future me.

That being said, progress was made.

Half-Baked Gamepad Support

During the first half of the week, before I knew about the call for games, this was the primary area of focus. I am using Xelu's excellent button-prompt images; I strongly recommend them.

I added a lot of mappings and controller-management code, so now, going forward, I can do something like:

let focus_on_exoframe: Handle<Image> = smart_prompt_collection.focus_on_exoframe.clone();

The result will always be the correct prompt image regardless of whether you are using the Steam Deck, an Xbox One controller, or a keyboard and mouse.

I didn't get any further than this, but I do have a list of supported devices/control schemes. I plan on supporting:

The Steam Deck with built-in controllers, a keyboard and mouse, or an Xbox One controller.

Modern (Debian 11 or newer) Linux with a keyboard and mouse or an Xbox One controller.

Windows 10/11 with a keyboard and mouse or an Xbox One controller.

Other systems or controllers should work but won't be tested. For more information on what may or may not work, see gilrs, the underlying library I am using via Bevy.

Control Guide

I also added a "control guide" panel. This panel shows you exactly what you can do at any given moment and self-updates as you play the game. Of course, you can always hide it if it gets in your way.

This is great for the technical preview and for the game in general.

Building Interface

Last but not least, I added a core new feature to the game: an in-game building can now produce a thing!

Conclusion

Overall, it was a stressful week, and I don't want to normalize this work pace (especially with my other obligations), but a lot got done, and the preview build should come together.

UI Foundations Laid

Unknown — Sat, 19 Apr 2025 00:00:00 +0000

Overview

This week was primarily focused on adding basic UI elements, working on Exoframe movement, and adding initial game sounds.

For now I am using VERY basic art assets while I focus on core game mechanics, so be prepared for some crappy looking art that definitively proves that I am not an artist.

Overall this week was not too bad in terms of the timeline.

Fleshing Out The UI

Exofactory is being written in Bevy, and while it has been quite enjoyable overall I must say that the UI developer experience is absolutely not fun. Future Bevy is supposed to address this, and for the sake of Rust game devs everywhere I hope they do. While the UI for the main menu and settings are in a good spot the core game itself till this week has seen no work.

This week, that changed with the addition of the main top bar. This bar is intended to be the goto place that players use to get a sense of what “mode” they are in what is going on a global level.

Secondly this week I laid down the framework for building detail/setting windows. This enables me to quickly iterate and reduce the amount of UI work as new buildings are introduced. For now all clicking on a building does is bring up some basic info as shown above.

Overall happy with things here.

Experiment With Sound

As a break from all the UI work I added some basic sounds to the game. After a bit of recording and tinkering in Tenacity I have a few sounds I am happy with. For example the menu mouse over I find quite nice.

Your browser does not support the audio element.

I still need to add a sound section to the settings menu, but that can wait for now.

Exoframe Motion

Lastly I added exofame motion. It’s very snappy and satisfying to say the least. The motion and physics system in general is handled by the excellent rapier library.

Conclusion

Bottom line, I am happy with this week. I aim to release weekly dev blogs and monthly video blogs, so keep an eye out.