small chambges

This commit is contained in:
Rowan 2024-12-20 09:48:29 -06:00
parent 4b70f9a931
commit f04f22a225

View file

@ -134,7 +134,7 @@ Depending on the engine and implementation, there may be a few options for solvi
An alternative solution would be to identify the behavior which raises events and isolate it into its own singleton. Doing this would allow it to easily be ordered before the damage handling system. We'll revisit this idea later. An alternative solution would be to identify the behavior which raises events and isolate it into its own singleton. Doing this would allow it to easily be ordered before the damage handling system. We'll revisit this idea later.
## The Offspring would be proud ## A Joke about The Offspring
Managing a game state as it grows in size and complexity is *difficult*. It's not uncommon for a game to have many thousands of active entities at a time. In many cases, it makes sense to decouple separate-but-related behaviors into their own systems to make them easier to manage. Managing a game state as it grows in size and complexity is *difficult*. It's not uncommon for a game to have many thousands of active entities at a time. In many cases, it makes sense to decouple separate-but-related behaviors into their own systems to make them easier to manage.
One such separation would be game logic and UI. Rather than directly coupling the player's health to the UI representation of the player's health, it makes sense to have them communicate via some type of messaging system. An event seems like a natural fit. One such separation would be game logic and UI. Rather than directly coupling the player's health to the UI representation of the player's health, it makes sense to have them communicate via some type of messaging system. An event seems like a natural fit.
@ -307,7 +307,7 @@ While these aren't *really* a separate concept from regular components, they're
One thing that I've deliberately not mentioned until now: ECS is usually *very* fast. I often see this touted as one of the main selling points of ECS. It's true that the performance is important to an application which is running anywhere from 60-144 times per second but I think there are *many* other benefits worth talking about. One thing that I've deliberately not mentioned until now: ECS is usually *very* fast. I often see this touted as one of the main selling points of ECS. It's true that the performance is important to an application which is running anywhere from 60-144 times per second but I think there are *many* other benefits worth talking about.
Many of the performance benefits of ECS are due to its overlap with data-oriented design concepts. One example of data-oriented design, parallel arrays, is a common implementation in many ECS frameworks. I'm *especially* not qualified to speak on this issue because I've very little exposure to the concept separate from using it via ECS in game development, so I'll let others explain it. Most of the performance benefits of ECS are due to its overlap with data-oriented design concepts. One example of data-oriented design, parallel arrays, is a common implementation in many ECS frameworks. I'm *especially* not qualified to speak on this issue because I've very little exposure to the concept separate from using it via ECS in game development, so I'll let others explain it.
## Revisiting our design problems ## Revisiting our design problems