I've recently been reading the book Game Programming Patterns by Bob Nystrom, and one chapter I've found a bit hard to grip is the chapter about the Component pattern.
In the example he uses (which you can find by clicking the link) to demonstrate the pattern, he starts with a class for the playable character that contains render logic, input logic and physics logic all together. He then shows how you can pull each domain of logic into its own component class and thus completely ditch the playable character class and just have a general "component bag" in the shape of an Entity
class.
Really impressed with how brilliant this pattern is, I fired up my code editor and started to incorporate the pattern into the little game engine library I've been working on while learning game development. After making a few little simple games trying to use this pattern, there are some problems and questions that keep appearing when I design the game logic around components.
Should the game engine be completely built around entities?
Often when I read articles explaining the pattern, they start off by showing a messy game loop that manually updates and renders every object in the game, to then slowly transform it into an ECS-based game engine. What confuses me is how they make it seem like the entire game will just consist of a bunch of game entities. Surely that's not the case? A lot of systems in a game that needs to be updated are things that are not rendered and don't need any input, they simply need a call to their update
function every frame. They don't have any physical representation in the game world, they are just things the game is keeping tabs on and changing. How are those systems supposed to work in an ECS-system? Are they supposed to be made into entities? If not, how will the game engine handle them?
Should all logic and behavior for an entity be put into its components?
Let's say we want the playable character to have an inventory for items he collects. In what component would you put the logic for that inventory? None of the components in the example from the book seem appropriate for something like that. Or should the inventory be kept in some static class along with other player stats and data, that the entity then reports to? In that case, how would you design an inventory system for NPCs? Given how complex systems connected to entities can be, I don't understand how you design them around a "component bag"-class.
Thanks in advance!