Input 1</th>	Input 2</th>	Direction</th></tr></thead>
`0</code></td>`	`0</code></td>`	Off</td></tr>
`1</code></td>`	`0</code></td>`	Forward</td></tr>
`0</code></td>`	`1</code></td>`	Backward</td></tr>
`1</code></td>`	`1</code></td>`	Off</td></tr> </tbody></table> Power supply</h3> I also picked up this very small power supply</a> and regulator, which has the important trait of current limiting so that I'm not relying solely on software to prevent catastrophic failure. A rail layout is essentially a long route of unshielded wires; a short is very likely, if not unavoidable. (Adding some additional protection like a fuse or software shutoff probably wouldn't be a terrible idea either).</p> </img> Power supply with the screen on. Note how both the voltage and amperage are adjustable.</figcaption> </figure> Hooking up the modules</h3> TrainElectronics.com helpfully includes a schematic</a>, albeit with a different motor driver. I adopted this to my own schematic based on the ESP32-C3, and eventually the C6. The ESP-C boards are fun and relatively inexpensive, but the C3 has a few clones with limited GPIO. I ended up purchasing a replacement ESP32-C6 board with several more pins that I'll be transitioning to later on, but the difference between the two is seemingly very negligible for my use case.</p> </img> This board has way too many power inputs. The MCU itself does have more pins left unconnected, and they are actually hooked up on some other clones.</figcaption> </figure> I use a circuit to invert the signal 6</a></sup>, as opposed to inverting using software with 2 separate pins (this is an option with DCC-EX). However, I don't see the benefit to doing this. It's a super simple circuit to create, allows for a simpler software implementation, and frees up an extra pin. It's not super clear by looking at it, but it appears that inputs `1</code> and 3</code> get the inverted signal, whereas 2</code> and 4</code> get the original signal` `7</a></sup>.</p>` </img> Schematic for the DCC signal inverter circuit</figcaption> </figure> </img> DCC signal inverter for both channels with chunky through-hole components</figcaption> </figure> Digging into DCC</h2> Before we can transmit anything, we need a way to build and serialize DCC data. Thankfully, a DCC crate called dcc-rs</code> already exists</a>, albeit on an outdated version of hal</code>. This is easily remedied with a few quick updates</a>. Now we just need a way to spit the data out to our motor controller.</p> DCC bits are distinguished based on the length of their pulse. At first, I attempted a bitbang solution with the dcc-rs library, but my timing was always too slow or completely off when taking a look in Pulseview. I tried changing timing, adding manual delays, and other hacks, but was never getting consistent results. Thankfully, the ESP32-C3 and C6 offer a hardware peripheral called "Remote Control Transceiver" or RMT that can help. IR remotes use a similar method of transmitting bits, and we can use this device to generate the signal we want quickly8</a></sup>. Using this method, I was able to successfully decode within Pulseview and send a signal to a commercial DCC decoder.</p> //</span> Building a pulse sequence and transmitting with the RMT peripheral</span></span> for</span> (</span>bit</span>,</span> pulse</span>)</span> in</span> new_data</span>[</span>..</span>len</span>]</span>.</span>iter</span>(</span>)</span>.</span>zip</span>(</span>pulse_buffer</span>[</span>..</span>len</span>]</span>.</span>iter_mut</span>(</span>)</span>)</span> {</span></span> </span>pulse</span> =</span> match</span> </span>bit</span> {</span></span> true</span> =></span> PulseCode</span>::</span>new</span>(</span></span> false</span>,</span></span> dcc_rs</span>::</span>ONE_MICROS</span> as</span> u16</span>,</span></span> true</span>,</span></span> dcc_rs</span>::</span>ONE_MICROS</span> as</span> u16</span>,</span></span> )</span>,</span></span> false</span> =></span> PulseCode</span>::</span>new</span>(</span></span> false</span>,</span></span> dcc_rs</span>::</span>ZERO_MICROS</span> as</span> u16</span>,</span></span> true</span>,</span></span> dcc_rs</span>::</span>ZERO_MICROS</span> as</span> u16</span>,</span></span> )</span>,</span></span> }</span>;</span></span> }</span></span> rmt</span>.</span>transmit</span>(</span>&</span>pulse_buffer</span>[</span>..</span>len</span> +</span> 1</span>]</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span> //</span> Much easier than trying to juggle timers!</span></span></code></pre> </source> Your browser does not support the video element.</p> </video> An early test. The MCU sends forward commands to address 03 (the default for this decoder) immediately on boot. I also have the loco motor power wired backwards, oops.</figcaption> </figure> Note: Receiving data</h4> I didn't end up with a working solution for receiving</em> DCC data, but did learn a few things about optoisolators. I've used these previously to decode MIDI data from keboards and synthesizers, using a 6N138</code>. It turns out that this is a little too slow for our applications, and the 6N137</code> is more commonly recommended as it is faster. The info around all this stuff, like MIDI, is pretty dated, and apparently nowadays digital isolators exist that are superior.</p> </blockquote> Note: Why not wireless?</h4> Why even go through this trouble when wireless communication exists? That is an excellent question - especially when the ESP32 boards I'm using support wireless, and even have mesh network support. I wanted to write this in Rust, which didn't have great support</a> for what I was looking for at the time of writing. Plus, using DCC grants a ton of compatibility with commercial accessories and locomotives, as many come "DCC ready". If you are interested in mesh network control of locos, someone's already done that!</a>.</p> </blockquote> Display</h2> I bought an OLED screen labeled SSD1322</code>. Despite being grayscale, it's relatively large, extremely bright, and has excellent support with the ssd1322_rs</code> crate. The units I found on Aliexpress needed to be converted to "4 wire" SPI by soldering some bridges. Note that I was unable to get it working with the advertised 3 wire mode, (even though we aren't using MISO).</p> </img> Back of the OLED module with bridged connections</figcaption> </figure> Housing</h2> Before this project, I used SolveSpace - a relatively simple parametric CAD program. However, around this time, FreeCAD 1.0 was released with a ton of improvements that made it much more stable and all-around sort-of-usable, so I decided to give it a go. I was able to create a simple housing and print a successful fit after a few attempts.</p> </img> Transmitter housing in FreeCAD</figcaption> </figure> FreeCAD is still very rough around the edges, but it's usable, and much more powerful than SolveSpace. The normal thing to do would be to just use SolidWorks, but I'm too cheap.</p> Putting everything together</h2> </img> Transmitter schematic</figcaption> </figure> </img> Testing the USB fit and stuffing cables into the enclosure</figcaption> </figure> </source> Your browser does not support the video element.</p> </video> The working minimal prototype. Fed up with the relatively dirty signal of my generic rotary encoders, I added a huge jogwheel using an optical rotary encoder, which was extremely unnecessary, but kind of cool.</figcaption> </figure> I used a very neat library for the UI called Kolibri</a>. I'm surprised how seemingly relative few people are working in the Rust embedded graphics/UI space, since these projects are a lot of fun. Kolibri does not yet support devices without a pointer</a>, so I achieved my effect with a "virtual pointer" that moves a set distance to each interactive element on the UI.</p> Rust on embedded</h2> The source code for this project, including the KiCAD and FreeCAD files, is freely available</a>.</p> A few thoughts after approaching a larger embedded project:</p> Embassy makes embedded development much more approachable, even more than RTIC, which was my previous go-to.</li> Espressif and STM chips seem to be among the best supported by embedded Rust, and getting set up is far simpler than it used to be.</li> The Rust embedded ecosystem is relatively small compared to something like its game development scene, but it's still full of highly knowledgable, helpful, and friendly people who help make this language both approachable and powerful.</li> </ul> Footnotes</h2> ^{1</sup> This seems to be the right lingo but I wish I could just say "train".</p> </div>}^{2</sup> Some people set up blocks of DC control but honestly that seems like such a hassle, and I'm pretty sure I'd burn down my house.</p> </div>}^{3</sup> It also probably has some protection built in for driving inductive loads which is helpful.</p> </div>}^{4</sup> I didn't explore it yet, but current sense is also used in a bi-directional extension to DCC called Railcom.</p> </div>}^5</sup>Source: https://lastminuteengineers.com/l298n-dc-stepper-driver-arduino-tutorial/</a></p> </div> ^6</sup>Source: https://dcc-ex.com/reference/hardware/motorboards/L298N-motor-board-setup.html</a></p> </div> ^{7</sup> This upsets me greatly as an audio person who percieves the first channel as left and default.</p> </div>}^8</sup>The popular FastLED library</a> for Arduino also works by utilizing the RMT device.</p> </div> birthday_system.system() 2024-09-08T00:00:00+00:00 </p> Table of contents</h3> 4 years of bevy</strong></a> Best bevy improvements</a></li> Organizing a bevy project for honor and success</a></li> Lessons from the past</a></li> </ul> </li> Looking forward</strong></a> What I'm still waiting for</a></li> bsn!</a></li> </ul> </li> Closing</strong></a></li> </ul> 4 years of bevy</h2> Bevy released 4 years</a> ago. Feel old yet? Well, I do, because my dive into making games with Rust started even earlier than that.</p> 5 years ago, Bevy didn't exist. The popular choices for Rust game engines were "Piston</a>", a modular game engine which pioneered a ton of useful crates1</a></sup>, and "Amethyst</a>", a data-oriented, ECS-driven game engine, both of which are no longer in active development2</a></sup>.</p> </p> I have a particularly strong attachment to Amethyst, being an esteemed "Emeritus Member" of the Amethyst foundation</a>. (If you don't know what that means, it's basically like being Knighted, except without the problematic implications of serving the Royal Family, so it's actually far more prestigious in that regard).</p> I like to think the spirit of Amethyst is living on despite its ceased development, as Amethyst directly inspired</a> Bevy. Take a look at some sample code</a> from an Amethyst project I wrote 5 years ago:</p> #</span>[</span>derive</span>(</span>Default</span>)</span>]</span></span> pub</span> struct</span> MovementSystem</span> {</span>}</span></span> </span> //</span> I was much newer to Rust at this point, but</span></span> //</span> I'm pretty sure this was idiomatic in Amethyst</span></span> impl</span><</span>'</span>a</span>></span> System</span><</span>'</span>a</span>></span> for</span> MovementSystem</span> {</span></span> type</span> SystemData</span> =</span> (</span></span> ReadStorage</span><</span>'</span>a</span>,</span> Movement</span>></span>,</span></span> WriteStorage</span><</span>'</span>a</span>,</span> Transform</span>></span>,</span></span> Read</span><</span>'</span>a</span>,</span> Time</span>></span>,</span></span> )</span>;</span></span> </span> fn</span> run</span>(</span>&</span>mut</span> self</span>,</span> (</span>movements</span>,</span> mut</span> transforms</span>,</span> time</span>)</span>:</span> Self</span>::</span>SystemData</span>)</span> {</span></span> for</span> (</span>movement</span>,</span> transform</span>)</span> in</span> (</span>&</span>movements</span>,</span> &</span>mut</span> transforms</span>)</span>.</span>join</span>(</span>)</span> {</span></span> //</span> move at a constant speed in the direction</span></span> transform</span>.</span>append_translation</span>(</span>movement</span>.</span>next</span>(</span>&</span>time</span>)</span>)</span>;</span></span> }</span></span> }</span></span> }</span></span></code></pre> This all might look strangely familiar, even if you've never heard of Amethyst. We're defining a type SystemData</code> that describes all the parameters we want to retrieve from our world, and then join</code> it, sort of like a Query</code>. In Bevy, this would look like the following:</p> fn</span> movement_system</span>(</span>mut</span> query</span>:</span> Query</span><</span>(</span>&</span>Movement</span>,</span> &</span>mut</span> Transform</span>)</span>></span>,</span> time</span>:</span> Res</span><</span>Time</span>></span>)</span> {</span></span> for</span> (</span>movement</span>,</span> mut</span> transform</span>)</span> in</span> query</span>.</span>iter_mut</span>(</span>)</span> {</span></span> transform</span>.</span>append_translation</span>(</span>movement</span>.</span>next</span>(</span>&</span>time</span>)</span>)</span>;</span></span> }</span></span> }</span></span></code></pre> In essence, we're still defining SystemData</code>, but defined in the parameters of our system. Visually, we can see how Bevy has improved the ergonomics of using an ECS over the past 5 years, and not just because I unfairly added two lines of comments to the first snippet. This is a very, very small facet of improvements, so while we're on the topic, I'd be remiss if I didn't talk about</p> My favorite bevy improvements since v0.1</h2> Subjective lists are fun! Do you agree? Do you disagree? Remember to leave a comment, and tap that notification bell.</p> system()</code>less systems</h3> If you're newer to Bevy, this post's title might not mean much to you, but back in Bevy v0-something, we registered systems like</a>:</p> App</span>::</span>build</span>(</span>)</span>.</span>add_startup_system</span>(</span>setup</span>.</span>system</span>(</span>)</span>)</span></span></code></pre> Amusingly, this, combined with developers' propensity to suffix their system functions respectively, led to system registrations that look like:</p> App</span>::</span>build</span>(</span>)</span>.</span>add_startup_system</span>(</span>birthday_system</span>.</span>system</span>(</span>)</span>)</span></span></code></pre> This is no more as of Bevy 0.6</a> which requires only the function name - no system()</code> call necessary.</p> Bevy is fun to write, as its thoughtful design dovetails with Rust's type system and language features. After some practice, Bevy's API fades away into the background3</a></sup>.</p> </blockquote> Better shaders</h3> I'm really not a math guy. I still don't "get" Quaternions (and I'm not fully convinced anyone else does). By extension, I'm not much of a graphics guy. Adding a custom shader to Bevy when it first released involved touching render code and writing a thesis of boilerplate that I was never able to defend against rustc. With 0.6</code> Bevy moved to wgsl</code> and simplified custom shader creation. 8 releases later, I finally managed to implement a star background shader.</p> I would still love to see more tutorials in this space, specifically for wgsl</code>.</p> Gizmos</h3> Gizmos, introduced in 0.11</a>, are a selection of "immediate mode" drawing primitives useful in debugging and prototyping. Gizmos are perfect for prototyping quick ideas while avoiding the added complexity of assets. I wrote a modest but respectable ~3,000 line project visualizing with only Gizmos before moving on to proper models.</p> </span> doomy 🦀</h6> @doomy@mastodon.social</p> </div> </a> </video> September 7, 2024 at 3:08 AM </a> </div> Triggers and observers</h3> I can't include the removal of .system()</code> without mentioning any of the other major</em> ECS improvements; the continual focus on ergonomics is a big reason I think Bevy has become a relatively popular engine.</p> To better understand what triggers do, let's first understand how to write a Bevy project before</em> triggers were introduced with regular events: Imagine we have a minefield. If one mine is triggered with a click, it causes an explosion with a defined radius. If any other mines are in range of that explosion, they're also triggered.</p> Using events, we can express this relationship like the following rusty pseudocode:</p> #</span>[</span>derive</span>(</span>Event</span>)</span>]</span></span> pub</span> struct</span> ExplodeEvent</span> {</span> entity</span>:</span> Entity</span> }</span></span> </span> fn</span> handle_explode_events</span>(</span>mut</span> cmd</span>:</span> Commands</span>,</span> events</span>:</span> EventReader</span><</span>ExplodeEvent</span>></span>,</span> mut</span> write_events</span>:</span> EventWriter</span><</span>ExplodeEvent</span>></span>)</span> {</span></span> for</span> event</span> in</span> events</span>.</span>read</span>(</span>)</span> {</span></span> let</span> ExplodeEvent</span> {</span> entity</span> }</span> =</span> event</span>;</span></span> //</span> Do something with this entity like play an explosion noise, then despawn it</span></span> cmd</span>.</span>entity</span>(</span>entity</span>)</span>.</span>despawn_recursive</span>(</span>)</span>;</span></span> //</span> Find any entities within a set radius (here it is done ~magically~)</span></span> let</span> entities_to_explode</span> =</span> find_entities_in_blast_radius</span>(</span>entity</span>)</span>;</span></span> for</span> entity_to_explode</span> in</span> entities_to_explode</span> {</span></span> write_events</span>.</span>send</span>(</span>ExplodeEvent</span> {</span> entity</span>:</span> entity_to_explode</span> }</span>)</span>;</span></span> }</span></span> }</span></span> }</span></span></code></pre> For astute observers</em> this might trigger</em> a negative reaction, as this is an invalid system definition, requiring both mutable and immutable access to ExplodeEvent</code> events. You'd actually need to use a ParamSet</code> here, accumulate events to write in the event read loop, then send out events after reading.</p> </blockquote> Additionally (and more importantly) these events do not trigger on the same update. Any entities_to_explode</code> are added to the event queue, and then hande_explode_events</code> runs on the next update. This isn't ideal when scaled to hundreds of objects. By comparison, triggers execute in a single update, even when recursed.</p> Bevy's official examples has code illustrating this exact minefield idea</a>. Here's what the equivalent of the above looks like in our pseudocode:</p> #</span>[</span>derive</span>(</span>Event</span>)</span>]</span></span> pub</span> struct</span> ExplodeTrigger</span>;</span></span> </span> fn</span> on_explode</span>(</span>trigger</span>:</span> Trigger</span><</span>ExplodeTrigger</span>></span>,</span> mut</span> cmd</span>:</span> Commands</span>)</span> {</span></span> let</span> entity</span> =</span> trigger</span>.</span>entity</span>(</span>)</span>;</span></span> //</span> Do something with this entity like play an explosion noise, then despawn it</span></span> cmd</span>.</span>entity</span>(</span>entity</span>)</span>.</span>despawn_recursive</span>(</span>)</span>;</span></span> //</span> Find any entities within a set radius (here it is done ~magically~)</span></span> let</span> entities_to_explode</span> =</span> find_entities_in_blast_radius</span>(</span>entity</span>)</span>;</span></span> for</span> entity_to_explode</span> in</span> entities_to_explode</span> {</span></span> cmd</span>.</span>trigger_targets</span>(</span>ExplodeTrigger</span>,</span> entity_to_explode</span>)</span>;</span></span> }</span></span> }</span></span></code></pre> With triggers, all entities to explode are calculated in a single update, and</em> we don't have issues juggling event mutability.</p> II. Looking back</h1> Organizing a bevy project for honor and success</h2> After many projects, repetition is inevitable. As I am Very Into Rust, I'm also very into conventions and planning (also known as over-engineering). With experience, I've generalized a project organization that works well, and condensed it into a template repo, which I use for new projects. Its goal is not to be a feature-complete starter like foxtrot</a>, but simply to nurture an understandable, scalable project file structure</a>.</p> Very Important Crates</h3> There are a few batteries included, but these are the crates I use in every project. Let's take a look at the default Cargo.toml</code>:</p> [</span>dependencies</span>]</span></span> leafwing</span>-</span>input</span>-</span>manager</span> =</span> {</span> git</span> =</span> "</span>https://github.com/Leafwing-Studios/leafwing-input-manager/</span>"</span> }</span></span> bevy</span> =</span> {</span> version</span> =</span> "</span>0.14</span>"</span>,</span> features</span> =</span> [</span>"</span>serialize</span>"</span>]</span>,</span> default</span>-</span>features</span> =</span> true</span> }</span></span> bevy_common_assets</span> =</span> {</span> version</span> =</span> "</span>0.11</span>"</span>,</span> features</span> =</span> [</span>"</span>ron</span>"</span>]</span> }</span></span> bevy_asset_loader</span> =</span> {</span> version</span> =</span> "</span>0.21</span>"</span>,</span> features</span> =</span> [</span>"</span>2d</span>"</span>,</span> "</span>3d</span>"</span>,</span> "</span>standard_dynamic_assets</span>"</span>,</span>]</span> }</span></span></code></pre> leafwing-input-manager</code> is a generalized way to get input over keyboards and gamepads. Folks, do we love to write generalized code? We love it. That guy over there loves it, I see them, they know.</li> bevy</code> is bevy.</li> bevy_common_assets</code> provides asset loaders for - would you believe this - common asset types like ron</code>. In fact, I'm only using its ron</code> feature (as json</code> doesn't let you use trailing commas 😡😤)</li> bevy_asset_loader</code> implements all of the asset loading logic that you would have implemented yourself.</li> </ul> There's also a few commonly used but alternative crates ready to be unleashed, but commented out. They're all related to egui</code>.</p> bevy_egui</span> =</span> "</span></span>"</span></span> bevy-egui-kbgp</span> =</span> "</span></span>"</span></span> egui_extras</span> =</span> {</span> version</span> =</span> "</span></span>"</span>,</span> features</span> =</span> [</span>"</span>file</span>"</span>,</span> "</span>image</span>"</span>]</span> }</span></span> image</span> =</span> {</span> version</span> =</span> "</span></span>"</span>,</span> features</span> =</span> [</span>"</span>png</span>"</span>]</span> }</span></span> bevy-inspector-egui</span> =</span> "</span></span>"</span></span></code></pre> The most important crate here is bevy-inspector-egui</code>, which provides a powerful way to diagnose runtime issues, especially for people like me who think debugging is when you write dbg!(..)</code>. We also make bevy-egui-kbgp</code> available, which adds gamepad input support to egui</code> menus. Until Bevy's own UI and editor gathers momentum, egui</code> is the de-facto way to present UI in games. That's it though, just 3-ish crates by default. Outside of setting up bevy_asset_loader</code>, this template doesn't really do</em> much else. It's more about project organization.</p> egui</code>! It's a great library. However, the difficulty with styling, lack of gamepad support, and ever-increasing world data needed to render custom widgets renders it a less-than-optimal choice. Additionally, egui</code> and Bevy's philosophies compete: there is a tendency to include all UI code in a single system to reduce complexity, leading to incredibly long and terse UI system functions. I'm looking forward to Bevy's own UI maturing providing a more constructive relationship between ECS and UI.</p> </blockquote> Project organization</h3> My 6th grade math teacher had a poster that said "Organization is the key to success". So true! I also couldn't stay quiet during his class, which also taught me about detention. Although I don't consider myself a particularly organized person, my brain does have those peculiar deleterious set of genes innate to humans that make us clap our hands and jump up and down whenever we successfully organize things into groups.</p> </blockquote> Here's another fact about my mysterious past: I used to be really into Ruby on Rails (and according to some Rust surveys, a lot you probably were, too). Rails is all about</em> "convention over configuration". That quote itself was coined by Rails' creator, Hatsune Miku.</p> </blockquote> MVC isn't exactly a sexy term. It's arguably sexless. But parts of MVC began to influence how I began to structure my Bevy projects, drawing inspiration particularly from strong separation of data and functionality. In Rails, the data bits are "models", and the functionality bits are "controllers". These are analogous to components and systems in Bevy. Rails has one more level of organization: controllers are not single functions, but a type with several inherited methods (e.g., "new", "create", "delete"). In Bevy, these are akin to Plugin</code>s, which group systems into a single unit.</p> </blockquote> In my experience, it's rare that a system doesn't</em> belong in a single Plugin</code>. Grouping related systems can help ease the cognitive load of storing larger projects in (human) working memory. To achieve this, all systems in my projects are private^{4</a></sup>, and only the containing Plugin</code> is exposed, resulting in this directory structure:</p>} src/</span></span> components/</span></span> mod.rs</span></span> my_component.rs</span></span> plugins/</span></span> mod.rs</span></span> my_thing.rs</span></span> resources/</span></span></code></pre> This simple setup works well for my projects and seems to grow manageably. So far.</p> Preludes</h4> Bevy developers love preludes! use bevy::prelude::</code> is far easier than importing every item by name. So why not extend this pattern to my own projects and be my own consumer by adding a pub use</code> statement within a prelude</code> module in our lib.rs</code>?</p> pub</span> mod</span> prelude</span> {</span></span> use</span> super</span>::</span></span>;</span></span> #</span>[</span>allow</span>(</span>unused_imports</span>)</span>]</span></span> pub</span> use</span> {</span>components</span>::</span></span>,</span> error</span>::</span></span>,</span> plugins</span>::</span></span>,</span> resources</span>::</span></span>,</span> states</span>::</span></span>,</span> ui</span>::</span></span>,</span> util</span>::</span></span>}</span>;</span></span> }</span></span> //</span> Leave out `pub` for any types you don't want available in these modules.</span></span></code></pre> With this pattern, our game's most important types are available with a single import of use crate::prelude::</code>.</p> Note that I have a states/</code> directory in my template repo, but I've yet to have an application need more than one state (and I don't even know if that's supported tbh). States are</em> just resources, so it's better to add a state.rs</code> file in resources/</code> instead.</p> </blockquote> Naming</h3> If it is necessary to convey type information in a type's name, it can be a signal that the project's organization may need improvement. Controller</code> is a better type name than ControllerComponent</code>; it is easier to type, clearer to read, and is already known to be a component by implementing the Component</code> trait. If disambiguation is necessary, modules can be used. For example, event and trigger names are often similar to component names. When using the prelude</code> method, a problem arises: What if we have an Equip</code> component and an Equip</code> event in the same namespace?</p> //</span> Errors</span></span> </span> pub</span> mod</span> prelude</span> {</span></span> use</span> super</span>::</span></span>;</span></span> pub</span> use</span> {</span> components</span>::</span>Equip</span>,</span> events</span>::</span>Equip</span> }</span>;</span></span> }</span></span> </span> pub</span> mod</span> components</span> {</span></span> pub</span> struct</span> Equip</span>;</span></span> }</span></span> </span> pub</span> mod</span> events</span> {</span></span> pub</span> struct</span> Equip</span>;</span></span> }</span></span></code></pre> It's tempting to add an "Event</code>" to the end of the type's name, but this creates a new issue where Event</code> types litter the project with no apparent grouping. We could prefix</em> the type name with "Event" to search alphabetically for related types in our editor, but this forces</em> us to be verbose, even in situations where it's unnecessary, and is downright awkward.</p> //</span> Not the best solution</span></span> </span> //</span> Components are common so no suffix is added</span></span> pub</span> struct</span> Equip</span>;</span></span> //</span> Events get a suffix added to the type name</span></span> pub</span> struct</span> EquipEvent</span>;</span></span> //</span> pub struct EventEquip; // Would be better for searching for events, but looks weird</span></span></code></pre> Instead of adding to the type name, we can leverage modules. Because component types are extremely</em> common to use, they can stay in the prelude</code> root. We'll move event</code>s and trigger</code>s to their respectively named modules available within prelude</code>.</p> pub</span> mod</span> prelude</span> {</span></span> use</span> super</span>::</span></span>;</span></span> //</span> This is identical as our first example, but we're only exposing</span></span> //</span> the entire events module instead of specific items</span></span> pub</span> use</span> {</span> components</span>::</span>Equip</span>,</span> events </span>}</span>;</span></span> }</span></span> </span> pub</span> mod</span> components</span> {</span></span> pub</span> struct</span> Equip</span>;</span></span> }</span></span> </span> pub</span> mod</span> events</span> {</span></span> pub</span> struct</span> Equip</span>;</span></span> }</span></span></code></pre>//</span> Use in the project</span></span> use</span> crate</span>::</span>prelude</span>::</span></span>;</span></span> </span> fn</span> my_system</span>(</span>equips</span>:</span> Query</span><</span>&</span>Equip</span>></span>,</span> events</span>:</span> EventReader</span><</span>event</span>::</span>Equip</span>></span>)</span> {</span></span> //</span> No conflicts!</span></span> }</span></span></code></pre> If in a particular file, components were completely unused, while events were used heavily, we could write use crate::prelude::event::</code>. This flexibility is a nice bonus to modules neatly separating our ever-growing list of types available in prelude</code>.</p> While we're crossing into subjective territory, I like</em> namespacing by modules instead of adding extra info to the actual type name. That's what modules are there for to begin with, right? I like</em> writing event::Equip</code> instead of Equip</code>, even if it weren't required due to aliasing another type in the prelude.</p> </blockquote> Projects</h2> Outside of a few projects, I've rarely pushed one to a "complete" playable state. I'm okay with that! I work on a product team of a tech company. It's nice to start creating without a clear goal. Ideating, finding creative solutions to problems, and promptly deleting those creative solutions because you've moved in a new direction isn't a good way to develop games, but it's a great way to learn.</p> Let's peruse the few dozen gibberish-named private repositories of ideas stashed on my GitHb and see if I've actually learned anything.</p> bevy-puzzle</a></h2> It's a puzzle game with tetrominoes! Simple as it is, I'm happy with how this turned out</a>. Sure, it may crash when you win because it tries to write to a highscores file that doesn't exist in the WASM build, but the several seconds of gameplay beforehand is fun!</p> This project highlights a recurring theme for me: I don't like 2D. Whenever I'm a few hours into a project using sprites, I can only think of how much easier everything would be in 3D space. I don't want to deal with sprite ordering in an isometric 2D game. We live in the future. We have access to more dimensions now, even the 2D is 3D5</a></sup>.</p> </span> doomy 🦀</h6> @doomy@mastodon.social</p> </div> </a> </video> September 7, 2024 at 4:12 AM </a> </div> wordlrs</a></h2> Wordle is a relatively simple game to implement, so this project</a> furthered my working knowledge of egui with an achievable goal. A feature of this implementation is that it is language-independent. (If the language uses an alphabet. 对不起6</a></sup>). While this sits among my rare playable projects, it's not at all interesting. Wordle doesn't particularly take full advantage of an ECS (but Wordle 99</a> absolutely would, someone get on that).</p> modsynth</a></h2> Not a Bevy project (nor a eurorack), modsynth is a naive model synthesis implementation (also known as "wave function collapse"). My main takeaway from this project is I am not good at math, and constraint solving is hard7</a></sup>.</p> I did, however, create a neat dynamically generated 3D scene using Bevy. It's exactly like "Lethal Company", except without any gameplay.</p> </span> doomy 🦀</h6> @doomy@mastodon.social</p> </div> </a> alright so i got my model synthesis program running in bevy so i can fit together a bunch of uninteresting hallways</p> </video> January 14, 2024 at 5:23 PM </a> </div> bevy-planty</a></h2> It's an L-system</a> visualizer! L-systems use relatively simple instructions to generate complex structures, and can be used to model plants.</p> egui is great, but working on this project was an early encounter with its aforementioned pitfalls. There's more than a few broken buttons.</p> </span> doomy 🦀</h6> @doomy@mastodon.social</p> </div> </a> </video> September 9, 2024 at 5:08 PM </a> </div> bevy blast ultra</a></h2> My solo Bevy jam #4 entry: a marble run game inspired by Super Marble Blast Ultra</em> with levels designed in Blender using Blenvy. In retrospect, I have no idea how I pulled this off in a week. I have an epic-style post talking about this some more</a>.</p> </p> III. Looking forward</h1> What I'm still waiting for</h2> In my game, I have items, which are described as an Asset</code> using ron.</p> ///</span> A general in-game item</span></span> #</span>[</span>derive</span>(</span>Debug</span>,</span> Component</span>,</span> Clone</span>,</span> Reflect</span>,</span> Asset</span>,</span> Serialize</span>,</span> Deserialize</span>)</span>]</span></span> pub</span> struct</span> Item</span> {</span></span> ///</span> The in-game name of this item</span></span> pub</span> name</span>:</span> String</span>,</span></span> ///</span> The in-world mass of this item</span></span> pub</span> mass</span>:</span> f32</span>,</span></span> ///</span> The space this item displaces in the [`Inventory`]</span></span> pub</span> size</span>:</span> usize</span>,</span></span> ///</span> The worth of this item in `Credits`</span></span> pub</span> value</span>:</span> usize</span>,</span></span> }</span></span></code></pre>(</span></span> name</span>:</span> "</span>scrap metal</span>"</span>,</span></span> mass</span>:</span> 0</span>.</span>1</span>,</span></span> size</span>:</span> 1</span>,</span></span> value</span>:</span> 10</span>,</span></span> )</span></span></code></pre> Assets are perfect, because I can modify or extend my game with new items without recompilation.</p> Items aren't entirely useful without the ability to pick them up, so we'll also need an inventory:</p> //</span> This is overly simplistic and not doing anything with our items `size` or `mass`, but it'll get the idea across, just wait.</span></span> #</span>[</span>derive</span>(</span>Debug</span>,</span> Clone</span>,</span> Component</span>,</span> Reflect</span>)</span>]</span></span> pub</span> struct</span> Inventory</span> {</span></span> ///</span> Items and their count in the inventory</span></span> items</span>:</span> HashMap</span><</span>Handle</span><</span>Item</span>></span>,</span> usize</span>></span>,</span></span> }</span></span></code></pre> Inventory</code> is a Component</code> that contains references to Item</code>s in the form of a Handle<Asset></code>. This provides two obvious benefits: items can be hot-reloaded, and cloning handles is cheap compared to cloning an entire Item</code> fully, especially as items gain fields and additional complexity. This works well until we need to serialize.</p> Handle</code>s are runtime specific, so while we can technically write a Handle</code>'s ID to a file, it won't be valid the next run. Instead, AssetPath</code>s are required to successfully serialize and deserialize. Bevy's animation graph</a> does something similar to this, but it's not necessarily a fun or easy thing to implement in your own projects.</p> //</span> From `bevy_animation` - https://docs.rs/bevy_animation/0.14.1/src/bevy_animation/graph.rs.html#166</span></span> </span> ///</span> A version of `Handle<AnimationClip>` suitable for serializing as an asset.</span></span> ///</span></span> ///</span> This replaces any handle that has a path with an [`AssetPath`]. Failing</span></span> ///</span> that, the asset ID is serialized directly.</span></span> #</span>[</span>derive</span>(</span>Serialize</span>,</span> Deserialize</span>)</span>]</span></span> pub</span> enum</span> SerializedAnimationClip</span> {</span></span> ///</span> Records an asset path.</span></span> AssetPath</span>(</span>AssetPath</span><</span>'</span>static</span>></span>)</span>,</span></span> ///</span> The fallback that records an asset ID.</span></span> ///</span></span> ///</span> Because asset IDs can change, this should not be relied upon. Prefer to</span></span> ///</span> use asset paths where possible.</span></span> AssetId</span>(</span>AssetId</span><</span>AnimationClip</span>></span>)</span>,</span></span> }</span></span></code></pre> This is just the data representation. Actually serializing and deserializing this isn't as straightforward. At least to me.</em></p> The ability to "persist" asset handles is useful - especially with dependency resolution. Wouldn't it be nice if we could just do</em> that?</p> bsn! bsn!</h1> Bevy's proposed scene format is going to solve all of my life's problems. For one, it solves that Handle<_></code> issue by introducing Construct</code>: a way to initialize components that need to access stuff from our ECS world. Now, we can serialize handles to an AssetPath<_></code>, and neatly deserialize back into a Handle<_></code> via access to the asset server. This can immediately simplify save strategies.</p> Now that we have a way to reference other assets, my idea of prefabs is possible. Let's go back to my top-down space game with the inventory as an example of why this is useful.</p> #</span> Our assets directory</span></span> assets/</span></span> items/</span></span> laser.weapon.ron</span></span> metal.item.ron</span></span> battery.energy.ron</span></span> models/</span></span> crab.gltf</span></span> ship.gltf</span></span> creatures/</span></span> crab.creature.ron</span></span></code></pre> You can think of creatures</code> as NPC definitions. If we load crab.creature.ron</code>, we should be able to spawn it and its components. This is what the crab creature ron</code> looks like:</p> (</span></span> name</span>:</span> "</span>crab</span>"</span>,</span></span> model</span>:</span> "</span>models/crab.gltf</span>"</span>,</span></span> inventory</span>:</span> [</span></span> (</span>"</span>items/laser.weapon.ron</span>"</span>,</span> 1</span>)</span>,</span></span> (</span>"</span>items/battery.energy.ron</span>"</span>,</span> 1</span>)</span>,</span></span> (</span>"</span>items/metal.item.ron</span>"</span>,</span> 3</span>)</span>,</span></span> ]</span>,</span></span> )</span></span></code></pre> This is valid ron</code>, so we could load this - but Bevy has no idea what these random path strings mean. We first need to map our asset paths to runtime handles. Luckily [bevy_asset_loader](https://docs.rs/bevy_asset_loader/latest/bevy_asset_loader/)</code> does this for us. All we need to do is load our items and models, then load our creatures - probably by checking an Added<Creature></code> query and building the described entity manually. This works, though it's highly manual, prone to errors, annoyances with circular dependencies, and is a general bother to maintain and extend.</p> Bevy doesn't have a concept of a common collection of components on purpose (Bundles and Archetypes don't count). There is no concept of the "shape" of an entity known statically. Our "NPC" is nothing more than interactions between specific components: they are entities that have a Transform</code> component, a Controller</code> component for movement, and a Thinker</code> component for directing Controller</code> movement. Nothing in the type system describes that specific relationship of components</strong> - and it shouldn't. Bevy's API encourages systems to use the least amount of components necessary, which results in general</em> code that adapts with emergent behavior as systems and components are added.</p> But, our ron</code> data description goes against this philosophy and limits flexibility 😢. What if we wanted to add a unique BossName</code> component? We'd have to add a whole new field to the creature</code> struct to support this optional BossName</code> component, which means recompilation is required. It also inevitably grows the entity description struct into a gigantic mess of Option<Component></code> fields.</p> With bsn</code>, we can instead define almost everything</em> in our game as a Bevy scene, with any arbitrary components, including our BossName</code> or anything else, allowing us to build significant game content without needing to venture into the codebase.</p> This is similar to Bevy's DynamicEntity</code> (used in DynamicScene</code>), except that we can now add and save components with world context, meaning we can serialize a Handle<_></code> to an AssetPath<'_></code> and back into a Handle<_></code>.</p> Check out the whole thread on GitHub for more details on Bevy's new scene system</a>.</p> Closing thoughts</h2> Organization is not easy. Bevy hitting 4 years, all the while gaining momentum, is beyond encouraging. Bevy community members are some of the most engaging, friendly, and helpful people I've met online. It's special to share a space where there's little profit motive - just creative people making cool stuff that inspires them.</p> Footnotes</h3> ^1</sup>Including some of the earliest work on a fully-Rust UI toolkit named conrod</a>. I can't overstate how cool it was to be able to write a GUI application, completely in Rust, 5 years ago.</p> </div> ^{2</sup> There's no indication that Piston is EOL like Amethyst, and there are some commits this year, but it looks to be in maintence mode.</p> </div>}^{3</sup> You know you're writing good rust when you have to include #[allow(clippy::too_many_arguments)]</code> or #[allow(clippy::type_complexity)]</code></p> </div>}^{4</sup> Sort of. Generic or error handling systems especially may be used across many plugins. I add these special cases to a utility</code> module public to the crate.</p> </div>}^{5</sup> When I work in 2D, I feel like I'm slowly walking down a big hill, wishing I remembered my Heelys so I could just slide to the bottom.</p> </div>}^6</sup>Some argue that Chinese has an alphabet, it's just thousands and thousands of characters long. In any case it cannot be wordled (but can be pinyindle'd</a>)</p> </div> ^7</sup>I may have had an easier time if I referenced more than a single YouTube video on repeat for several hours</a>. (This entire experience also revealed to me just how criminally underappreciated Paul Merrell is for his research in this area.)</p> </div> I submitted a game to Bevy Jam 4 and it was pretty cool 2023-12-16T00:00:00+00:00 I submitted an entry to the 4th #bevy jam this December, with the theme of " That's a LOT of Entities!". As a big fan of the Marble Blast Ultra</em></a> game on the 360 arcade, I though I might try a stab at something similar.</p> Bevy Blast Ultra</h2> With subtle acknowledgement of its inspiration, Bevy Blast Ultra</a> brings several minutes of non-stop MVP marble action to any browser</del> Windows, Mac, or Linux machine.</p> How's Bevy 0.12?</h2> There's a couple Epic Rust Moments and issues I ran into while creating this game. Bevy has grown tremendously since I last wrote about it in version 0.6, and this is an effort to document what I found of note.</p> Bevy editor, pls</h3> While Bevy is a capable engine, its lack of an editor means procedural generation is much more achievable in comparison to handcrafted levels. A game like MBU, however, requires intentionally designed levels (or a wizardly knowledge of procedural generation).</p> </p> A few 3rd party editors for Bevy</a> exist at the moment, but are understandably limited in comparison to established engines like Unreal.</p> Fortunately, Bevy is</em> able to import GLTFs, and a workflow for exporting to Bevy is already available</a>. Using a single .blend</code> file, I could edit all levels as different scenes, and create reusable prefabs. Most importantly, I could create any kind of level geometry that Blender could export.</p> </span> doomy 🦀</h6> @doomy@mastodon.social</p> </div> </a> goal areas #bevy</span></a> b vevy bev y</p> </video> December 5, 2023 at 1:57 AM </a> </div> Early development footage</p> </blockquote> Assets are still kind of tricky, but not as much</h3> Assets used to be among the more tedious game logic to implement. With the advent of helpful crates like bevy_asset_loader</code></a>, this isn't much of an issue.</p> Before I decided on going the Blender route, I considered writing a bunch of .ron</code> scene files by hand. I would have liked to specify a bunch of prefab .ron</code> scenes, and use them within level .ron</code> scenes. Apparently, that still isn't a possibility just yet, but I hear an overhaul of the way scenes are handled in Bevy is under way. I imagine this might rely on some of the new asset v2 preprocessing features released in 0.12</code>.</p> Annoyingly, it's still impossible to load folders with WASM (which isn't a Bevy issue, but still a bummer when you have to hard-code filenames in your project for web support).</p> Z will always be up to me</h3> ok seriously though. "Up" is (0.0,0.0,1.0)</code>, and I'm Tired of People trying to Tell Me Otherwise! It is not (0.0,1.0,0.0)</code>. I will die on this very tall Z-aligned hill.</p> This brings me to The worst moment of the Bevy Game Jam 2023</strong>: figuring out skyboxes.</p> I spent 6 very misplaced hours right before the due date attempting to figure out how to convince my skybox image that Z is up.</p> This was, of course, completely unnecessary compared to fixing core issues with the camera logic, but I persisted and brute-forced my way to figuring it out.</p> The wretched skybox journey</h3> Bevy provides a few files in the example assets for showing a skybox image, but it has some minor issues - mostly the fact that it is a little bit rotated.</p> </p> But that shouldn't be an issue, right? With the right editing, I could certainly rotate it back in the right direction. But the files Bevy provides are ktx2</code> images. Most tools to convert to and from this format are CLI based (or need compilation) which I wanted to avoid. NVIDIA does</em> provide a GUI application for viewing and exporting many of these filetypes, but it claimed my precious ktx2</code> files were corrupt.</p> </p> This application has many, many settings, and I know what approximately 0 of them actually do.</p> </blockquote> Thankfully, the Bevy repo also provide a .png</code> skybox example, I just needed to map portions on the image in the correct sequence and rotation to match, which I figured out slowly and arduously by changing the image until everything properly tiled together.</p> </p> I'm sure this is a solved problem, and there's a document somewhere specifying where to put which bit of image, but I instead spent hours brute forcing this. But hey, it eventually worked!</p> I skipped over a lot with this story. It also involved forking a cubemap generator javascript project so I could up the photo resolution, and lots of aggravated scribbling in Microsoft paint</p> </blockquote> I do not know how to compile a C project</h4> One alternative route was to use Patrick Walton's automatic tool</a>, but this requires a beginner level of C knowledge and some patience. After scouring the internet for the right header files to download, and reading source code to figure out where to place them, I gave up. But it looks like a great application for this exact purpose, if you're able to get it running.</p> The world's most difficult to remember acronym</h3> Since I last used Bevy, its added another physics engine to the mainstream - bevy_xpbd</code></a>. The xpbd</code> part stands for Extended Position Based Dynamics</em>. Without a bookmark, prepare to enter every permutation of xpbd</code>'s letters in your search engine.</p> XPBD to my understanding is a newer (but less battle-tested) way to calculate physics. The YouTube channel Two Minute Papers</code></a> does a pretty good job summarizing the differences between XPBD and more traditional methods. One interesting feature of XPBD is that it can simulate situations where more traditional methods would fail, such as marbles on a track, which I incorporated into my game.</p> </p> </span> doomy 🦀</h6> @doomy@mastodon.social</p> </div> </a> something cool about bevy_xpbd is you can do these marble track things that would definitely break other engines</p> </video> December 8, 2023 at 2:59 AM </a> </div> I've used Rapier almost exclusively in the past, and while it's matured nicely, it's still a library intended for general use. That means it needs the glue of bevy_rapier</code> to translate into our game world, and the Rapier and Bevy world don't always play together without issues. bevy_xpbd</code> on the other hand, is designed specifically for use in Bevy, which (in my opinion) makes its resulting API far friendlier and intuitive to use. I didn't encounter any bugs or strange behavior and will use it as my physics engine of choice moving forwards.</p> I only wish it had some built in forces (outside of gravity) like wind or magnetism - but those are easy enough to implement yourself.</p> Graphics are too good</h3> As I alluded to earlier in this post, Bevy Blast Ultra is not playable in-browser, because it runs like rotten garbage, clocking in a spectacular ~0.5FPS despite my desperate fumbling with wasm-opt</code>. After playing a few other submissions, I suspect the issue is the shadow graphics, which were recently improved and look great, but might cost too much for a browser game. But hey, it looks really nice!</p> </iframe></div>

