I spent 2 years building my own game engine (Rust, WASM, WebGPU)

&gt; In conclusion, I have no regrets.<p>I&#x27;m also deep into making a Minecraft-like game with a custom engine in Rust with WebGPU. Having worked in dozens of languages, I&#x27;ve found Rust to be extremely productive for what I&#x27;m building. It&#x27;s been great, and I have relatively few complaints.

Kudos to the author. I think this stack will slowly acquire more and more market share as time goes on.<p>I&#x27;m also working on a Rust+WASM+WebGPU game from scratch. The process has been absolutely wonderful.<p>The stack (or, more generally, game dev from scratch) touches so many important CS concepts: computer architecture and systems programming at the bottom, all the way up to extremely abstract programming language theory and front end web dev at the top. Add in networking and your own distribution platform (even a simple REST website) and you end up doing and learning more than you would in most CS programs.

As someone who really needs high-performance 3D from Rust [1], I wish more of the people who really want to build a game engine would focus on 3D. You don&#x27;t need Rust for a 2D game. It&#x27;s overkill. There are already too many 2D engines.<p>[1] <a href="https:&#x2F;&#x2F;video.hardlimit.com&#x2F;w&#x2F;7usCE3v2RrWK6nuoSr4NHJ" rel="nofollow">https:&#x2F;&#x2F;video.hardlimit.com&#x2F;w&#x2F;7usCE3v2RrWK6nuoSr4NHJ</a>

Does anybody have experience with component systems like the one used in the engine in large projects? I feel like they all work well with components like Position and Velocity, but for anything less genetic, when you need to control what updates, when, and in what order, it looks like a nightmare to use. I get the same vibes as when using a genetic physics engine for a game; you end up messing with mass, gravity and casting a ton of rays just to get the behaviour you want. Maybe in sandbox games the trade off is worth it.

From the article:<p>&gt; But of course, are we thinking about making a quick buck, or are we thinking about making quality games for the next 30 years?<p>I’m not in the games industry, but I don’t see this as a viable mindset anywhere in the consumer software industry. The half-life of the software I work with is maybe 3-4 years, and during major projects many things get rewritten or replaced.

Hopefully constructive criticism: the glow from the light sources bothers me because it washes out the player and background. The opposite would be preferable — darken all but a &quot;gradiated&quot; region around the light sources.<p>That or use a different form of compositing — something equivalent to &quot;Lighten&quot; or &quot;Screen&quot; (using standard paint-program parlance).

One gotcha that would bug me with Rust&#x2F;WASM today is concurrency in the browser. You only get one thread per WASM binary AFAIK, and the way to compute in the background is to use a web worker.<p>The abstraction libraries that are higher level than web_sys don&#x27;t support transferable objects currently, so you&#x27;d have to write your web worker in web_sys directly to avoid needless data copying. It&#x27;s pretty doable, and I&#x27;ve gotten started on a crate abstracting this part, but it&#x27;s been a serious willpower blocker for me.<p>One thread is pretty limiting for any web app today. As soon as you want to do something interesting, you&#x27;re blocking the main thread.

Two years is not much. I&#x27;ve worked on mine for over 4 years by now ;-)<p><a href="https:&#x2F;&#x2F;github.com&#x2F;ensisoft&#x2F;detonator">https:&#x2F;&#x2F;github.com&#x2F;ensisoft&#x2F;detonator</a><p>Too bad there&#x27;s no actual technical information about the authors engine.

&quot;One of the primary strengths of ECS is its cache efficiency, which is crucial when managing the simulation of thousands to millions of entities in a massive, open-world multiplayer environment. Unlike traditional object-oriented approaches where an object contains both data and methods, ECS separates data and behavior. This separation allows for component data of similar types to be stored contiguously in memory. When the game runs and needs to process these components, the CPU can efficiently load and process large blocks of component data with minimal cache misses. This translates to faster computation and smoother gameplay, which are essential for maintaining performance in large-scale multiplayer environments.&quot;<p>Huh? Is there something I&#x27;m missing here? Does he think that object-oriented languages store a copy of behavior code for every instance of an object?

Really great blog post!<p>When I first started game development, I was all-in on building my own engine.<p>Then I matured a bit, and found the wisdom in using someone else&#x27;s engine.<p>Now that I&#x27;ve grown a bit more, I&#x27;m starting to see the appeal of building ones&#x27; own engine again. I feel like this blog post enumerates the reasons quite nicely, and I respect the approach.<p>Kudos -- this looks great. :)

More appreciation should be given to flecs which is a brilliant main ECS written in pure C. It should be part of the title, esp since he ditched Rust Bevy, but sadly it has become uncool to mention C nowadays in the context of Rust.

I&#x27;ve lost track of how many years Planimeter has been working on our game engine. I guess over 8. <a href="https:&#x2F;&#x2F;github.com&#x2F;Planimeter&#x2F;game-engine-2d">https:&#x2F;&#x2F;github.com&#x2F;Planimeter&#x2F;game-engine-2d</a>

Which games are built with it mow?

awesome work! I have been trying to build something similar and originally built a basic prototype in pure JS and then converted to a react library but it became apparent that due to the extra performance cycles that it needs to be rewritten into wasm for the performance I want. I had a similar idea, community driven content and interchangeable packages for games and protocol specs around a common format that allows for scripting and assets to be simply loaded and changed much like a cartridge. glad to see others working on a similar idea! good luck!

Ironically Google is now beginning the first steps of forcing the bulk of Chrome&#x2F;ium users back to Firefox by removing the API ublock needs, Firefox which has no WebGPU support and renders WebGL as a stuttery mess, so all of this extensive work may have been for nothing. Back to the dark ages we go.