- Devil Dahu developers blog

A year of bevy, past and future

2023-08-11T00:00:00+00:00

Recently, bevy</a> celebrated its third anniversary</a>.

I (Nicola) started using bevy around November 2021. This was under the impulse of our project mushroom prototype. Since then, I invested myself more and more in bevy. I contributed large features such as morph targets</a> and parallax mapping</a>, and I created useful plugins such as bevy-debug-text-overlay</code></a>, bevy-scene-hook</code></a>, and cuicui_layout</code></a>.

I also take a lot of time reviewing and giving feedback on community-provided pull requests. During the last 12 months, according to GitHub, I submitted 200 PR reviews on bevy projects and opened 90 pull requests. This means I am responsible for 5% of all bevy PRs in the past year, and reviewed 10% of them (though GitHub might count multiple reviews on the same PR).

How did bevy evolve in the past 12 months?</h2> I’m spending way too much time on bevy for my own good. While my wallet doesn’t thank me for that, I have a clear idea of the health of the project. So let’s share here what I see. Code reviews</h3> I was impressed at the speed at which bevy was capable of processing pull requests and integrate them. However, in the past three months, I see a drastic slowdown in PR reviews. I think a lot of active members are focusing on other things currently and don’t have as much time to review code. It’s a shame, because this is blocking amazing features such as: Cosmic text integration</a></li> GPU picking</a></li> System stepping (aka: time machine)</a></li> dynamic queries (aka: efficient script queries)</a></li> archetype invariants</a></li> batched queries (aka: SIMD query iters)</a></li> </ul> I’m also frustrated with the snail pace at which my own PRs gets reviewed. It’s sad to open a PR or design suggestion and get no feedback on it for several weeks. I’ve no solution for this. I review a lot of PRs and it’s not enough to compensate the PRs I open! The only option I see is a call to action: please review bevy PRs, it will make bevy move much faster, and it might attract more contributors who themselves may become reviewers in time. Rendering</h3> I’m extremely surprised at the insane speed at which bevy’s renderer progressed in the past twelve months. I’ve no background in graphic programming, yet my most meaningful contributions to bevy are rendering features. This is thanks to Rob</a> and James</a>, and their excellent support in introducing me to bevy’s gnarly rendering system. Yet, I think anyone who worked on bevy’s rendering system understands how complex and error prone the code is: Nine layers of very indirect abstractions</a></li> Awfully cryptic error messages</a></li> </ul> I wrote down in the bevy GitHub discussion forum a “guide” on how to navigate the render code</a>, but it’s still incomplete and glosses over major concepts. UI</h3> bevy_ui</code> has been seeing steady improvement in the past few months thanks to ickshonpe</a>. Current day bevy UI might look bad, but you don’t realize how awful it was 12 months ago, especially looking at the internals. Thank you ickshonpe for improving bevy_ui</code> internals! It’s a very thankless work, they deserve the shout out. A bevy of bevy plugins exists to make handling UI easier. I’m personally responsible for a few of those. Recently, lumex</a> and cuicui_layout</code></a> came out. Both try to abstract UI from UI rendering. I think it’s a viable path. Re-using the sprite renderer also has the advantage of culling a lot of duplicate code. It’s also important to note bevy-ui-dsl</code></a>. It was a breakthrough in bevy UI declaration ergonomics, cuicui_dsl</code> is mostly derived from bevy-ui-dsl</code>. Performance</h3> Performance and code size has been steadily declining in the past 12 months. It’s currently difficult to know how much performance impact your PR has, and it’s currently too burdensome to benchmark changes outside of perf-focused PRs. We need to have better benchmarking (or any benchmarking at all) in order to avoid the trap of steady bloat and perf decline. Other engines fell out of relevance partially due to this kind of bloat. This is a threat to bevy and we should be careful to avoid it. What’s next for bevy</h2> UI</h3> I suspect bevy is going to see a lot of change in UI in the near future. ickshonpe has been doing stellar work on bevy’s UI. IDEDARY</a> ported their longstanding game UI toolkit</a> recently to bevy. I broke ground on cuicui_richtext</code></a> and started work on cuicui_layout</code></a>. Cart mentioned they want to focus on UI next. I really hope we get an ECS-based solution for UI state. The only difference between storing state in the ECS and passing state to a sort of react/tauri-like framework is that you won’t be able to query UI state outside of UI code. My wish list for UI is: Easy, hot reloadable, UI declaration syntax. Should have the ability to integrate with rust logic, while not itself containing logic (so that it is hot-reloadable)</li> A rust-based UI declaration API with good error messages and trivial layouting algo, such that it’s easy to know the end result from the code (yes, this is the cuicui_layout</code></a> tagline)</li> Tool to build visually a UI. But the tool in question should follow closely the UI declaration syntax</li> Debugging tools similar to cuicui_layout</code></a></li> A way to use UI with sprites, and maybe within 3D worlds if possible. (also a cuicui_layout</code></a> tagline)</li> Good integration in ECS, so that interoperability between bevy systems and the UI are trivial (I have in mind the cuicui_bevy_fab</code> query system).</li> Way to also define logic based on inlined rust code (not sure why people think it’s mutually exclusive with bevy systems)</li> Amazing richtext module (cuicui_richtext</code></a> cough cough)</li> Setting up gamepad and keyboard-based UI navigation without headaches.</li> </ul> What's the plan for your UI crates?</h4> bevy-ui-navigation</code> should be split up, so that it focuses entirely on keyboard/gamepad driven navigation, and leave pointer-based UI to other crates. cuicui_richtext</code> is on hiatus. Its scope has exploded and I’m not sure what the way forward is. I’m still working on cuicui_layout</code>. I’m working on an even better debugging view, with more detailed text information on container state. A hot-reloadable UI declaration syntax is on the roadmap. Currently I’m taken up in other duties and progress on those crates are stalled for the next month or so. </div> Reflection</h3> I also see a lot of potential for reflection. Currently it depends a lot on rust’s trait objects. This is safe and easy to validate. But I see a future where bevy_reflect</code> works on a much lower level, leveraging pointer offsets and memory layout. This would make bevy_reflect</code> viable on a much broader set of use cases. I suspect it could help us reduce the binary size of bevy apps, as a lot of the code size (10%) are instantiation of generic functions, such as FromType<T></code> and App::init_resource</code>. Hopefully we can move most of the code into erased function that works on bits rather than specific types. My wish list for reflection: Dynamic queries: makes it possible to construct in non-rust code queries, submit them to bevy and get &dyn Reflect</code> in response.</li> Offset-based field dereference. So that accessing a field of a struct is literally as efficient as just doing it in rust. Currently it calls a dynamic trait object method. With path-based reflection, it may do it several times.</li> Fast, efficient World se/deser based on reflection. I designed bvyfst</code></a> as a testbed for a max performance bevy scene format, but it requires deriving additional stuff on components.</li> The Unique Reflect RFC is implemented.</li> </ul> What's up with unique reflect?</h4> The Unique Reflect RFC</a> is more a set of guidelines on how to think and document bevy_reflect</code> features. I’m already satisfied with it, in that it has been helpful to bevy contributors to design and document their code. </div> Rendering</h3> There is still two major rendering PRs open: PCF shadows</a> and light transmission</a>. They will be merged quickly before 0.12. Those are amazing features to have! Otherwise, I think it’s time to rethink bevy’s rendering system. Griffin worked on a deferred renderer</a> for bevy. JMS55 have been considering ways to simplify our gnarly rendering systems. My personal wish list is: A less indirect rendering approach, make obvious when rendering code runs</li> Shortcuts for bind group & bind group layout creation. Currently, most of the rendering code is bind group creation boilerplate.</li> Better handling of shader defs. We could track what bind group layout each shader def requires, so that errors are more easily surfaced.</li> Vertex attribute generation. This is a requirement for arbitrary morph targets.</li> Better error messages. I suspect keeping track of bind groups, entity and comparing them to the shader of render pipeline would be very helpful. But in a prefect world, we would track and tell the users which line (in rust and their shader) is causing the error.</li> </ul> Strangely, I have the presentiment that such improvements are dependent on better understanding of what would make a great bevy UI framework, and better reflection. Why I'm not working on adding parallax mapping to the prepass</h4> Ideally we run parallax mapping in the prepass. We would update the depth buffer so that shadow mapping, TAA, SSAO, and proper object occlusion follows the visuals of the geometry with parallax mapping applied. But parallax mapping is fairly costly, and running it once per shadow-casting source, and bloating the perpass with it is bad. </div> Editor</h3> The editor is blocked on better UI. There has been a lot of discussion on the editor. Whether it should use IPC or be an in-game bevy plugin. What design guidelines to follow, etc. However, for my part, I refuse to partake in such speculative discussions before the UI story is resolved. I designed the klod editor</a> so I may comment on it. To me, the Klod editor was useful because: It let me place visually objects in scenes, fixing up at the last minute levels I designed in Blender.</li> I could extend it to bring my own key mapping (I prefer Blender’s keymaps)</li> </ul> Gizmos</h3> Bevy’s gizmos are still very limited. As a result, gizmos from one plugin do not play well with gizmos from other plugins. As more crates adopt gizmos, we might see more and more conflicts. My amazing gizmos tracking issue</a> is already a wish list, so I won’t write one here. The bevy book</h3> This has been cooking forever and it’s a major failure of the project IMO. But we finally started work on it, and I’m expecting to see an amazing high quality guide for newcomers taking shape in the next 12 months. Bevy CI</h3> I think bevy has now outgrown the capabilities of GitHub CI and needs dedicated CI hardware. I would love to see a bevy build server for the following reasons: Faster CI for PRs & merges. Faster site deployment, all the goodies!</li> Regular benchmarks to track bevy’s performance and compiled binary size. We do love graphs, let’s make graphs.</li> </ul> Rustc has an excellent benchmarking setup, and it would be lovely if we had a similar one. In short</h2> Bevy has been moving forward at an incredible pace. The only negative thing I can say about it is that it didn’t move even faster. It’s already an incredible pace because it’s far beyond any expectation. So it would be ridiculous to complain about it not being faster. I have nothing but positive things to say of cart and the community. Just “let’s go!!!” And remember, please review bevy PRs!!!!!

