I spent 2 years building my own game engine (Rust, WASM, WebGPU) | Hacker News Reader

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

legendofworlds.com

202 pointsupmind83 comments

> In conclusion, I have no regrets.

I'm also deep into making a Minecraft-like game with a custom engine in Rust with WebGPU. Having worked in dozens of languages, I've found Rust to be extremely productive for what I'm building. It's been great, and I have relatively few complaints.

There has yet to be a single successful minecraft-like game despite it being one of the most common projects for gamedev beginners. Seriously, spend time in a gamedev discord and see how often people talk about their voxel game.

So I'm curious what makes you and your game different. I think one of the traps here is minecraft-likes have fun algorithms so people get nerd-sniped on the technical side but the gameplay side and art are severely lacking.

What is the definition of “success” you're using here? It seems like a solo game dev could operate with their own unique definition of success since they don’t need to convince others to adopt their approach.

just because you don't know them, does not mean they don't exist

Wrong, Vintage Story is successful.

Define successful. Are the devs working on the game full-time?

Yes. It has an active player base that is growing daily.

That's not what I asked.

You asked them to define successful. You asked them a question. I see them answering the question and defining successful.

You are, by definition, 100% wrong.

You asked them to define successful, and they did (implicitly). The fact that you also provided your own arbitrary definition of successful seems largely irrelevant given that you asked them for their own, regardless of whether VS meets yours.

https://www.vintagestory.at/aboutus.html/

"The Team - The list of currently active game developers, part-time and full-time"

Doesn't say who's full-time, but it's a team of 14 with 3 programmers.

How are these 2 things related? Why do devs need to work on a game full time for it to be successful?

If that's your criteria for success then yes, there are many such games that are successful. Do you seriously think Minecraft is the only voxel game that can support its developers full-time?

Minecraft doesn't use voxels

I suppose it depends on what you mean by "uses", but it does store the map as voxels, even if it renders via a polygon mesh.

I agree. Any reasonable person would agree VS is successful.

Who says the author is looking for "success" the same way you seem to think. Perhaps just writing it for their own enjoyment, fun or learning is success enough?

After all, anyone who takes a look at the games and game engine market can quickly realize that the market is so over saturated with content that most people can't give their stuff away for free. In fact most people would have to pay people to have a look at their content/tool/game.

Correct, I'm building it for fun and the challenge and have learned quite a bit about performance in the process. I don't expect it to be a commercial success. It's also been quite good at getting the attention of potential employers, where they see that if I can make this, I can build something great for them too.

I'm in the middle of building out a custom entity system, and learning about the speed limitations of smart pointers, and to occasionally embrace unsafe Rust for the best performance at the cost of a bit of safety.

https://www.youtube.com/watch?v=eoPyClyO_QU

That looks great!!

Thanks for the compliment!

7 Days to Die is a minecraft-like game that has sold 18 million copies. As of this moment has 92,580 players playing which is 16th out of all games currently being plated on Steam.

Are you saying it's a minecraft-like because it's a survival game? Because 7 days to die does not look like a voxel game. How was that not obvious to you from this discussion?

> Because 7 days to die does not look like a voxel game.

Here: https://7daystodie.wiki.gg/wiki/Block

Speaking of successful voxel games, Space Engineers also seems to be well regarded: https://store.steampowered.com/app/244850/Space_Engineers/

I’d also put Empyrion up there, though it was a bit niche: https://store.steampowered.com/app/383120/Empyrion__Galactic...

Oh also definitely No Man’s Sky: https://store.steampowered.com/app/275850/No_Mans_Sky/

Here's a cool video on how they did things for that game: https://www.youtube.com/watch?v=sCRzxEEcO2Y

Also teardown!

> 7 days to die does not look like a voxel game

It is definitely a voxel game. Both games also share the same core gameplay loop of mining blocks of materials and using those materials to build other blocks elsewhere.

The wikipedia page for the game literally says "The game is voxel-based (similar in some aspects to Minecraft, but with smooth terrain)".

The fact it doesnt look like one proves your point wrong. There are many other places in the voxel game space which are as yet untapped.

No, I'm saying it's a minecraft-like because it's a voxel game.

> There has yet to be a single successful minecraft-like game

No? Off the top of my head, there's Teardown, which has sold over a million copies and has rave reviews.

And there's a lot more games that use voxel-tech but don't make it part of their core aesthetic, especially for terrain deformation/mining. Notable examples include No Man's Sky and Deep Rock Galactic.

Minecraft-likes are among one of the most successful game formulas.

Some examples:

No Man's Sky (survival, voxel, proc gen)

Astroneer (survival, voxel, proc gen)

Valheim (survival, proc gen)

Enshrouded (survival, voxel)

Terraria (survival, proc gen)

Like it or not there's a lot to be gained from learning how to make a Minecraft-like. Does making one guarantee success, NO, but same goes for any other type of game.