Using Game Center with Bevy on iOS to manage save files

2025-07-31T00:00:00+00:00

Disclaimer: I am not an expert about iOS or XCode. I wanted to post this solution because I couldn't find any information about it online. Please file an issue</a> with any corrections. </blockquote>

Note that the iOS sim is broken as of 0.16</code>. You will need a physical device for this to compile, otherwise you will get an error like failed to run custom build command for tracing-oslog v0.2.0</code>. If you want to use Game Center, you will need an Apple developer account. </blockquote>
If you're developing Bevy apps for release on Apple's store, at some point you'll probably want to integrate with Game Center</a>, or know the safe areas</a> of your window. These crates require Swift Package Manager (SPM) dependencies.
Download a working template</h2> If you want to skip how to get here and just download a working iOS template with SPM dependencies included, check out this repository</a>. Note that Android is removed, as I do not currently know anything about Android development and can't provide a known working solution. Refer to the official Bevy examples for Android. Issues with the 0.16</code> mobile template</h2> If you use the 0.16</code> mobile XCode template and build scripts, you're in for a terrible time, because the template has changed, and it is not possible to use SPM without using XCode to handle linking. This is how iOS builds were formerly handled in the 0.15</code> template, though (thank you to b.R. in Discord for pointing this out, I was about to give up after trying to make the 0.16</code> template work for 2 days straight!). If you are not very familiar with XCode like me and have an existing project on 0.16</code>, I recommend removing your XCode project files instead of trying to adapt, since many attributes have changed. Adapting the 0.15</code> template</h2> This tutorial assumes you already have the toolchain and dependencies required to use XCode and build an iOS application </blockquote> First, let's download Bevy 0.15</code></a> and grab the mobile project in examples/mobile/</code> (I moved the entire folder to a new directory to make it a project). Open bevy_mobile_example.xcodeproj</code> so we can make a few changes. Currently, our project is bevy_mobile_example</code>, with targets bevy_mobile_example</code> and cargo_ios</code>. We'll add SPM dependencies to the bevy_mobile_example</code> target. Because we're creating a new project from this example, we need to fix Library Search Paths</code>. Go to the bevy_mobile_example</code> target (not project), "Build Settings", and then scroll to "Search Paths". We need to remove the ../../</code> from each path. ../../target/aarch64-apple-ios-sim/debug ../../target/aarch64-apple-ios/debug ../../target/x86_64-apple-ios/debug ../../target/aarch64-apple-ios-sim/release ../../target/aarch64-apple-ios/release ../../target/x86_64-apple-ios/release</code></pre> It should now look like this: </img> XCode showing the corrected Library Search Paths</figcaption> </figure> Fixing assets</h3> Let's look at the Project navigator. The assets</code> directory is also broken because of relative links. </img> XCode showing the Project navigator with the “assets” directory in red error text</figcaption> </figure> We can fix this by selecting the assets</code> directory in the Project navigator, and showing the Inspector with the top right icon on the XCode window. In this pane, under "Identity and Type" is "Location" with the value ../../../assets</code>. First, create the assets</code> directory in your project root, and then change the location path to ../assets</code>. If you are using Git, you might want to add a .gitkeep</code> in your assets directory if it's empty. </blockquote> Renaming the project</h3> We don't really want to publish an app called bevy_mobile_example</code>, so lets select the project, select the bevy_mobile_example</code> target, select the text again, and rename it to whatever we want. In my case, I'll choose ios_template</code>, but you can name it whatever you want. Take note of the name you choose. We're going to need to change 1 more options in target Build Settings: Linking - General Other Linker Flags Existing value: $(inherited) -lbevy_mobile_example -lc++abi</code></li> New value: $(inherited) -lios_template -lc++abi</code></li> </ul> </li> </ul> </li> </ul> Cargo.toml</code> changes</h3> If you have an existing Cargo.toml</code> from a 0.16</code> project, you should be able to skip this section. Just note your library name matches what you just set! </blockquote> There are still a few issues with our project's Cargo.toml</code>. Dependency paths don't exist as this is no longer an example project. Cargo.toml</div> </div>[package] name = "bevy_mobile_example" # ... [lib] name = "bevy_mobile_example" crate-type = ["staticlib", "cdylib"] [dependencies] bevy = { path = "../../" } [target.aarch64-apple-ios-sim.dependencies] bevy = { path = "../../", features = ["ios_simulator"] } [lints] workspace = true</code></pre> Change your toml to the following. Realistically, you're probably going to want a different package name than default, so I'll change mine here too so we can follow along together. Let's also remove that workspace lint while we're here. Lastly, remove the whole target.aarch64-apple-ios-sim.dependencies</code> section, as it's not needed in 0.16</code></a>. Cargo.toml</div> </div>... [package] name = "ios_template" # ... [lib] name = "ios_template" crate-type = ["staticlib", "cdylib"] [dependencies] bevy = { version = "0.16" }</code></pre> You're probably going to want some debug optimization here too so your game doesn't take up 200% CPU </blockquote> Adjusting lib.rs</code></h3> At line 22</code> of lib.rs</code>, the #[bevy_main]</code> macro is used. It appears that the code this generates has changed from 0.15</code> to 0.16</code> leading to compilation errors, so remove the #[bevy_main]</code> line entirely, and add a new function: lib.rs</div> </div>#[unsafe(no_mangle)] unsafe extern "C" fn main_rs() { main() }</code></pre>Signing the app</h3> Back in XCode, ensure that a physical device is targeted, then build and run the application. If this is your first time running the application, you might see something like this: </img> XCode dialog with the title “The executable is not codesigned.” and text “Sign the executable with a valid certificate and provisioning profile.”</figcaption> </figure> To solve this, go back to your project settings. Go to your newly-named target, go to "Signing & Capabilities", enable "Automatically manage signing", then select the desired value under "Team". Running the app</h2> Ensure your device is in developer mode </blockquote> At this point, you can build and run the application for your physical device. It should successfully build and display the default scene. </img> The default bevy mobile example scene from 0.15</figcaption> </figure> Adding SPM dependencies</h2> Now that we have everything working with the 0.15</code> template, let's take advantage by adding in packages that rely on SPM dependencies. Let's add bevy_ios_gamecenter</code></a> into our Rust project. Cargo.toml</div> </div>... # ... [dependencies] # ... bevy_ios_gamecenter = "=0.4.0"</code></pre> If you want Android and desktop builds, make sure you're using feature flags. </blockquote> According to the project docs, we also need to add a package in XCode</a>, so do that now. It is recommended to keep it on the "Exact version" </img> A dialog for choosing which dependency to add a package to. Ensure that your custom named target is selected.</figcaption> </figure> Depending on the package you're using, this might be all you need! Linking should work correctly and you can continue developing as normal. However, certain features require permissions and other setup, including Game Center. Setting up Game Center</h2> At this point, we'll need to create a developer account with Apple, and (create a new app to publish)[https://appstoreconnect.apple.com/apps]. In the main settings for the app, ensure that Game Center is checked. We'll also need to associate the newly created app with the existing bundle under your account. If you don't have one set up, create that now, and ensure Game Center is enabled. </img> A webpage showing app ID registration. Take note of your bundle identifier and ensure Game Center is enabled.</figcaption> </figure> </img> A dialog for creating a new app with the previously created bundle selected.</figcaption> </figure> </img> The newly created app page. Ensure that Game Center is enabled here, it's easy to miss.</figcaption> </figure> Back in XCode, ensure that the Bundle Identifier matches the one you just created. </img> The XCode bundle is modified to match my newly created bundle identifier.</figcaption> </figure> Permissions</h3> We'll need to add a few capabilities for GameCenter to work. In Signing & Capabilities, click the "+ Capability" button, and add Game Center. </img> Adding the Game Center capability</figcaption> </figure> If you're taking advantage of game saves and other storage, you'll also need iCloud. If you enable iCloud, ensure "iCloud Documents" is enabled and assigned to a Container. </img> Both capabilities with necessary settings</figcaption> </figure> Using Game Center in Rust</h3> It's finally time to stop fiddling with XCode and dive back into Rust. Here's what we're going to add to the mobile starter: The app should automatically sign in to Game Center</li> When the camera view changes, its transform settings should be saved</li> If a save file is present, it should be loaded and applied to the camera</li> </ol> First, lets add serde</code> and ron</code> so we can serialize and deserialize to a format. cargo add ron serde</code></pre> Next, ensure that Bevy has the serialize</code> feature enabled. Cargo.toml</div> </div># ... bevy = { version = "0.16", features = ["serialize"] }</code></pre> While we can directly serialize the Transform</code> to a file, in real scenarios we'll likely want a struct with all save information. We can add that to our lib.rs</code>. Let's also add a loading state, since we'll need to wait on Game Center to load, and for our scene to spawn. lib.rs</div> </div>#[derive(serde::Serialize, serde::Deserialize, Resource)] struct SaveFile { pub(crate) camera_transform: Transform, } impl Default for SaveFile { fn default() -> Self { // Match the mobile example default transform Self { camera_transform: Transform::from_xyz(-2.0, 2.5, 5.0).looking_at(Vec3::ZERO, Vec3::Y), } } } #[derive(States, Clone, PartialEq, Eq, Hash, Debug, Default)] pub enum GameState { #[default] Loading, Main, }</code></pre> lib.rs</div> </div>// Ensure this is after `DefaultPlugins` are registered // ... .init_state::<GameState>() .init_resource::<SaveFile>() // ...</code></pre> Also in main</code>, replace all add_systems</code> calls so that it uses states: lib.rs</div> </div>// ... .add_systems(OnEnter(GameState::Main), (setup_scene, setup_music)) .add_systems( Update, (touch_camera, button_handler, handle_lifetime).run_if(in_state(GameState::Main)), ) // ...</code></pre> Now, let's create a system that signs into Game Center, checks for any save, loads it, and then transitions to the main state. lib.rs</div> </div>fn load_gamecenter(mut gc: bevy_ios_gamecenter::BevyIosGamecenter) { use bevy_ios_gamecenter::*; info!("Authenticating with GameCenter..."); gc.authenticate() .on_response(|trigger: Trigger<IosGCAuthResult>, mut gc: bevy_ios_gamecenter::BevyIosGamecenter| match &trigger.event() { IosGCAuthResult::IsAuthenticated => { info!("Successfully authenticated GameCenter"); info!("Fetching saved games..."); gc.fetch_save_games().on_response( |trigger: Trigger<bevy_ios_gamecenter::IosGCSaveGamesResponse>, mut gc: bevy_ios_gamecenter::BevyIosGamecenter, mut next_state: ResMut<NextState<GameState>>| { match trigger.event() { IosGCSaveGamesResponse::Done(saved_games) => { info!("Successfully fetched saved games"); let save = saved_games.0.first(); match save.cloned() { Some(save) => { info!("Loading save..."); gc.load_game(save).on_response( move |trigger: Trigger<IosGCLoadGamesResponse>, mut save_file: ResMut<SaveFile>, mut next_state: ResMut<NextState<GameState>>| { match &trigger.event() { IosGCLoadGamesResponse::Done((_save_game, data)) => { info!("Successfully loaded save file"); if let Some(bytes) = data { // Process the most recent save data match ron::de::from_bytes::<SaveFile>(bytes) { Ok(save_data) => { // Successfully deserialized info!("Save file loaded and ready!"); *save_file = save_data; } Err(e) => { error!("Failed to deserialize save file: {}", e); } } next_state.set(GameState::Main); } } IosGCLoadGamesResponse::Unknown(_ios_gcsave_game) => { info!("Couldn't find any save files"); next_state.set(GameState::Main); } IosGCLoadGamesResponse::Error(e) => { error!("Error loading save file: {}", e); } } }, ); }, None => { info!("No saves."); next_state.set(GameState::Main); }, } } IosGCSaveGamesResponse::Error(err) => { error!("Error fetching save games: {}", err); } } }, ); } IosGCAuthResult::LoginPresented => {}, IosGCAuthResult::Error(e) => error!("auth error: {e}"), }); }</code></pre> That's a lot! Most of this system is just messages for diagnosing issues, but the important flow is as follows: When this system is called, Game Center will attempt to authenticate.</li> When authenticated, a list of save files for this app will be retrieved</li> After the list is retrieved, we select a specific filename to load</li> After loading the save file data, we set the SaveFile</code> resource to that data and transition states</li> </ol> We need to add this system and the Game Center plugins in our app. lib.rs</div> </div>// ... .add_systems(OnEnter(GameState::Loading), load_gamecenter) // ...</code></pre> lib.rs</div> </div>app.add_plugins(( bevy_ios_gamecenter::IosGamecenterPlugin::new(true), DefaultPlugins // ...</code></pre> Because of an issue with winit, I also recommend setting the log level to error to prevent log spam. lib.rs</div> </div>// ... .set(LogPlugin { // This will show some log events from Bevy to the native logger. level: Level::DEBUG, filter: "wgpu=error,bevy_render=info,bevy_ecs=trace,winit=error".to_string(), ..Default::default() })</code></pre> Now, we'll pass the SaveFile</code> resource into our scene setup. Modify the following system: lib.rs</div> </div>fn setup_scene( mut commands: Commands, mut meshes: ResMut<Assets<Mesh>>, mut materials: ResMut<Assets<StandardMaterial>>, save_file: Res<SaveFile>, // Add this line ) { // ...</code></pre> And use the save file in the system for the camera transform: lib.rs</div> </div>// ... // camera commands.spawn((Camera3d::default(), save_file.camera_transform)); // ...</code></pre> Finally, hook up the button to save the current camera transform. lib.rs</div> </div>// Test ui commands .spawn(( Button, Node { justify_content: JustifyContent::Center, align_items: AlignItems::Center, position_type: PositionType::Absolute, left: Val::Px(50.0), right: Val::Px(50.0), bottom: Val::Px(50.0), ..default() }, )) .with_child(( Text::new("Save"), TextFont { font_size: 30.0, ..default() }, TextColor::BLACK, TextLayout::new_with_justify(JustifyText::Center), )) .observe( // Save the camera position on click |_: Trigger<Pointer<Click>>, camera_transform: Single<&Transform, With<Camera>>, mut gc: bevy_ios_gamecenter::BevyIosGamecenter| { let save_data = ron::to_string(&SaveFile { camera_transform: **camera_transform, }) .unwrap(); gc.save_game("save.ron".to_string(), save_data.as_bytes()) .on_response( |trigger: Trigger<bevy_ios_gamecenter::IosGCSavedGameResponse>| { match trigger.event() { bevy_ios_gamecenter::IosGCSavedGameResponse::Done(_save_game) => { info!("Game saved successfully!"); } bevy_ios_gamecenter::IosGCSavedGameResponse::Error(e) => { error!("Failed to save game: {}", e); } } }, ); }, );</code></pre> And that's it! We can now boot up the app, move the camera around, and save the position. When we re-open the app, the position is loaded from our save file and applied to our scene! </source> Your browser does not support the video element. </video> Saving the game state</figcaption> </figure> </source> Your browser does not support the video element. </video> Loading the game state</figcaption> </figure>