Our dev environment 2023-02-26T00:00:00+00:00 A setup post this week, because I’ve really no progress to report on. Fossil</h2> Fossil</a> is a source code management system similar to git</a>. Unlike git, it integrates project management features like bug tracking, wikis, and account access control. It’s very much like github, but you can manage it yourself. Our web host</a> comes with fossil preinstalled. Issue is that at the time I didn’t know it, so it took me a while to get there. But once I figured I could just use the preinstalled version, it went as simply as it could. </div> Once I got things setup, of course, the first thing I did was personalize the CSS. As you can see, I went ham. In terms of source code version control, fossil doesn’t change much from git. It is opinionated toward trunk-based development, and automatically syncs before commit. Otherwise, the most important difference is the absence of a staging area. But for solo dev, it’s not that different. In terms of project management. I didn’t have the opportunity to use the wiki and tickets. However, unlike gitlab, fossil is extremely efficient. And unlike gitea, it runs as a CGI script. Which means I can use it on my host provider. Fossil, furthermore, is fully open source: No gated functionalities, no artificial limitations. It has an expansively fine-grained user access control panel, and a way to sync them between repositories. For game development, fossil is lacking large file support. I’m currently using the “untracked files” feature to publish (internally) the assets with the dev game executable. Ideally, tracking of assets goes beyond source control, and is integrated into the game executable as much as source control. Discord</h2> devildahu exists mostly as a discord server where we coordinate our efforts. (note that we also have a public discord server</a>). The little programming I did this week involved creating a bot to post fossil timeline updates to our discord server. </div> The bot is just a rust program running once per hour on the web host that calls the fossil executable like so: fossil rss</code> and posts to a discord webhook</a> a summary. Using a rss parsing crate, I read the relevant metadatas and, with serde, converts them into the POST payload for the line item. This enable us to know what each other is working on. Because I’m terribly obsessive and want to know everything my friends do</del> it allows to build trust by making our work and contribution to the team visible. Hopefully motivate each other to contribute more, and know where to focus our contributions. 2023 devlog 3 2023-02-19T00:00:00+00:00 Third weekly devildahu devlog, the last one is available here</a>. This is going to be short, as I burnt a bit out and kept 3 days for myself. bevy_mod_cuicui</code></h2> As promised last week, I spent more time thinking about UI in bevy. After the last post, which helped me better understand what I wanted, I quickly came to the conclusion that I didn’t want to make a UI framework. I wanted to keep in the bevy spirit, create primitives and build UI on top of those primitives. An integrated framework solution, not only is antithetical to bevy’s goals, but also antithetical to my own principles. I was designing the Prefab</code> interface for bevy_mod_cuicui</code></a>, but I came to the conclusion, such an interface wasn’t needed (while not exactly useless). My current assessment is that I just want several ways to “spawn” or “specify” an UI: I want a way to define my UI through a simple text format, I want this to be composable, and extensible through bevy’s Reflect</code></a> trait.</li> I want a concise but beautiful by-default way of specifying a tree of UI elements. Ideally, this is composable, extensible and type-safe.</li> </ul> Those two ways are not mutually exclusive, but they are definitively unrelated. This is pretty much the result of half a second of through after last devlog. It really took me more time to write this section than go to this conclusion. So I went back to an older abandoned project of mine (I tend to accumulate those) bevy-kdl-ui</code></h2> bevy-kdl-ui</code></a> was my first attempt at solving the bevy ui problem. The premise was informed by insights that I seem to have forgotten: How great it was to use a LISP interpreter for defining state machines for project mushroom. As I could use LISP macros to make state machine declarations composable, without writing any parsing code. (for my defence, a similar system was used in The Last of Us)</li> Prefab</code>s (meaning: a tree of ECS entities with collections of components) can be expressed as a macro, parameters as macro parameters, etc. All the work could be done before deserialization.</li> </ul> I actually spent a lot of efforts on bevy-kdl-ui</code> before abandoning it. But I still think this model may help, so I went to it and tried to at least get a minimal working version (if even extremely buggy, slow and limited) to see if I could iterate on it and start building a collection of widgets on top of it. In the space of 3 days, I gorked the code, then wrote a bevy loader for the deserialization format that already worked (thanks to an excellent test suit). I wrote an example, but never ran it. It feels very unpleasant working on it. Every functionality I added needed very ugly hacks (for example, the loader doesn’t use bevy’s loading system due to dependency management, it also isn’t asynchronous, due to the complexity of managing a cache of loaded templates). So of course, most of the code I write is marked for refactoring, it just feels wrong. As a result I didn’t do much more. I hope to get back on track for next week. (you may be interested in this blog’s [rss] feed) Necking devlog 2 2023-02-12T00:00:00+00:00 Second weekly devildahu devlog, the first one is available here</a>. Necking</h2> This week, I only dedicated 3 days to Necking, and three very short days at that. I wanted to make Necking more editable to enable less technical members of the team to play with parameters of the game, and especially load arbitrary models for the giraffes. Scene reload</h3> bevy</a> ostensibly supports hot reloading. However, hot reloading in bevy is broken for scenes</a>. This is a problem, since giraffes are loaded as scenes, this bug would prevent loading live new giraffe models. Solving this involved two things: Have some sort of management of scenes to keep track of spawned entities related to a scene.</li> Writing hot-reloading code.</li> </ol> For (1) I was already using bevy-scene-hook</code></a>. However, as implemented, it didn’t allow for reloading. So I created a reload</code> module, mostly a copy of the original code, but with handling for respawning and despawing. For (2), I started by shamelessly copying the bevy code for hot-reloading, it’s about 30 lines of code. It’s nothing more than creating a RecommendedWatcher</code> from the notify crate</a>, establishing a communication channel between it and a bevy system and reacting to events it sends. I kept this code, and when receiving an event, I set the ReloadSate</code> component from the newly created reload</code> module of bevy-scene-hook</code>. Parametrization</h3> I’ve been a great fan of Sakurai’s series on video games</a>. He explains in one of those videos that he uses an Excel Add-In to manage all the parameters</a> (damage, time, cancel frames etc.) of the Smash Bross characters. Necking had a lot of parameters hardcoded. But as a good programmer, I avoid just sprinkling the code with arbitrary values. Most of the parameters, even if hardcoded, were named and centralized as a series of const</code> definitions. Hot programming tip</h4> If in your code, you see a literal value within a function such as 0.132</code> (something extremely specific), it is probably worthwhile to replace it with a constant. Naming things help build a semantic narrative around what your code is doing. Furthermore if in the future, you need to re-use the same value, you can simply use the variable name rather than copy/paste the value: // What is 12.344??? fn do_the_foobar(position: &mut Vec3) { position.x += 12.344; } // much better, // I know that I'm adding RETICULAR_OFFSET to `x`! const RETICULAR_OFFSET: f32 = 12.344; fn do_the_foobar(position: &mut Vec3) { position.x += RETICULAR_OFFSET; } </code> </div></pre> My goal was to get rid of all those const</code>s and replace them with a bevy resource that I would load at startup from an external file. I also wanted to be able to write a template file, ideally with default values taken from the const</code>s pre-existing values. It was almost straightforward. I decided to create a struct Parameters</code> per bevy plugin/rust module that used to rely on hardcoded const</code> values. #[derive(Clone, Debug, Resource, Default)] #[cfg_attr(feature = "debug", derive(Reflect, FromReflect))] pub struct Parameters { pub controls: scheme::Parameters, pub neck: neck::Parameters, pub camera: cam::Parameters, pub input_mapping: input::Mapping, pub models: Models, } mod scheme { #[derive(Clone, Debug, Resource, Default)] #[cfg_attr(feature = "debug", derive(Reflect, FromReflect))] pub(super) struct Parameters { neck: neck::Parameters, giraffe: giraffe::Parameters, tongue: tongue::Parameters, } mod neck { pub(super) struct Parameters { idle_stiffness_multiplier: f32, idle_damping_multiplier: f32, moving_stiffness_multiplier: f32, // ... } } mod giraffe { // ... } // ... } mod cam { // ... } //... </code> </div></pre> Then, in systems defined in those plugins, I would add a Res<Parameters></code> to access the parameters, instead of directly using a const</code>. This worked fairly well, the rust module privacy system also aligns very nicely with this. In a module, I needed to access the root Parameters</code> fields, so the root’s field needed to be public, but each individual module Parameters</code> could keep their field private, hence limiting what can be influenced by which field, resulting in much more robust code. A snag was the hook for spawning giraffes. The physics parameters for the neck are used in the scheme::neck</code> module, but also in the neck</code> module, where the giraffe is spawned. I simply made those parameters public across the whole game, so that I could use them in both places. The cleaner solution would have been to get rid of that neck</code> module, but I didn’t have time for that. Serializing parameters</h3> Only thing left to do was reading and writing to a file the parameters, so that they could be changed by anyone with a text editor. I hit a snag here. I relied on bevy’s bevy_reflect</code> for serialization, this is because bevy_reflect</code> is readily available. The standard rust crate for serialization is serde</code>, but it has the reputation of drastically slowing down compile time. I then used the toml</code></a> crate for the parameters file. When I first launched the game to write the default list of parameters, I hit a very generic error. It said something along the line of “enums are not supported” without further details. I recalled that once upon a time, bevy_reflect</code> didn’t support serialization of enum</code>s. But having myself reviewed the code that added support for enum</code>s in bevy_reflect</code>, I was very surprised to encounter this error now! Turned out the error emanated from the toml</code></a> crate, indeed, the doc string for the toml::ser::Serializer</code> struct has a line explaining that toml</code> doesn’t support enums (It would have been judicious to advertise that limitation in the README or the crate-level doc string, or having a better error message). In my Parameters</code>, I only had a single enum</code>, for custom input: enum KmKey { Mouse(MouseButton), Key(KeyCode), } </code> </div></pre> I needed to replace this. I immediately thought of two options: Use a struct</code> with two Option</code> fields, one for mouse buttons, one for keyboard keys.</li> MouseButton</code> and KeyCode</code> being two enums, merge them in a giga-enum. Precisely, what toml</code></a> doesn’t support are enums with data, KeyCode</code> and MouseButton</code> are what rust calls “C-like enums”, they do not have associated data, so making a large enum would work.</li> </ol> I opted for (2), KeyCode</code> is a very large enum, but whatever eh! If at any point KeyCode</code> or MouseButton</code> in bevy changes, I’ll have a compilation error allowing me to update the enum. This is thanks to rust’ exhaustiveness check. The February game</h2> I solicited game ideas in the devildahu discord chat for the 3 weeks project. Brinzer posted his detailed design doc of PointFusion, a 2d Ik-driven game. I’m not sure it’s possible to complete it in 3 weeks, so you might not hear much more of it until the distant future. Cuicui</h2> In the meantime, between two games projects, I thought it would be productive to focus on my UI framework, bevy_mod_cuicui</code>. A very naive thought. I spent the past 4 days writing design documentation, just to know what code to write for it! I always feel “so close” to getting somewhere, yet at each point in time, I am seemingly as far from a solution as I was at any given moment in the past. I think this stems from me not having an exact idea of what I want to do with bevy_mod_cuicui</code>. How much flexibility should it have? What should it do? After 4 days though, I’m convinced (as I was 2 days ago though) that I’ve a vague – if not clear – idea of what I want. Bevy and ECS’s strength is in modularity. I don’t really want to write a UI framework. UI frameworks have a tendency to be totalitarian, they deal poorly with things that exist outside of them. This is the antithesis of what I want to do. I want to empower people, give more possibilities. My current plan is to simply write a few systems, that, if used together, enable a pleasant UI experience in bevy: The layout algorithm I mentioned last week</a>.</li> A Prefab</code> trait to spawn things into the ECS, despawn them and query their current state.</li> A set of Prefab</code>s to build UI elements that are a composition of entities.</li> A QT-inspired signaling system, where functions associated with certain entities can be “activated” and read the state of children entities to do things.</li> </ol> I’m still not sure for (4). The goal is to avoid footguns and enable developers to reason locally (avoid having to think holistically, accidentally mixing several instances of the UI elements) I’ll probably need an ultimate layer of coating on this. Raw, it will still be painful to use, so I expect to add something like a macro to thread together multiple UI elements. Turns out making a UI framework is as difficult as people say. (you may be interested in this blog’s rss</a> feed) Necking devlog 1 2023-02-05T00:00:00+00:00 I’m Nicola. This is the beginning of devildahu’s weekly devlog. Necking</h2> We are working on Necking. Necking is a competitive/cooperative 1-on-1 online game where players are giraffes and fight for male dominance in the giraffe way. Necking is the way male giraffes fight each other to assert dominance. Level of violence during necking vary widely, going from drawing blood, including quick one-tap-and-its-over and even reaching the zone of affection where it’s difficult to tell if the giraffes are hitting each other or tenderly caressing. Necking started as a project in late December 2021, after watching an animal documentary on giraffes. So that’s a bit more than a year ago. I’ve been contributing to it on and off for the past year. I’ve picked up at a faster pace development about two weeks ago (19th of January) I had stopped work on the project around July 2022, in the middle of a migration. Custom joint system</h3> Initially, the game used custom joint physics, built on the heron</a> collision detection library (it is a physics library, but at the time, we only used the collision detection). In 2022, rapier</a> (a popular rust physics library) got a really good integration with bevy</a> and I decided to migrate to it. The joint physics looked great but didn’t have credible or enjoyable physics at all, which is a major issue for a physics-based video game. </div> </div> </div> Migrating to rapier</h3> In the week of the 19th I spent most of my time reimplementing existing features. Notably mouse controls. I also rewrote the way input is translated into actions (of course, since that’s the part that touches the physics). </video> mouse picking Target indicator</h3> I added little arrows to show in which direction the neck is tilting. I felt that the movement was very difficult to read without the arrows. The arrows represent the “target” position of the neck, the one the giraffe tries to reach, but due to its limited strength, and being pushed by the other giraffe, won’t necessarily be the exact position of the neck. So what is shown on screen doesn’t reflect exactly the player input. This is really bad, it feels wrong and sluggish, there is a dissociation between input and effect. Adding the arrows shows to the player as soon as possible that the game registered their input. It feels just right. Bevy controls design</h3> On a more technical aspect. I completely rewrote the controls system. This involved transforming a single component representing all possible input methods, including AI and Network controlled giraffes, into many different components, four (4) per input methods. It’s a bit weird and contrary to what I’m used to do, but it actually works extremely well. There is a component to control each neck vertebra using mouse, using the left stick, the right stick, etc. There is a component for each way to control the whole giraffe body, etc. There are even 3 different components to control the tongue of the giraffe! pub mod giraffe; pub mod neck; pub mod tongue; //.. app.init_resource::<Dragging>() .add_system(neck::apply_left_stick) .add_system(neck::apply_right_stick) .add_system(neck::apply_stick_move_stiffness) .add_system(neck::apply_mouse) .add_system(neck::reset_mouse) .add_system(neck::apply_mouse_move_stiffness) .add_system(giraffe::controller_cam_update.before("camera")) .add_system(giraffe::keyboard_cam_update.before("camera")) .add_system(giraffe::keyboard_move.before("camera")) .add_system(giraffe::controller_move.before("camera")) .add_system(tongue::gp_move) .add_system(tongue::keyboard_move); </code> </div></pre> Bevy UI</h3> I also rewrote the UI. The last draft used my library, bevy-ui-build-macros</a>. It is a monstrosity, please do not use it. Because it is a monstrosity, I had to switch to something different. The default way to define UI in bevy is a catastrophe, so I needed something else to replace my ungodly macro. Recently, someone posted in the bevy discord bevy_ui_dsl</a>. I used this, but it felt like it didn’t improve much on the default experience. Anyway, once I could just press spacebar twice to start the game, I left that on the side and focused on gameplay. There is still so much other stuff to do. Second week</h2> All of that was in the first week of the development resumption. I could now focus on actual gameplay. I added movement. The giraffe controls exactly like a tank. This required changing the camera point of view to a more classic video-gamey position. I first wanted to make the game look like a documentary using trope documentary camera sequences (long shot with zooms, pans, and even maybe commentary on top, in the vein of Regular Human Basketball</a>). Maybe I’ll go back to this in the future, but currently, the over-the-shoulder cam makes more sense, as a gamer, it’s a bit easier to pick up. </video> First movement design, since then, the giraffes have slowed down. Now that the giraffes could move, I needed a way to prevent them from occupying the same space. I used the rapier character controller</a>, I had to fiddle a lot with it. I was using a horizontally laid capsule for the giraffe body. This resulted in giraffes just climbing each other as soon as they touched. This behavior is actually seen sometimes in nature when two males neck each other (yes, in a sexual manner). But that’s not what I want (at least yet) for my game, and anyway they don’t do it all the time. Also once they were not in the same plane anymore, that was it, they were either half buried in the ground or floating in space, with no way to get back on firm ground. I had to adjust the giraffe collider so that they couldn’t climb each other. I used a rounded cuboid, but it took time to get to it, more on that later. Even with a cuboid, there is still a major problem! The rapier character controller doesn’t support rotation. This is fine if you are using a classic shape for controller such as the vertical capsule; it has a circular footprint, and therefore rotation doesn’t change the space the shape occupies. But giraffes (very much like tanks) do have more of a rectangular footprint, hence rotation is meaningful. So when you rotate, it’s still fairly easy to occupy the same space as another giraffe. I’ve not implemented anything to fix that yet though. </div> </div> Tongue controls</h3> Giraffes have funny tongues! ahahah! Of course, the natural consequence is that the tongue must be a central element of gameplay. Players must be able to control the tongue and do funny things with it. Otherwise, might as well use cats with long necks instead of giraffes, come on. Cool giraffe fact</h4> (I’ve a list of 20 cool giraffe facts, might as well start dropping them now) Giraffe tongues are about 45cm long (18 inch). It is extremely prehensile, since it must be able to pick out acacia leaves from its surrounding thorns. </div> But here is the bummer. We are now using rapier for joints. This allows me to specify joints (ragdoll physics) for more than just the 7 neck vertebrae. It looks great on the tongue, ears and ossicones (the horn-looking things). It was very hard to specify the joint parameters so that they work well with the model, but I already solved this last year. But now, to move the tongue, I need to move the joint linking the tongue to the head, change its parameters to something else. The “root” of the tongue would move to the inside of the head and the rest of it would follow up. I needed to find the right joint parameters to express “the inside of the head”. As it is, I would need to change a little bit the code, compile (1s) restart the game and look at the tongue (10s) to see the result. It simply is not feasible in any reasonable time, and it’s extremely tedious and I care for myself at least a bit. Component Mirror</h2> The way I adjust minor values for components in bevy, is using bevy-inspector-egui</a>. It allows me to modify at runtime some component values and the copy them back into the source code. Problem: bevy-inspector-egui</a> requires libraries to implement bevy’s Reflect</code> interface. Rapier joints and collider shapes do not, and cannot implement bevy’s Reflect</code> trait. So I made bevy_mod_component_mirror</a>. In this crate, I define “mirrors” of the joint. They are just structures that can be created from rapier’s joints and colliders, can be modified, implement bevy’s Reflect</code> trait and can update the joints and colliders with the modified values. As a bonus, the joints structure is much more plain and understandable than the actual rapier joints and collider shape struct</code>. This is because rapier’s struct</code> definition is informed foremost with speed in mind, at the expanse of readability. </video> BLeeeehhrrrrrpppppps, boinyongyongsluuuurp, bleeeeehhhhrp, boinyongyongsluuuuuurp… Cuicui</h2> Now that the burning question of the tongue was solved, I decided to go back to the game menu. </div> The player must be able to chose how many giraffes there are, what controls to use, if they are online, etc. Also we have a basic options menu. I hope this doesn’t sound like a lot, because those are very limited options. But even then, it’s impossible to accomplish using bevy_ui</code>. I also wanted the text to be outlined, but again, impossible in bevy_ui</code>. Placing elements in bevy_ui</code> is also a struggle, the layout model (Flexbox) relies a lot on implicit parameters, it’s very hard to get an idea of how things will look when you write the code. And even using something like bevy-inspector-egui</a>, it is hard to understand what is going on. bevy-inspector-egui fairs poorly with bevy_ui</code>, because the Flexbox components have a lot of parameters and it quickly becomes a struggle to manage them. Well, this simply means bevy_ui</code> is not usable for necking. At least right now. Enters Cuicui </blockquote> Cuicui is the name for the UI framework I’m developing. Over the past 18 months, I’ve accumulated a lot of opinions on how a good bevy UI framework would look like. And cuicui is the concretization of those opinions. Most notably: Prefab</code> system inspired by Bone Klod</a>’s scene design for widgets. A recent innovation by bevy discord user Nionidh enables composable Prefab</code>s.</li> Cuicui layout, a layout algorithm your grandma could understand (ok, depends on your grandma) It emits a useful error when the constraints you specified are wrong, and it is easy to gork, you’ll be able to know the final layout from looking at source code.</li> Reuses bevy’s 2d Rendering. Now that bevy supports RenderLayers</code>, there is no reason to split UI and sprites. It also allows us to re-use pre-existing crates. Go ahead, add particles to your UI, add dynamic 2d lights or jump-flood outlines, or even animate it. You can do all of that in cuicui.</li> Give back control to users. Specifically, the Transform</code> can be manipulated.</li> More than a button widgets.</li> </ul> Cuicui layout</h3> Those are not empty promises, cuicui layout already exists. </video> Demonstration of cuicui layout. This took a bit more than a day to get working, and half a day to write documentation and a type-safe wrapper to construct a layout tree (the compiler yells at you if you make an invalid layout). The cuicui source code is available here</a> (will be licensed under permissive apache 2.0). The docs explaining the layout algorithm is here</a>. The plan for next week is to work up to Wednesday on Necking and start work on a 3 weeks-and-it’s-done-I-promise game. See you next Sunday for another devlog. (you may be interested in this blog’s rss</a> feed) Architecture of a GBA game — gssa 2022-11-14T00:00:00+00:00 This is part 2 of a series of blog posts on developing GSSA. The first part</a> introduced why I ended up rewriting a C game in Rust for a 20 years old console. Acronyms and characters</h4> GBA: The Game Boy Advance</a> a 20 years old hand-held game console with a CPU clock of 16MHz and 340KB of internal memory (my phone, slightly smaller than a GBA, has eight 2GHz CPUs (×1000) and 6GB (×17650) of internal memory</a>)</li> VRAM: Video RAM, the memory to which you must send your stuff to change pixels on the screen</li> UB: Undefined Behavior, things that a C compiler assumes a C programmer will never do, that oddly every C programmer do all the time, and result in nasty hair-tearing bugs (proven made-up fact: there is an inverse correlation between hair line and years lived while owning “The C Programming Language” by Kernighan and Ritchie)</li> mgba</code></a>: an accurate GBA emulator.</li> GSSA</a>: Generic Space Shooter Advance a game for the GBA I wrote for a uni assignment in 2018, tried to rewrite in rust in 2020, and independently rewrote a second time in rust in 2022 (not to be confused with a Swiss pacifist NGO)</li> Mr. Leone: The lecturer of the systems programming lecture I followed in 2018</li> The little UBs: The author’s nasal demons, mostly manifested as broken games</li> The author: clearly someone who needs to touch grass, calls himself “cyber-hippie”</li> </ul> </div> This is where I narrate how I actually implement the menu in my first rewrite of 2020 in rust. Architecture</h3> A neophyte wrote the GSSA C code. Myself, writing a large program, not only for the first time in C, but for the first time in any language. In 2020, I’m different. I wrote a whole frontend app</a> in elm, and the corresponding backend in rust. 2020 me is also an enterprise™ developer. I am an acolyte of data driven programming, I’ve been the midwife of many software, seeing them from birth to their maturity. The C version of GSSA was a struggle. How to structure code? I had never seen game or C code before. I wrote most of the code in public transport, on a shitty 1st gen Microsoft surface, with the shitty “surface cover” finger-numbing keyboard. I didn’t know git</code>. I wrote regressions I took days to fix. Remember, it took weeks to fix the code to run mgba</code>, the accurate GBA emulator. Dread fills me. What will I see? I’ve gazed in the abyss of legacy enterprise™ code. I’ve seen a massive visual basic app, I’ve seen a compiler written seemingly as an exercise of how to write the most confusing chain of JavaScript callbacks, unspeakable blasphemy, chtonic incantations that somehow a computer can parse, let alone a human being. Someone with less fortitude would have not survived, not with their sanity intact. Will I gaze into my own code, and witness my own spawn as a monstrosity? Curiously no. There are goto</code>s, the code may have more magic numbers and mutable globals than local variables, I abuse criminally the C pre-processor, and the code is indeed a barely working pile of little UBs riddled with bugs. But I can read it. It is clean, I understand the purpose and intent of everything, architectural design decisions are documented, the code is structured coherently, using common patterns. In fact, it’s almost better than the code I write today 🥲 tldr</h4> bug ridden</code> does not imply bad code</code>. Furthermore bad code</code> does not imply bug ridden</code>. experience</code> does not imply better code</code>. </div> The design principle is clear: ownership of control flow. I structured the GSSA code like a bunch of happy little games that wait their turn and take the helm and drive exclusively the entirety of the console. The main menu code looks like this: // main.c for (;;) { bootMenu(gameState); playGame(gameState); } // mainmenu.c void bootMenu(GameState* globalState) { // ... for (;;) { frameCount = (frameCount+1) % (BLANK_SEC<<1); if (frameCount == BLANK_SEC){ drawText(" ", 10, 16, BOOT_SBB); } else if (frameCount == 0) { drawText("Press Start", 10, 16, BOOT_SBB); } if (CHECK_INPUT(KEY_START)) { srand(frameCount); goto gameMenu; } WAIT_BLANK; } // ... gameMenu: { // ... if (TST_FG(curKeys,KEY_A)) { //Changes submenu. drawText(" ", 5, currentRow, MAIN_SBB); switch (currentRow) { //Exits the game menu loop case 0: break; case BEGIN_ROW: return; //goes to game case SHIP_ROW: goto shipMenu; case CHEAT_ROW: goto cheatMenu; } } // ... } shipMenu: { // ... } cheatMenu: { // ... } } </code> </div></pre> The bootMenu()</code> handles the initial screens, including ship selection, difficulty selection, cheat code menu, and the title card. Each one of those represent a different screen. Each screen has a corresponding loop, when the user changes screen, a goto</code> goes to the selected screen’s loop. Without goto</code>, we bloat the stack, we enter a new context whenever we enter or exit a menu, potentially leading to a stack overflow on the poor GBA’s tinny memory. This implies giving up the concept of functions, but it works. The C GSSA uses liberally mutable global variables. I pick arbitrary location in memory and split them between all the happy little games: #define OAMCLONE_MEM 0x03004000 #define oamClone ((spriteTag*) OAMCLONE_MEM) // ... in another c header // a single value of size sizeof(PlayerShip) #define PSHIP_MEM (OAMCLONE_MEM + sizeof(spriteTag) * 128) // An array of size MAX_BULLET * sizeof(ActiveBullet) #define ACTIVBULLET_MEM (PSHIP_MEM + sizeof(char) * MAX_BULLET + 8) // An array of size MAX_ENNEMY * sizeof(ActiveEnnemy) #define ACTIVENNEMY_MEM (ACTIVBULLET_MEM + sizeof(ActiveBullet) * MAX_BULLET) // An array of size MAX_PICKUP * sizeof(ActivePickup) #define ACTIVPICKUP_MEM (ACTIVENNEMY_MEM + sizeof(ActiveEnnemy) * MAX_ENNEMY) // ... // In main.c #define GAMESTATE_MEM 0x03003F00 int main() { GameState* gameState = (GameState*) GAMESTATE_MEM; </code> </div></pre> I’m sure a few readers ground their teeth to dust seeing this code. But on the GBA it is fine. Remember? No OS, just GSSA running on the hardware. Only risk is for the stack to grow so much they overwrite the hardcoded memory. (Though apparently I was an “ennemy” of spelling when I wrote this) This is what I learned from Mr Leone’s lecture: some memory regions are faster to read/write than others, so make sure to use the fast ones for critical data structures. So how will I write the rust version? No such code in my rewrite. I’ll leave it to the compiler to do the hard work of picking where to place my beloved data structures. (In any case, I will specify the stack memory position in the linker.ld</code> file, this tells the linker which addresses to use for what purpose) The acolyte of data-driven programming (DDP) than I am now has lost the ability to reason in terms of control flow. DDP is all about data structures. I first define the game state, and design code as transformations on the state. GameState</code> is now an enum, each variant relevant to a different point in the game. Each variant its own little state, all describing what to draw on screen and what the next state is based on button input. There is a single loop, that looks at the state and call its corresponding draw</code> and update</code> methods. I need to split draw</code> and update</code> on the GBA, changing VRAM memory at a narrow specific interval, otherwise, I’ll see ugly screen tearing. This is the elm architecture. The discarded cargo</a>, filled with bobbles of another kind of civilisation, that I picked up at university and to this day still praise as gospel of clean code. Regardless, I have other better reasons to idolize cargo</code></a> (my savior). In fact, there is a bit more to that. I can split the GameState</code> in two: Mutable data changing with the game progression</li> Purely descriptive constant data (text positions in menus, menu text, player speed, etc.)</li> </ul> Constants will replace all the magic values. This is more code, but I don’t have to uncover what 5</code> or 10</code> means. </div> const MAIN_MENU: Menu<3> = Menu { entries: ["BEGIN GAME !!!", "Ship select", "Code zone"], pos: (7, 4), dir: MenuDir::Verti(3), }; </code> </div></pre> A Menu</code> tells me how to draw something based on the global GameState</code>. Each struct has a draw</code> method that takes as argument everything that is mutable and it needs to know. In the case of Menu</code> the signature of draw</code> is as follow: fn draw(&self, selected: u8, tile_map: Sbb) { </code> </div></pre> (where tile_map</code> is going to be a point to the location in memory we need to write to to display things, it has nothing to do with the Schweizerische Bundesbahnen) This architecture greatly reduces the size of what is going to be passed around in drawing and updating routines (the state), which is necessary for performance reasons. One positive side effect of this is that the menus are entirely declaratively defined. The corresponding C code fails to decouple drawing from updating, but on the flip side, is dead easy to understand: drawText("BEGIN GAME !!!", 7, BEGIN_ROW, MAIN_SBB); drawText("Ship Select", 7, SHIP_ROW, MAIN_SBB); drawText("Code zone", 7, CHEAT_ROW, MAIN_SBB); </code> </div></pre> Yes, you’ll find magic numbers all around the code, this is quite ugly, but not a difficulty to code comprehension. There is more to it though. The blinking cursor. The damn blinking cursor. You think it’s easy?</a> My draw</code> method only has access to the current state, but I need to erase the cursor at the previous position. The cursor is not in the struct definition of Menu</code>, it can’t since the cursor position changes and Menu</code> is immutable. The cursor must be part of the GameState</code>. With the C model, the menu has an internal state updated every frames, and draws based on that state in the same loop: frameCount = (frameCount+1) % BLANK_SEC; if (frameCount == 0 || frameCount == 4800) { drawText(">", curPos, 5, MAIN_SBB); } else if (frameCount == 2400 || frameCount == 7200) { drawText(" ", curPos, 5, MAIN_SBB); } </code> </div></pre> This snippet is repeated in every submenu loops. With the rust model, the cursor is represented as a text box: fn cursor(pos: (u8, u8)) -> TextBox { TextBox {text: ">",pos,blink_rate: Some(30)} } </code> </div></pre> And the update: fn update(&self, cycle: u16, selected: Diff<u8>, tile_map: Sbb) { if selected.changed() { cursor(self.cursor_pos(selected.prev)).clear(tile_map); } cursor(self.cursor_pos(selected.current)).update(cycle, tile_map); } </code> </div></pre> More precisely, the blinking happens in the TextBox::update</code> method: pub fn update(&self, cycle: u16, tile_map: Sbb) { if let Some(blink_rate) = self.blink_rate { let tick = cycle % blink_rate; if tick == 0 { self.clear(tile_map); } else if tick == blink_rate / 2 { self.draw(tile_map); } } } </code> </div></pre> It’s a bit more verbose. Note the Diff</code> for the selected</code> entry. I need to know the previous state to clear the cursor if it changed position. I can do that, because update</code> is not updating self</code> (notice the &self</code>, non-mutable!) it is creating a new self</code>, this way, the old self</code> is kept around, and can be used later to compare new and old value, and execute code when relevant. This doubles memory requirement, but for simple menus, this works great and the memory footprint is tinny enough to not be a worry. The C code has the following snippet wherever it needs to change the cursor position: if (TST_FG(curKeys, KEY_UP)) { drawText(" ", 5, currentRow, MAIN_SBB); currentRow = (currentRow == FIRST_ROW)? LAST_ROW : (currentRow - 3); drawText(">", 5, currentRow, MAIN_SBB); } else if (TST_FG(curKeys, KEY_DOWN)) { drawText(" ", 5, currentRow, MAIN_SBB); currentRow = (currentRow == LAST_ROW)? FIRST_ROW : (currentRow + 3); drawText(">", 5, currentRow, MAIN_SBB); } </code> </div></pre> This demonstrates also the unabashed mixing between state change and drawing in the C version. Let’s try this again</h2> Forget everything you just read. Or rather, let me forget that I ever wrote that. The year is now 2022, no hoverboards, just even dimmer hopes, and me, a bored dude, alone with his computer. And I do what most lone bored dude with computers do: rewrite a C GBA game in Rust. This time I take a different approach. My first action is to split hardware access and game code, this is called a HAL (hardware abstraction layer). I call it haldvance</code>, because I am a victim of puns. The second decision I make, is to use a MVC approach. I first design the data, and then, I… I mean I just spent a thousand words telling you about that, but for me this was a new and innovative solution. Architecture bis</h3> Oh, but in the mean time, I forgot about all this fancy “diffing” I nicely described earlier. My update</code> methods take a &mut self</code>, and the previous state is not kept track of. The split between draw</code> and update</code> has become my nemesis. Why? When I change from one state to another, this typically requires “exceptional” draw</code> operations. For example, when starting the game, I change the video mode, generate a star map and load the game’s sprites into video memory. But here is the question: How do I know that I “just entered” the game state? I only have the current state, outside of any context of changes. Oh I see several solutions to this, but I made the mistake of trying to solve it before thinking about it. Here are the possibilities: Callbacks. Create an API where you can return optionally a callback to run in the draw</code> interval</li> Diff again.</li> A generic state machine, where I can query whether state was updated/entered/left.</li> Just keep a struct with a bunch of flags and check them every time</li> Build a more principled version of the naive “ownership of loops” design I used in the C GSSA</li> </ul> I initially went with callbacks. My game currently uses this design. It probably kills perfs by preventing potential inlining. But more than that, it only partially solves the issue, because now I have to surface callbacks from inner functions, handle conflicts of callbacks… Fun in perspective. Disaster, my prophetic faith in DDP is shook. Maybe I should take another approach? This is a question for another time. HAL (elujah)</h3> Now let’s talk about the HAL. Generally, designing and writing a completely generic, fully documented, opinionated and flexible library API takes much more time than going at the hardware with a raw hammer and accepting your hardware access bugs will surface all around your game logic. For reference, currently the HAL is 2K lines of code with over 800 lines of documentation, while the game itself is about 1K lines of code (suspicious, he doesn’t say how much doc the game has). And development is sluggish: every time I add a functionality, I have to first design an API for it, and wrap the hardware, thinking about the cheapest way of doing it, thinking of edge cases, explore rust features allowing them, and all of that is before I even get started writing game code, which itself is a slog, because this 2nd rust rewrite started with a crippling architectural decision. Ah! But at least the separation between gameplay and hardware code did help me understand in isolation why certain things do not work. It’s also so much easier to read, and as I write the HAL, I’m writing an exhaustive manual on how to write GBA games in Rust, with directions in the more hairy parts of the API. The HAL is great, but I worry it’s a massive waste of time, we are talking about an abstraction layer for a 20 years old console. And why? Just because. A weird obsession. And more</h3> Now my second rewrite reached feature parity with the first one. Ah, accidentally. It is time to start making strides toward feature parity with The C Version. Fun in perspective, to the next post! Rewriting a GBA game in Rust — gssa 2022-11-07T00:00:00+00:00 I’m Nicola, I’ll discuss how I converted a C game written as a student assignment into Rust, and tell you about all the friends (later referred as “little UBs”) I made along the way. The year is 2018, as assignment in professor Leone’s systems programming class, I write a game for the Game Boy Advance</a> (GBA), a console released in 2001, without any operating system, a blazing fast CPU of 16.8 MHz, a mind-bending 256Kb of RAM (it ought to be enough for everyone) and a fantastical memory-mapped (mmio) interface to program graphics, audio, basically everything the GBA can do. In short, the perfect device to teach bare-metal programming. In the year 2018, I write my first significant C program. A game for the GBA, I called it “Generic Space Shooter Advance” (GSSA). A stinky pile of undefined behavior (UB). UB is what you get when you write C code the C compiler can assume could never possibly exist (about one out of every three lines of C ever written). It is such a stinky pile, in fact, that for a while, it only worked on inaccurate GBA emulators, until I spent about 2 weeks to suss out where I was accessing invalid memory addresses (hint: in way too many places). After those two weeks, I could finally play GSSA on mgba</code> (an accurate GBA emulator). Yet, when I opened the live memory view of mgba</code>, I could see random bits in memory being swapped for no apparent reasons, but since it didn’t touch the bits of memory containing my game data or the mmio registers, my game worked (kinda). </div> The development of the game was over. A shame we never learned about UB at uni (sorry Mr Leone). The year is 2020, one year in my first job as scala developer, trying to fight the existential dread of spending most of my waking hours helping make the world a worse place, working on a depressingly slow virtualized dev machine, where every key presses is followed by a 500ms coffee break before even altering anything on screen. I now know elm, Haskell, scala and rust. I’ve read “Expert C programming” twice, I now can see some of the previously invisible UBs that plagued my game, all the little UBs, here in front of me, sneering, provoking, spitting me, telling me “You’ll never catch us!” I hate it, I despise them. I learn about the gba crate</a>. Finally, an escape hatch. A way to live in the impossible world I always wanted to live, the world where I make the best selling GBA game, without constantly fighting the little UBs of the C tribe. A way to escape the morose every day life of an investment bank developer, I can enter again a world without allocations, without an unknowable Garbage Collector that somehow makes all my program eat about 500MB of RAM at minimum (not a problem, just spin up a new prod server, say my colleagues). I feel like playing TIS-100</a> again, but this time I can write it on my resume. Let’s port GSSA to Rust, call it gssa-rs, free it from the tyranny of the little UBs, and brag about it on the internet. </blockquote> Setup</h2> Look at that, look at those setup instructions, so terse, so simple. rustup install nightly rustup +nightly component add rust-src sudo apt-get install binutils-arm-none-eabi # copy an example from the github.com/rust-console/gba repository # Add gba as a dependency to the Cargo.toml cargo run </code> </div></pre> It works! Just like that, I even get full code completion and a working package manager, cargo</code> my love, my savior. The sbt exorcism</h4> Begone sbt</code></a>, my calvary, my daily ordeal for the sins of scala. Begone the 10 seconds startup time, the excruciating compilation times. Begone sbt</code>’s cryptic configuration, each dependency an additional shibboleth, each compilation target an incantation, each error message a gnomic curse. Begone sbt</code>, the oxymoronically named build tool. </div> Oh what is this, a compilation error</a> in my rust dependency? Hmm, a change to the rust asm!</code> macro. This, the swi</code> instruction, I did learn in Mr Leone’s lecture. A requirement to summon the GBA’s BIOS functions. Despite my unreasonably zealous belief, rust still manages to amaze me: Now, even writing inline assembly is safe(ish)</a>. A quick fix</a>, a quick merge. - asm!(/* ASM */ "swi 0x06" - :/* OUT */ "={r0}"(div_out), "={r1}"(rem_out) - :/* INP */ "{r0}"(numerator), "{r1}"(denominator) - :/* CLO */ "r3" - :/* OPT */ + asm!( + "swi 0x06", + inout("r0") numerator => div_out, + inout("r1") denominator => rem_out, + out("r3") _, + options(nostack, nomem), + ); </code> </div></pre> Making the game</h2> Now is the time, little UBs. Watch out. Your time is up, time to demolish your house of card, and each little nook of my C code you hide yourselves in. Time to rebuild GSSA on sounder foundations. Sprites and color palettes</h3> I have sprites, the GBA video processor needs those sprites in video memory (VRAM). I need the sprites to be in the game ROM. </div> In C, using DevkitPro, it’s easy. Add the binary to a resource</code> directory, then add resource</code> to Devkit’s Makefile</code></a>’s DATA</code> list. You then can #include "menuset_til_bin.h"</code> in the C’s header file (this is fine 🥲). How to do this in Rust? Looks like include_bytes!</code></a> it is. So let’s replace those _bin</code>s with include_bytes!</code>. … error[E0080]: it is undefined behavior to use this value --> src/assets.rs:138:5 | 138 | pub(crate) const menuset_til: &[Color; 12288] = unsafe { 139 | transmute(include_bytes!("../resources/menuset_til.bin")) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ constructing invalid value at .0.data.data: | encountered an unaligned reference (required 2 byte alignment but found 1) | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. = note: the raw bytes of the constant (size: 64, align: 4) { 0x00 │ ╾─alloc26─╼ 06 00 00 00 ╾alloc381─╼ 00 00 00 00 │ ╾──╼....╾──╼.... 0x10 │ ╾─alloc27─╼ 06 00 00 00 ╾alloc390─╼ 00 00 00 00 │ ╾──╼....╾──╼.... 0x20 │ ╾─alloc28─╼ 06 00 00 00 ╾alloc399─╼ 00 00 00 00 │ ╾──╼....╾──╼.... 0x30 │ ╾─alloc29─╼ 06 00 00 00 ╾alloc408─╼ 00 00 00 00 │ ╾──╼....╾──╼.... } </code> </div></pre> ROGNTUDJU</a> What even is this? Why is rust showing me circuit diagrams with random numbers now? Ok, let’s just store the sprites in an array of bytes (&[u8]</code>) instead of an array of Color</code>s, aka “shorts,” or u16</code> (&[Color]</code>). </div> Honestly</h4> To get the previous screenshot, I reverted to the version of the game and compiler used before fixing this bug. But I never managed to reproduce the bug. The screenshot is actually an artist interpretation, edited from the “working” version. </div> Now my menu is broken! I’ve seen this in the C version. It was easy to solve, just move around some unrelated variables and it works again! No such luck with rust, let’s take closer attention to rust’s error message: error[E0080]: it is undefined behavior to use this value … constructing invalid value at .0.data.data: encountered an unaligned reference (required 2 byte alignment but found 1) </blockquote> It’s an UB! Rustc ruthlessly (rustlessly huehue) seizes the little UB jerk, and slay it without giving it the opportunity to make your life a misery (that is, until you work around it without paying attention). unaligned reference. Yes, this we learned about in Mr Leone’s lectures. Alignment, this is important for the GBA processor, ARM7TDMI</a>. To write data to VRAM, you must only use 2 byte length store instructions. 1 byte length stores will still write 2 bytes, storing one and an undefined value in the other (normally, it should be the same value repeated twice, but for some reasons I ended up with one out of two values zeroed out). The workaround</a> is a bit involved</a>, but here it is, UB-free title screen! </div> To be perfectly fair, I did solve it more correctly in the C version, using the GBA DMA</a> for writing to VRAM. No nonsense tl;dr</h4> Even knowing about alignment didn’t stop me from ignoring it when storing to memory in C. Compiler errors help catch, and understand bugs before they even exist. Rust’s high quality error messages help understand what caused the error and actually put in practice your knowledge to write correct code. </div> History repeats itself</h2> The year is now 2022. I vanquished my dread, I now left my salaried job and I spend the day contributing to an open source game engine. I’ve become a cyber-hippie. Kumbaya! Two weeks away from keyboard. I pick up my unworn laptop. I bore myself quickly from the lacking literature I picked up departing. I find an old abandoned project, gssa-rs. Very rustic, it compiles, I can run it on mgba</code>, but it is nothing more than the title screen. Ah! Time to hone my skill on embedded rust and finally complete this dream of mine. I’m free now, I can do it. I go all in, writing a full hardware abstraction layer (HAL), pick apart GBA documentations, and in the last 12 hours, get around to implement menus beyond the title screen. Back from the trip, I discover on my desktop PC a major uncommitted set of changes on the local copy of the gssa-rs repository. The five days of intensive programming I did in vacation were the programmer’s first sin: “Duplicated effort.” Perusing the code, I find eerily familiar 2 years old solutions to problems I had just two days ago. I don’t remember any of this. Oh, what is this entry in my notebook? A 300 lines document describing my experience converting GSSA to rust, dated September 2020. In fact, it is this very article (before editing). Amazing! Sure, a sin, but an opportunity as well. I get a peek at how I would solve the exact same problem at a 2 year interval. Did my experience since then changed the way write code? Do I write better code, worse code? What I think of my 2020 code, I’ll leave for a later post. (you may be interested in this blog’s rss</a> feed) Teaser</h4> Dread fills me. What will I see? I’ve gazed in the abyss of legacy entreprise™ code. I’ve seen a massive visual basic app, I’ve seen a compiler written seemingly as an exercise of how to write the most confusing chain of Javascript callbacks, unspeakable blasphemy, chtonic incantations that somehow a computer can parse, let alone a human being. Someone with less fortitude would have not survived, not with their sanity intact. Will I gaze into my own code, and witness my own spawn as a monstruosity? </blockquote> </div> Video game essence 2022-09-27T00:00:00+00:00 disclaimer</h4> Devil Dahu or Nicola (the author) has no affiliation what-so-ever with Sakurai, Nintendo, HAL or anyone. This blog is usually technical, this post is very handwavy and abstract, but it touches to the soul of games and I wanted to share it. (tldr at the end) </div> I’ve a feel for games. A deep belief, I need to share it. Well, more specifically, it is Masahiro Sakurai</a>’s video on game essence</a> that prompted me. I don’t agree with Sakurai on what Game Essence is. This is mostly a play on word and a way of looking at games, so it’s not of much practical applications, pretty much only good for occupying disk space and inking paper. Anyway, close this browser tab if you don’t want it to also occupy your precious limited time on earth, because I’m going deep. What is Game Essence?</h2> To Sakurai, Game Essence, far from being a brand of perfume smelling of cheap alcohol and sweat, is an extension of the “Risk/Reward” equation. What is the Risk/Reward equation? </blockquote> Risk/Reward is a classic video game design idea. I’ll defer to Sakurai on this one, see his video</a>. Let’s see this model applied to existing video games: Super Mario Bros: To defeat enemy and progress (reward) you need to get closer to enemies.</li> Space Invader: Same really, but on the Y axis.</li> Sekiro: sic.</li> RPGs of all sort: When dungeon-crawling, you need to go deeper to get more loot, but you risk defeat by encountering unexpected enemies. (Darkest Dungeon is the ultimate incarnation of that)</li> </ul> But Risk/Reward is clearly absent from a lot of great games. Baba is You: Where is the risk, what is the reward? More puzzles, the completely inexistent story and lore? (same applies to The Witness)</li> Return of The Obra Dinn: There is simply no risk involved, guessing incorrectly does nothing, guessing correctly is just the opportunity to focus on another murder mystery to solve. Story is more than contingent to gameplay.</li> </ul> Sakurai says this</a>: What is important is the balance of tension an relief. In a puzzle game, the tension is the closed door, the unsolved puzzle gating further progress. The player gets relief by solving the puzzle, which the puzzle game generally rewards with… more puzzles. The Essence of a game is then how the game decides to present that Risk/Reward equation to the player. Sakurai’s model is pretty good, but I have a different way of looking at it. A game is a language</h2> Game is play, play is interaction between people. Fun is understanding and gaining a new shared understanding with a playmate. The developer of a puzzle game creates a new language, like the private languages</a> some twins develop. This new language the player discovers with bafflement, this is something they never saw before. Solving puzzles is learning a new language, grokking its grammar and discovering its vocabulary. Learning a language shared between themselves and the developer only. A secret and precious connection, a break up from isolation. Similar to Noita’s magic wand system. Literally a grammar: The reverse polish notation. And a language: With nouns, adjectives, verbs and adverbs. Action games are languages too. Languages in a different register. This is the language that the model of Risk/Reward describes. It is a language of threats and rewards. The game speaks in urgent tones to the player, the player replies with groans: “How am I supposed to beat that?” And hopefully, later, other groans: “I did it! VICTORY!” But ultimately, victory is this: finally understanding the language of the game and speaking it yourself. Or maybe it’s the game giving up and just letting the player through, not a hard game, just a reproduction of a template that is known to sell. Each player will find their own language. What the game is, is not exactly a language, but a seed for a shared understanding, from which sprouts a language unique to the combination of the player and the game. Playing a game is speaking with the developer. A game is a language through which the player and the developer communicate, through which they negotiate, argue, laugh, cry, care, remember good old times or ponder on life. A game is a unique personal connection, a connection stronger than words or pantomime, that unite player and developer. Tension, Squeeze/Release, Risk/Reward, game flow are dull incomplete models. They help understand some games, but at the price of fleecing them of their beauty. They are crude models of human communication. Game Essence is flavor</h2> Where does this leave Game Essence? Game essence is what makes a game unique and places it in relation to other existing games. I call it flavor. A developer is an alchemist, picking up existing game flavors, breaking them into their elemental constituents, game design atoms, aromas, and mixing them back into something new and unique. A new flavor, with its own bitterness and sweetness, each player appreciating it differently, according to their own personal history and innate preferences. Developers stand on the shoulders of giants. Even genre-defining games like Dark Souls, Spelunky or Slay the Spire are but mere copy of pre-existing games. Split Super Mario World in its constituent parts, take most of it; Split Rogue in its constituent parts, take some of it. Mix them, you get Spelunky. Something fundamentally unoriginal, yet completely new and innovative. Those are genre-defining games. The new mix of aromas created a new completely distinct and compelling flavor. We have not just a new flavor, but a new class of flavors. This is what a genre is. Games in the same genre share many aromas, yet all have their own subtle distinct flavor. Games of the same developer have different flavors, yet have a consistent undertone. This is because the developer, like the player, has their personal taste, favorite aromas. Aromas and flavors are a language indeed. Game design and play is a communion, a cryptophasia</a> of players and developers. I’m not proposing anything practical here (indeed, I warned you of that much at the beginning of the post). I want to share a way of looking at games as beautiful things and allow anyone to appreciate them more for what they are. The language model of games may not help a company bump their quarterly revenue, but is a beautiful way of talking about games, it helps see into the core of the game, its essence, and appreciate all its flavor and scent. Maybe it’s pure navel gazing, maybe this could be honed into a game design tool? Who knows? Anyway, I hope I helped make things more beautiful. tl;dr</h4> Game is a medium, a mean of communication. Play is the resolution of a personal dialog between the developer and the player. (Or sometimes, between multiple players) Game essence is what makes a game unique and places it in relation to other existing games. I call it flavor. Flavor is a sum of many aromas. Aromas (or elements, game design atoms) are shared between games. Each game has however its own exact combination of aromas, which gives it its unique flavor. A genre is a common set of aromas. The game developer picks up aromas from all the games they want (consciously or not) and put them together to create their own flavor in a new game. </div> Behind the Klod 2022-09-02T00:00:00+00:00 Klod</a> is our submission to the second Bevy game jam. It was made in 10 days by Devil Dahu, our 2 people team. Nicola (me) at programming and music, and Xo at 3d art. Jargon</h4> to klod, klodding, klodded: verb, to add to the klod ball. </div> Preparing</h2> Pre-jam, I prepared a template based on our entry in the last jam, Warlock’s Gambit</a>. Since the game was still running on bevy 0.7, it was a challenge to bring the code up to date. But it helped a lot, since UI is definitively the most annoying part of bevy, and all the UI I ended up needing was in the template. A saving grace was the addition of the focus_follows_mouse</code></a> field in the input mapping resource of bevy-ui-navigation</code>. I will pat myself on the back for caring for existing users, because sometimes that user is just me 🙂. The Idea</h2> The theme choice fell at 22:00, I did want to have a reasonable night sleep, but we first started throwing around game ideas. Xo quickly suggested something similar to Katamari, and I was in. I love Katamari Damacy, and programming a clone seemed like a very fun challenge. I jokingly went: Let’s make our own twist: Katamari Damacy, but dark souls (smirking face emote) </blockquote> Puzzle game with Katamari mechanics? Where depending on what you pick up, you get different abilities </blockquote> Then realization dawned upon me: Oh man, Katamari, but the ball is just an agglomeration of corpses </blockquote> I started implementing the klod mechanic and waited on Xo for more feedback. At this point I was not sure about the dark fantasy setting, but Xo seemed more onboard than myself. We discussed what other mechanics we could add to the game, failure and win states. I proposed a time trial object collection challenge. We had some more crazy ideas including multiplayer, which might feed into a larger game, but at the end we settled with: Time trial score based win condition.</li> “Key” mechanic with “pickup item X to open door Y.”</li> </ul> Trivia</h4> the formula for mana is just bone weight × time left</code>, it was the initial formula, and it was so good it didn’t need improvement. </div> The game would be mostly going downhill, trying to steer the ball enough to pick up items for secret paths and score. In the end, it would look a lot like Rock of Ages. The Music</h2> At the start of the jam, I didn’t feel like programming at all! So, after settling on the setting, “dark fantasy,” I immediately went on jummbox</a> and did what can only be described as “jamming,” and in 3 hours, the game soundtrack was complete. The track was later cut to fit the game length. The music was to be split into several tracks, triggering by reaching certain game areas. At first, I implemented a very fancy music queue, waiting until the last track ends before running new ones, to avoid jarring music transitions. Tracks, however, were too long for that, so you wound up never hearing the final staircase scale. The very last-minute change to play the music immediately after reaching an area is still quite buggy. This, for example, results in audio cutting if you die in the first area of the game. Klod soundtrack</h4> </audio> </div> Game jam tip</h4> I strongly recommend using jummbox</a> for game jam music. I have no formal music education and do not play any instrument, yet I can get some compelling crap out of it. </div> The Editor</h2> This is the single most damaging mistake I made. We “needed” an editor to design the level. I wanted something in-engine so that it would be trivial and quick to test out the level and edit it. However, no such level editor exists for bevy. So obviously… I made one. I used bevy_editor_pls</code></a> as a base, added bevy_transform_gizmo</code></a> for manipulating objects, added keybindings similar to blender to move objects around, created a scene system with prefabs, and wrote the UI for adding Klod-specific object, saving and loading a level, just for the jam. This took more or less 7 days out of the 10 we were given for the jam. It didn’t help us much, but it</a> did help</a> other people</a>. </video> Early editor prototype demo. I ended up designing the level in Blender</a> using exclusively 1×1×1 cubes and spheres resized using scale, and writing a tinny importer based off bevy-scene-hook</code></a> to convert it into the internal scene format. What was imported included the environment and the items such as the bones and shovels. Trivia</h4> Klodable items are also 1×1×1 cubes, if you open the game files with Blender, you’ll notice that everything, including shovels and bones, are stretched to fit a 1×1×1 cube. </div> The level is imported as a bunch of invisible fixed colliders, and the actual visible geometry is just a single entity located at the origin of the level. The editor was however useful at the end: to place lights in the level, do last-minute fixups for balance and filling huge holes in the walls. Trivia</h4> Until the very last moment, the final staircase doors didn’t have a doorstep, making it nearly impossible to use the shovels, I just added a cube with the editor. </div> In the end, I bundled the editor with the native build artifacts, so I have an excuse for having wasted so much of my time doing something only tangential. The sound effects</h2> We had music, but we needed some sound effects. Physics become empirically 1195.93% better if combined with sounds. This was easy, I downloaded the Kenny</a> “Impact Sounds” audio pack, wrote a very lengthy and extremely fancy audio system to handle all the possible sound effects and configure them with the editor. Yet, only a single impact sound effect is used in the whole game… Trivia</h4> The ball has a roll sound, the sound used is found in the “Sci-Fi sounds” Kenny audio pack, under the thrusterFire_002.ogg</code> name. The roll sound is almost never heard, because it requires the ball to roll smoothly for a while, which becomes impossible after the first bone you pick up. </div> Trivia</h4> The game has 127 “impact” audio files totalling 1.4M, yet only uses 5 tracks for 75K. I’m sorry to waste your bandwidth 😢 </div> The Gameplay</h2> The gameplay ended up relatively minimal, it only required: A “end goal” sensor zone to know that the player completed.</li> Pickable items, with specified “weight” to count toward the final score.</li> Items with “powers” that allow destroying special walls.</li> Special walls that can be destroyed.</li> A character controller with movement.</li> </ul> Controls</h3> So how should the game control? Katamari controls themselves are unique: You use the two sticks of the controller to steer the ball in a direction, as if the left stick and right stick were mapped to the left and right hands of the Prince. Katamari controls are notoriously disorienting, so reproducing them wasn’t a priority. I opted for an orbit cam with WASD/left stick directional movement, because I was expecting most players to be familiar with such controls. It also would make it possible to play the game on keyboard. I actually planned Katamari controls as an option, if only as a nod to an amazing game, but I didn’t have enough time to implement them. Trivia</h4> Gamepad support was added in 5 minutes. </div> The Camera</h3> Klod has a classical 3d plateformer orbit camera, which is known to be disorienting, especially indoors. This was a contentious point in the team at the beginning of the jam, because we opted for an indoor setting despite knowing we would depend on an orbit cam. Knowing that, I made sure there is ample space for the camera to move around when designing the level. But there is still a few cramped places, and indeed the camera in those is really bad, I’m sorry. The orbit cam code is straight up cut from a previous unfinished game, which itself is cut out of a very old crate running only on bevy 0.4. I am very proud how camera-relative input works in Klod, it simply rotates the input by the camera’s x</code> rotation. pub(crate) struct OrbitCamera { distance: f32, x_rot: f32, y_rot: f32, follows: Entity, } impl OrbitCamera { pub(crate) fn horizontal_rotation(&self) -> f32 { self.x_rot % TAU } } fn ball_input() { let force = ;// input force … let force = Vec2::from_angle(-camera.horizontal_rotation()).rotate(force); } </code> </div></pre> The trick is just to use the x_rot</code> of the camera rotation, and rotate the force by it, now input forward is forward for the camera. Physics</h3> The physics were surprisingly both difficult and easy to get right. </video> (2nd day Katamari-like physics) I opted to use bevy_rapier</code></a> for the physics, as I am familiar with it and there isn’t much of an alternative anyway. The klodding mechanic was relatively trivial to implement: bevy_rapier</code> allows specifying composite collider shapes as a parent RigidBody</code> and a collection of children Collider</code>. So theoretically, I only had to convert the transform of an entity I can klod into the klod-local coordinate space, remove the entity’s RigidBody</code> and set its parent to the klod ball itself. fn transform_relative_to(point: &GlobalTransform, reference: &GlobalTransform) -> Transform { let relative_affine = reference.affine().inverse() * point.affine(); let (scale, rotation, translation) = relative_affine.to_scale_rotation_translation(); Transform { translation, rotation, scale } } // ... // `agglo_trans` is the transform of the entity to add to the klod. let trans = transform_relative_to(agglo_trans, klod_trans); </code> </div></pre> However, bevy_rapier</code> has a few</a>, rough</a>, edges</a> which made the straightforward solution simply not work. Once those bumps were surpassed with monstrous workarounds, including splitting the components of the added entities into multiple entities, that was it. It just worked. Well, not quite. I got the Katamari mechanic working, but it was nearly impossible to navigate the level, because you invariably ended up with a shape preventing you from moving or too big to go through doors. The solution had many elements: Increase the ExternalImpulse</code> power applied by inputs proportionally to the total klod weight.</li> Slightly pull toward the center each klodded object.</li> Only klod objects if they are within a certain radius of the ball.</li> Make the bone collider a RoundedCuboid</code> over just a Cuboid</code>, removing all hard edges that caused the most friction and sporadic jumps.</li> </ul> fn within_radius(&self, distance: f32) -> bool { let max_distance = self.weight / KLOD_INITIAL_WEIGHT; distance < max_distance } fn agglo_to_klod() { //... let mut trans = transform_relative_to(agglo_trans, klod_trans); trans.translation = trans.translation * 0.8; //.. } </code> </div></pre> Level Design</h2> The level design was very awkward. The best tool I had at hand was Blender, but it’s not well suited for that kind of tasks. Furthermore, I made the level before Xo made the tileset, and this resulted in incompatible designs. So I made due, and just added the textures Xo made to the base collider cubes (the “greybox</a>” level), adjusting the UVs so they don’t feel too stretched. Game design tip</h4> Greyboxing</a> is the practice of developing a 3D game exclusively with filler grey boxes. This permits to focus exclusively on gameplay. If your game is fun with grey boxes, it will definitively be fun with cool graphics as well. And in a pinch, you can always do like me, keep the box geometry and add a simple texture. </div> The visuals of Klod is a massive downgrade compared to Warlock’s Gambit. I tried to salvage it last-minute, adding more visual diversity with lights, but then the problem was performance, so I had to add a way to disable lighting. Final touches</h2> 18 hours before the end of the jam, I felt like the game was not fun at all! I was very sad. However, after adjusting the physics and adding a goal, it magically became fun and addictive. I think the best part of the game is when you die. Everything goes in every direction, including the hands, and a “you lose” sound effect plays. This was difficult to do due to the rapier issues I’ve mentioned, but it was 159.1% worth it. I was tempted to make the game nearly impossible so that people would naturally see the death animation. In insight, I should have played the death animation on any loss condition. The spawn animation with the hands joining the ball and the ball growing is also excellent flavor, even if it lasts less than half a second, I love it for how silly it is. Results and learning</h2> I eventually came around to enjoy the game. Despite the sub-par graphics, it is still a fun game to play. (reminder that you can play it in browser for free</a>) However, this time, the competition is fierce! I think at least two games out of the ones I played are better than Klod, and I’ve only played 15 out of the 89 submitted games. I think our weakness is still unfamiliarity with game development processes and a lack of environmental artists. The weakness bevy showed are: Lack of an opinionated focus system</li> No mature level editors</li> Poor scene API design</li> Awful UI library</li> </ul> Making Warlock's Gambit 2022-03-06T00:00:00+00:00 Warlock’s Gambit</a> is our submission to the first Bevy game jam. It was made over 7 days by Team Plover. This dev log is a rundown of the development process. Will dive into the nitty-gritty code implementation details in a future dev log</a>. The Team</h2> Team Plover had 7 members but most of the work was done by 4 of them. The participation of the 3 other members was still welcome and helped finish the game in time. I’m one of the two developers who put serious work into Warlock’s Gambit. I’ve programmed all the logic, while vasukas made sure my code ran on all plateforms and implemented the win/lose states. Which is not chump change! It was an invaluable contribution. Team Plover is extremely distributed, with at least 4 continents accounted for. This was already a challenge in itself. The channels most people use for consensus are not available to a distributed team. The Setup</h2> We decided pretty quickly to work using git on Github. The game would be in a private repo until the release, when we would open-source it. The competition rules allowed to start from a “generic” project. I decided to setup a project with probably-useful dependencies and write a minimal starting menu with audio sliders (turns out we have the only game in the comp with audio sliders.) The Idea</h2> Once the jam theme was announced, we discussed what we could do based on “Unfair Advantage” in Discord on text channels. I personally wanted something involving pigeons or wizards or both at the same time, imagining a game of soccer with wizards. However, the idea that caught everyone’s imagination was Lorithan’s card game: you play against someone who stacked the deck against you. The only way to win would be by cheating. Once we had the idea. I put it down on a markdown file on git with a very basic draft of game design. Github has a surprisingly usable markdown editor that let you edit text files and update them in the browser. With this, I encouraged everyone, including our artists with no concept of programming to edit the design file with their comments and design suggestions. However that file didn’t see a lot of edits and the game design lingered. The Design</h2> It was convened that we should have a voice chat where we could discuss synchronously the game design to acquire a consensus before going forward with code or art. We spent a day and an half picking up everyone’s schedule and trying to find a time frame during which we could get all together. This failed as we were really distributed and simply didn’t have overlapping free time to get together. After having spent two days waiting on something that didn’t happen, we implicitly decided on going forward with the design. I improved the design by adding more details. Once we were ready, we went at it like a canon ball. This is where development really took off. The Code</h2> This means we only had about 4 days left to write the code and get something out the door. I still can’t believe I managed to make such a high polish game in such short notice. This is contrary to everything I’ve done before. I think the team was the real catalyst for that productivity. I was already very familiar with rust and was coming from 5 months of full time focus on bevy game making. I knew the ins and out of the engine, what were the areas to avoid and how to use optimally bevy’s feature to make a great game. But I never reached such an intense coding output before. I’ll go into the coding details in a future dev log</a>. The Art</h2> Xo has been working with me for the same length of time I’ve been discovering bevy. He’s an excellent artist, it’s in fact an honor to be able to work with such a talented person. Xo mocked a scene (the one you can see in the game) and produced the assets as separate 2d png files. I specifically asked him for this, so that I could put them together in a 3d scene in blender, in addition to various “empty” objects that would serve an anchor for gameplay elements. I’ll go in more details how I linked the gameplay elements to the objects in a future post. You can find that scene in the game files. You can open it with blender to see for yourself how it looks like 🙂 I spent a few hours adjusting the graphical assets, not only in the 3d scene, but also the card assets. To reduce file size, I converted the card numbers and words to a 2d color palette. The PNG file format can efficiently compress low color count images with simple shapes. This involved a lot of looking up on stack overflow how to use the imageMagick convert</code> tool. But we got everything in the correct format by the end. Samuel_Sound was a late-comer to the party, and worked completely independently of the rest of the team, just asking for a mood and some inspirations. But their contribution was paramount to give a personality to the game. The music they produced is excellent. They worked off of The Banished soundtrack</a>. Samuel_Sound also contributed the card shuffling sounds. The “words of power” that gives effect to cards are written in Enochian</a>. The voice you can hear when they are played is mine. I say the word as they would be pronounced in Enochian. I modified the voice with Audacity effects. I also made squawking and quacking noises for the bird, sadly I couldn’t add those sfx in time. The Final Rush</h2> The final day was insane! Up until Friday, we really didn’t have any playable “game”. Just card drawing, dragging, dropping and basic War score counting. But it came together very quickly! I calculated I could get a publishable game with sound, music, card effects and win/lose by midday (while the submission was at 10PM). And I wasn’t far off. By 3PM I implemented that day: The card effects (point bonuses, adding seeds etc.)</li> An overlay system that shows tutorial texts and card effect descriptions</li> The music and sfxs (card shuffling, voices)</li> An AI that can chose to play a better card than the one the player played</li> The bird eye looking at the card the player grabs and detecting when the cheat is used</li> </ul> I took the rest of the afternoon to design a sequence of cards that makes it impossible to win without cheating while being beatable with the sleeve trick. This involved pen and paper and a calculator. It was very fun to design. This prompted me to add synergies to the card effects. Surprisingly, designing the deck with synergies in mind (for example, the +12 and x2 would double the bonus) was much easier. By 6:30PM I added the deck to the game. It was time to publish the game on itch.io. This is where vasukas’s and BLucky’s contributions were the most critical. I developed the game on Linux with absolutely no regard for multiplatform. While I was hammering at the code, vasukas was figuring out how to create an HTML file with the game embedded. BLucky compiled the binary for MacOS. I was hopping that the official bevy Github CI pipeline would be enough, but it was too dang slow, the MacOS build failed and the wasm version didn’t even work! Each team member pushed their version of the game to the itch.io page and by the end we had everything in order. I even had the time to add the deck shrinking mechanic. That’s it. I’m really proud of the result. I do think we have the most polished entry in the jam by a large margin, despite all the bugs. I’m myself extremely surprised I could write so quickly such a game. And I’m surprised the game ended up actually quite fun despite having about 3 hours of thought put into it. Now I know you are a bevy users and you are highly disappointed I didn’t go into details about game architecture, ecs, events and all the implementation details. But don’t be despondent! I love writing about technical things and as I said I’m very proud of the code, so obviously I’ll go into a deep dive in a future dev log entry</a>. Be patient 😉

