5 ms·

The fact the the original code is a straw-man is discussed. The fact the flexibility is being removed is discussed too, along with why it was there and hits on

The fact the the original code is a straw-man is discussed. The fact the flexibility is being removed is discussed too, along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up. You need to work on your speed reading skills before throwing shade...

SolarNet 8y ago
> The fact the the original code is a straw-man is discussed. Yes, but instead of timing it against the improvements the grand-author made to the straw man, you still timed it against his straw man. So I'll quote you: "You need to work on your speed reading skills before throwing shade..." > The fact the flexibility is being removed is discussed too You state: "Why do these frameworks exist then? Well to be fair, they enable dynamic, runtime composition. Instead of GameObject types being hard-coded, they can be loaded from data files. This is great to allow game/level designers to create their own kinds of objects... However, in most game projects, you have a very small number of designers on a project and a literal army of programmers, so I would argue it's not a key feature." Which is failing to recognize that the whole point of the original code - written by a game engine developer - is to demonstrate exactly how to do this for performance and flexibility for any small team. > along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up. With out it being there, I cannot judge it. But considering that you removed features and barely managed to match the ECS for performance is... not promising. The point of the ECS is to be a very efficient solution to the run-time composition problem. You removed run-time composition and still weren't technically able to be more performant than it with your solution. You are comparing apples to oranges and still loosing on arguably the most key aspect of the entire problem space!
- Hodgman 8y ago
  Calm your titties my dude, you're angrier than me, here... You're still missing my point, claiming I'm making points I'm not, and insulting me for it. Grab a handful of good faith, please. I timed it against the bad starting point because that's what Aras did too when showing that "ECS beats OOP by 10x". My version wasn't designed to be optimised - it was designed to be a simple rule abiding OOP rewrite. The point of the blog was about the annoying ECS evangelism trope of comparing ECS to bad OOP code and showing massive wins - the simple rewrite shows that the optimised ECS version is like a 1.03x win, not a 10x win. The fixes that Aras makes to the starting straw-man code help perf, yes, but they fly in the face of idiomatic C++ and are still bad OOP. Still, I can update the graph is perf resufrom each of Aras's commits if it makes you happy. Run time composition is(will be) added in the next version in a way doesn't add any performance overheads at all (a benefit of using composition properly that the straw man code lacks). There's no need for bloated frameworks to achieve this. BTW I'm also an engine dev, previously at a 400 person company, and now indie for a small team. I'm familiar with many kinds of entity frameworks... Making a game without one is perfectly valid. Many of the big commercial games that I've worked on didn't have one at all (just normal/good code)... The particular ECS implementation from Aras (again its bad due to it being learning material, not a real project) has lots of holes too. The memory usage is atrocious due to it allocating one component per entity regardless of need, but he presents a memory-usage win against his straw man OOP version! His example framework also has silly restrictions on composition, such as a limit of one component per entity. This kind of stuff doesn't fly outside of toy game projects.
  - dang 8y ago
    Welcome to HN! (I'm a moderator here.) Please stick to civil, substantive comments, regardless of how wrong someone else is (or you feel they are). Swipes like "calm your titties" (or even telling people to "work on their reading skills", as you did upthread) are the sort of thing we ban accounts for. We're trying hard to prevent this place from sinking into a toxic swamp, as so much of the internet has become. Doom is probably inevitable in the long run, but we're still hoping to stave it off for a while. If you'd please read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here, we'd appreciate it.

SolarNet 8y ago

> The fact the the original code is a straw-man is discussed. Yes, but instead of timing it against the improvements the grand-author made to the straw man, you still timed it against his straw man. So I'll quote you: "You need to work on your speed reading skills before throwing shade..." > The fact the flexibility is being removed is discussed too You state: "Why do these frameworks exist then? Well to be fair, they enable dynamic, runtime composition. Instead of GameObject types being hard-coded, they can be loaded from data files. This is great to allow game/level designers to create their own kinds of objects... However, in most game projects, you have a very small number of designers on a project and a literal army of programmers, so I would argue it's not a key feature." Which is failing to recognize that the whole point of the original code - written by a game engine developer - is to demonstrate exactly how to do this for performance and flexibility for any small team. > along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up. With out it being there, I cannot judge it. But considering that you removed features and barely managed to match the ECS for performance is... not promising. The point of the ECS is to be a very efficient solution to the run-time composition problem. You removed run-time composition and still weren't technically able to be more performant than it with your solution. You are comparing apples to oranges and still loosing on arguably the most key aspect of the entire problem space!

Hodgman 8y ago
Calm your titties my dude, you're angrier than me, here... You're still missing my point, claiming I'm making points I'm not, and insulting me for it. Grab a handful of good faith, please. I timed it against the bad starting point because that's what Aras did too when showing that "ECS beats OOP by 10x". My version wasn't designed to be optimised - it was designed to be a simple rule abiding OOP rewrite. The point of the blog was about the annoying ECS evangelism trope of comparing ECS to bad OOP code and showing massive wins - the simple rewrite shows that the optimised ECS version is like a 1.03x win, not a 10x win. The fixes that Aras makes to the starting straw-man code help perf, yes, but they fly in the face of idiomatic C++ and are still bad OOP. Still, I can update the graph is perf resufrom each of Aras's commits if it makes you happy. Run time composition is(will be) added in the next version in a way doesn't add any performance overheads at all (a benefit of using composition properly that the straw man code lacks). There's no need for bloated frameworks to achieve this. BTW I'm also an engine dev, previously at a 400 person company, and now indie for a small team. I'm familiar with many kinds of entity frameworks... Making a game without one is perfectly valid. Many of the big commercial games that I've worked on didn't have one at all (just normal/good code)... The particular ECS implementation from Aras (again its bad due to it being learning material, not a real project) has lots of holes too. The memory usage is atrocious due to it allocating one component per entity regardless of need, but he presents a memory-usage win against his straw man OOP version! His example framework also has silly restrictions on composition, such as a limit of one component per entity. This kind of stuff doesn't fly outside of toy game projects.
- dang 8y ago
  Welcome to HN! (I'm a moderator here.) Please stick to civil, substantive comments, regardless of how wrong someone else is (or you feel they are). Swipes like "calm your titties" (or even telling people to "work on their reading skills", as you did upthread) are the sort of thing we ban accounts for. We're trying hard to prevent this place from sinking into a toxic swamp, as so much of the internet has become. Doom is probably inevitable in the long run, but we're still hoping to stave it off for a while. If you'd please read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here, we'd appreciate it.