</th>	UASTC</th>	ETC1S</th></tr></thead>
Quality</strong></td>	Near lossless</td>	Lossy, lower quality</td></tr>
VRAM Usage</strong></td>	~1 byte/pixel</td>	~0.5 bytes/pixel</td></tr>
Disk Size</strong></td>	Larger (with Zstd)</td>	Much smaller</td></tr>
Transcode Speed</strong></td>	Fast</td>	Very fast</td></tr>
Best For</strong></td>	Normal maps, UI elements, detailed textures</td>	Textures where quality is less critical</td></tr> </tbody></table> 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.</p> Finding a bug in Bevy around KTX2</h2> In moving to KTX2 files one of the bugs I noticed is that Bevy was not honoring the `.meta</code> files for ktx2 files. One small PR later</a> and it was fixed. This fix will be included in Bevy 0.18.1</p>` Using KTX2 properly in GLB files</h2> 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.</p> The root cause of this problem is that Bevy is using gltf-rs</a> 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</a> I have submitted a PR</a> but the last code change was in November 2025 and I am not hopeful.</p> For now Exofactory is using my fork of the library, but a longer term solution needs to be found.</p> I am currently working on a document with a few ideas to be pitched to the Bevy core team based on a their request.</p> Results</h2> 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.</p> Tooling</h1> As a small side project I worked on BevyDex.dev</a> this month. It's basically a thin wrapper around the crates.io</a> api and a postgres database.</p> But it's always up to date, shows important details and is lightning fast(tm).</p> 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.</p> Funds</h1> 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.</p> Conclusion</h1> 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.</p> Multiplayer, Bevy 0.18, and Fosdem Unknown — Wed, 04 Feb 2026 00:00:00 +0000 Overview</h1> This month was basically solely focused on adding multiplayer functionality with a small break for a bevy 0.18 migration.</p> If you find this interesting and find the game interesting I would encourage you to give the game a wishlist on steam</a>. It helps a ton.</p> 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</em> hard to refactor.</p> In other news migrating from 0.17 to 0.18</a> was pretty painless. I had to drop a few more less maintained crates, but the core migration itself was simple.</p> 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</a> gave an excellent one on mobile bevy game development</a>.</p> Multiplayer</h1> </picture> The game supports simultaneous Direct Connect, LAN, and Steam multiplayer hosting and joining.</figcaption> </figure> </div> 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.</p> So with that my updated list of things to consider early are your:</strong></p> Multiplayer / Netcode Story</li> Gamepad Story</li> Save Story</li> Internationalization Story</li> </ol> Adding these later will be annoying and painful. (Ask me how I know! /s)</p> Exofactory Specifics</h2> 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.</p> 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.</p> 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:</p> Interact with the world in Global mode including building interaction.</li> Selecting and controlling one of a Pool of Exoframes.</li> Running the rest of the world to update the relevant components.</li> Ensuring the client sees the world in an accurate way.</li> </ol> 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.</p> Picking a Library</h2> At the time on Bevy 0.18 there seem to be two well supported crates these being bevy_replicon</a> and lightyear</a></p> 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</a>, deterministic replication</a> 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.</p> Edit:</strong> Someone did reach out! Turns out bevy_replicon does</em> 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.</p> For Exofactory, given that the game is definitively NOT</em> 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.</p> This all being said, I suspect that if your game architecture is already well structured switching later would not be a painful process.</p> From Single Player to Multi</h2> At the heart of it replicon does two things. Replicate components, and handle network events/messages to/from clients.</p> In order to enable multiplayer I had to refactor several systems and logically group them.</p> </p> Authoritative Core Systems</h3> 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.</p> 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.</p> These systems are allowed to write to components directly. Replicon automatically replicates these changes to the client instance of the components.</a></p> Player UI Systems</h3> 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.</p> 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</a> which then manipulates the components on behalf of the client and updates the components which are replicated to the client.</p> Network Messages & Events</h3> In the above diagram I only included one example, but in reality basically everything you do in the game beyond "looking at stuff"</em> happens via event or message. This includes the player on the server instance of the game.</p> 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</a> or message systems</a> will save you time later.</p> Ramifications & Outcomes</h2> </p> 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.</p> With the refactoring and a new feature based build of the game that uses MinimalPlugins</a> instead of DefaultPlugins</a> we get a clean lean headless server instance of the game that can run basically anywhere including most RISC-V SBCs!</p> This still needs testing but things are looking good. Above is a similar diagram but for the headless version of the game.</p> The second interesting outcome is that I am using way fewer Bevy resources</a> namely because Replicon does not replicate resources. Resultingly I am using way more pseudo-singletons</a> (aka an "empty" entity that just has the component that holds the data the resource used to.)</p> I am not a huge fan of object oriented design patterns, so it's a bit funny and feels a bit dirty.</p> Bevy 0.18 Migration</h1> 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.</p> Overall beyond a few shader bind group things (i.e. BindGroupLayout -> BindGroupLayoutDescriptor</a>) and Atmosphere</a> changes it was a simple migration.</p> Glad to see the release schedule back on track.</p> 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.</p> Fosdem!</h1> Speaking of, I had the privilege to attend Fosdem</a> a libre get together that is hosted in Brussels every year.</p> 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</a>, Gee</a>, Niklas Eicker</a>, Firestar99</a> and several other charming individuals was very fun.</p> Conclusion</h1> 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.</p> Bevy 0.18 was simple to migrate to.</p> I strongly recommend going to Fosdem if you have the chance.</p> Real Time Settings, Save Overhaul, & a Wiki Unknown — Tue, 30 Dec 2025 00:00:00 +0000 Overview</h1> 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.</p> 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</a>. It helps a ton.</p> Also, I recently took the public demo down from Steam. At this point it REALLY</em> 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.</p> So without further ado here are the latest areas of work.</p> Save Overhaul</h2> </picture> We can now continue the last game or load a specific save file.</figcaption> </figure> </div> 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</a> and a a baby state machine.</p> This auto saves the game while allowing for manual saves when needed.</p> 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.</p> Right now the default is 5 saves each 5 min apart, but if you edit the config.toml</code> file you can change that.</p> Crash Reporting & Logging Rework</h2> 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!</code> println!</code> eprint!</code> eprintln!</code> info!</code> warn!</code> error!</code> all over the place. Debug prints became permanent output.</p> 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.</p> Drop all the stdout/err stuff except for info!</code> warn!</code> error!</code> and panic!</code>. Migrating one plugin at a time.</li> Added a non-blocking tracing capture system that appends the output to a log file.</li> 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.</li> </ol> </picture> After detecting a crash we can upload logs.</figcaption> </figure> </div> 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?"</em> discussions.</p> Lastly added a small library that shows panics in the GUI</a>. Worst, worst case a player could copy paste the output.</p> Settings Overhaul</h2> </video> You can change graphics settings in real time.</figcaption> </figure> 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.</p> 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.</p> I took an ECS/Bevy centric approach and think it went well.</p> The way that settings work now is that settings are serialized/deserialized to/from the config.toml</code> file and is represented in game as a series of Resource structs.</p> 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.</p> For example let's consider changing ScreenSpaceAmbientOcclusion</a> settings in the game.</p> In a ECS world this is easy. We find the global camera entity by getting entities with the Exofactory GlobalCamera</code> 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.</p> The same can be applied to any setting.</p> All settings are just properties in a resource</a> struct that are mirrored onto specific components.</p> 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.</p> </video> Language and everything else too.</figcaption> </figure> Pretty cool in my book.</p> Wiki</h2> The idea behind the wiki is to provide a community oriented wiki</a> 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</a>.</p> While I agree that it is a bit early to set up the wiki I wanted to do so because of:</p> A genuine need for documentation around the config.toml</a> file.</li> A desire to short circuit any wikis being built on less community oriented platforms.</li> </ol> There isn't too much to be said except that as the game gets closer to launch the wiki will become even more useful.</p> 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.</p> Conclusion</h1> 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.</p> That and the save system WITH</strong> crash reporting is a really nice to have.</p> Quite happy and I am excited to get working properly on the much better demo 2.</p> Draggable Belts, Electricity, & View Modes Unknown — Thu, 04 Dec 2025 00:00:00 +0000 Overview</h1> This month focused on a few new areas these being major game mechanics, visuals, and major quality of life belt placement changes.</p> 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.</p> 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.</p> I will get a bit deeper in the relevant sections.</p> Draggable Belts</h1> </video> Dragging belts to connect buildings is now easy.</figcaption> </figure> 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.</p> 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</del> doing a bunch of research I found that I could use an approach similar to Shapez2</a> adapted for 3d and the peculiarities of Exofactory.</p> 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.</p> </video> Longer belt connections take way less work now.</figcaption> </figure> This makes the game way less tedious to play and I am super glad to have it coded out.</p> Electricity</h1> </video> Building automatically connect to the nearest power source in range.</figcaption> </figure> 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.</p> 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.</p> From a coding perspective this was quite an easy feature to add. Just add some ECS</a> components and you are good to go, buildings update their components as they cycle and power systems query for them accordingly.</p> The hard part was visualization. I'll cover that below.</p> View Modes</h1> One piece of feedback I got was "What's the point of the global mode?"</em> 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.</p> I am happy to show them off now. Good god did I have to learn a lot about shaders</a>, stencils</a> and skinning</a> to get things to work.</p> The view modes can be accessed in the global mode with the tab button or relevant controller button.</p> Power</h2> </video> You can see the powered zones, and which buildings and wires are powered or not.</figcaption> </figure> 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.</p> 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.</p> Productivity</h2> </video> The color of the buildings shows their productivity. Green for 100%, Red for 0%.</figcaption> </figure> 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.</p> 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.</p> Conclusion</h1> 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.</p> Real Factory Game Quality of Life Changes Unknown — Sun, 16 Nov 2025 00:00:00 +0000 Overview</h1> 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</a> as well as the switch to the Avian</a> physics engine.</p> 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.</p> Switching to Avian</h2> </picture> Autogenerated Avian Collider Meshes</figcaption> </figure> </div> I had initially been using the venerable Rapier3D</a> for physics but was unsatisfied for a few reasons.</p> 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.</li> Non Ergonomic APIs.</li> No collider generation.</li> </ol> This all being said, Rapier is a solid physics engine and the work that dimforge</a> does for the Bevy community is amazing. They are just not the best fit for me.</p> Switching to Avian addressed all of these issues and made things like raycasting</a> a breeze compared to what I was doing.</p> That, and the amazing collider constructor</a> system, sealed the deal. <3 ConvexDecompositionWithConfig</a></p> I did run into one snafu though: Avian does not have a native character controller</a> like Rapier does. This being said, after reading the Avian FAQs</a>, I settled on using bevy_tnua</a>, an excellent replacement.</p> Time-wise the whole port took a day. Approximately:</p> 2 hours for all the colliders and tuning the parameters.</li> 3 hours to replace all the ray casting and to set up collision layers</a>. (With enums, very pleasant to do.)</li> 3 hours to rewire all the player controls through tnua.</li> </ul> Thanks to all the work done by Joona Aalto</a> on Avian. I am super happy to sponsor him and if you like Avian you should consider it too.</p> General Quality of Life</h1> </video> We can now jump!</figcaption> </figure> 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.</p> </picture> Instead of the broken tool tips we now have the build costs shown in the build menu.</figcaption> </figure> </div> 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.</p> </picture> We now see the costs and the available stock when we go to place buildings.</figcaption> </figure> </div> Machine Productivity</h1> </video> The mining machine now shows us ideal and real outputs.</figcaption> </figure> 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.</p> Like, I play and enjoy Satisfactory</a> and Factorio</a>. I don't know how I missed this. That being said, it's there now.</p> 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.</p> </video> The furnace shows what we actually need to input and what we are and should be outputting.</figcaption> </figure> Settings</h1> I will say part of why I was itching for Bevy 0.17 was due to the new/reworked UI using observers</a>. 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.</p> 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!</p> </p> </p> </p> Site Fancification</h1> 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.</p> 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.</p> Conclusion</h1> 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.</p> Steam Next Fest Reflections Unknown — Tue, 21 Oct 2025 00:00:00 +0000 Overview</h1> 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.</p> I never knew that so many keyboards report to the operating system that they are Xbox-branded human interface devices. Crazy.</p> Based on all that I learned, I think I can solidify the timeline for the game going forward.</p> Next Fest Results</h1> More Good Things</h2> A ton of bugs were found and quickly fixed. Thank you very much to those who reported them.</li> A ton of interest was shown in the game, both in terms of wishlists and playtime.</li> Many ideas on how to fix and improve things were given.</li> </ul> Less Good Things</h2> 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.</li> I thought the game was fully accessible for those who use accessibility devices and controllers, but from the feedback, I missed a few things.</li> </ul> Updated Timeline</h1> 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.</p> The Q4 2025 date was just unrealistic. Flat out.</p> Given this, a new plan is needed.</p> After consideration and reflection on what is best for the game, the plan is this:</p> 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.</li> Consider options on how to fund the game further, whether that be Kickstarter, investment, or working with a publisher.</li> Aim to release the full game in late 2026.</li> </ol> As someone once said: "A delayed game is eventually good, but a rushed game is forever bad."</em></p> Meme or not, I do want to release a game I am proud of.</p> Conclusion</h1> 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.</p> Demo Release and Polish Unknown — Tue, 07 Oct 2025 00:00:00 +0000 Overview</h1> 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.</p> The amount of work that has gone into this has been a lot, and we cover a good amount of it here.</p> Steam Next Fest</h2> </picture> Nice little Demo download button.</figcaption> </figure> </div> 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</a>/.exe</a> file to Steam and have them distribute it. You have to use quite a bit of Steam-specific tooling.</a> 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.</p> 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</a> or DEB</a> distributable.</p> The good news was, in the end, the game made the deadline, but with intense timing difficulties.</p> Testing Mistakes Made</h2> This leads to the next major point. If you signed up for alpha/beta testing you were not forgotten or passed over. Due to:</p> The unexpected (by me) delays in Steam approving the game.</li> The unexpected (by me) difficulties in packaging the game.</li> The sheer number of "breaking" bugs that I was crunch fixing found by friends and family.</li> </ol> I was not able to upload and get early testing keys before the Demo had to be soft launched for Next Fest.</p> 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.</p> Animations & Mechanics</h2> </video> Lifters, Belts, Splitters, and Mergers</figcaption> </figure> 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</a>. No linking or hierarchy to speak of. Just async systems running in such a way to give that illusion.</p> Long story short, the game now behaves like a game should, animations, sound, and all.</p> Demo Released + Trailer</h2> 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</a>.</p> 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.</p> Roadmap</h2> 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.</a></p> I will be providing a more detailed roadmap on this site soon. These lists are preliminary and VERY VERY incomplete.</p> Coming Sooner</h3> </picture> Accessibility Prioritized Steam Deck and Controller Support</figcaption> </figure> </div> Full accessibility prioritized Steam Deck and controller support.</li> Terrain and foliage asset rework.</li> Massive optimization overhaul.</li> The first diverging branches of technology unlocks in the tech web based on your in-game choices.</li> A public wiki like a proper factory game should have.</li> Continuing work on the "real" terrain.</li> Real power use.</li> Liquids.</li> German.</li> Test ELF binaries for aarch64</a> and RISC-V</a> if possible.</li> </ul> Coming Later</h3> Game binaries for more Rust Tier 1 and 2 targets.</a> (Anyone want to help test on the BSDs?)</li> Steam-free way to play the game Factorio</a> style.</li> Officially supported Flathub</a> / Flatpak</a> images.</li> Continuing work on the "real" terrain.</li> </ul> Conclusion</h1> The demo is out and I look forward to working on the full game. I am looking forward to seeing what people make.</p> Demo on Steam</span> </div> </a> </div> Private Alpha, Steam, & Core Functionality Unknown — Mon, 08 Sep 2025 00:00:00 +0000 Overview</h1> 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!</p> Private Alpha</h2> 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</a>. You should see a button where you can sign up there.</p> 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.</p> Steam Next Fest</h2> 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.</p> 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.</p> This is all managed by the emotional core and it's pretty cool.</p> 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.</p> Belt Fundamentals & Logistics</h2> 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.</p> 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.</p> 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.</p> Included here is a rough technical explanation of how things work under the hood. Feel free to skip this if you find it boring.</p> </video> Fancy Belt Stuff</figcaption> </figure> How Belts Actually Work</h3> 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.</p> To be clear there is no linked-list like structure anywhere. We are just tagging belt entities with a segment component.</p> Connections and Segment Formation</h3> </p> 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.</p> 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.</p> This was like 95% of the work.</p> Item Movement</h3> Items on a belt move along a piecewise set of CubicHermite Splines</a> 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.</p> Capacity, Throughput, and Backpressure</h3> 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.</p> Performance</h3> </p> 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.</p> New Buildings & Resources</h2> We've added a few new buildings since the last dev blog and they're all pretty cool.</p> Mining Platform v1</h3> </video> Mining Machine In Action</figcaption> </figure> This is the first resource extractor that the player has access to. It will extract ores from the planet just as humans taught.</p> Ancient AI Core</h3> </p> The core where you the player AI's mind resides. Where you have been... for quite a while.</p> Gas Extractor Sneak Preview</h3> </p> And here is a sneak preview of the gas extractor. Not everything is a mineral after all.</p> Music</h2> Super happy to be working with Repto Eternef</a> 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.</p> Dialogue & The Emotional Core</h2> </p> Lastly, but certainly not least, the emotional core and dialogue system was added.</p> 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.</p> 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.</p> 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.</p> Conclusion</h1> 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. :)</p> Exofactory is now available on Steam! If you are interested in the game I would encourage you to consider wishlisting it there.</p> Wishlist on Steam</span> </div> </a> </div> 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.</p> Wishlist on Steam</span> </div> </a> </div> Overview</h1> 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.</p> Additionally, I did give a presentation at Bornhack 2025</a> 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.</p> Animation</h1> 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</a> by Chris Biscardi</a>. He is doing a ton for the Bevy community and I see his work everywhere.</p> 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.</p> Skein on the Bevy side sees those embedded components and makes them available in Bevy's Entity Component System</a>. This saves a ton of time and boilerplate code.</p> </video> Programmatic Control of Lifter Animation</figcaption> </figure> 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.</p> </video> Motion Transitions</figcaption> </figure> In addition to more interesting programmatic animation we are using Bevy's animation graph system</a>. 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.</p> Resources</h1> We now have resources! We are starting with iron and copper. Soon we should see some machines start to get to work!</p> 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.</p> 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.</p> Terrain v3</h1> The Bevy space is full of halfborn, unmaintained, and poorly documented terrain level of detail (LoD)</a> 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:</p> Spawning and despawning terrain based on the location of multiple</em> cameras.</li> Swapping in higher and lower resolution meshes and textures based on the location of said multiple cameras.</li> Handling LoD for terrain details like foliage or stones.</li> Doing all of this in a performant Bevy native ECS way.</li> </ol> </video> Level of Detail System Testing</figcaption> </figure> 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.</p> 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.</p> </video> Terrain v3 with only base colors</figcaption> </figure> 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.</p> Conclusion</h1> 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.</p> Terrain, Animation, and Major Work Done Unknown — Sun, 06 Jul 2025 00:00:00 +0000 UPDATE:</strong> We were approved and Exofactory is now available on Steam</a>.</p> Overview</h1> 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</a>, and we have everything in line to get our steam presence up.</p> Also over the month I had the pleasure of attending GPN23</a> 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</a>. The cool thing is that this talk was received well enough that I could justify giving a longer extended presentation at an upcoming event.</p> As a bonus Julef</a> shares a peek behind the scenes at her work on Exofactory in her first blog contribution.</p> More to come.</p> Animation</h1> Where a ton of work shows is the animation and 3d work by Julef</a>. I am super excited to add these to the game.</p> </video> Wave Animation</figcaption> </figure> </video> Walk Animation</figcaption> </figure> </video> Idle Animation</figcaption> </figure> </video> Scene with Belts and Machines</figcaption> </figure> Behind the Scenes with Julef</h1> Hello, Julija here – Art Director and head of the full Art Development team for Exofactory.</p> I'd like to share a quick art update on the game.</p> Over the past month, we've been focused on refining assets and enhancing the terrain.</p> One of the key highlights: the Fabricator has received a complete visual overhaul with a brand-new look.</p> </div> We added more belts with Level 1 and 2 and gave them a life. Things are starting to move!</p> </video> </figure> The Exoframe also came to life with a working rig and animations – big thanks to Juan</a>, who supported the rig setup and created the animation work!</p> </video> Walk Animation</p> </div> </video> Wave Animation</p> </div> </video> Idle Animation</p> </div> </div> We successfully completed and submitted First Visuals for Steam.</p> </p> And here you can see what is happening behind the scenes.</p> </p> Terrain</h1> </p> Cait here agan! If the imaga above is terrain v2 below you will see v2.5.</p> 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.</p> 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.</p> Steam Screenshots</h1> </p> The screenshots were the killer for me. I had initially planned to set up our Steam presence much</em> sooner, but I just couldn't get the screenshots to a point where they actually represented the game.</p> Bevy</a>, 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</strong> exactly like a player would. Given that thing like deleting building haven't been added yet, you can imagine how this went.</p> 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.</p> So without further ado here are the in game images that will be submitted to Steam. We expect the game to be approved soon.</p> </p> </p> </p> </p> Conclusions</h1> All in all a productive month. Great work was done all around, particularly by Julef.</p> 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.</p> This month was great and soon that greatness will be rock solid.</p> Our Art Lead, ESC, and the 3D Rework Unknown — Sun, 25 May 2025 00:00:00 +0000 Overview</h2> 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).</p> The largest of these changes is that Exofactory now has an art lead. So we should start to see some visual improvements soon.</p> Art Lead</h2> 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.</p> I simply lack the skills and don't think the game would be best served by me driving the art direction.</p> We've been working together for a bit now and the game now has an aesthetic that we are aiming for.</p> I'm excited to work together and lots is to be done.</p> If you want to learn more about Julija, you can take a look at her portfolio here.</a></p> ESC</h2> 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!</p> 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.</p> We're now 3D!</h2> </p> 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.)</p> 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.</p> </p> Funnily enough, generating the terrain takes just enough time to justify adding a game loading screen. So we now have one of those.</p> </p> Conclusion</h2> Pretty happy this week. Lots of important work was started and the game now has an artistic direction.</p> Art and Artists Unknown — Sat, 10 May 2025 00:00:00 +0000 Overview</h2> 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.</p> Art and Artists</h2> I am a programmer, not an artist so I made a few mistakes. Namely focusing on 2d artists.</p> 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.</p> I was told that hiring a 3D artist and doing a UV map</a> 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.</p> Before I was told this though I did get some concept art that's pretty cool.</p> </p> A bit too round compared to what I was looking for but cool for sure.</p> </p> Quite like this one.</p> Sadly this 2D concept art can't really be taken further, but it helps define the game energy which is a good thing.</p> Conclusion</h2> 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.</p> Offsets, Menus, Accessibility, and 0.16 Unknown — Sat, 03 May 2025 00:00:00 +0000 Overview</h2> 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</p> This being said, major work was done this week, both behind the scenes, and user facing stuff. All of which is exciting.</p> Bevy 0.16</h2> The first big task was porting the game from Bevy 0.15 to 0.16</a>. I had 3 reasons for this.</p> I plan on starting work on belts soon. I plan on heavily using the new ECS Relationships feature</a> to manage belt sources and sinks. Without this I would just have ended up writing "ECS Relationships at home".</li> I wanted to use the stabilized Input Focus feature</a>. This is important for accessibility and gamepad support. (More details below.)</li> 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.</li> </ol> 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</code> for Single</code> where I could. This let me delete a lot of if let Some(x) =</code> style code removing a lot of nesting which is nice.</p> 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.</p> Menus & Accessibility</h2> </p> The other big project this week was the new complete-ish build menu.</p> 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.</p> Conclusion</h2> 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.</p> Building Menus, Gamepads, and Change Unknown — Sat, 26 Apr 2025 00:00:00 +0000 Overview</h2> This week started with a nearly completely different set of goals than the week ended with. Things changed when Pokinsson </a> 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.</p> 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.</p> That being said, progress was made.</p> Half-Baked Gamepad Support</h2> 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</a>; I strongly recommend them.</p> I added a lot of mappings and controller-management code, so now, going forward, I can do something like:</p> let focus_on_exoframe: Handle<Image> = smart_prompt_collection.focus_on_exoframe.clone(); </code></pre> 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.</p> I didn't get any further than this, but I do have a list of supported devices/control schemes. I plan on supporting:</p> The Steam Deck with built-in controllers, a keyboard and mouse, or an Xbox One controller.</p> Modern (Debian 11 or newer) Linux with a keyboard and mouse or an Xbox One controller.</p> Windows 10/11 with a keyboard and mouse or an Xbox One controller.</p> Other systems or controllers should work but won't be tested. For more information on what may or may not work, see gilrs</a>, the underlying library I am using via Bevy.</p> Control Guide</h2> </p> 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.</p> This is great for the technical preview and for the game in general.</p> Building Interface</h2> </p> Last but not least, I added a core new feature to the game: an in-game building can now produce a thing!</p> Conclusion</h2> 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.</p> UI Foundations Laid Unknown — Sat, 19 Apr 2025 00:00:00 +0000 Overview</h2> This week was primarily focused on adding basic UI elements, working on Exoframe movement, and adding initial game sounds.</p> 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.</p> Overall this week was not too bad in terms of the timeline.</p> Fleshing Out The UI</h2> Exofactory is being written in Bevy</a>, and while it has been quite enjoyable overall I must say that the UI developer experience is absolutely not fun. Future Bevy</a> 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.</p> 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.</p> </p> 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.</p> Overall happy with things here.</p> Experiment With Sound</h2> 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</a> I have a few sounds I am happy with. For example the menu mouse over I find quite nice.</p> Your browser does not support the audio element. </audio> I still need to add a sound section to the settings menu, but that can wait for now.</p> Exoframe Motion</h2> </p> 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.</p> Conclusion</h2> Bottom line, I am happy with this week. I aim to release weekly dev blogs and monthly video blogs, so keep an eye out.</p>