What’s next for bevy</h2>

What's up with unique reflect?</h4>
The Unique Reflect RFC</a> is more a set of guidelines on how to think and document `bevy_reflect</code> features. I’m already satisfied with it, in that it has been helpful to bevy contributors to design and document their code.</p> </div>`

Gizmos</h3>
Bevy’s gizmos are still very limited. As a result, gizmos from one plugin do not play well with gizmos from other plugins. As more crates adopt gizmos, we might see more and more conflicts. My amazing gizmos tracking issue</a> is already a wish list, so I won’t write one here.</p>

Migrating to rapier</h3>
In the week of the 19th I spent most of my time reimplementing existing features. Notably mouse controls. I also rewrote the way input is translated into actions (of course, since that’s the part that touches the physics).</p> </video>
mouse picking</p>

And more</h3>
Now my second rewrite reached feature parity with the first one. Ah, accidentally. It is time to start making strides toward feature parity with The C Version</strong>. Fun in perspective, to the next post!</p>

Making the game</h2>
Now is the time, little UBs. Watch out. Your time is up, time to demolish your house of card, and each little nook of my C code you hide yourselves in.</p>
Time to rebuild GSSA on sounder foundations.</p>

Jargon</h4>
to klod, klodding, klodded</em>: verb, to add to the klod ball.</p> </div>

