24 Hours of Rust Game Development

While working through your experience with Rust, would you mind writing down (doesn't have to be more than a couple of words and maybe a code snippet) diagnostic errors that were hard to understand or that were misleading? That feedback is invaluable in making rustc friendlier.

This is why discipline is the one thing that differentiates developers that release something and those that don't.

It's easy to try something new all the time, but it is tough as nails to stay with something even in the many cases where it sucks and gets difficult. Finishing something is it's own reward though, so even though it's tough it's always worth it.

If I made a game though, it would likely be because I wanted to learn how an ECS works, or how to make an ECS, or how to make a game engine in general. Also I'd probably quit once the ECS was done but before anything was actually playable, because all the fun stuff (in my opinion) would be the technical plumbing and engine details, and not actually making anything creative with it.

As another example of this: I just bought a big DAW and a midi keyboard, and now obviously I'm stuck coding audio filters in Rust rather than making music.

I agree.

It's definitely fun to play with new programming languages and technologies. Using games as a medium to explore a new language is a great way to learn and have fun at the same time. That said, when a game development luminary like jblow takes the time to make a comment, it's good to think about why.

It seems to bother jblow that people are buying into the use of this system without thinking about the costs as well.

Its the same as the debate about when it is the right time to move to a distributed microservice architecture from a monolith. In this case, the use of an Entity Component Systems in a small game could be compared to the choice to use a Distributed Microservice Architecture for a small application.

Monolithic applications are easy to build and maintain by a small solo developer/shop, but they don't scale as well as you increase the number of engineers and expand the scope of the product. So a monolith is split into domain specific distributed microservices to allow for an increased number of developers working in parallel. When you pick to employ this tactic is up for debate.

Building a distributed system is hard. Debugging a distributed system without solid tooling/tracing is even harder. In the microservice world we have a lot of tooling to help us. Games, usually much less so. Where you might use GRPC in microservices and have stuff like OpenTracing to lean on, in games with Entity Component Systems you'll usually have some form of a message bus/event system without the same level of tooling and tracing.

Entity Component Systems/Distributed Systems are a useful pattern to implement when your desire is to build a reusable generic game engine/application to be implemented by large or scaling engineering teams. That's why you see these patterns employed and used by large game companies/startups and game engine/SaaS developers.

In summary, perhaps jblow's point is that small/solo developers can build a good game/application without employing the ECS/distributed microservice architecture pattern. And like you said, it's also useful to try building/using these patterns in toy applications to gain experience.

I have been using specs ECS in rust for about a year and a half now and I think rust + ECSs work really nicely together.

However, I started with a simple stupid solution you describe. Despite that, I quickly realized I was going to end up coding an ad-hoc version of an ECS if I keep trying to do my own thing.

For reference, I am making a sim game like dwarf fortress so it has been kind of nice, though I think in the fullness of time I will probably end up writing my own ECS to replace specs or start contributing stuff to it.

I have used unity and UE4's "ECS" and I could see how they get a bad wrap. They aren't very good ECS systems and because the engine uses this model it forces people to use it.

One of the big advantages of writing a game from "scratch" is you are not burdened by weird architectures that don't make sense so experimenting first before makes sense. I don't know if I agree that ECS never have a place in game programming.