Of these, I'm familiar with Enshrouded. Although I suppose it's voxel based in a sense it's not really voxel-based like minecraft is. Like instead of displaying the voxels as is, the game interpolates them into smooth shapes. Also characters and placables are high-poly like you would expect from any other game rather than blocky like in minecraft.

The effect of this is that it's actually quite non-obvious that it's voxel based unless you pay careful attention.

I don't totally follow how this is relevant to the thread? If you make your own game engine, you can design it to display the voxels however you wish. It seems odd to dismiss Minecraft-like games as unsellable when many Minecraft-like games have sold very well by expanding on the gameplay and visuals. There is no reason why the developer in this article can't do the same.

There's also the fact that the map is fixed rather than procedurally generated, that there is a story with voice acting and plenty of lore scattered. To me the differences are large enough that I don't consider it minecraft-like. But I guess that's a matter of opinion.

No Man's Sky Astroneer, Enshrouded are not voxel games AFAICT. Of those, I've only played No Man's Sky, which I agree at some level is similar to Minecraft in gameplay

Astroneer is indeed a voxel game. With some trickery to make it appear differently.

They may not look it, but the underlying terrain is done with voxels. It's harder to notice because the voxels are smaller, and use techniques like marching cubes to render smooth looking angled surfaces.

Here's a GDC talk about No Man's Sky world generation:

https://youtu.be/sCRzxEEcO2Y?si=H0r5zPRfO1CCeZ_m

Voxels doesn't necessarily mean something looks blocky like Minecraft.

Yep, tons of games behind the scenes use it.