Game jam tip</h4>
I strongly recommend using jummbox</a> for game jam music. I have no formal music education and do not play any instrument, yet I can get some compelling crap out of it.</p> </div>

Trivia</h4>
The game has 127 “impact” audio files totalling 1.4M, yet only uses 5 tracks for 75K. I’m sorry to waste your bandwidth 😢</p> </div>

Trivia</h4>
Gamepad support was added in 5 minutes.</p> </div>

- Devil Dahu developers blog

A year of bevy, past and future

Our dev environment

2023 devlog 3

Necking devlog 2

Necking devlog 1

Architecture of a GBA game — gssa

Rewriting a GBA game in Rust — gssa

Video game essence

Behind the Klod

Making Warlock's Gambit

- Devil Dahu developers blog

A year of bevy, past and future

What’s next for bevy</h2>

UI</h3> I suspect bevy is going to see a lot of change in UI in the near future.</p>

Our dev environment

2023 devlog 3

Necking devlog 2

Necking devlog 1

Migrating to rapier</h3> In the week of the 19th I spent most of my time reimplementing existing features. Notably mouse controls. I also rewrote the way input is translated into actions (of course, since that’s the part that touches the physics).</p> </video> mouse picking</p>

Architecture of a GBA game — gssa

Architecture</h3> A neophyte wrote the GSSA C code. Myself, writing a large program, not only for the first time in C, but for the first time in any language.</p>

