3 ms·

Since engine is targetting pixel art, isn't ECS a bit of an overkill...? And yes, technically artstyle has nothing to do with game architecture. But in practi

by Xeamek 3y ago

Since engine is targetting pixel art, isn't ECS a bit of an overkill...? And yes, technically artstyle has nothing to do with game architecture. But in practice, most games of this style are pretty small, and thus don't really have any real performance requirements, so ecs'ing everything is overengineering compared to oop-style, coupled architecture, no? Also related: https://youtu.be/JxI3Eu5DPwE https://youtu.be/JxI3Eu5DPwE

TillE 3y ago
Hugely popular little indie game Vampire Survivors, for example, requires some thoughtful optimization to have a zillion objects on screen without lagging to death. ECS isn't the only answer, but it is a valid one.
- ElectricalUnion 3y ago
  I think Factorio is a better example; items still exist when you don't see them on the map, and assuming you have a somewhat optimized base the performance is very acceptable until you are around 383k items/s being created and destroyed (50kSPM in the in-game parlance).
  - Xeamek 3y ago
    >Items still exist when you don't see them I was always wondering about that: Do they have to? Couldn't you come up with some chunking based system where the game only monitors the 'inputs' for given area and as long as those are stable, skip simulating entire chunk and only generate the output?
    - ElectricalUnion 3y ago
      That would imply that you need to somewhat have: * a mechanism to constantly evaluate whenever a active chunk is worth promoting to a "hibernated" chunk, with its overhead and; * a very steady state factory chunk. But endgame steady state factories already overperform your average factory by a lot in the first place. It is the chaotic state non-endgame factories that currently need optimizations the most. And it is speficially them that don't reach steady state; one small moment of instability in the inputs and you need to start evaluating the state of your entire factory again. I think that clustorio or the next expansion approach, where you have several "surface" maps that each have well defined limited I/O interfaces "chest or spaceships", in a way that you could split off the massive state of the game into a cluster of smaller servers is the way to go.
mattgreenrocks 3y ago
I find ECS easier to think about and use. It’s effectively controlled mutation.
skitter 3y ago
One of the commonly mentioned performance advantages of ECSs is the structure of arrays style, which Murder isn't using, so I'm guessing that they're using ECS less for performance reasons and more because they favor the programming style.
ElectricalUnion 3y ago
> But in practice, most games of this style are pretty small, and thus don't really have any real performance requirements, so ecs'ing everything is overengineering compared to oop-style, coupled architecture, no? I would call out that "performance requirements" those days aren't just "it runs smooth enough for me". It's also about "it doesn't waste all my game device battery". I appreciate when you can run games for 7 hours instead of 2 hours on a mobile device. More that pure CPU/GPU use, the main battery life villain for your average software is horrible memory access patterns. Doing logic or math (even including FP math) is basically energy free compared to fetching data from DRAM or SRAM.

by Xeamek 3y ago

TillE 3y ago

Hugely popular little indie game Vampire Survivors, for example, requires some thoughtful optimization to have a zillion objects on screen without lagging to death. ECS isn't the only answer, but it is a valid one.

ElectricalUnion 3y ago
I think Factorio is a better example; items still exist when you don't see them on the map, and assuming you have a somewhat optimized base the performance is very acceptable until you are around 383k items/s being created and destroyed (50kSPM in the in-game parlance).
- Xeamek 3y ago
  >Items still exist when you don't see them I was always wondering about that: Do they have to? Couldn't you come up with some chunking based system where the game only monitors the 'inputs' for given area and as long as those are stable, skip simulating entire chunk and only generate the output?
  - ElectricalUnion 3y ago
    That would imply that you need to somewhat have: * a mechanism to constantly evaluate whenever a active chunk is worth promoting to a "hibernated" chunk, with its overhead and; * a very steady state factory chunk. But endgame steady state factories already overperform your average factory by a lot in the first place. It is the chaotic state non-endgame factories that currently need optimizations the most. And it is speficially them that don't reach steady state; one small moment of instability in the inputs and you need to start evaluating the state of your entire factory again. I think that clustorio or the next expansion approach, where you have several "surface" maps that each have well defined limited I/O interfaces "chest or spaceships", in a way that you could split off the massive state of the game into a cluster of smaller servers is the way to go.

mattgreenrocks 3y ago

I find ECS easier to think about and use. It’s effectively controlled mutation.

skitter 3y ago

One of the commonly mentioned performance advantages of ECSs is the structure of arrays style, which Murder isn't using, so I'm guessing that they're using ECS less for performance reasons and more because they favor the programming style.

ElectricalUnion 3y ago

> But in practice, most games of this style are pretty small, and thus don't really have any real performance requirements, so ecs'ing everything is overengineering compared to oop-style, coupled architecture, no? I would call out that "performance requirements" those days aren't just "it runs smooth enough for me". It's also about "it doesn't waste all my game device battery". I appreciate when you can run games for 7 hours instead of 2 hours on a mobile device. More that pure CPU/GPU use, the main battery life villain for your average software is horrible memory access patterns. Doing logic or math (even including FP math) is basically energy free compared to fetching data from DRAM or SRAM.