I used to read this guy over at procworld.blogspot.com (as I type this I'm not sure if it even works anymore) who developed a very nice Voxel engine he ended up eventually licensing to game studios like SOE named Voxel Farm which was intended to be in EverQuest Next.

It had tons of features way beyond a simple Minecraft clone. I was always blown away at what was possible and the tech behind it.

I think we have different definitions of Voxel

I don't think so?

They use voxels under the hood but still render smooth graphics with techniques like marching cubes.

I think you are underestimating voxels or don't understand how they are applied in modern game development.

If those aren't voxel games, neither is Minecraft.

That's like saying games don't use polygons or triangles to render because when you zoom in everything looks smooth / no triangles.

Minecraft already exists and has had over 10 years, hundreds of millions of dollars of development, and a broad modding community. You can't just displace it with a Minecraft clone.

Early builds of Deep Rock Galactic look extremely Minecraft-like. There are plenty of others depending on what you consider Minecraft features.

I’m curious what makes you think each and every snippet of code has to be monetized and turned into a product?

Minecraft doesn't use voxels

It absolutely does, as the definition of a voxel is, roughly, "a 3ormoreD regular grid of point-samples".

If it doesnt use voxels what does it use then?

I think the game Teardown is the golden child of voxel rendering in production video games. beautifully lit, fully destructible, and performant

Polygons. It renders the blocks using traditional polygons

Voxels are not a rendering technique. They are an internal representation of the game world as a set of points on a (usually) 3D grid, as opposed to a fully pre-rendered map. Voxels allow for destructibility and full reshaping of terrain, for instance.

Yup, makes perfect sense after thinking about it more.

There are quite a lot of successful voxel-based games; see https://voxel.wiki/wiki/projects/ for an incomplete list.

Most people think voxel means 'cube' or 'block', but really it just means "regularly spaced sample in a 3-or-more-D grid".

The voxel gamedev community tends to call Minecraft-y voxel games "bloxel"-based.

Kudos to the author. I think this stack will slowly acquire more and more market share as time goes on.

I'm also working on a Rust+WASM+WebGPU game from scratch. The process has been absolutely wonderful.

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't need Rust for a 2D game. It's overkill. There are already too many 2D engines.

[1] https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ

Rust is a great fit for 2D games with massive amount of particles. See Gnorp Apologue and https://gnorp.dev/news/10-Hats-And-Rust/

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.

For context, I recently completed a game on a team of 4 devs who were all relatively new to ECS for the last bevy game jam [1]

Initially, we struggled a bit with how much ceremony there seemed to be to make simple stuff like movement work within the paradigm of an ECS (entity component system) engine.

But by the end of the week I think i can safely speak for all of us when i say we came away impressed by how organized everything was - despite everyone working on different pieces at a frantic pace for a week.

One concrete example is a last minute addition of little text dialog popups over various entities in response to different events : enemy sighting a player, player respawning, reaching an objective, etc. This ended up being trivial once the system for picking which line to say was in place, largely thanks to ecs and bevy’s event system.

Now i wouldn’t want to go back to the gameObject / update function way of structuring things ecs and bevy actually really shine once you do cross a certain threshold of size/complexity - especially with multiple people working simultaneously.

That said i do agree with you on the generalized physics engine point - we decided early on that was overkill and we could write our own collision and movement much faster, with better game feel to boot.

[1] https://itch.io/jam/bevy-jam-5/rate/2824463

From the article:

> But of course, are we thinking about making a quick buck, or are we thinking about making quality games for the next 30 years?

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.

>The half-life of the software I work with is maybe 3-4 years, and during major projects many things get rewritten or replaced.

Games decay quickly. But Games engines ironically enough iterate much more slowly than many other types of software. You'd be surprised how much of UE5 still has UE 1 code at its base.

The main exceptions to that is the renderer, and even then: openGL still isn't out the door yet. you can work on maintaining the Vulkan/DX12 backend for decades to come. Thinking of the half life as the renderer instead of the entire engine makes this task much less daunting.

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 "gradiated" region around the light sources.

That or use a different form of compositing — something equivalent to "Lighten" or "Screen" (using standard paint-program parlance).

One gotcha that would bug me with Rust/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.

The abstraction libraries that are higher level than web_sys don't support transferable objects currently, so you'd have to write your web worker in web_sys directly to avoid needless data copying. It's pretty doable, and I've gotten started on a crate abstracting this part, but it's been a serious willpower blocker for me.

One thread is pretty limiting for any web app today. As soon as you want to do something interesting, you're blocking the main thread.

Two years is not much. I've worked on mine for over 4 years by now ;-)

https://github.com/ensisoft/detonator

Too bad there's no actual technical information about the authors engine.

It’s called toxoid. It’s here: https://github.com/toxoidengine/toxoid

Thanks for the link.

You both have very nice game engines.

"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."

Huh? Is there something I'm missing here? Does he think that object-oriented languages store a copy of behavior code for every instance of an object?

No, the key part is "component data of similar types"

What he means is that when using ECS, the data for all components of a particular type is contiguous. Say you want to update the physics, if all the physics data for all objects is in the same memory block you minimise cache misses when processing it

Without profiling, such statements carry little weight. In particular, for optimal performance unless you use data oriented design and structure using SoA vs AoS.

However for a 2d top-down game where you have extremely good culling and layering, it’s possible you might be IO and GPU bound than anything else.

Still, without profiling it’s hard to say.

Really great blog post!

When I first started game development, I was all-in on building my own engine.

Then I matured a bit, and found the wisdom in using someone else's engine.

Now that I've grown a bit more, I'm starting to see the appeal of building ones' own engine again. I feel like this blog post enumerates the reasons quite nicely, and I respect the approach.

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've lost track of how many years Planimeter has been working on our game engine. I guess over 8. https://github.com/Planimeter/game-engine-2d

Which games are built with it mow?

You don't get it. Building a game engine and building games are two separate hobbies. It would be like gardening and cooking. You may like both, or just one, or none.

Yeah but when you make a game, you have a game. Something you can share.

When you make yet another toy game engine, you've hopefully learned a lot, but what you have is a lot of dead code.

Like with the gardening and cooking example above!

You might be able to build a perfectly wonderful garden, but that doesn't mean you can use the vegetables you carefully cultivated in any meaningful way in your kitchen to cook a healthy and delicious meal if you can't cook at all (but you can still share the vegetables with your neighbors who might share their cooking with you)! :)

Learned a lot that gets you a paid position at an engine company that makes a lot more than 99.99% of indie games (probably makes more than a gameplay programmer too). "When in a gold rush, sell shovels".

2024: 17 new Rust game engines created, 3 new games made. :D

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/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.

In "the dark ages" as you put it, we didn't conflate the browser with the operating system.

Well, the dark ages of web browsers. But well, for casual users that would be playing games made with such engines, the browser might as well be the OS.

Yeah, we just broke out of the sandox and ran browser games with random Java and Flash we downloaded from strangers.

Y'know, the good old days.

Don't forget ActiveX!

Those 3d games were pretty standout amidst the Macromedia/Adobe/Shockwave/Flash platformers on Miniclip.

fwiw Chrome on Linux has no WebGPU support or hardware acceleration, so I often use Firefox for e.g. playing Ruffle content. The story is different on different platforms, and will slowly improve.

wgpu is the main rust crate for webgpu rendering, and it's what Firefox is using for it's experimental webgpu support. It's also enabled by default in Firefox nightly builds. I don't think it'll be long before it ships in stable.

wgpu and WebGPU aren't just for browsers. They can be used in native programs as well. They're primarily a way of unifying platform APIs to produce a portable graphics target.

Middleware engines are much better for that purpose than APIs limited by the constraints of targeting the Web browser.

In case you care about using the actual GPU capabilities, and not a 10 year old API.

Also, I think you are overestimating how many people will switch.

I installed the ublock lite and the web looks the same to me. Perhaps I'm not going to the right places, but not many ads are getting through to me.

Reply on news.ycombinator.com