And more</h3> Now my second rewrite reached feature parity with the first one. Ah, accidentally. It is time to start making strides toward feature parity with The C Version</strong>. Fun in perspective, to the next post!</p>

Rewriting a GBA game in Rust — gssa

Setup</h2> Look at that, look at those setup instructions, so terse, so simple.</p>

Making the game</h2> Now is the time, little UBs. Watch out. Your time is up, time to demolish your house of card, and each little nook of my C code you hide yourselves in.</p> Time to rebuild GSSA on sounder foundations.</p>

Sprites and color palettes</h3> I have sprites, the GBA video processor needs those sprites in video memory (VRAM). I need the sprites to be in the game ROM.</p>

Video game essence

What is Game Essence?</h2> To Sakurai, Game Essence, far from being a brand of perfume smelling of cheap alcohol and sweat, is an extension of the “Risk/Reward” equation.</p> What is the Risk/Reward equation?</strong></p> </blockquote> Risk/Reward is a classic video game design idea.</p>

Behind the Klod

Jargon</h4> to klod, klodding, klodded</em>: verb, to add to the klod ball.</p> </div>

Klod soundtrack</h4> </audio></p> </div>

The sound effects</h2> We had music, but we needed some sound effects. Physics become empirically 1195.93% better if combined with sounds.</p>

