|
|
|
|
|
|
by zemo
1936 days ago
|
|
|
> the tendency to prioritize accessible fast iteration in early stages over performance and scalability well, I'm glad you're describing the way you see the tradeoffs, I just have a hard time seeing how hanging your hat on the ability to eek out every little bit of resource optimization at the expense of early iteration is a worthwhile tradeoff for the majority of gamedevs. Running the game at a worse framerate or render setting so that you can tune the gameplay early, get through many different gameplay design iterations, and get the artists and sound people working sooner seems like it would be of value to more teams than something highly performant that makes it harder to experiment and iterate. (on the ECS vs inheritance point I'm in agreement.) |
|
|
The origins of ECS are in the work of Scott Bilas and Adam Martin, who weren't seeking performance improvements, but rather a way to allow non-technical teammates to iterate faster. This thing was revolutionary in the late 90s/early 2000s because suddenly you didn't need an army of increasingly expensive programmers just to get simple things done.
The performance boost was discovered much later when people found out that ECS could naturally benefit from data-oriented design. Performance is a nice-to-have but is far from being the raison d'être of ECS. It still makes sense to to have ECS or EC (or even just non-inheritance-component-based, like Unity) without the performance advantages of data-oriented design.