Building a model locomotive controller with embedded Rust

2025-07-22T00:00:00+00:00

Do you have too many electronic components? Do you have a drawer full of $1 microcontroller dev boards? And, critically, do you have a 3D printer and nothing to print? Congratulations! You're going to put everything to good use by getting really into model railways.

DC controlled locomotives</h2> Conventional model trains use DC power of variable voltage controlling speed. It's not very interesting. It actually kind of sucks. Running a loco 1</a> at very low speeds means very low voltage. Corroded connections and decades of rail gunk leads inconsistent power. These are workable issues - for permanent installations, adding multiple connection points, or running a wire in parallel to the track connecting at every segment can help. But, can multiple trains run at once? On a traditional system with no modifications, two locos cannot receive independent controls 2</a>.
</img>
This N-scale (1:160) loco I want to control is especially susceptible to track dirt and poor connections</figcaption> </figure>
DCC</h2>
DCC (Digital Command Control) is one solution to this problem. It uses digital signals, instead of variable voltage, to control locomotive speed, accessories, and other functions. Consistent power helps eliminate reliability issues due to low voltage, and digital control enables each loco or accessory to receive independent instructions.
DCC sends commands to locomotives and accessories without the need for a third data rail; the signal is comprised of pulses of variable widths. A short pulse is a `1</code>, and a longer pulse is a 0</code>. The microcontroller generates these pulses, which are then powered by a motor driver at ~12V. The signal of one rail is inverted in order to create a consistent electric potential.`
`Building a controller</h2> There's already billion DCC-compatible controllers on the market, but we're trying to use up all of our spare components, so we're building our own. The first thing we'll need to do is buy some more components: a motor controller and a power supply.`Motor controller</h3> I purchased this module</a> for about $2. It's important to understand that no motors are directly controlled with this module; the part I care about is the H-bridge 3</a>. </img> The L298N motor driver board</figcaption> </figure> Following the guide on dcc-ex.com</a>, I added a couple current sense resistors. These are helpful for detecting shorts or stuck motors, shutting off the driver to prevent damage 4</a>. I found that a combination of clipping the pins on the top of the board and soldering wires to pads on the back was easy enough. The guide also instructs to remove the jumpers keeping the enable</code> pins high, so that we can control them manually via our MCU. It also instructs to remove the jumper from the power regulator if over 12V, however, after looking up the data sheet for my board, it appears the regulator IC used in my specific module is the LM76M05, and it can handle 2 to 35V</a> input, so I kept the jumper on and used it to power the MCU. Make sure your board's regulator can handle the voltage you're throwing at it, or remove the power regulator jumper. </blockquote> Motor channels and programming tracks</h4> The L298N is a 2 channel motor driver, meaning we can drive two separate tracks at once. If you wanted double the advertised 2A per channel, you could common each input and output. I thought this would be a good idea, but learned that DCC utilizes something called a "programming" track, and an "operations" track, so 2 separate channels is actually useful if we want to be able to program locos while a normal operations track is also running. Each channel has two input bit pins, with the following truth table 5</a>: Input 1</th> Input 2</th> Direction</th></tr></thead> 0</code></td> 0</code></td> Off</td></tr> 1</code></td> 0</code></td> Forward</td></tr> 0</code></td> 1</code></td> Backward</td></tr> 1</code></td> 1</code></td> Off</td></tr> </tbody></table> Power supply</h3> I also picked up this very small power supply</a> and regulator, which has the important trait of current limiting so that I'm not relying solely on software to prevent catastrophic failure. A rail layout is essentially a long route of unshielded wires; a short is very likely, if not unavoidable. (Adding some additional protection like a fuse or software shutoff probably wouldn't be a terrible idea either). </img> Power supply with the screen on. Note how both the voltage and amperage are adjustable.</figcaption> </figure> Hooking up the modules</h3> TrainElectronics.com helpfully includes a schematic</a>, albeit with a different motor driver. I adopted this to my own schematic based on the ESP32-C3, and eventually the C6. The ESP-C boards are fun and relatively inexpensive, but the C3 has a few clones with limited GPIO. I ended up purchasing a replacement ESP32-C6 board with several more pins that I'll be transitioning to later on, but the difference between the two is seemingly very negligible for my use case. </img> This board has way too many power inputs. The MCU itself does have more pins left unconnected, and they are actually hooked up on some other clones.</figcaption> </figure> I use a circuit to invert the signal 6</a>, as opposed to inverting using software with 2 separate pins (this is an option with DCC-EX). However, I don't see the benefit to doing this. It's a super simple circuit to create, allows for a simpler software implementation, and frees up an extra pin. It's not super clear by looking at it, but it appears that inputs 1</code> and 3</code> get the inverted signal, whereas 2</code> and 4</code> get the original signal 7</a>. </img> Schematic for the DCC signal inverter circuit</figcaption> </figure> </img> DCC signal inverter for both channels with chunky through-hole components</figcaption> </figure> Digging into DCC</h2> Before we can transmit anything, we need a way to build and serialize DCC data. Thankfully, a DCC crate called dcc-rs</code> already exists</a>, albeit on an outdated version of hal</code>. This is easily remedied with a few quick updates</a>. Now we just need a way to spit the data out to our motor controller. DCC bits are distinguished based on the length of their pulse. At first, I attempted a bitbang solution with the dcc-rs library, but my timing was always too slow or completely off when taking a look in Pulseview. I tried changing timing, adding manual delays, and other hacks, but was never getting consistent results. Thankfully, the ESP32-C3 and C6 offer a hardware peripheral called "Remote Control Transceiver" or RMT that can help. IR remotes use a similar method of transmitting bits, and we can use this device to generate the signal we want quickly8</a>. Using this method, I was able to successfully decode within Pulseview and send a signal to a commercial DCC decoder. // Building a pulse sequence and transmitting with the RMT peripheral for (bit, pulse) in new_data[..len].iter().zip(pulse_buffer[..len].iter_mut()) { pulse = match bit { true => PulseCode::new( false, dcc_rs::ONE_MICROS as u16, true, dcc_rs::ONE_MICROS as u16, ), false => PulseCode::new( false, dcc_rs::ZERO_MICROS as u16, true, dcc_rs::ZERO_MICROS as u16, ), }; } rmt.transmit(&pulse_buffer[..len + 1]).await.unwrap(); // Much easier than trying to juggle timers!</code></pre> </source> Your browser does not support the video element. </video> An early test. The MCU sends forward commands to address 03 (the default for this decoder) immediately on boot. I also have the loco motor power wired backwards, oops.</figcaption> </figure> Note: Receiving data</h4> I didn't end up with a working solution for receiving DCC data, but did learn a few things about optoisolators. I've used these previously to decode MIDI data from keboards and synthesizers, using a 6N138</code>. It turns out that this is a little too slow for our applications, and the 6N137</code> is more commonly recommended as it is faster. The info around all this stuff, like MIDI, is pretty dated, and apparently nowadays digital isolators exist that are superior. </blockquote> Note: Why not wireless?</h4> Why even go through this trouble when wireless communication exists? That is an excellent question - especially when the ESP32 boards I'm using support wireless, and even have mesh network support. I wanted to write this in Rust, which didn't have great support</a> for what I was looking for at the time of writing. Plus, using DCC grants a ton of compatibility with commercial accessories and locomotives, as many come "DCC ready". If you are interested in mesh network control of locos, someone's already done that!</a>. </blockquote> Display</h2> I bought an OLED screen labeled SSD1322</code>. Despite being grayscale, it's relatively large, extremely bright, and has excellent support with the ssd1322_rs</code> crate. The units I found on Aliexpress needed to be converted to "4 wire" SPI by soldering some bridges. Note that I was unable to get it working with the advertised 3 wire mode, (even though we aren't using MISO). </img> Back of the OLED module with bridged connections</figcaption> </figure> Housing</h2> Before this project, I used SolveSpace - a relatively simple parametric CAD program. However, around this time, FreeCAD 1.0 was released with a ton of improvements that made it much more stable and all-around sort-of-usable, so I decided to give it a go. I was able to create a simple housing and print a successful fit after a few attempts. </img> Transmitter housing in FreeCAD</figcaption> </figure> FreeCAD is still very rough around the edges, but it's usable, and much more powerful than SolveSpace. The normal thing to do would be to just use SolidWorks, but I'm too cheap. Putting everything together</h2> </img> Transmitter schematic</figcaption> </figure> </img> Testing the USB fit and stuffing cables into the enclosure</figcaption> </figure> </source> Your browser does not support the video element. </video> The working minimal prototype. Fed up with the relatively dirty signal of my generic rotary encoders, I added a huge jogwheel using an optical rotary encoder, which was extremely unnecessary, but kind of cool.</figcaption> </figure> I used a very neat library for the UI called Kolibri</a>. I'm surprised how seemingly relative few people are working in the Rust embedded graphics/UI space, since these projects are a lot of fun. Kolibri does not yet support devices without a pointer</a>, so I achieved my effect with a "virtual pointer" that moves a set distance to each interactive element on the UI. Rust on embedded</h2> The source code for this project, including the KiCAD and FreeCAD files, is freely available</a>. A few thoughts after approaching a larger embedded project: Embassy makes embedded development much more approachable, even more than RTIC, which was my previous go-to.</li> Espressif and STM chips seem to be among the best supported by embedded Rust, and getting set up is far simpler than it used to be.</li> The Rust embedded ecosystem is relatively small compared to something like its game development scene, but it's still full of highly knowledgable, helpful, and friendly people who help make this language both approachable and powerful.</li> </ul> Footnotes</h2> ^{1 This seems to be the right lingo but I wish I could just say "train". </div>}^{2 Some people set up blocks of DC control but honestly that seems like such a hassle, and I'm pretty sure I'd burn down my house. </div>}^{3 It also probably has some protection built in for driving inductive loads which is helpful. </div>}^{4 I didn't explore it yet, but current sense is also used in a bi-directional extension to DCC called Railcom. </div>}^5Source: https://lastminuteengineers.com/l298n-dc-stepper-driver-arduino-tutorial/</a> </div> ^6Source: https://dcc-ex.com/reference/hardware/motorboards/L298N-motor-board-setup.html</a> </div> ^{7 This upsets me greatly as an audio person who percieves the first channel as left and default. </div>}^8The popular FastLED library</a> for Arduino also works by utilizing the RMT device. </div> birthday_system.system() 2024-09-08T00:00:00+00:00 Table of contents</h3> 4 years of bevy</a> Best bevy improvements</a></li> Organizing a bevy project for honor and success</a></li> Lessons from the past</a></li> </ul> </li> Looking forward</a> What I'm still waiting for</a></li> bsn!</a></li> </ul> </li> Closing</a></li> </ul> 4 years of bevy</h2> Bevy released 4 years</a> ago. Feel old yet? Well, I do, because my dive into making games with Rust started even earlier than that. 5 years ago, Bevy didn't exist. The popular choices for Rust game engines were "Piston</a>", a modular game engine which pioneered a ton of useful crates1</a>, and "Amethyst</a>", a data-oriented, ECS-driven game engine, both of which are no longer in active development2</a>. I have a particularly strong attachment to Amethyst, being an esteemed "Emeritus Member" of the Amethyst foundation</a>. (If you don't know what that means, it's basically like being Knighted, except without the problematic implications of serving the Royal Family, so it's actually far more prestigious in that regard). I like to think the spirit of Amethyst is living on despite its ceased development, as Amethyst directly inspired</a> Bevy. Take a look at some sample code</a> from an Amethyst project I wrote 5 years ago: #[derive(Default)] pub struct MovementSystem {} // I was much newer to Rust at this point, but // I'm pretty sure this was idiomatic in Amethyst impl<'a> System<'a> for MovementSystem { type SystemData = ( ReadStorage<'a, Movement>, WriteStorage<'a, Transform>, Read<'a, Time>, ); fn run(&mut self, (movements, mut transforms, time): Self::SystemData) { for (movement, transform) in (&movements, &mut transforms).join() { // move at a constant speed in the direction transform.append_translation(movement.next(&time)); } } }</code></pre> This all might look strangely familiar, even if you've never heard of Amethyst. We're defining a type SystemData</code> that describes all the parameters we want to retrieve from our world, and then join</code> it, sort of like a Query</code>. In Bevy, this would look like the following: fn movement_system(mut query: Query<(&Movement, &mut Transform)>, time: Res<Time>) { for (movement, mut transform) in query.iter_mut() { transform.append_translation(movement.next(&time)); } }</code></pre> In essence, we're still defining SystemData</code>, but defined in the parameters of our system. Visually, we can see how Bevy has improved the ergonomics of using an ECS over the past 5 years, and not just because I unfairly added two lines of comments to the first snippet. This is a very, very small facet of improvements, so while we're on the topic, I'd be remiss if I didn't talk about My favorite bevy improvements since v0.1</h2> Subjective lists are fun! Do you agree? Do you disagree? Remember to leave a comment, and tap that notification bell. system()</code>less systems</h3> If you're newer to Bevy, this post's title might not mean much to you, but back in Bevy v0-something, we registered systems like</a>: App::build().add_startup_system(setup.system())</code></pre> Amusingly, this, combined with developers' propensity to suffix their system functions respectively, led to system registrations that look like: App::build().add_startup_system(birthday_system.system())</code></pre> This is no more as of Bevy 0.6</a> which requires only the function name - no system()</code> call necessary. Bevy is fun to write, as its thoughtful design dovetails with Rust's type system and language features. After some practice, Bevy's API fades away into the background3</a>. </blockquote> Better shaders</h3> I'm really not a math guy. I still don't "get" Quaternions (and I'm not fully convinced anyone else does). By extension, I'm not much of a graphics guy. Adding a custom shader to Bevy when it first released involved touching render code and writing a thesis of boilerplate that I was never able to defend against rustc. With 0.6</code> Bevy moved to wgsl</code> and simplified custom shader creation. 8 releases later, I finally managed to implement a star background shader. I would still love to see more tutorials in this space, specifically for wgsl</code>. Gizmos</h3> Gizmos, introduced in 0.11</a>, are a selection of "immediate mode" drawing primitives useful in debugging and prototyping. Gizmos are perfect for prototyping quick ideas while avoiding the added complexity of assets. I wrote a modest but respectable ~3,000 line project visualizing with only Gizmos before moving on to proper models. doomy 🦀</h6> @doomy@mastodon.social </div> </a> </video> September 7, 2024 at 3:08 AM </a> </div> Triggers and observers</h3> I can't include the removal of .system()</code> without mentioning any of the other major ECS improvements; the continual focus on ergonomics is a big reason I think Bevy has become a relatively popular engine. To better understand what triggers do, let's first understand how to write a Bevy project before triggers were introduced with regular events: Imagine we have a minefield. If one mine is triggered with a click, it causes an explosion with a defined radius. If any other mines are in range of that explosion, they're also triggered. Using events, we can express this relationship like the following rusty pseudocode: #[derive(Event)] pub struct ExplodeEvent { entity: Entity } fn handle_explode_events(mut cmd: Commands, events: EventReader<ExplodeEvent>, mut write_events: EventWriter<ExplodeEvent>) { for event in events.read() { let ExplodeEvent { entity } = event; // Do something with this entity like play an explosion noise, then despawn it cmd.entity(entity).despawn_recursive(); // Find any entities within a set radius (here it is done ~magically~) let entities_to_explode = find_entities_in_blast_radius(entity); for entity_to_explode in entities_to_explode { write_events.send(ExplodeEvent { entity: entity_to_explode }); } } }</code></pre> For astute observers this might trigger a negative reaction, as this is an invalid system definition, requiring both mutable and immutable access to ExplodeEvent</code> events. You'd actually need to use a ParamSet</code> here, accumulate events to write in the event read loop, then send out events after reading. </blockquote> Additionally (and more importantly) these events do not trigger on the same update. Any entities_to_explode</code> are added to the event queue, and then hande_explode_events</code> runs on the next update. This isn't ideal when scaled to hundreds of objects. By comparison, triggers execute in a single update, even when recursed. Bevy's official examples has code illustrating this exact minefield idea</a>. Here's what the equivalent of the above looks like in our pseudocode: #[derive(Event)] pub struct ExplodeTrigger; fn on_explode(trigger: Trigger<ExplodeTrigger>, mut cmd: Commands) { let entity = trigger.entity(); // Do something with this entity like play an explosion noise, then despawn it cmd.entity(entity).despawn_recursive(); // Find any entities within a set radius (here it is done ~magically~) let entities_to_explode = find_entities_in_blast_radius(entity); for entity_to_explode in entities_to_explode { cmd.trigger_targets(ExplodeTrigger, entity_to_explode); } }</code></pre> With triggers, all entities to explode are calculated in a single update, and we don't have issues juggling event mutability. II. Looking back</h1> Organizing a bevy project for honor and success</h2> After many projects, repetition is inevitable. As I am Very Into Rust, I'm also very into conventions and planning (also known as over-engineering). With experience, I've generalized a project organization that works well, and condensed it into a template repo, which I use for new projects. Its goal is not to be a feature-complete starter like foxtrot</a>, but simply to nurture an understandable, scalable project file structure</a>. Very Important Crates</h3> There are a few batteries included, but these are the crates I use in every project. Let's take a look at the default Cargo.toml</code>: [dependencies] leafwing-input-manager = { git = "https://github.com/Leafwing-Studios/leafwing-input-manager/" } bevy = { version = "0.14", features = ["serialize"], default-features = true } bevy_common_assets = { version = "0.11", features = ["ron"] } bevy_asset_loader = { version = "0.21", features = ["2d", "3d", "standard_dynamic_assets",] }</code></pre> leafwing-input-manager</code> is a generalized way to get input over keyboards and gamepads. Folks, do we love to write generalized code? We love it. That guy over there loves it, I see them, they know.</li> bevy</code> is bevy.</li> bevy_common_assets</code> provides asset loaders for - would you believe this - common asset types like ron</code>. In fact, I'm only using its ron</code> feature (as json</code> doesn't let you use trailing commas 😡😤)</li> bevy_asset_loader</code> implements all of the asset loading logic that you would have implemented yourself.</li> </ul> There's also a few commonly used but alternative crates ready to be unleashed, but commented out. They're all related to egui</code>. bevy_egui = "" bevy-egui-kbgp = "" egui_extras = { version = "", features = ["file", "image"] } image = { version = "", features = ["png"] } bevy-inspector-egui = ""</code></pre> The most important crate here is bevy-inspector-egui</code>, which provides a powerful way to diagnose runtime issues, especially for people like me who think debugging is when you write dbg!(..)</code>. We also make bevy-egui-kbgp</code> available, which adds gamepad input support to egui</code> menus. Until Bevy's own UI and editor gathers momentum, egui</code> is the de-facto way to present UI in games. That's it though, just 3-ish crates by default. Outside of setting up bevy_asset_loader</code>, this template doesn't really do much else. It's more about project organization. egui</code>! It's a great library. However, the difficulty with styling, lack of gamepad support, and ever-increasing world data needed to render custom widgets renders it a less-than-optimal choice. Additionally, egui</code> and Bevy's philosophies compete: there is a tendency to include all UI code in a single system to reduce complexity, leading to incredibly long and terse UI system functions. I'm looking forward to Bevy's own UI maturing providing a more constructive relationship between ECS and UI. </blockquote> Project organization</h3> My 6th grade math teacher had a poster that said "Organization is the key to success". So true! I also couldn't stay quiet during his class, which also taught me about detention. Although I don't consider myself a particularly organized person, my brain does have those peculiar deleterious set of genes innate to humans that make us clap our hands and jump up and down whenever we successfully organize things into groups. </blockquote> Here's another fact about my mysterious past: I used to be really into Ruby on Rails (and according to some Rust surveys, a lot you probably were, too). Rails is all about "convention over configuration". That quote itself was coined by Rails' creator, Hatsune Miku. </blockquote> MVC isn't exactly a sexy term. It's arguably sexless. But parts of MVC began to influence how I began to structure my Bevy projects, drawing inspiration particularly from strong separation of data and functionality. In Rails, the data bits are "models", and the functionality bits are "controllers". These are analogous to components and systems in Bevy. Rails has one more level of organization: controllers are not single functions, but a type with several inherited methods (e.g., "new", "create", "delete"). In Bevy, these are akin to Plugin</code>s, which group systems into a single unit. </blockquote> In my experience, it's rare that a system doesn't belong in a single Plugin</code>. Grouping related systems can help ease the cognitive load of storing larger projects in (human) working memory. To achieve this, all systems in my projects are private^{4</a>, and only the containing Plugin</code> is exposed, resulting in this directory structure:} src/ components/ mod.rs my_component.rs plugins/ mod.rs my_thing.rs resources/</code></pre> This simple setup works well for my projects and seems to grow manageably. So far. Preludes</h4> Bevy developers love preludes! use bevy::prelude::</code> is far easier than importing every item by name. So why not extend this pattern to my own projects and be my own consumer by adding a pub use</code> statement within a prelude</code> module in our lib.rs</code>? pub mod prelude { use super::; #[allow(unused_imports)] pub use {components::, error::, plugins::, resources::, states::, ui::, util::}; } // Leave out `pub` for any types you don't want available in these modules.</code></pre> With this pattern, our game's most important types are available with a single import of use crate::prelude::</code>. Note that I have a states/</code> directory in my template repo, but I've yet to have an application need more than one state (and I don't even know if that's supported tbh). States are just resources, so it's better to add a state.rs</code> file in resources/</code> instead. </blockquote> Naming</h3> If it is necessary to convey type information in a type's name, it can be a signal that the project's organization may need improvement. Controller</code> is a better type name than ControllerComponent</code>; it is easier to type, clearer to read, and is already known to be a component by implementing the Component</code> trait. If disambiguation is necessary, modules can be used. For example, event and trigger names are often similar to component names. When using the prelude</code> method, a problem arises: What if we have an Equip</code> component and an Equip</code> event in the same namespace? // Errors pub mod prelude { use super::; pub use { components::Equip, events::Equip }; } pub mod components { pub struct Equip; } pub mod events { pub struct Equip; }</code></pre> It's tempting to add an "Event</code>" to the end of the type's name, but this creates a new issue where Event</code> types litter the project with no apparent grouping. We could prefix the type name with "Event" to search alphabetically for related types in our editor, but this forces us to be verbose, even in situations where it's unnecessary, and is downright awkward. // Not the best solution // Components are common so no suffix is added pub struct Equip; // Events get a suffix added to the type name pub struct EquipEvent; // pub struct EventEquip; // Would be better for searching for events, but looks weird</code></pre> Instead of adding to the type name, we can leverage modules. Because component types are extremely common to use, they can stay in the prelude</code> root. We'll move event</code>s and trigger</code>s to their respectively named modules available within prelude</code>. pub mod prelude { use super::; // This is identical as our first example, but we're only exposing // the entire events module instead of specific items pub use { components::Equip, events }; } pub mod components { pub struct Equip; } pub mod events { pub struct Equip; }</code></pre>// Use in the project use crate::prelude::; fn my_system(equips: Query<&Equip>, events: EventReader<event::Equip>) { // No conflicts! }</code></pre> If in a particular file, components were completely unused, while events were used heavily, we could write use crate::prelude::event::</code>. This flexibility is a nice bonus to modules neatly separating our ever-growing list of types available in prelude</code>. While we're crossing into subjective territory, I like namespacing by modules instead of adding extra info to the actual type name. That's what modules are there for to begin with, right? I like writing event::Equip</code> instead of Equip</code>, even if it weren't required due to aliasing another type in the prelude. </blockquote> Projects</h2> Outside of a few projects, I've rarely pushed one to a "complete" playable state. I'm okay with that! I work on a product team of a tech company. It's nice to start creating without a clear goal. Ideating, finding creative solutions to problems, and promptly deleting those creative solutions because you've moved in a new direction isn't a good way to develop games, but it's a great way to learn. Let's peruse the few dozen gibberish-named private repositories of ideas stashed on my GitHb and see if I've actually learned anything. bevy-puzzle</a></h2> It's a puzzle game with tetrominoes! Simple as it is, I'm happy with how this turned out</a>. Sure, it may crash when you win because it tries to write to a highscores file that doesn't exist in the WASM build, but the several seconds of gameplay beforehand is fun! This project highlights a recurring theme for me: I don't like 2D. Whenever I'm a few hours into a project using sprites, I can only think of how much easier everything would be in 3D space. I don't want to deal with sprite ordering in an isometric 2D game. We live in the future. We have access to more dimensions now, even the 2D is 3D5</a>. doomy 🦀</h6> @doomy@mastodon.social </div> </a> </video> September 7, 2024 at 4:12 AM </a> </div> wordlrs</a></h2> Wordle is a relatively simple game to implement, so this project</a> furthered my working knowledge of egui with an achievable goal. A feature of this implementation is that it is language-independent. (If the language uses an alphabet. 对不起6</a>). While this sits among my rare playable projects, it's not at all interesting. Wordle doesn't particularly take full advantage of an ECS (but Wordle 99</a> absolutely would, someone get on that). modsynth</a></h2> Not a Bevy project (nor a eurorack), modsynth is a naive model synthesis implementation (also known as "wave function collapse"). My main takeaway from this project is I am not good at math, and constraint solving is hard7</a>. I did, however, create a neat dynamically generated 3D scene using Bevy. It's exactly like "Lethal Company", except without any gameplay. doomy 🦀</h6> @doomy@mastodon.social </div> </a> alright so i got my model synthesis program running in bevy so i can fit together a bunch of uninteresting hallways </video> January 14, 2024 at 5:23 PM </a> </div> bevy-planty</a></h2> It's an L-system</a> visualizer! L-systems use relatively simple instructions to generate complex structures, and can be used to model plants. egui is great, but working on this project was an early encounter with its aforementioned pitfalls. There's more than a few broken buttons. doomy 🦀</h6> @doomy@mastodon.social </div> </a> </video> September 9, 2024 at 5:08 PM </a> </div> bevy blast ultra</a></h2> My solo Bevy jam #4 entry: a marble run game inspired by Super Marble Blast Ultra with levels designed in Blender using Blenvy. In retrospect, I have no idea how I pulled this off in a week. I have an epic-style post talking about this some more</a>. III. Looking forward</h1> What I'm still waiting for</h2> In my game, I have items, which are described as an Asset</code> using ron. /// A general in-game item #[derive(Debug, Component, Clone, Reflect, Asset, Serialize, Deserialize)] pub struct Item { /// The in-game name of this item pub name: String, /// The in-world mass of this item pub mass: f32, /// The space this item displaces in the [`Inventory`] pub size: usize, /// The worth of this item in `Credits` pub value: usize, }</code></pre>( name: "scrap metal", mass: 0.1, size: 1, value: 10, )</code></pre> Assets are perfect, because I can modify or extend my game with new items without recompilation. Items aren't entirely useful without the ability to pick them up, so we'll also need an inventory: // This is overly simplistic and not doing anything with our items `size` or `mass`, but it'll get the idea across, just wait. #[derive(Debug, Clone, Component, Reflect)] pub struct Inventory { /// Items and their count in the inventory items: HashMap<Handle<Item>, usize>, }</code></pre> Inventory</code> is a Component</code> that contains references to Item</code>s in the form of a Handle<Asset></code>. This provides two obvious benefits: items can be hot-reloaded, and cloning handles is cheap compared to cloning an entire Item</code> fully, especially as items gain fields and additional complexity. This works well until we need to serialize. Handle</code>s are runtime specific, so while we can technically write a Handle</code>'s ID to a file, it won't be valid the next run. Instead, AssetPath</code>s are required to successfully serialize and deserialize. Bevy's animation graph</a> does something similar to this, but it's not necessarily a fun or easy thing to implement in your own projects. // From `bevy_animation` - https://docs.rs/bevy_animation/0.14.1/src/bevy_animation/graph.rs.html#166 /// A version of `Handle<AnimationClip>` suitable for serializing as an asset. /// /// This replaces any handle that has a path with an [`AssetPath`]. Failing /// that, the asset ID is serialized directly. #[derive(Serialize, Deserialize)] pub enum SerializedAnimationClip { /// Records an asset path. AssetPath(AssetPath<'static>), /// The fallback that records an asset ID. /// /// Because asset IDs can change, this should not be relied upon. Prefer to /// use asset paths where possible. AssetId(AssetId<AnimationClip>), }</code></pre> This is just the data representation. Actually serializing and deserializing this isn't as straightforward. At least to me. The ability to "persist" asset handles is useful - especially with dependency resolution. Wouldn't it be nice if we could just do that? bsn! bsn!</h1> Bevy's proposed scene format is going to solve all of my life's problems. For one, it solves that Handle<_></code> issue by introducing Construct</code>: a way to initialize components that need to access stuff from our ECS world. Now, we can serialize handles to an AssetPath<_></code>, and neatly deserialize back into a Handle<_></code> via access to the asset server. This can immediately simplify save strategies. Now that we have a way to reference other assets, my idea of prefabs is possible. Let's go back to my top-down space game with the inventory as an example of why this is useful. # Our assets directory assets/ items/ laser.weapon.ron metal.item.ron battery.energy.ron models/ crab.gltf ship.gltf creatures/ crab.creature.ron</code></pre> You can think of creatures</code> as NPC definitions. If we load crab.creature.ron</code>, we should be able to spawn it and its components. This is what the crab creature ron</code> looks like: ( name: "crab", model: "models/crab.gltf", inventory: [ ("items/laser.weapon.ron", 1), ("items/battery.energy.ron", 1), ("items/metal.item.ron", 3), ], )</code></pre> This is valid ron</code>, so we could load this - but Bevy has no idea what these random path strings mean. We first need to map our asset paths to runtime handles. Luckily [bevy_asset_loader](https://docs.rs/bevy_asset_loader/latest/bevy_asset_loader/)</code> does this for us. All we need to do is load our items and models, then load our creatures - probably by checking an Added<Creature></code> query and building the described entity manually. This works, though it's highly manual, prone to errors, annoyances with circular dependencies, and is a general bother to maintain and extend. Bevy doesn't have a concept of a common collection of components on purpose (Bundles and Archetypes don't count). There is no concept of the "shape" of an entity known statically. Our "NPC" is nothing more than interactions between specific components: they are entities that have a Transform</code> component, a Controller</code> component for movement, and a Thinker</code> component for directing Controller</code> movement. Nothing in the type system describes that specific relationship of components - and it shouldn't. Bevy's API encourages systems to use the least amount of components necessary, which results in general code that adapts with emergent behavior as systems and components are added. But, our ron</code> data description goes against this philosophy and limits flexibility 😢. What if we wanted to add a unique BossName</code> component? We'd have to add a whole new field to the creature</code> struct to support this optional BossName</code> component, which means recompilation is required. It also inevitably grows the entity description struct into a gigantic mess of Option<Component></code> fields. With bsn</code>, we can instead define almost everything in our game as a Bevy scene, with any arbitrary components, including our BossName</code> or anything else, allowing us to build significant game content without needing to venture into the codebase. This is similar to Bevy's DynamicEntity</code> (used in DynamicScene</code>), except that we can now add and save components with world context, meaning we can serialize a Handle<_></code> to an AssetPath<'_></code> and back into a Handle<_></code>. Check out the whole thread on GitHub for more details on Bevy's new scene system</a>. Closing thoughts</h2> Organization is not easy. Bevy hitting 4 years, all the while gaining momentum, is beyond encouraging. Bevy community members are some of the most engaging, friendly, and helpful people I've met online. It's special to share a space where there's little profit motive - just creative people making cool stuff that inspires them. Footnotes</h3> ^1Including some of the earliest work on a fully-Rust UI toolkit named conrod</a>. I can't overstate how cool it was to be able to write a GUI application, completely in Rust, 5 years ago. </div> ^{2 There's no indication that Piston is EOL like Amethyst, and there are some commits this year, but it looks to be in maintence mode. </div>}^{3 You know you're writing good rust when you have to include #[allow(clippy::too_many_arguments)]</code> or #[allow(clippy::type_complexity)]</code> </div>}^{4 Sort of. Generic or error handling systems especially may be used across many plugins. I add these special cases to a utility</code> module public to the crate. </div>}^{5 When I work in 2D, I feel like I'm slowly walking down a big hill, wishing I remembered my Heelys so I could just slide to the bottom. </div>}^6Some argue that Chinese has an alphabet, it's just thousands and thousands of characters long. In any case it cannot be wordled (but can be pinyindle'd</a>) </div> ^7I may have had an easier time if I referenced more than a single YouTube video on repeat for several hours</a>. (This entire experience also revealed to me just how criminally underappreciated Paul Merrell is for his research in this area.) </div> I submitted a game to Bevy Jam 4 and it was pretty cool 2023-12-16T00:00:00+00:00 I submitted an entry to the 4th #bevy jam this December, with the theme of " That's a LOT of Entities!". As a big fan of the Marble Blast Ultra</a> game on the 360 arcade, I though I might try a stab at something similar. Bevy Blast Ultra</h2> With subtle acknowledgement of its inspiration, Bevy Blast Ultra</a> brings several minutes of non-stop MVP marble action to any browser</del> Windows, Mac, or Linux machine. How's Bevy 0.12?</h2> There's a couple Epic Rust Moments and issues I ran into while creating this game. Bevy has grown tremendously since I last wrote about it in version 0.6, and this is an effort to document what I found of note. Bevy editor, pls</h3> While Bevy is a capable engine, its lack of an editor means procedural generation is much more achievable in comparison to handcrafted levels. A game like MBU, however, requires intentionally designed levels (or a wizardly knowledge of procedural generation). A few 3rd party editors for Bevy</a> exist at the moment, but are understandably limited in comparison to established engines like Unreal. Fortunately, Bevy is able to import GLTFs, and a workflow for exporting to Bevy is already available</a>. Using a single .blend</code> file, I could edit all levels as different scenes, and create reusable prefabs. Most importantly, I could create any kind of level geometry that Blender could export. doomy 🦀</h6> @doomy@mastodon.social </div> </a> goal areas #bevy</a> b vevy bev y </video> December 5, 2023 at 1:57 AM </a> </div> Early development footage </blockquote> Assets are still kind of tricky, but not as much</h3> Assets used to be among the more tedious game logic to implement. With the advent of helpful crates like bevy_asset_loader</code></a>, this isn't much of an issue. Before I decided on going the Blender route, I considered writing a bunch of .ron</code> scene files by hand. I would have liked to specify a bunch of prefab .ron</code> scenes, and use them within level .ron</code> scenes. Apparently, that still isn't a possibility just yet, but I hear an overhaul of the way scenes are handled in Bevy is under way. I imagine this might rely on some of the new asset v2 preprocessing features released in 0.12</code>. Annoyingly, it's still impossible to load folders with WASM (which isn't a Bevy issue, but still a bummer when you have to hard-code filenames in your project for web support). Z will always be up to me</h3> ok seriously though. "Up" is (0.0,0.0,1.0)</code>, and I'm Tired of People trying to Tell Me Otherwise! It is not (0.0,1.0,0.0)</code>. I will die on this very tall Z-aligned hill. This brings me to The worst moment of the Bevy Game Jam 2023: figuring out skyboxes. I spent 6 very misplaced hours right before the due date attempting to figure out how to convince my skybox image that Z is up. This was, of course, completely unnecessary compared to fixing core issues with the camera logic, but I persisted and brute-forced my way to figuring it out. The wretched skybox journey</h3> Bevy provides a few files in the example assets for showing a skybox image, but it has some minor issues - mostly the fact that it is a little bit rotated. But that shouldn't be an issue, right? With the right editing, I could certainly rotate it back in the right direction. But the files Bevy provides are ktx2</code> images. Most tools to convert to and from this format are CLI based (or need compilation) which I wanted to avoid. NVIDIA does provide a GUI application for viewing and exporting many of these filetypes, but it claimed my precious ktx2</code> files were corrupt. This application has many, many settings, and I know what approximately 0 of them actually do. </blockquote> Thankfully, the Bevy repo also provide a .png</code> skybox example, I just needed to map portions on the image in the correct sequence and rotation to match, which I figured out slowly and arduously by changing the image until everything properly tiled together. I'm sure this is a solved problem, and there's a document somewhere specifying where to put which bit of image, but I instead spent hours brute forcing this. But hey, it eventually worked! I skipped over a lot with this story. It also involved forking a cubemap generator javascript project so I could up the photo resolution, and lots of aggravated scribbling in Microsoft paint </blockquote> I do not know how to compile a C project</h4> One alternative route was to use Patrick Walton's automatic tool</a>, but this requires a beginner level of C knowledge and some patience. After scouring the internet for the right header files to download, and reading source code to figure out where to place them, I gave up. But it looks like a great application for this exact purpose, if you're able to get it running. The world's most difficult to remember acronym</h3> Since I last used Bevy, its added another physics engine to the mainstream - bevy_xpbd</code></a>. The xpbd</code> part stands for Extended Position Based Dynamics. Without a bookmark, prepare to enter every permutation of xpbd</code>'s letters in your search engine. XPBD to my understanding is a newer (but less battle-tested) way to calculate physics. The YouTube channel Two Minute Papers</code></a> does a pretty good job summarizing the differences between XPBD and more traditional methods. One interesting feature of XPBD is that it can simulate situations where more traditional methods would fail, such as marbles on a track, which I incorporated into my game. doomy 🦀</h6> @doomy@mastodon.social </div> </a> something cool about bevy_xpbd is you can do these marble track things that would definitely break other engines </video> December 8, 2023 at 2:59 AM </a> </div> I've used Rapier almost exclusively in the past, and while it's matured nicely, it's still a library intended for general use. That means it needs the glue of bevy_rapier</code> to translate into our game world, and the Rapier and Bevy world don't always play together without issues. bevy_xpbd</code> on the other hand, is designed specifically for use in Bevy, which (in my opinion) makes its resulting API far friendlier and intuitive to use. I didn't encounter any bugs or strange behavior and will use it as my physics engine of choice moving forwards. I only wish it had some built in forces (outside of gravity) like wind or magnetism - but those are easy enough to implement yourself. Graphics are too good</h3> As I alluded to earlier in this post, Bevy Blast Ultra is not playable in-browser, because it runs like rotten garbage, clocking in a spectacular ~0.5FPS despite my desperate fumbling with wasm-opt</code>. After playing a few other submissions, I suspect the issue is the shadow graphics, which were recently improved and look great, but might cost too much for a browser game. But hey, it looks really nice! </iframe></div>