Trivia</h4> The game has 127 “impact” audio files totalling 1.4M, yet only uses 5 tracks for 75K. I’m sorry to waste your bandwidth 😢</p> </div>

The Gameplay</h2> The gameplay ended up relatively minimal, it only required:</p>

Trivia</h4> Gamepad support was added in 5 minutes.</p> </div>

Level Design</h2> </p> The level design was very awkward. The best tool I had at hand was Blender, but it’s not well suited for that kind of tasks.</p>

Making Warlock's Gambit

Migrating to rapier</h3>
In the week of the 19th I spent most of my time reimplementing existing features. Notably mouse controls. I also rewrote the way input is translated into actions (of course, since that’s the part that touches the physics).</p> </video>
mouse picking</p>

And more</h3>
Now my second rewrite reached feature parity with the first one. Ah, accidentally. It is time to start making strides toward feature parity with The C Version</strong>. Fun in perspective, to the next post!</p>

Making the game</h2>
Now is the time, little UBs. Watch out. Your time is up, time to demolish your house of card, and each little nook of my C code you hide yourselves in.</p>
Time to rebuild GSSA on sounder foundations.</p>

Jargon</h4>
to klod, klodding, klodded</em>: verb, to add to the klod ball.</p> </div>

Trivia</h4>
The game has 127 “impact” audio files totalling 1.4M, yet only uses 5 tracks for 75K. I’m sorry to waste your bandwidth 😢</p> </div>

Trivia</h4>
Gamepad support was added in 5 minutes.</p> </div>