New Demo, New Buildings, New Architecture

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.

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:

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.
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.
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. 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.
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.