Source</h4>
Source code for the synthesizer simulation shown on this page can be found in this repository</a>.</p> </blockquote>

birthday_system.system()

II. Looking back</h1>

I submitted a game to Bevy Jam 4 and it was pretty cool

doomy

Bevy's 5th Birthday

Using Game Center with Bevy on iOS to manage save files

Building a model locomotive controller with embedded Rust

doomy

Bevy's 5th Birthday

Using Game Center with Bevy on iOS to manage save files

Adapting the 0.15</code> template</h2> This tutorial assumes you already have the toolchain and dependencies required to use XCode and build an iOS application</p> </blockquote>

Fixing assets</h3> Let's look at the Project navigator. The assets</code> directory is also broken because of relative links.</p>

Building a model locomotive controller with embedded Rust

birthday_system.system()

II. Looking back</h1>

Preludes</h4> Bevy developers love preludes! use bevy::prelude::*</code> is far easier than importing every item by name. So why not extend this pattern to my own projects and be my own consumer by adding a pub use</code> statement within a prelude</code> module in our lib.rs</code>?</p>

doomy 🦀</h6> @doomy@mastodon.social</p> </div> </a>

III. Looking forward</h1>

What I'm still waiting for</h2> In my game, I have items, which are described as an Asset</code> using ron.</p>

I submitted a game to Bevy Jam 4 and it was pretty cool

doomy 🦀</h6> @doomy@mastodon.social</p> </div> </a>

doomy 🦀</h6>
@doomy@mastodon.social</p> </div> </a>
alright so i got my model synthesis program running in bevy so i can fit together a bunch of uninteresting hallways</p> </video> January 14, 2024 at 5:23 PM </a> </div>