Exofactory Dev Blog

Technical Rework of Belts, and Global Planning Mode

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

Overview</h1>
This month a few important developments were brought together.</p>
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</a> 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.</p>
The second of these was addressing the inherent tension between the tile/voxel</a> 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?"</strong></em> 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</a> system.</p>
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.</p>

Wishlist on Steam</span> </div> </a> </div>
Global Planning Mode</h1>
</video>
Placing buildings in Global View mode and building them in the Exoframe.</figcaption> </figure>
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</a>.</p>
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.</p>
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.</p>
Excited to see people experience this.</p>
Stranger 2.5D Belts in a Strange 3D Land</h1>
</picture>
Back when Exofactory was a 2D prototype.</figcaption> </figure>
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.</p>
Thought Process</h2>
Exofactory initially started as a 2D prototype factory game</a> based around the excellent bevy_ecs_tilemap</a>. 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.</p>
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.</p>
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.</p>
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.</p>
After some tests and reflection, ultimately I decided that any solution around voxels would just be a hack given the game direction.</p>
Going forward, the voxel system will be gradually removed and replaced with more 3D-native approaches, namely Bevy splines</a>, avian3d colliders</a>, sensors</a>, and the like.</p>
Spline Belt Work</h2>
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.</p>
I took a step-by-step piecewise approach to this.</p>
Step 1 - Most Basic Spline Belt Possible</h3>
</video>
Simplest Spline Belt Possible</figcaption> </figure>
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</a> to "extrude" the mesh along the spline.</p>
At this point everything is just visual. Most of the work here was done around adding the boilerplate for a new building, etc.</p>
Step 2 - Refine Belt Visuals & Geometry</h3>
</video>
The updated belt surface and profile with a clean bend.</figcaption> </figure>
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.</p>
Being better with FreeCAD</a> than I am with Blender</a>, I actually opened the old belt glb file in FreeCAD, took a cross section, and used the FreeCAD measurement tools to get the dimensions.</p>
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.</p>
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.</p>
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.</p>
The final meshes are produced by sweeping a 2D cross-section along the spline through the 2D profiles.</p>
At this point the belt is looking a lot better but is still just visual.</p>
Step 3 - Making the Belt Do Belting</h3>
</video>
A working belt carrying ore along a complex path.</figcaption> </figure>
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.</p>
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</a>) chain component mappings.</p>
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.</p>
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.</p>
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.</p>
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.</p>
Removing the old belt tile system was very satisfying, to say the least, after this.</p>
Work to Be Done</h3>
The spline-based belt system is working, but it isn't fully done yet. At least I want to:</p>

