https://morgenthum.dev Developer blog about game development with Rust & Bevy, and other projects. Zola en Sat, 21 Mar 2026 00:00:00 +0000 Sat, 21 Mar 2026 00:00:00 +0000 Mario Morgenthum https://morgenthum.dev/blog/weather-tablet-for-quest-planning/ https://morgenthum.dev/blog/weather-tablet-for-quest-planning/ <p>Wild Spikes has dynamic weather. Rain, sun, clouds - the conditions change over time and affect the world. Some quests are easier to complete under certain weather conditions. Until now, the player had no way to know what was coming. That changes with the weather tablet.</p> <p><img src="/img/weather_tablet.png" alt="The weather tablet in Wild Spikes" /></p> <h2 id="what-it-does">What it does</h2> <p>The weather tablet shows a forecast of upcoming weather conditions. The player can pick it up, check what the next hours will look like, and plan accordingly. If a quest requires sneaking past NPCs and rain is coming - which reduces visibility - it might be worth waiting. If the sun is about to come out, it might be a good time to gather resources that only appear in clear weather.</p> <p>It turns weather from a background system into something the player actively thinks about.</p> <h2 id="how-it-is-built">How it is built</h2> <p>The tablet is split into two crates:</p> <p><strong>weather_app</strong> is a pure UI application that renders the forecast. It takes weather data as input and displays it. It has no knowledge of the game world, no physics, no 3D. It can run as a standalone Bevy app, which makes it easy to develop and test in isolation.</p> <p><strong>weather_tablet</strong> handles the integration into the game. It renders the app onto a display in the 3D world, manages colliders for interaction, and bridges the weather simulation data into the app. Everything that ties the tablet to the game lives here.</p> <p>This separation follows the same layered architecture I described in my <a href="https://morgenthum.dev/blog/introduce-layers-into-bevy/">previous post</a>. The app sits in the engine layer - it is a generic, reusable UI component. The tablet crate sits in the game features layer, where it connects the app to the actual game systems.</p> Tue, 10 Mar 2026 00:00:00 +0000 Mario Morgenthum https://morgenthum.dev/blog/introduce-layers-into-bevy/ https://morgenthum.dev/blog/introduce-layers-into-bevy/ <p>Wild Spikes is a survival and stealth game with quests, day/night cycles, weather, crafting, and other systems you would expect in a full-fledged game. I'm building it with Rust and Bevy, targeting PC and mobile. As the project grows, keeping things organized becomes critical. In this post I want to share the architecture I use and the thinking behind it.</p> <h2 id="the-problem">The problem</h2> <p>Bevy makes it easy to add systems and plugins. I started the project as one crate, with a few plugins that all lived together, operating on one State, SubState, or ComputedState. It was great for getting something up and running quickly.</p> <p>As the plugins grew, it became harder to keep track of dependencies. The moment I introduced the HUB - a separate screen for opening the inventory and crafting menu - the whole thing became messy. I couldn't test it because everything was wired together, either through direct dependencies or through shared states. Sometimes my character controller blew up, sometimes the HUB exploded, and every time I had to fix something while keeping the whole picture in mind.</p> <p>I didn't just want Bevy plugins - I wanted real self-contained modules. So I split the codebase into multiple crates. Some were more game-specific, others more generic. After a few iterations, I introduced a separate "engine" layer to abstract some of the game-specific details and keep things inside the game cleaner and more focused. After further iterations, I arrived at the architecture I'm currently using. I'm sure it's not perfect, but it has been working well for me so far.</p> <h2 id="the-layers">The layers</h2> <p>The architecture is organized in layers, ordered from the bottom up. Each layer can only depend on layers below it - never upward.</p> <pre><code>Product Apps apps&#x2F;* Platform entries (desktop, mobile) Sandboxes sandboxes&#x2F;* Prototyping, experiments Game Assembly assembly&#x2F; Composition root, states, scheduling App Bootstrap bootstrap&#x2F; Bevy defaults, window, logging Game Features game&#x2F;* Survival, quests, NPCs, UI Game Core game&#x2F;core Shared contracts, events, tags Engine Modules engine&#x2F;* Generic tech, no game knowledge </code></pre> <h2 id="what-lives-where">What lives where</h2> <p><strong>Engine Modules</strong> are the foundation. These are reusable building blocks that know nothing about the actual game. Things like a camera controller, input actions, weather/time simulation, navigation, animation utilities, and visual effects. They work with generic components and traits. You will never find a <code>Snail</code> or <code>Fox</code> type here.</p> <p><strong>Game Core</strong> defines the shared contracts. Data structures, traits, events, and marker components that game features need to communicate at the lowest level. It contains no gameplay logic itself - just the vocabulary that features use to talk to each other.</p> <p><strong>Game Features</strong> is where the actual game lives. Each feature is its own crate with its own plugin, covering a self-contained part of the game. The character crate handles the player controller, stealth, and survival mechanics. The NPC crate owns concrete creature logic like the owl's behavior. Narrative contains the dialogue and quest systems. Gameplay covers crafting, inventory, and object spawning. Features depend on Game Core and Engine Modules, and can depend on each other when explicitly needed.</p> <p><strong>App Bootstrap</strong> handles the Bevy boilerplate: default plugins, window setup, logging, settings I/O. Both the real game and sandboxes use this.</p> <p><strong>Game Assembly</strong> is the composition root. It wires everything together: which plugins to load, which states exist, how system sets are ordered, and which feature flags are active. No gameplay logic here - just configuration.</p> <p><strong>Sandboxes</strong> are throwaway apps for prototyping. They can reach into any layer, which makes them great for quick experiments without polluting the real codebase.</p> <p><strong>Product Apps</strong> are the final binaries. A desktop app, a mobile app. They do almost nothing - just connect Bootstrap and Assembly.</p> <h2 id="the-dependency-rules">The dependency rules</h2> <p>The core principle is simple: dependencies only point downward. But there are a few extra rules that matter:</p> <ul> <li>Engine Modules must never reference concrete game types. No <code>Owl</code>, no <code>QuestLog</code>. Only generic components and traits.</li> <li>Game Features must not use closed enums that grow with every new content type. Instead, I use composition via components. Each concrete type builds its own set of behavior components.</li> <li>Game Core defines generic contracts. Concrete implementations belong in the features.</li> <li>Product Apps contain no gameplay logic. They only wire Bootstrap and Assembly.</li> </ul> <p>These rules are not just documented - they are enforced. A custom <code>xtask</code> lint checks the dependency graph on every CI run.</p> <h2 id="communication-between-features">Communication between features</h2> <p>Features do not reach into each other's internals. Instead, they communicate through clear public APIs:</p> <ul> <li><strong>Events and Messages</strong> are the main tool for cross-feature communication. One feature sends a <code>StartDialogue</code> or <code>GiveItem</code> event, another reacts to it. No direct coupling needed.</li> <li><strong>Public components</strong> allow features to spawn entities that other features understand. A feature can attach a marker component that another feature's systems pick up.</li> </ul> <p>Direct queries into another feature's private components are not allowed. If it is not part of the public API, it does not exist for other features.</p> <h2 id="scheduling">Scheduling</h2> <p>One important aspect is the scheduling of systems. I thought my plugins were independent, but they were not. Even after splitting them into separate crates, they were still tightly coupled through states - which were not available in isolated examples or sandbox apps. So I introduced injectable schedules for each plugin. It looks like this:</p> <pre data-lang="rust" class="language-rust "><code class="language-rust" data-lang="rust">pub struct CharacterPlugin { spawn_schedule: Interned&lt;dyn ScheduleLabel&gt;, despawn_schedule: Interned&lt;dyn ScheduleLabel&gt;, input_schedule: Interned&lt;dyn ScheduleLabel&gt;, interact_schedule: Interned&lt;dyn ScheduleLabel&gt;, camera_collision_schedule: Interned&lt;dyn ScheduleLabel&gt;, } </code></pre> <p>The <code>CharacterPlugin</code> combines all character-related systems, such as camera following, collision, hovering, ground adjustment, and so on.</p> <p>The initialization in the game assembly looks like this:</p> <pre data-lang="rust" class="language-rust "><code class="language-rust" data-lang="rust">app.add_plugins( CharacterPlugin::new( OnEnter(AppState::InGame), OnExit(AppState::InGame), Update, Update, PostUpdate, ) ); </code></pre> <p>But in examples or sandbox apps it can be initialized like this:</p> <pre data-lang="rust" class="language-rust "><code class="language-rust" data-lang="rust">app.add_plugins( CharacterPlugin::new( OnEnter(SandboxState::Running), OnExit(SandboxState::Running), Update, Update, PostUpdate, ) ); </code></pre> <p>That way, the functionality of my self-contained crates is truly self-contained. I can test them in isolation without having to worry about the rest of the game.</p> <h2 id="why-it-matters-for-me">Why it matters (for me)</h2> <ul> <li>Every crate in every layer can have its own examples. This lets me test them in isolation.</li> <li>Through isolated testing, I can clearly see when something feels messy or when the API is lacking. If I have to reach into another crate or add a bunch of unrelated plugins, it is a sign that the public API of that crate is not good enough.</li> <li>Smaller crates mean faster incremental builds. When I change something in a game feature, only that crate and the layers above it need to recompile - not the entire project.</li> <li>Clear boundaries make it easier to reason about changes. I can refactor the internals of a feature without worrying about breaking other features, as long as the public API stays the same.</li> <li>The engine modules are not tied to Wild Spikes. I can reuse them in other projects or share them as standalone crates.</li> <li>Sandboxes let me prototype new ideas quickly. I can try out a new mechanic or visual effect without touching the real game code - and throw it away if it doesn't work out.</li> </ul> <h2 id="a-note-on-perspective">A note on perspective</h2> <p>I'm not a professional game developer. My background is in software architecture, and I lean on the usual principles - SOLID, design patterns, clear boundaries - to keep things manageable. I'm not one of the experienced engine developers you meet on the Bevy Discord who live deep in ECS internals and rendering pipelines. This architecture is shaped by what I know, and it works for me.</p> <h2 id="by-the-numbers">By the numbers</h2> <p>As of today, Wild Spikes has 14 states, 97 plugins, and 71 system sets. I track these with <a href="https://github.com/morgenthum/bevy_xray">bevy_xray</a>, a small tool I built to inspect the structure of a Bevy app.</p> Mon, 09 Mar 2026 00:00:00 +0000 Mario Morgenthum https://morgenthum.dev/blog/welcome/ https://morgenthum.dev/blog/welcome/ <p>It's finally here - my developer blog is online!</p> <h2 id="what-to-expect">What to expect</h2> <p>I'm currently working on <strong>Wild Spikes</strong>, a 3D game I'm building with <a href="https://www.rust-lang.org/">Rust</a> and the <a href="https://bevyengine.org/">Bevy Engine</a>. I constantly run into interesting challenges and pick up new insights that I'd like to share here.</p> <p>The topics will mostly revolve around <strong>game development with Rust</strong>, but other projects and general software development may show up as well.</p> <h2 id="the-tech-stack-of-this-blog">The tech stack of this blog</h2> <p>This blog itself is also a small Rust project - it's generated with <a href="https://www.getzola.org/">Zola</a>, a blazingly fast static site generator written in Rust. I write posts in Markdown, and Zola takes care of the rest.</p> <p>To be honest - if I had written and styled this blog by hand, it would look like something from the 90s. I used Claude to generate it. I gave it a few prompts about my preferences, technologies, and it came up with the design, layout, and even the color scheme. I just had to make a few tweaks to get it right.</p> <p>See you soon!</p>