<h1 id="zenithdevlog251324">Zenith Devlog #2: 5/13/24</h1>
Well, it looks like trying to do this once a week was a bit ambitious. BUT, ambitious is good, and this week I finally got back to making Zenith a priority. Jumping back into things, I was pleasantly surprised how easy it was to use a lot of the tools I wrote myself earlier. Especially everything that had to do with animations. Now that I'm focusing less on "boilerplate" and more on "game features", having an ergonomic way to instantiate sprites and animations has been huge.
<h2 id="segmentsmakingrocksmoreinteresting">Segments: Making Rocks More Interesting</h2>
Before this week, rocks were these uniform, polygonal things. I had different types (normal, icy, or death-y), but within a single rock there wasn't much variety. This week, I added the concept of "segments", which are things that connect two points on a rock that are neighbors. To start I've implemented "spikes" and "springs" as two types of segments. See the picture below:
<img src="/blog_images/zenith-devlog-2/SegmentShowcase.png" alt="SegmentShowcase" />
Getting this to work required slightly rethinking how I handled meshes, sprites, and animations. Previously, I had the concept of a textured mesh (what I was using for rocks) that lived separately from the concept of an animation (what I used for things like the goal/start). A textured mesh was a sprite attached to an arbitrary set of points, either scaled or repeating. An animation was a rectangle with a given sprite sheet and speed. But then I had the following thought: if I have a spring, it can potentially have an arbitrary length, and I want it to play an animation when the player hits it. So then I need an animation which can play on an arbitrarily sized rectangle. This is basically the same amount of work as getting an animation that can play on an arbitrary set of points, so I just combined these two things in to one thing, an <code>AnimationManager</code> which is flexible enough to handle both use cases.
Here's what the spring initialization code ended up looking like:
<pre><code class="rust language-rust">AnimationManager::from_nodes(vec![
 (
 "idle",
 AnimationNode {
 sprite: SpriteInfo {
 path: "sprites/goodies/spring.png".to_string(),
 size: UVec2::new(7, 7),
 },
 length: 1,
 ..default()
 },
 ),
 (
 "bounce",
 AnimationNode {
 sprite: SpriteInfo {
 path: "sprites/goodies/spring_bounce.png".to_string(),
 size: UVec2::new(7, 7),
 },
 length: 6,
 next: Some("idle".to_string()),
 ..default()
 },
 ),
])
</code></pre>
Each node should be thought of as the node of some finite state machine. By default, the animation will loop, unless it's given a "next", in which case when the animation finishes it will switch states to the given key. By default, the points are assigned to initially match the provided sprite, but can be stretched and moved arbitrarily.
The <code>AnimationManager</code> itself has a lot more properties, exposed through setters to control the state of animation.
<pre><code class="rust language-rust">pub struct AnimationManager {
 key: String,
 map: HashMap&lt;String, AnimationNode&gt;,
 points: Vec&lt;IVec2&gt;,
 scale: AnimationScale,
 offset: IVec3,
 angle: f32,
 render_layers_u8: Vec&lt;u8&gt;,
 hidden: bool,
 scroll: Vec2,
 is_changed: bool,
}
</code></pre>
Along with this are a handful of systems that read the current state of the manager, and manage child entities displaying the animation. When the animation is just playing as normal, neither the mesh nor the material needs to be regenerated, just a few parameters defining the underlying material are tweaked. However, when a big change occurs, like switching keys or changing points, the mesh and material are regenerated, a slightly expensive step but one that really only happens in the editor.
As I was thinking through how this manager would be used in the game, I also realized that many things would need to manage multiple animations simultaneously. The most common is things that have both a sprite and a light, two animations that — while living in different render layers — should be controlled by the same entity.
Obviously an entity can't have two <code>AnimationManager</code>s, so I made another handy component, <code>MultiAnimationManager</code> which is basically a map of keys to animation managers that allows a single entity to control many <code>AnimationManager</code> children.
<pre><code class="rust language-rust">pub struct MultiAnimationManager {
 pub map: HashMap&lt;String, AnimationManager&gt;,
 pub is_coup: bool,
}
</code></pre>
The <code>is_coup</code> field sounds scary but exists to solve a pretty basic ABA issue that happens when editing rocks. Basically if you have a rock that has 3 animation children, <code>field1, field2, field3</code>, and then delete <code>field3</code> and add a new <code>field3</code> on the same tick, then the system that is watching for changes will miss it (since it's only doing comparison on keys, not deep comparisons on the animations). This flag is marked anytime such an issue could occur, and signals to the underlying system that it should do deep comparisons when updating the entities actually displaying the animations this frame.
In terms of gameplay, spikes are simple hitboxes that stop and kill the ship. Springs launch the ship at a consistent vertical (or really normal) velocity while conserving horizontal (or really parallel) velocity.
<h2 id="gettingspringphysicsrighttweakingtriggerorder">Getting Spring Physics Right - Tweaking Trigger Order</h2>
Previously, my physics logic worked like this:
There are two kinds of things that <code>dynos</code> (moveable objects) may hit.
<ol>
<li><code>statics</code> - Are things that objects bounce off of. Right now, this is only rocks. Each <code>static</code> defines a bounciness and a friction which make the interactions unique.</li>
<li><code>triggers</code> - Are things that have no specific collision logic, but get added to the <code>dyno</code>'s <code>trigger</code> list each frame while moving so it knows which triggers it passed through and can handle the logic later.</li>
</ol>
Both <code>statics</code> and <code>triggers</code> share <code>ColliderBoundary</code> logic for defining their hitboxes, which may be arbitrary polygons.
Each update, each <code>dyno</code> first clears the list of <code>triggers</code> it has collided with. Then, it inches along 1 unit at a time, resolving collisions with all <code>statics</code>. Then, once moving is finished, it checks which <code>triggers</code> it's colliding with and adds them to it's list. A later system then reads these triggers to apply things like field gravity and drag.
However, this created an issue with springs. Springs define a <code>trigger</code>, not a <code>static</code>. This is because I don't just want springs to be a bouncy material, but rather an object that will always send the ship (ball) at a consistent height to make tighter gameplay possible. So, my first attempt simply had me adding a system that looked at the triggers after the ball finished moving, and applying springs if there was a collision. But this felt bad. Sometimes, the ball "should" have hit a spring trigger, but because it was only checked at the end of movement, and not at the 1-unit increments, it was missed.
The fix was to make the physics update work as follows:
<ol>
<li>Clear the <code>triggers</code> list.</li>
<li>Perform a series of 1-unit "inches" resolving static collisions as you inch.</li>
<li>After each inch, check for trigger collisions and update the <code>triggers</code> list. If one of the triggers is a spring, immediately update the velocity.</li>
<li>Later systems can then read the <code>triggers</code> list for applying things like gravity, or checking if the ball collided with a spike.</li>
</ol>
This ended up working wonderfully. The last small change I made was for the underlying collider physics logic to add it's parent id as the trigger id instead of it's own, just to avoid some weird parent chasing that popped up in some trigger processing systems.
<h2 id="replenishesfasterpacedgameplay">Replenishes - Faster Paced Gameplay</h2>
My original vision for this game placed a lot of emphasis on precision. The goal would be to finish each level in as few shots as possible, which means planning out shots carefully and taking calculated risks.
<img src="/blog_images/zenith-devlog-2/Replenish.png" alt="Replenish" />
A screenshot from the game showing the ship flying past the "replenish" diamonds (inspired from Celeste) which will give you a fresh shot mid flight.
While I think that this vision could still work, as I've spent more time playing around with the physics I've found it actually rather hard to accurately predict the balls path through gravity on a gameplay level. Very small changes to the power or launch angle may completely change how the ball does (or doesn't) wrap around certain edges or escape certain fields. Maybe this is a skill issue, but without something like a shot preview I thought that this could be frustrating to players who feel the physics is too complicated.
Instead of changing the physics, I'm going to see what the game feels like if the metric the player cares about isn't number of shots but is instead speed. Your ability to "shoot" wouldn't return when the ball completely stopped moving, but rather when the ball hit a static with a "small enough" velocity. There would also be yellow boxes, decently easy to hit, floating out in space that the player could aim for that would allow them to modify the path of their ball mid flight.
I've only now barely finished implementing replenishes, but I'm hoping this week to add a bullet-time feature that activates when taking a shot so I can see how the game feels at this fast pace.
<h2 id="todonext">TODO next</h2>
I feel I'm actually getting very close to a point where I can crank out a bunch of levels, send a copy to my friends and have them tell me whether it's fun. Before I do that I need:
<ul>
<li>Bullet time when making a shot</li>
<li>Fix some slight performance issues on old hardware (it feels a bit laggy on my old laptop)</li>
<li>Tuning the shot speed, gravity strength, to make levels and gameplay feel as "crisp" as possible.</li>
<li>Design a bunch of levels.</li>
<li>Simple tutorial</li>
<li>Simple way of chaining levels</li>
</ul>

Zenith Devlog 2

<h1 id="zenithdevlog14924">Zenith Devlog #1: 4/9/24</h1>
I've noodled around making a lot of games. Some using established engines like Unity and Unreal, others from scratch using C/C++. Lately, I've been diving into Bevy, an incredibly potent yet lightweight engine. It feels like starting from scratch but without a lot of the annoying stuff. Plus, it's in Rust, which (imo) is fun to use.
Most of the time, I get really into these games for a few weeks, but then completely drop them. Either the gameplay doesn't feel good, or I'm not passionate about the story, or I'm simply afraid of how much work it'll be.
But with my current game, Zenith, things feel different. I've got a concrete sense of what the gameplay will be like, and it feels good. I like the story, and I think I just might have a solid enough grasp on Bevy/ECS in general where I can make things happen in the game relatively quickly.
Also, I'm in a pretty unique place in my life at the moment. I'm about to graduate college, and have decided to go out with a relatively light semester. This might be the last time in awhile I can afford to make some passion-game a major priority, and I don't want to waste the opportunity.
So, I've decided to start a devlog. In this post, I hope to explain why I'm doing this, who I think might be interested, and actually write my first devlog.
<h2 id="whyadevlog">Why a devlog?</h2>
Plainly speaking: I want to finish this game, I want it to be good, and I want to be polished. I think getting fragments of the game and my mind out in to the public as early as possible will be motivating and make the final product as high quality as possible.
This devlog is a good chance for me to get more involved in the community. I'm hoping that by putting my thoughts, struggles, and solutions out in the open I can engage with the community, providing and receiving valuable advice.
There's also the very real point that by forcing myself to sit down and write at a high-level about the project every week, I'll be more likely to finish it and perhaps more willing to do the "high priority annoying stuff" as opposed to just "whatever feels fun today" (although usually they're not too far off).
<h2 id="whocares">Who cares?</h2>
Realistically, probably no one. I'm perfectly content if this ends up being loose rambling into the void.
But for the sake of focusing my writing, here's who I'm thinking might want to read some of these:
<ul>
<li>People who care about me / my work - My future self, friends, other game developers.</li>
<li>People who want to learn more about Bevy/Rust - I anticipate being pretty technical in these posts. I'm hoping I can answer someone's random Google search (Bevy docs are not great), and hopefully even get roasted by someone who's smarter than me.</li>
<li>People who want to play the game - This will probably be 0 people for a long time. But maybe once I get a public beta I can use this as a space to get feedback from potential players about what they want to see from the game.</li>
</ul>
<h1 id="theactualdevlog">The Actual Devlog</h1>
<h2 id="prefacewhatsthegame">Preface: What's the game?</h2>
I've always had a soft spot for golf games. Most 2d, but some 3d. I'm hoping to make an interstellar-travel themed 2d "golf" game where you shoot the ship and interact with fields and the like from scattered planets. Think: some kind of mash-up between Super Mario Galaxy and Golf-Story, in 2d.
Before this week, I had rudimentary foundations for all major parts of the game: physics, level editor, cutscenes. This week I made some of them a lot better.
<h2 id="editorhell">Editor Hell</h2>
This week I've been working on revamping the level editor to make it more expressive. Previously, gravity fields for planets had to be uniform, and there wasn't an easy way to move multiple points at the same time, or add points to an existing planet, or do a bunch of other things.
And this makes sense! I think for a game like this with custom physics, you need to make a rudimentary editor to use alongside the first implementation of the physics. Since it's not just default AABB, or some out-of-the-box solution, I needed a way to test the edge cases I felt unsure of, and make sure it felt fun for the levels I thought might be interesting. The first editor definitely did this. But boy was it time to write a new one.
Rewriting the editor turned out to be a more herculean task than I original thought, but the bright side is I learned a lot, and I think some of the key takeaways will help me write cleaner ECS code going forward. Let's dive in to exactly what changes I made to the editor in the new version and what I learned about this kind of ECS structure.
<h3 id="thepointasthefundamentalentity">The point as the fundamental entity</h3>
Previously, I had had the point information wrapped up in some <code>Vec&lt;Vec2&gt;</code> inside another component. This lead to a lot of really annoying queries, and made it pretty impossible to have meaningful hierarchies (i.e., point A is parented to point B, so when you move point A point B should move too). The solution was pretty simple: Make (most) editor interactions just interacting with a point (moving, spawning, deleting), and make higher level components (rocks, fields, start/goal) references to points with some additional metadata. It took a couple iterations to get the point data factored into the right components, but it made things feel a lot better.
<img src="/blog_images/zenith-devlog-1/parented_points.png" alt="parented_points" />
The above screenshot is from the new editor. Each square is a point, and the thick white lines show the parent-child relationships between the points. This makes it especially easy to edit the rocks while having the gravity fields adjust appropriately.
<h3 id="markercomponentsforcomplexchanges">Marker components for complex changes</h3>
Previously when I had written the update functions for my old editor, when something happened, it happened right away. (Well, technically the next Update, but as "right away" as is possible for deferred commands in ECS). For example, if you spawned a gravity field, it would spawn and immediately have all the right points and direction. This meant fewer systems, but meant each system took way more parameters and did way more work and was pretty hard to follow.
So instead, for "complex" things, I just decided to attach some marker components that basically say "Hey! Some work needs to be done here", and then I could write more targeted systems to do surgical updates to the editor state.
The biggest win here was with spawning new fields. Like I mentioned at the beginning, one of the biggest limitations of my old editor was that every planet had to have a uniform field around it. But what about a planet that has a strange spike? Or a zero-gravity portion? The solution was to give each point a type, either "Rock", "Field", or "Wild".
"Rock" points make up the solid mesh of the planet, and their position is relative to the planet.
"Field" points are the children of rock points.
"Wild" points are points that are children of the planet, but should be able to be converted into field points (i.e. "adopted" by some rock point) to make a field on the planet.
In the new editor, when a new field is created for some planet, all of it's points are marked with a <code>PendingPlanet(pub Vec&lt;u32&gt;)</code>. Then, the system that's watching for the new field input (selecting points and hitting <code>F</code>) can move on and completely forget about it.
Meanwhile another system is watching for <code>Point</code>s marked with a <code>PendingPlanet</code>. When it finds some, it determines the shape of the field, it's gravity, and (potentially) turns <code>Wild</code> points into <code>Rock</code> points parented to the nearest rock point.
<h3 id="bevyreflectiskindajank">Bevy reflect is kind a jank</h3>
After a lot of work I had an editor that I was pretty happy with that had a decent number of components that used <code>Entity</code> to refer to some entity. Then I wanted it to be possible to save the level (something that was only barely possible before). I thought briefly about writing some system that manually would serialize everything, and another system which could read that and then spawn everything in right order, but that seemed like a lot of work. Instead I tried to use good 'ol <code>serde</code> and Bevy's built in <code>Reflect</code> capabilities.
<blockquote>
 An aside: what is <code>Reflect</code>? A simple way to think about it is a way of describing the fields and type information for a struct at runtime, so that it can be automatically serialized in a way such that some combination of Serde, the engine, and the type system can reconstruct it again in runtime sometime later.
</blockquote>
This was SUPER annoying. Firstly, I learned that I shouldn't have been relying on <code>Entity</code>s to be unique across save/load. This is kinda mentioned in the docs, and it's on me for missing it, but basically I needed to go back and replace everywhere where I had <code>Entity</code> with my own custom unique identifier component which would actually be unique across save/load.
There also seem to be some weird quirks in the actual serialization. For example, when <code>Vec2</code> (or similar) is used in a component I define, it gets serialized to:
<pre><code>field_name: (
 x: flksdf,
 y: kdljfs,
)
</code></pre>
Looks good, right? Wrong. Turns out the <code>.ron</code> deserializer actually expects it to look like
<pre><code>field_name: (sdfsk, skdjf)
</code></pre>
I have no idea why, or why this doesn't also break serialization for built-in higher-order types (like Transform). I spent too many hours trying to write my own serializer, but bevy refused to use it, before I finally gave up and just wrote a script which would serialize it into the broken <code>x: lsdfkj, y: lsdkfj</code> form, and then make edits to put it into the right form to be deserialized.
This, combined with having to replace <code>Entity</code> everywhere basically led to a rewrite of the whole editor. Yay!
<h3 id="aphoenixfromtheashesstubsandheads">A phoenix from the ashes: Stubs and Heads</h3>
Through all of this writing and rewriting, I stumbled upon two patterns which seem quite good for ergonomic management of complex entities, requiring complex assets (meshes with custom sprite textures were the original inspiration).
Stub - A component that lets another system know something should happen here
For example, let's say I'm spawning a planet given 4 points. That planet needs a mesh. One option I have is to at the moment I spawn the planet, add a mesh as a component on the entity. But now let's say the planet actually need's two meshes, for another section or whatever. Well now bevy doesn't like this because you can't have two of the same component on an entity.
So the solution is to spawn the mesh but just make it a child of the original entity with 0 offset. This works, but is super annoying in practice. It means anytime you want to spawn a planet, you need to have mutable access to <code>Assets&lt;Mesh&gt;</code>, <code>Assets&lt;SpriteMaterial&gt;</code> (a custom material), you need to not only spawn the bundle you care about, but also a bunch of boilerplate stuff that looks exactly the same as the boilerplate stuff that gets written when you're putting a mesh on the ship, or the star, or whatever.
So what do we do? How do we avoid annoyingly passing around <code>ResMut&lt;Assets&lt;Mesh&gt;&gt;</code> everywhere and writing 20+ lines to spawn a single planet?
The better solution is to make the <code>Planet</code> bundle have a <code>MeshStub</code> component This component, like above, just exists to say, "Hey! Mysterious game engine, you should spawn a mesh here with the given data and parent it to whatever entity has this component.
This was a game-changer for me. It made code that looked like this:
<pre><code class="rust language-rust">impl BorderedMesh {
 fn spawn(
 commands: &amp;mut ChildBuilder,
 meshes: &amp;mut ResMut&lt;Assets&lt;Mesh&gt;&gt;,
 points: Vec&lt;IVec2&gt;,
 material: (BorderedMatData, Handle&lt;SpriteMaterial&gt;),
 border_material: Option&lt;(BorderedMatData, Handle&lt;SpriteMaterial&gt;)&gt;,
 border_width: Option&lt;f32&gt;,
 render_layer: RenderLayers,
 inner_info: SpriteInfo,
 outer_info: Option&lt;SpriteInfo&gt;,
 ) -&gt; Entity {
 let fpoints: Vec&lt;Vec2&gt; = points.clone().into_iter().map(|p| p.as_vec2()).collect();
 let inner_points = outline_points(&amp;fpoints, -border_width.unwrap_or(0.0));
 let mut inner_mesh = generate_new_sprite_mesh(&amp;inner_points, &amp;material.1, meshes);
 inner_mesh.transform.translation.z += 0.5;
 let outer_mesh = match &amp;border_material {
 Some(mat) =&gt; Some(generate_new_sprite_mesh(&amp;fpoints, &amp;mat.1, meshes)),
 None =&gt; None,
 };
 commands
 .spawn((
 BorderedMesh {
 last_points: points.clone(),
 points,
 last_material: material.0.clone(),
 material: material.0.clone(),
 last_border_material: match border_material.clone() {
 Some(thing) =&gt; Some(thing.0),
 None =&gt; None,
 },
 border_material: match border_material {
 Some(thing) =&gt; Some(thing.0),
 None =&gt; None,
 },
 border_width,
 scroll: default(),
 },
 IntMoveable::new(IVec3::ZERO),
 SpatialBundle::default(),
 ))
 .with_children(|parent| {
 parent.spawn((
 inner_mesh,
 render_layer.clone(),
 BorderMeshType("inner".to_string()),
 ScrollSprite::default(),
 inner_info.clone(),
 ));
 if let (Some(outer_mesh), Some(outer_info)) = (outer_mesh, outer_info) {
 parent.spawn((
 outer_mesh,
 render_layer.clone(),
 BorderMeshType("outer".to_string()),
 ScrollSprite::default(),
 outer_info.clone(),
 ));
 }
 })
 .id()
 }
}
</code></pre>
look like this
<pre><code class="rust language-rust">impl EPlanetBundle {
 pub fn new(pos: IVec2) -&gt; (Self, impl Bundle) {
 let core_uid = fresh_uid();
 let bordered_mesh_uid = fresh_uid();
 let bordered_mesh_head_stubs = BorderedMeshHeadStubs(vec![BorderedMeshHeadStub {
 uid: bordered_mesh_uid,
 head: BorderedMeshHead {
 inner_path: "textures/play_inner.png".to_string(),
 inner_size: UVec2::new(36, 36),
 outer_path: "textures/play_outer.png".to_string(),
 outer_size: UVec2::new(36, 36),
 render_layers: vec![sprite_layer_u8()],
 border_width: 7.0,
 ..default()
 },
 }]);
 let bund = EPlanetBundle {
 uid: UIdMarker(core_uid),
 eplanet: EPlanet {
 bordered_mesh_uid,
 ..default()
 },
 spatial: SpatialBundle::from_transform(Transform::from_translation(
 pos.as_vec2().extend(0.0),
 )),
 moveable: IntMoveable::new(pos.extend(0)),
 save: SaveMarker,
 };
 (bund, bordered_mesh_head_stubs)
 }
}
</code></pre>
At first glance, these don't look that different, but I think there's two big things that make this a huge quality of life improvement. First, in the improved code, you get a bundle back. That means you don't need to pass in 4 parameters everytime you call this function with proper mutable access. Second, whatever is using this only needs to know the stuff that's relevant. Where is the image path, how big is it, what's the border? It is truly data first.
The downside? The only real downside is that it makes these kinds of things potentially a frame or two delayed. Obviously there'll be some system running watching to actually spawn the meshes, and so it'll likely be:
<pre><code>spawn stub -&gt; (maybe frame passes?) -&gt; sytem spawns actual mesh, removes stub -&gt; (frame passes) -&gt; (asset loads) -&gt; asset appears
</code></pre>
But I think this will probably almost never matter. Also, in the alternative, you really only save one or two frames, tops (and usually probably zero). Commands are defered anyway, so if it's spawned here or in another system, it probably doesn't matter.
Head - A component that controls something that's annoying to serialize
Reflect for saving/loading levels worked great for simple data, but it immediately exploded as soon as I tried to serialize assets like images, meshes, materials, etc. This is because somewhere in the entities containing these things, the assets are just basically <code>Arc</code> pointers to something that lives in memory. Serializing that in a way that can be recreated, especially when that thing in memory had to be loaded somewhere else from disk, is hard (and probably a bad idea).
Naively just ignoring these <code>Assets</code> kept leaving the editor in a broken state, and trying to plug holes one by one felt like this:
<img src="/blog_images/zenith-devlog-1/holes.gif" alt="ice_age_gif" />
So instead, for any entity that should be able to be seamlessly loaded, and correct itself if it's child is ever in a f***-d up state, I gave it a <code>Head</code>. It's really just a component that contains whatever data is needed to recreate the <code>Arc</code> on that asset (i.e. a filepath, maybe some metadata), and a collection of systems that make sure it always has a child (at 0 offset) with the right asset.
That's pretty much what I've been working on for the game lately. I also went back to a lot of other things I had already written (ship, rock, etc) and changed it to use the new stub/head framework for things like meshes and animations, where relevant.
<h3 id="nextsteps">Next Steps</h3>
With a solid, expressive editor, my next goal is going to be to solidify the game's mechanics. There are a few features I want to add (spikes, bouncy-stuff, replenishing shots, bullet time) before I'd consider it super fun to play. It should be fun stuff to work on, but probably will be time consuming as ideally I want to solidify all the physics and core interactions so I can move on to designing great levels and a great story.
Thanks for reading! Here are a couple more screenshots of the game highlighting the stuff I worked on this week.
<img src="/blog_images/zenith-devlog-1/complex.png" alt="complex" />
<img src="/blog_images/zenith-devlog-1/testing.png" alt="testing" />
(This one is the same as the title image, but bigger and easier to see.)

Zenith Devlog 1

<h1 id="jpegxlisastupidname">JPEG XL is a Stupid Name</h1>
Compression is one of the purest problems in CS. What's not to love about it? It touches almost every piece of software ever written, it's basically just math, and it makes things smaller! Awesome!
NOTE: It makes things smaller.
Obviously, I have a lot of respect for <a href="https://www.play-jpeg.com/">jpeg</a>. It's smart, and it's survived the test of time, which is not true of most compression schemes. The name, an acronym for Joint Photographic Experts Group, is pretty good, probably better than the average acronym given it's convenient vowel placement.
NOTE: XL = X-tra Large (almost always).
So why the f*** is the defacto JPEG successor, which will probably be the leading compression algorithm for the rest of my life, called JPEG XL?
<h2 id="justification">"Justification"</h2>
Here's why it's called JPEG XL:
<ul>
<li>JPEG: It's a successor to JPEG</li>
<li>X: There were other competing compression schemes that had the letter X in them, including JPEG XT, JPEG XR, and JPEG XS. Notice that "XS" almost always means X-tra Small. Compression means making things smaller. Just food for thought.</li>
<li>L: L stands for long term, because the authors want this scheme (like JPEG) to be around for awhile.</li>
</ul>
<h2 id="whythisjustificationisbad">Why this Justification is Bad</h2>
XL = X-tra Large = not small =/= small = compression.
Put simply: an average person will hear: JPEG is being replaced by JPEG XL and think: My images are going to get bigger. This is bad and not true. Who knows, maybe 40 years from now some kid who's only ever grown up using JPEG XL will stumble upon some dusty old JPEG file and — perfectly rationally — think its some kind of new fancy compression scheme with smaller image sizes.
<h2 id="whyisnooneelsetalkingaboutthis">Why is No One Else Talking About This?</h2>
I have no idea.
<h2 id="whatamigoingtodoaboutit">What am I Going to Do About It?</h2>
Nothing. (Besides post this and see what the reaction is to guage if this also bothers other people or if its just me.)
As an aside: From what I've read the algorithm itself seems like a pretty big improvement. Being able to progressively decode, while also support photographic and synthetic imagery will lead to some pretty huge savings both in terms of final image size and efficiency. The authors are all very smart, and <code>.jxl</code> has an okay ring to it.
But man, JPEG XL is a terrible name.

JPEG XL is a Stupid Name

Reflections and advice after making a few simple games in Bevy.

<h1 id="ecsfinally">ECS, Finally</h1>
As someone who's only ever been a casual game developer, diving into entity-component-system (ECS) programming proved more challenging than expected. I'd made some simple games with Unity (which is technically ECS), but usually I'd preferred to do my own thing from scratch which tended to drift towards an OOP style. Recently I've started falling in love with Rust, and stumbled upon <a href="https://bevyengine.org/learn/book/getting-started/">Bevy</a>, what seems to be the most mature Rust-based Game Engine.
Bevy has a lot of upside. It comes with a ton of built-in helpers for the things you need, but isn't annoyingly hand-holdy like Unity or Unreal. The community is filled with incredibly passionate and smart people, and it's young enough that an at-least-okay developer could probably contribute back. Plus it's Rust, which means fast and fun to write. The downside? It's all in on this ECS thing, which is a bit of a mindf*ck if you're not used to it.[^1]
<h2 id="howithoughtaboutgames">How I thought about games</h2>
Before I started making games in Bevy, I tended to structure games using one of two strategies:
#1: Spaghetti code
For simple games, this is a surprisingly good strategy. Your game has a player, enemies, and an environment? Great! Make a class for each, throw in some <code>update</code> and <code>render</code> functions, and start specializing. Make everything public so you can read and change it wherever, cook up some global state when you need it, and you're good.
This is a strategy which is very fun at the beginning because you can get a lot done in a short amount of time. Needless to say it becomes a nightmare as soon as you want to generalize (multiple levels, reuse logic in slightly different ways, complex hierarchies, etc.) It's probably a good time to mention that almost every game I've ever worked on never got finished, ending up in some kind of half-finished purgatory once I realized the central mechanic I thought would be fun is either boring or too hard to do as a side project. So, yeah, take this with a grain of salt.
#2: Parents, parents, parents
The more "rational" way I'd approach making games was to break everything into tiny bite-size pieces, and then have a ton of parent-child relationships. For example, a player is an object with health, a position, and a weapon; a weapon is either a gun or a sword and has a hitbox, which is a position and an animation which has a….. you get the gist.
Besides being intuitive, the best part about breaking up game objects and logic like this is that it usually forces you to think in a data-first way. When you make a new object, you're encouraged to think critically about all the data that thing is responsible for, and all the things it depends on as children. Especially compared to the spaghetti approach, this makes it possible to put development down for a week, come back, and have a reasonable chance of understanding things and making meaningful progress.
The downside (which I don't think I appreciated until I put on my ECS hat) is that it's actually not that generalizable. Even if you eat your vegetables and try to make reusable interfaces or base classes it still ends up being an prohibitive amount of boilerplate most times you want to add stuff.
Why? The biggest reason is that when you break things up like this in a top down way, it's hard to make reusable classes that actually work in all the places you'll need them too without a bunch of extra code. For example, consider hitboxes. You probably want the player to have a hitbox and you probably want the enemies to have hitboxes too. So you make a hitbox class, and it's great when you just have black boxes on the screen running into each other. But now let's say you add animations, and you realize when something gets hit it should probably update it's animation, and maybe die. And now all of a sudden your hitbox logic cares about how it's parent implemented animations and death. So maybe you add an option to pass in a callback to the hitbox that gets called whenever something gets hit, but then you have to duplicate the animation switching logic in both the player and the enemy even though they're basically doing the same thing. Or maybe you solve it by standardizing the methods that things with both hitboxes and animations have, but this is often tricky to do with "clean" OOP syntax and still probably means code dupe. So what do you do?
<h2 id="enterecs">Enter: ECS</h2>
After my time in Bevy, I think ECS (to a non-ECS person) can best be summed up in the following:
ECS means developing from the bottom up.
Looking back, I'm surprised that a lot of the resources I'd looked at to learn ECS from a mostly OOP background didn't phrase it this way.
<blockquote>
 An Aside: What are Entities, Components, and Systems?
 An entity is simply a collection of components with a given id. Entities are flexible, in that they can contain any arbitrary collection of components and don't need to be pre-typed. You can even add and remove components dynamically. Most ECS systems give you access to familiar things like fetching entities by id, deleting by id, attaching parent child relationships between entities, etc.
 A component is just data. In Bevy, it's just a struct. It has no obligation to provide any behavior (although it can implement whatever you want). It fits well with a data-first approach.
 A system is functionality that affects entities and components. Most systems will work in the following way:
 <ol>
 <li>Fetch all the entities with a specific component, or with a specific combination of components (for example, <code>Moveable</code> and <code>AABBPhysics</code>).</li>
 <li>Read, mutate, or whatever with these entities and components.</li>
 </ol>
</blockquote>
In both the spaghetti code and the parent-based approaches above, development is unmistakebly top down. Take the biggest, flashiest, most noticable parts of the final game that exists in your mind and break it down into smaller and smaller pieces until you reach something that's possible to code in a few hours.
ECS feels philisophically different. Start with the smallest possible state/behavior pair you care about and build up from there. For example, you probably want to make things that move. So you create a <code>Moveable</code> component that has a velocity vector. Then add in a system that every frame iterates through all the entities with <code>Moveable</code> component and nudge them according to the velocity. Voila!
Now what happens if you want to make a player that responds to input, can jump around, and is animated? Well you add in some more components, perhaps <code>AABBPhysics</code> so it gets collisions and gravity (and you could reuse for enemies), <code>Controllable</code>, and <code>Animated</code>. Each of these gets a corresponding system or two, and you're done.
Developing in this way doesn't force you to do things the right way. You can still occassionally make components that don't generalize and lead to refactors or bloat, find yourself with a bunch of systems which together feel like spaghetti. The point is: it's harder to trap yourself in these bad outcomes. It's a well-known saying that languages and frameworks are useful because they tell you what you can't (or shouldn't) do. ECS (and Bevy) feels the same.
<h2 id="performanceconsiderations">Performance Considerations</h2>
The other huge upside of ECS is that it's usually very, very fast. This is due to a couple factors:
Prefer Parallelization, Always
Say you have a bunch of systems which every frame operate on a bunch of data. It's very easy for the engine (in this case Bevy) to schedule systems that operate on separate data in parallel. You, the developer, probably don't need to think about parallelization at all, and yet you can rest easy knowing that the engine alone will probably find enough data parallelism to fully utilize all available cores.
It's worth noting that in some cases you have to explicitly order things (for example checking for collisions and applying physics before moving), but the default is to parallelize everything you can.
Compare this with what you might see in naive approaches:
<pre><code>void update() {
 checkForCollisions();
 for (player : players) {
 player.update();
 }
 for (projectile : projectiles) {
 projectile.update();
 }
 map.loadBoundaries();
 checkForDeath();
 checkForVictory();
 ...
}
</code></pre>
While it's clear that a lot of these things can be parallelized, that's not the default, and the burden falls on the programmer to notice that and structure their code to take advantage of it.
Flat Structure
ECS also tends to lead to a flat structure of gameobjects. That is, instead of having a scene where there is a top-level parent, which has an environment, which has a bunch of block children, each of the blocks exists and has it's own id at a "flat" level. This means that most times your accessing the data of blocks, you're not doing a bunch of pointer chasing which could lead to cache misses or other wonky behavior. This becomes especially important for complex scenes with lots of entities.
<h2 id="drawbacks">Drawbacks?</h2>
The biggest drawback I've experienced while using ECS vs. my own custom OOP engines is that it's often times harder to know where to start. When you're developing from the bottom up, it's harder to see what's the natural next component to implement. Decision paralysis is real, and if you try to overcome it by simply diving in and implementing "something", you'll probably find yourself in refactor hell further down the road.
All-in-all, this is not a bad problem to have and I'm sure it'll get better the more comfortable I get. The underlying problem here is less with the framework, and more with the ambiguity of the game itself.
[^1]: Many people would consider the emphasis on ECS another upside.

ECS, Finally

numcross.com is coming down, at least for a little while.

<h1 id="toourmanymanyusers">To Our Many, Many Users</h1>
It is with a heavy heart that today I must take down <a href="https://numcross.com">numcross.com</a>. Who would've guessed that a side project by a few college seniors would become an overnight hit with millions of users, spiraling completely out of our control?
I certainly wouldn't have. I would've guessed that like most side projects, we'd make it, improve it for a few months, force some of our friends to use it, complain that "the world simply isn't ready for it", get bored, move onto something else, and then begrugingly pay Amazon $70 a month for half a year until we decided it was time to take it down because we were too lazy to not use Docker.
But dear user, I must assure you that did not happen. You can imagine that with a jabillion DAUs, unimaginably high PMF, and a few other acronyms you haven't even heard of, numcross was simply too much for us to manage.
Hopefully this change isn't forever, but for the time being it's time to say goodbye. Thanks for all the memories.

Mark.md