Use the actual texture for the belt rails. Simple in theory, but annoying to do cleanly.</li>
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.</li> </ol>
Conclusion</h1>
Really happy with finally addressing the internal 2.5D/3D tension of the game. I have been stalling on fixing it for too long.</p>
Also super happy to have my first cool in-game story element fully coded out. Feels weird to not give all the details.</p>
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.</p>

Wishlist on Steam</span> </div> </a> </div>

Building Animation, Trailer, & Pitch Deck Stuff

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

Overview</h1>
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.</p>
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.</p>
If you are interested in the game I would encourage you to consider wishlisting it on Steam.</p>

Wishlist on Steam</span> </div> </a> </div>
New Building Animation</h1>
</video>
The fabricator being spawned in.</figcaption> </figure>
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</a> sci-fi series, particularly my interpretation of how the "Inhibitors" (spoiler warning)</a> 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.</p>
Larger buildings take longer to spawn and smaller ones take less time. It ends up being a pretty elegant shader/loading system.</p>
</video>
Short belt segments have no spawning animation, long do.</figcaption> </figure>
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.</p>
Trailer</h1>
</iframe> </div>
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.</p>
Publishing & Resource Management</h1>
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.</p>
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.</p>
Conclusion</h1>
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.</p>

Optimizations, PRs, Tooling, & Funds

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

