Hacker News Reader

Comment by mcbrit | Hacker News Reader

From the first few sentences of the article:

"ECS meant that iteration was quick because adding new or modifying existing systems or game objects was easy, and performance gains were clear when saving and loading the Case Board."

and there's an accompanying screenshot with perhaps 20 objects on a case board.

I scanned through the rest of the article with one question in mind: what the hell? ECS is not a solution to putting 20 photos on a case board. You're pushing 100Ks or Ms of objects and need performance and are willing to suffer for performance = ECS. Not this.

So, despite world class developer, I did not find the article credible. The main cause of the lack of credibility is the author of the article did not anticipate the reader glancing at the case board and the ECS claim and saying: bullshit. Alternatively, they did anticipate the claim, and were told to ship the article anyways.

View on HN

The next section isn't better:

We built a new Voxel-Based Character Control that enables smooth navigation in cramped, complex and dynamic environments; it makes character movement more natural and fluid.

Fluid movement can be a problem, but "Voxel" is not what you did here, it's a marketing term. Maybe start with how a 2d collider for a 2d game should perhaps be a sphere smaller than the character (not a square, they get stuck on corners), and then say sth interesting about how you solved 3d. I am fairly certain that "voxel" isn't what happened, esp with the prior of "ECS".

ECS isn't just useful for performance. It's a better way to architect games and other sorts of software in a more data-oriented (rather than OOP oriented) way.

In much the same way that your run of the mill AbstractFactoryGeneratingFactoryGeneratorSingleton involves writing a bunch of not so useful code, and then someone comes along and "improves" it by changing that final Singleton to Dependency Injection:

ECS also has a lot of overhead. You almost certainly don't need ECS, and whatever you're writing would almost certainly be much simpler without ECS. Use ECS because it solves a serious problem that you have.

Edit: And my seriously downvoted point was putting objects on a "Case Board" does NOT justify an ECS; it's a problem with a /lot/ of good and good enough solutions. Were there any problems that needed an ECS, or did the article just want to say ECS (and voxel) because it's hip?

Having written Unity, Godot, Unity DOTs, Bevy, an obscure ECS engine called kivent, and even rolled a java engine from scratch at one point I somewhat disagree with this statement.

When people think of overhead, they might be thinking of the jankiness of Unity DOTs and it's lacklustre ECS integration with a preexisting editor designed for Unity's Gameobjects world.

The truth is, an engine built with ECS from the outset has ergonomics that go beyond merely writing better multithreaded code. It truly enforces composition over inheritance when done right. Overwatch is an example of a game written using ECS that generally doesn't have hundreds of thousands of entities bouncing around

Overwatch has networked gunplay and uses ECS to deal with that hard problem.

Cool. I get why ECS is used there. Hard problem, meet the formalism that I will use to think about you.

A case board is not a hard problem. Using composition or a functional style instead of OOP is not a hard problem, or at least not a hard problem that ECS solves.

I'm not sure that we're talking past each other now, but I did want to at least respond to your point about Overwatch and note that ECS is used to solve an actual, hard problem there.

(edit: ECS doesn't solve networked gunplay. but it could be part of a solution, and even as part of a solution ECS can totally justify why it's there, because again: hard problem.)

Reply on news.ycombinator.com