Overview</h1>
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.</p>
If you find this interesting and find the game interesting I would encourage you to give the game a wishlist on steam</a>. It helps a ton.</p>
Optimizations</h1>
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.</p>
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</code> builds on my (admittedly old) 11th Gen Intel Framework.</p>
Given this situation I set out to learn tracy and how it works in bevy</a>, and to take the time to actually clean things up.</p>
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:</p>
Storing Everything in System Memory</h2> By default when you do a asset_server.load("my_thing.png")</code> 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</code></a> 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</a> make that ~512MB per GLB asset. This alone was responsible for the GREAT MAJORITY of the crazy amount of RAM Exofactory was using.</p> The good news is that you don't have to store this all in system memory. In Bevy you can store things in MainWorld</a> or in RenderWorld</a> 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.</p> 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.</p> Bevy has several ways to do this, but the simplest for me was to use .meta</code> files.</p> In Bevy, .meta</code> files sit alongside your assets and let you override how the asset loader handles them. They use Bevy's RON-like format</a> and are named after the asset file they configure. So for fabricator_01_icon.ktx2</code> you would have a fabricator_01_icon.ktx2.meta</code> file right next to it.</p> For a simple image asset the meta file looks like this:</p> ( 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"), ), ), ) </code></pre> The key line is asset_usage: RenderAssetUsages("RENDER_WORLD")</code>. This tells Bevy to only keep the texture on the GPU, freeing up the system memory copy entirely.</p> For GLB files we can get more granular. Here is an example from one of the belt building models:</p> ( 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, ), ), ) </code></pre> Notice that load_meshes</code> keeps both MAIN_WORLD | RENDER_WORLD</code>. This is because I need mesh data in system memory for things like collision detection</a> and raycasting</a>. But load_materials</code> (which includes the textures) is set to only RENDER_WORLD</code>. 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.</p> 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</a> script later and I was done.</p> Using non GPU native bitmap formats</h2> 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.</p> Moving to KTX2</a> for textures was the solution. It's a container format from Khronos that can hold many GPU native compressed formats</a>. Of the formats available I considered UASTC and ETC1S because of native Bevy support. They have different tradeoffs:</p> </th> UASTC</th> ETC1S</th></tr></thead> Quality</strong></td> Near lossless</td> Lossy, lower quality</td></tr> VRAM Usage</strong></td> ~1 byte/pixel</td> ~0.5 bytes/pixel</td></tr> Disk Size</strong></td> Larger (with Zstd)</td> Much smaller</td></tr> Transcode Speed</strong></td> Fast</td> Very fast</td></tr> Best For</strong></td> Normal maps, UI elements, detailed textures</td> Textures where quality is less critical</td></tr> </tbody></table> 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.</p> Finding a bug in Bevy around KTX2</h2> In moving to KTX2 files one of the bugs I noticed is that Bevy was not honoring the .meta</code> files for ktx2 files. One small PR later</a> and it was fixed. This fix will be included in Bevy 0.18.1</p> Using KTX2 properly in GLB files</h2> 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.</p> The root cause of this problem is that Bevy is using gltf-rs</a> 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</a> I have submitted a PR</a> but the last code change was in November 2025 and I am not hopeful.</p> For now Exofactory is using my fork of the library, but a longer term solution needs to be found.</p> I am currently working on a document with a few ideas to be pitched to the Bevy core team based on a their request.</p> Results</h2> 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.</p> Tooling</h1> As a small side project I worked on BevyDex.dev</a> this month. It's basically a thin wrapper around the crates.io</a> api and a postgres database.</p> But it's always up to date, shows important details and is lightning fast(tm).</p> 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.</p> Funds</h1> 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.</p> Conclusion</h1> 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.</p> Multiplayer, Bevy 0.18, and Fosdem Unknown — Wed, 04 Feb 2026 00:00:00 +0000 Overview</h1> This month was basically solely focused on adding multiplayer functionality with a small break for a bevy 0.18 migration.</p> If you find this interesting and find the game interesting I would encourage you to give the game a wishlist on steam</a>. It helps a ton.</p> 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</em> hard to refactor.</p> In other news migrating from 0.17 to 0.18</a> was pretty painless. I had to drop a few more less maintained crates, but the core migration itself was simple.</p> 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</a> gave an excellent one on mobile bevy game development</a>.</p> Multiplayer</h1> </picture> The game supports simultaneous Direct Connect, LAN, and Steam multiplayer hosting and joining.</figcaption> </figure> </div> 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.</p> So with that my updated list of things to consider early are your:</strong></p> Multiplayer / Netcode Story</li> Gamepad Story</li> Save Story</li> Internationalization Story</li> </ol> Adding these later will be annoying and painful. (Ask me how I know! /s)</p> Exofactory Specifics</h2> 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.</p> 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.</p> 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:</p> Interact with the world in Global mode including building interaction.</li> Selecting and controlling one of a Pool of Exoframes.</li> Running the rest of the world to update the relevant components.</li> Ensuring the client sees the world in an accurate way.</li> </ol> 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.</p> Picking a Library</h2> At the time on Bevy 0.18 there seem to be two well supported crates these being bevy_replicon</a> and lightyear</a></p> 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</a>, deterministic replication</a> 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.</p> Edit:</strong> Someone did reach out! Turns out bevy_replicon does</em> 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.</p> For Exofactory, given that the game is definitively NOT</em> 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.</p> This all being said, I suspect that if your game architecture is already well structured switching later would not be a painful process.</p> From Single Player to Multi</h2> At the heart of it replicon does two things. Replicate components, and handle network events/messages to/from clients.</p> In order to enable multiplayer I had to refactor several systems and logically group them.</p> </p> Authoritative Core Systems</h3> 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.</p> 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.</p> These systems are allowed to write to components directly. Replicon automatically replicates these changes to the client instance of the components.</a></p> Player UI Systems</h3> 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.</p> 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</a> which then manipulates the components on behalf of the client and updates the components which are replicated to the client.</p> Network Messages & Events</h3> In the above diagram I only included one example, but in reality basically everything you do in the game beyond "looking at stuff"</em> happens via event or message. This includes the player on the server instance of the game.</p> 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</a> or message systems</a> will save you time later.</p> Ramifications & Outcomes</h2> </p> 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.</p> With the refactoring and a new feature based build of the game that uses MinimalPlugins</a> instead of DefaultPlugins</a> we get a clean lean headless server instance of the game that can run basically anywhere including most RISC-V SBCs!</p> This still needs testing but things are looking good. Above is a similar diagram but for the headless version of the game.</p> The second interesting outcome is that I am using way fewer Bevy resources</a> namely because Replicon does not replicate resources. Resultingly I am using way more pseudo-singletons</a> (aka an "empty" entity that just has the component that holds the data the resource used to.)</p> I am not a huge fan of object oriented design patterns, so it's a bit funny and feels a bit dirty.</p> Bevy 0.18 Migration</h1> 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.</p> Overall beyond a few shader bind group things (i.e. BindGroupLayout -> BindGroupLayoutDescriptor</a>) and Atmosphere</a> changes it was a simple migration.</p> Glad to see the release schedule back on track.</p> 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.</p> Fosdem!</h1> Speaking of, I had the privilege to attend Fosdem</a> a libre get together that is hosted in Brussels every year.</p> 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</a>, Gee</a>, Niklas Eicker</a>, Firestar99</a> and several other charming individuals was very fun.</p> Conclusion</h1> 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.</p> Bevy 0.18 was simple to migrate to.</p> I strongly recommend going to Fosdem if you have the chance.</p> Real Time Settings, Save Overhaul, & a Wiki Unknown — Tue, 30 Dec 2025 00:00:00 +0000 Overview</h1> 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.</p> 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</a>. It helps a ton.</p> Also, I recently took the public demo down from Steam. At this point it REALLY</em> 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.</p> So without further ado here are the latest areas of work.</p> Save Overhaul</h2> </picture> We can now continue the last game or load a specific save file.</figcaption> </figure> </div> 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</a> and a a baby state machine.</p> This auto saves the game while allowing for manual saves when needed.</p> 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.</p> Right now the default is 5 saves each 5 min apart, but if you edit the config.toml</code> file you can change that.</p> Crash Reporting & Logging Rework</h2> 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!</code> println!</code> eprint!</code> eprintln!</code> info!</code> warn!</code> error!</code> all over the place. Debug prints became permanent output.</p> 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.</p> Drop all the stdout/err stuff except for info!</code> warn!</code> error!</code> and panic!</code>. Migrating one plugin at a time.</li> Added a non-blocking tracing capture system that appends the output to a log file.</li> 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.</li> </ol> </picture> After detecting a crash we can upload logs.</figcaption> </figure> </div> 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?"</em> discussions.</p> Lastly added a small library that shows panics in the GUI</a>. Worst, worst case a player could copy paste the output.</p> Settings Overhaul</h2> </video> You can change graphics settings in real time.</figcaption> </figure> 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.</p> 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.</p> I took an ECS/Bevy centric approach and think it went well.</p> The way that settings work now is that settings are serialized/deserialized to/from the config.toml</code> file and is represented in game as a series of Resource structs.</p> 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.</p> For example let's consider changing ScreenSpaceAmbientOcclusion</a> settings in the game.</p> In a ECS world this is easy. We find the global camera entity by getting entities with the Exofactory GlobalCamera</code> 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.</p> The same can be applied to any setting.</p> All settings are just properties in a resource</a> struct that are mirrored onto specific components.</p> 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.</p> </video> Language and everything else too.</figcaption> </figure> Pretty cool in my book.</p> Wiki</h2> The idea behind the wiki is to provide a community oriented wiki</a> 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</a>.</p> While I agree that it is a bit early to set up the wiki I wanted to do so because of:</p> A genuine need for documentation around the config.toml</a> file.</li> A desire to short circuit any wikis being built on less community oriented platforms.</li> </ol> There isn't too much to be said except that as the game gets closer to launch the wiki will become even more useful.</p> 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.</p> Conclusion</h1> 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.</p> That and the save system WITH</strong> crash reporting is a really nice to have.</p> Quite happy and I am excited to get working properly on the much better demo 2.</p> Draggable Belts, Electricity, & View Modes Unknown — Thu, 04 Dec 2025 00:00:00 +0000 Overview</h1> This month focused on a few new areas these being major game mechanics, visuals, and major quality of life belt placement changes.</p> 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.</p> 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.</p> I will get a bit deeper in the relevant sections.</p> Draggable Belts</h1> </video> Dragging belts to connect buildings is now easy.</figcaption> </figure> 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.</p> 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</del> doing a bunch of research I found that I could use an approach similar to Shapez2</a> adapted for 3d and the peculiarities of Exofactory.</p> 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.</p> </video> Longer belt connections take way less work now.</figcaption> </figure> This makes the game way less tedious to play and I am super glad to have it coded out.</p> Electricity</h1> </video> Building automatically connect to the nearest power source in range.</figcaption> </figure> 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.</p> 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.</p> From a coding perspective this was quite an easy feature to add. Just add some ECS</a> components and you are good to go, buildings update their components as they cycle and power systems query for them accordingly.</p> The hard part was visualization. I'll cover that below.</p> View Modes</h1> One piece of feedback I got was "What's the point of the global mode?"</em> 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.</p> I am happy to show them off now. Good god did I have to learn a lot about shaders</a>, stencils</a> and skinning</a> to get things to work.</p> The view modes can be accessed in the global mode with the tab button or relevant controller button.</p> Power</h2> </video> You can see the powered zones, and which buildings and wires are powered or not.</figcaption> </figure> 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.</p> 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.</p> Productivity</h2> </video> The color of the buildings shows their productivity. Green for 100%, Red for 0%.</figcaption> </figure> 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.</p> 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.</p> Conclusion</h1> 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.</p> Real Factory Game Quality of Life Changes Unknown — Sun, 16 Nov 2025 00:00:00 +0000 Overview</h1> 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</a> as well as the switch to the Avian</a> physics engine.</p> 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.</p> Switching to Avian</h2> </picture> Autogenerated Avian Collider Meshes</figcaption> </figure> </div> I had initially been using the venerable Rapier3D</a> for physics but was unsatisfied for a few reasons.</p> 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.</li> Non Ergonomic APIs.</li> No collider generation.</li> </ol> This all being said, Rapier is a solid physics engine and the work that dimforge</a> does for the Bevy community is amazing. They are just not the best fit for me.</p> Switching to Avian addressed all of these issues and made things like raycasting</a> a breeze compared to what I was doing.</p> That, and the amazing collider constructor</a> system, sealed the deal. <3 ConvexDecompositionWithConfig</a></p> I did run into one snafu though: Avian does not have a native character controller</a> like Rapier does. This being said, after reading the Avian FAQs</a>, I settled on using bevy_tnua</a>, an excellent replacement.</p> Time-wise the whole port took a day. Approximately:</p> 2 hours for all the colliders and tuning the parameters.</li> 3 hours to replace all the ray casting and to set up collision layers</a>. (With enums, very pleasant to do.)</li> 3 hours to rewire all the player controls through tnua.</li> </ul> Thanks to all the work done by Joona Aalto</a> on Avian. I am super happy to sponsor him and if you like Avian you should consider it too.</p> General Quality of Life</h1> </video> We can now jump!</figcaption> </figure> 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.</p> </picture> Instead of the broken tool tips we now have the build costs shown in the build menu.</figcaption> </figure> </div> 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.</p> </picture> We now see the costs and the available stock when we go to place buildings.</figcaption> </figure> </div> Machine Productivity</h1> </video> The mining machine now shows us ideal and real outputs.</figcaption> </figure> 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.</p> Like, I play and enjoy Satisfactory</a> and Factorio</a>. I don't know how I missed this. That being said, it's there now.</p> 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.</p> </video> The furnace shows what we actually need to input and what we are and should be outputting.</figcaption> </figure> Settings</h1> I will say part of why I was itching for Bevy 0.17 was due to the new/reworked UI using observers</a>. 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.</p> 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!</p> </p> </p> </p> Site Fancification</h1> 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.</p> 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.</p> Conclusion</h1> 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.</p> Steam Next Fest Reflections Unknown — Tue, 21 Oct 2025 00:00:00 +0000 Overview</h1> 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.</p> I never knew that so many keyboards report to the operating system that they are Xbox-branded human interface devices. Crazy.</p> Based on all that I learned, I think I can solidify the timeline for the game going forward.</p> Next Fest Results</h1> More Good Things</h2> A ton of bugs were found and quickly fixed. Thank you very much to those who reported them.</li> A ton of interest was shown in the game, both in terms of wishlists and playtime.</li> Many ideas on how to fix and improve things were given.</li> </ul> Less Good Things</h2> 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.</li> I thought the game was fully accessible for those who use accessibility devices and controllers, but from the feedback, I missed a few things.</li> </ul> Updated Timeline</h1> 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.</p> The Q4 2025 date was just unrealistic. Flat out.</p> Given this, a new plan is needed.</p> After consideration and reflection on what is best for the game, the plan is this:</p> 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.</li> Consider options on how to fund the game further, whether that be Kickstarter, investment, or working with a publisher.</li> Aim to release the full game in late 2026.</li> </ol> As someone once said: "A delayed game is eventually good, but a rushed game is forever bad."</em></p> Meme or not, I do want to release a game I am proud of.</p> Conclusion</h1> 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.</p> Demo Release and Polish Unknown — Tue, 07 Oct 2025 00:00:00 +0000 Overview</h1> 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.</p> The amount of work that has gone into this has been a lot, and we cover a good amount of it here.</p> Steam Next Fest</h2> </picture> Nice little Demo download button.</figcaption> </figure> </div> 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</a>/.exe</a> file to Steam and have them distribute it. You have to use quite a bit of Steam-specific tooling.</a> 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.</p> 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</a> or DEB</a> distributable.</p> The good news was, in the end, the game made the deadline, but with intense timing difficulties.</p> Testing Mistakes Made</h2> This leads to the next major point. If you signed up for alpha/beta testing you were not forgotten or passed over. Due to:</p> The unexpected (by me) delays in Steam approving the game.</li> The unexpected (by me) difficulties in packaging the game.</li> The sheer number of "breaking" bugs that I was crunch fixing found by friends and family.</li> </ol> I was not able to upload and get early testing keys before the Demo had to be soft launched for Next Fest.</p> 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.</p> Animations & Mechanics</h2> </video> Lifters, Belts, Splitters, and Mergers</figcaption> </figure> 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</a>. No linking or hierarchy to speak of. Just async systems running in such a way to give that illusion.</p> Long story short, the game now behaves like a game should, animations, sound, and all.</p> Demo Released + Trailer</h2> 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</a>.</p> 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.</p> Roadmap</h2> 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.</a></p> I will be providing a more detailed roadmap on this site soon. These lists are preliminary and VERY VERY incomplete.</p> Coming Sooner</h3> </picture> Accessibility Prioritized Steam Deck and Controller Support</figcaption> </figure> </div> Full accessibility prioritized Steam Deck and controller support.</li> Terrain and foliage asset rework.</li> Massive optimization overhaul.</li> The first diverging branches of technology unlocks in the tech web based on your in-game choices.</li> A public wiki like a proper factory game should have.</li> Continuing work on the "real" terrain.</li> Real power use.</li> Liquids.</li> German.</li> Test ELF binaries for aarch64</a> and RISC-V</a> if possible.</li> </ul> Coming Later</h3> Game binaries for more Rust Tier 1 and 2 targets.</a> (Anyone want to help test on the BSDs?)</li> Steam-free way to play the game Factorio</a> style.</li> Officially supported Flathub</a> / Flatpak</a> images.</li> Continuing work on the "real" terrain.</li> </ul> Conclusion</h1> The demo is out and I look forward to working on the full game. I am looking forward to seeing what people make.</p> Demo on Steam</span> </div> </a> </div> Private Alpha, Steam, & Core Functionality Unknown — Mon, 08 Sep 2025 00:00:00 +0000 Overview</h1> 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!</p> Private Alpha</h2> 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</a>. You should see a button where you can sign up there.</p> 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.</p> Steam Next Fest</h2> 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.</p> 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.</p> This is all managed by the emotional core and it's pretty cool.</p> 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.</p> Belt Fundamentals & Logistics</h2> 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.</p> 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.</p> 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.</p> Included here is a rough technical explanation of how things work under the hood. Feel free to skip this if you find it boring.</p> </video> Fancy Belt Stuff</figcaption> </figure> How Belts Actually Work</h3> 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.</p> To be clear there is no linked-list like structure anywhere. We are just tagging belt entities with a segment component.</p> Connections and Segment Formation</h3> </p> 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.</p> 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.</p> This was like 95% of the work.</p> Item Movement</h3> Items on a belt move along a piecewise set of CubicHermite Splines</a> 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.</p> Capacity, Throughput, and Backpressure</h3> 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.</p> Performance</h3> </p> 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.</p> New Buildings & Resources</h2> We've added a few new buildings since the last dev blog and they're all pretty cool.</p> Mining Platform v1</h3> </video> Mining Machine In Action</figcaption> </figure> This is the first resource extractor that the player has access to. It will extract ores from the planet just as humans taught.</p> Ancient AI Core</h3> </p> The core where you the player AI's mind resides. Where you have been... for quite a while.</p> Gas Extractor Sneak Preview</h3> </p> And here is a sneak preview of the gas extractor. Not everything is a mineral after all.</p> Music</h2> Super happy to be working with Repto Eternef</a> 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.</p> Dialogue & The Emotional Core</h2> </p> Lastly, but certainly not least, the emotional core and dialogue system was added.</p> 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.</p> 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.</p> 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.</p> Conclusion</h1> 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. :)</p> Exofactory is now available on Steam! If you are interested in the game I would encourage you to consider wishlisting it there.</p> Wishlist on Steam</span> </div> </a> </div> 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.</p> Wishlist on Steam</span> </div> </a> </div> Overview</h1> 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.</p> Additionally, I did give a presentation at Bornhack 2025</a> 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.</p> Animation</h1> 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</a> by Chris Biscardi</a>. He is doing a ton for the Bevy community and I see his work everywhere.</p> 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.</p> Skein on the Bevy side sees those embedded components and makes them available in Bevy's Entity Component System</a>. This saves a ton of time and boilerplate code.</p> </video> Programmatic Control of Lifter Animation</figcaption> </figure> 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.</p> </video> Motion Transitions</figcaption> </figure> In addition to more interesting programmatic animation we are using Bevy's animation graph system</a>. 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.</p> Resources</h1> We now have resources! We are starting with iron and copper. Soon we should see some machines start to get to work!</p> 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.</p> 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.</p> Terrain v3</h1> The Bevy space is full of halfborn, unmaintained, and poorly documented terrain level of detail (LoD)</a> 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:</p> Spawning and despawning terrain based on the location of multiple</em> cameras.</li> Swapping in higher and lower resolution meshes and textures based on the location of said multiple cameras.</li> Handling LoD for terrain details like foliage or stones.</li> Doing all of this in a performant Bevy native ECS way.</li> </ol> </video> Level of Detail System Testing</figcaption> </figure> 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.</p> 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.</p> </video> Terrain v3 with only base colors</figcaption> </figure> 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.</p> Conclusion</h1> 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.</p> Terrain, Animation, and Major Work Done Unknown — Sun, 06 Jul 2025 00:00:00 +0000 UPDATE:</strong> We were approved and Exofactory is now available on Steam</a>.</p> Overview</h1> 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</a>, and we have everything in line to get our steam presence up.</p> Also over the month I had the pleasure of attending GPN23</a> 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</a>. The cool thing is that this talk was received well enough that I could justify giving a longer extended presentation at an upcoming event.</p> As a bonus Julef</a> shares a peek behind the scenes at her work on Exofactory in her first blog contribution.</p> More to come.</p> Animation</h1> Where a ton of work shows is the animation and 3d work by Julef</a>. I am super excited to add these to the game.</p> </video> Wave Animation</figcaption> </figure> </video> Walk Animation</figcaption> </figure> </video> Idle Animation</figcaption> </figure> </video> Scene with Belts and Machines</figcaption> </figure> Behind the Scenes with Julef</h1> Hello, Julija here – Art Director and head of the full Art Development team for Exofactory.</p> I'd like to share a quick art update on the game.</p> Over the past month, we've been focused on refining assets and enhancing the terrain.</p> One of the key highlights: the Fabricator has received a complete visual overhaul with a brand-new look.</p> </div> We added more belts with Level 1 and 2 and gave them a life. Things are starting to move!</p> </video> </figure> The Exoframe also came to life with a working rig and animations – big thanks to Juan</a>, who supported the rig setup and created the animation work!</p> </video> Walk Animation</p> </div> </video> Wave Animation</p> </div> </video> Idle Animation</p> </div> </div> We successfully completed and submitted First Visuals for Steam.</p> </p> And here you can see what is happening behind the scenes.</p> </p> Terrain</h1> </p> Cait here agan! If the imaga above is terrain v2 below you will see v2.5.</p> 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.</p> 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.</p> Steam Screenshots</h1> </p> The screenshots were the killer for me. I had initially planned to set up our Steam presence much</em> sooner, but I just couldn't get the screenshots to a point where they actually represented the game.</p> Bevy</a>, 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</strong> exactly like a player would. Given that thing like deleting building haven't been added yet, you can imagine how this went.</p> 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.</p> So without further ado here are the in game images that will be submitted to Steam. We expect the game to be approved soon.</p> </p> </p> </p> </p> Conclusions</h1> All in all a productive month. Great work was done all around, particularly by Julef.</p> 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.</p> This month was great and soon that greatness will be rock solid.</p> Our Art Lead, ESC, and the 3D Rework Unknown — Sun, 25 May 2025 00:00:00 +0000 Overview</h2> 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).</p> The largest of these changes is that Exofactory now has an art lead. So we should start to see some visual improvements soon.</p> Art Lead</h2> 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.</p> I simply lack the skills and don't think the game would be best served by me driving the art direction.</p> We've been working together for a bit now and the game now has an aesthetic that we are aiming for.</p> I'm excited to work together and lots is to be done.</p> If you want to learn more about Julija, you can take a look at her portfolio here.</a></p> ESC</h2> 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!</p> 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.</p> We're now 3D!</h2> </p> 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.)</p> 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.</p> </p> Funnily enough, generating the terrain takes just enough time to justify adding a game loading screen. So we now have one of those.</p> </p> Conclusion</h2> Pretty happy this week. Lots of important work was started and the game now has an artistic direction.</p> Art and Artists Unknown — Sat, 10 May 2025 00:00:00 +0000 Overview</h2> 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.</p> Art and Artists</h2> I am a programmer, not an artist so I made a few mistakes. Namely focusing on 2d artists.</p> 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.</p> I was told that hiring a 3D artist and doing a UV map</a> 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.</p> Before I was told this though I did get some concept art that's pretty cool.</p> </p> A bit too round compared to what I was looking for but cool for sure.</p> </p> Quite like this one.</p> Sadly this 2D concept art can't really be taken further, but it helps define the game energy which is a good thing.</p> Conclusion</h2> 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.</p> Offsets, Menus, Accessibility, and 0.16 Unknown — Sat, 03 May 2025 00:00:00 +0000 Overview</h2> 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</p> This being said, major work was done this week, both behind the scenes, and user facing stuff. All of which is exciting.</p> Bevy 0.16</h2> The first big task was porting the game from Bevy 0.15 to 0.16</a>. I had 3 reasons for this.</p> I plan on starting work on belts soon. I plan on heavily using the new ECS Relationships feature</a> to manage belt sources and sinks. Without this I would just have ended up writing "ECS Relationships at home".</li> I wanted to use the stabilized Input Focus feature</a>. This is important for accessibility and gamepad support. (More details below.)</li> 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.</li> </ol> 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</code> for Single</code> where I could. This let me delete a lot of if let Some(x) =</code> style code removing a lot of nesting which is nice.</p> 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.</p> Menus & Accessibility</h2> </p> The other big project this week was the new complete-ish build menu.</p> 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.</p> Conclusion</h2> 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.</p> Building Menus, Gamepads, and Change Unknown — Sat, 26 Apr 2025 00:00:00 +0000 Overview</h2> This week started with a nearly completely different set of goals than the week ended with. Things changed when Pokinsson </a> 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.</p> 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.</p> That being said, progress was made.</p> Half-Baked Gamepad Support</h2> 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</a>; I strongly recommend them.</p> I added a lot of mappings and controller-management code, so now, going forward, I can do something like:</p> let focus_on_exoframe: Handle<Image> = smart_prompt_collection.focus_on_exoframe.clone(); </code></pre> 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.</p> I didn't get any further than this, but I do have a list of supported devices/control schemes. I plan on supporting:</p> The Steam Deck with built-in controllers, a keyboard and mouse, or an Xbox One controller.</p> Modern (Debian 11 or newer) Linux with a keyboard and mouse or an Xbox One controller.</p> Windows 10/11 with a keyboard and mouse or an Xbox One controller.</p> Other systems or controllers should work but won't be tested. For more information on what may or may not work, see gilrs</a>, the underlying library I am using via Bevy.</p> Control Guide</h2> </p> 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.</p> This is great for the technical preview and for the game in general.</p> Building Interface</h2> </p> Last but not least, I added a core new feature to the game: an in-game building can now produce a thing!</p> Conclusion</h2> 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.</p> UI Foundations Laid Unknown — Sat, 19 Apr 2025 00:00:00 +0000 Overview</h2> This week was primarily focused on adding basic UI elements, working on Exoframe movement, and adding initial game sounds.</p> 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.</p> Overall this week was not too bad in terms of the timeline.</p> Fleshing Out The UI</h2> Exofactory is being written in Bevy</a>, and while it has been quite enjoyable overall I must say that the UI developer experience is absolutely not fun. Future Bevy</a> 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.</p> 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.</p> </p> 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.</p> Overall happy with things here.</p> Experiment With Sound</h2> 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</a> I have a few sounds I am happy with. For example the menu mouse over I find quite nice.</p> Your browser does not support the audio element. </audio> I still need to add a sound section to the settings menu, but that can wait for now.</p> Exoframe Motion</h2> </p> 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.</p> Conclusion</h2> Bottom line, I am happy with this week. I aim to release weekly dev blogs and monthly video blogs, so keep an eye out.</p>

Exofactory Dev Blog

Technical Rework of Belts, and Global Planning Mode

Step 3 - Making the Belt Do Belting</h3> </video> A working belt carrying ore along a complex path.</figcaption> </figure> 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.</p>

Work to Be Done</h3> The spline-based belt system is working, but it isn't fully done yet. At least I want to:</p> Use the actual texture for the belt rails. Simple in theory, but annoying to do cleanly.</li>

Building Animation, Trailer, & Pitch Deck Stuff

Conclusion</h1> 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.</p>

Optimizations, PRs, Tooling, & Funds

Overview</h1> 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.</p>

Finding a bug in Bevy around KTX2</h2> In moving to KTX2 files one of the bugs I noticed is that Bevy was not honoring the .meta</code> files for ktx2 files. One small PR later</a> and it was fixed. This fix will be included in Bevy 0.18.1</p>

Multiplayer, Bevy 0.18, and Fosdem

Overview</h1> This month was basically solely focused on adding multiplayer functionality with a small break for a bevy 0.18 migration.</p>

Real Time Settings, Save Overhaul, & a Wiki

Overview</h1> 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.</p>

Draggable Belts, Electricity, & View Modes

Conclusion</h1> 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.</p>

Real Factory Game Quality of Life Changes

General Quality of Life</h1> </video> We can now jump!</figcaption> </figure> 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.</p>

Conclusion</h1> 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.</p>

Steam Next Fest Reflections

Next Fest Results</h1>

Conclusion</h1> 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.</p>

Demo Release and Polish

Testing Mistakes Made</h2> This leads to the next major point. If you signed up for alpha/beta testing you were not forgotten or passed over. Due to:</p> The unexpected (by me) delays in Steam approving the game.</li> The unexpected (by me) difficulties in packaging the game.</li>

Conclusion</h1> The demo is out and I look forward to working on the full game. I am looking forward to seeing what people make.</p>

Private Alpha, Steam, & Core Functionality

New Buildings & Resources</h2> We've added a few new buildings since the last dev blog and they're all pretty cool.</p>

Ancient AI Core</h3> </p> The core where you the player AI's mind resides. Where you have been... for quite a while.</p>

Gas Extractor Sneak Preview</h3> </p> And here is a sneak preview of the gas extractor. Not everything is a mineral after all.</p>

Conclusion</h1> 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. :)</p> Exofactory is now available on Steam! If you are interested in the game I would encourage you to consider wishlisting it there.</p>

Animation, Motion, & Terrain v3

Overview</h1> 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.</p>

Terrain, Animation, and Major Work Done

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

Our Art Lead, ESC, and the 3D Rework

Conclusion</h2> Pretty happy this week. Lots of important work was started and the game now has an artistic direction.</p>

Art and Artists

Overview</h2> 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.</p>

Offsets, Menus, Accessibility, and 0.16

Conclusion</h2> 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.</p>

Building Menus, Gamepads, and Change

Building Interface</h2> </p> Last but not least, I added a core new feature to the game: an in-game building can now produce a thing!</p>

Conclusion</h2> 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.</p>

UI Foundations Laid

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

Conclusion</h1>
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.</p>

Finding a bug in Bevy around KTX2</h2>
In moving to KTX2 files one of the bugs I noticed is that Bevy was not honoring the `.meta</code> files for ktx2 files. One small PR later</a> and it was fixed. This fix will be included in Bevy 0.18.1</p>`

Conclusion</h1>
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.</p>

Conclusion</h1>
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.</p>

Conclusion</h1>
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.</p>

Conclusion</h1>
The demo is out and I look forward to working on the full game. I am looking forward to seeing what people make.</p>

Demo on Steam</span> </div> </a> </div>

New Buildings & Resources</h2>
We've added a few new buildings since the last dev blog and they're all pretty cool.</p>

Ancient AI Core</h3>
</p>
The core where you the player AI's mind resides. Where you have been... for quite a while.</p>

Gas Extractor Sneak Preview</h3>
</p>
And here is a sneak preview of the gas extractor. Not everything is a mineral after all.</p>

Conclusion</h2>
Pretty happy this week. Lots of important work was started and the game now has an artistic direction.</p>

Overview</h2>
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.</p>

Conclusion</h2>
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.</p>

Building Interface</h2>
</p>
Last but not least, I added a core new feature to the game: an in-game building can now produce a thing!</p>

Conclusion</h2>
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.</p>

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