4 ms·

Meh. I'm working on a video game at the moment, and have read lots of advice like this. My old game engine experiments all used 'Entities' to describe objects

by 5hoom 15y ago

Meh. I'm working on a video game at the moment, and have read lots of advice like this. My old game engine experiments all used 'Entities' to describe objects in the game world, and these 'Entities' were created, deleted and invoked by an 'EntityManager' (kind of half factory & half controller). Every game tick, the EntityManager calls a 'tick' method on all the current game entities and facilitates communication between them. For the most part, all entities are created/destroyed at the same time (game-level loading/unloading). Trying to avoid architecture mistakes, I've come up with all sorts of tortured designs to do away with the concept of any kind of 'manager'. It is probably my inexperience with various design patterns, but all these alternatives were overly complicated and difficult to use. I would end up with a mess of objects & functors all needing pointers to each other & stepping on each others toes. It then occurred to me that my 'manager' was in fact mapped to the real-world concept of 'a manager', being someone/something that is given orders from upper-management (game-level data, user-input, etc.) 'hires' & then assigns tasks to 'workers', hands the results to upper management, then 'fires' the workers when they are not needed ;). The metaphor works. So I'm back to the 'manager' pattern and things are moving ahead quite nicely, even if some OO purists might frown. Should I call my 'EntityManager' 'EntityBoss'? Gets rid of the 'er' at least...

chipsy 15y ago
Similarly, my game has Managers for entities, collision components, and renderable components. With each one of these, I don't want to try to dump all of the data in one place where the access patterns become strained, I want them to be "managed" from afar, where there's an interface to easily query or update them.
- 5hoom 15y ago
  Yeah, from my own experience the 'manager' metaphor is just easier for understanding the flow of execution & adding-new-features/maintenance. Everything is in one place, and when the systems do need to communicate it is usually in pretty well defined ways (eg. physics manager ticks--> passes collision data to entity manager which ticks--> passes scene data to render manager which draws the screen, etc) I'll go with whatever pattern works best in the name of Just Getting Stuff Done (with my own limited brainpower).
wnight 15y ago
The entity boss part seems like it's just an array of objects you perform actions on. It's not a description of the goal of the object, it's an internals-level view of how it does it. Maybe there's another more fundamental behavior or dataset that would suggest a better name? Perhaps Scene or World, depending on the things the EntityManager was doing. If it's reloading them it's like a scene, if it's changing gravity it's more worldy...

by 5hoom 15y ago

chipsy 15y ago

Similarly, my game has Managers for entities, collision components, and renderable components. With each one of these, I don't want to try to dump all of the data in one place where the access patterns become strained, I want them to be "managed" from afar, where there's an interface to easily query or update them.

5hoom 15y ago
Yeah, from my own experience the 'manager' metaphor is just easier for understanding the flow of execution & adding-new-features/maintenance. Everything is in one place, and when the systems do need to communicate it is usually in pretty well defined ways (eg. physics manager ticks--> passes collision data to entity manager which ticks--> passes scene data to render manager which draws the screen, etc) I'll go with whatever pattern works best in the name of Just Getting Stuff Done (with my own limited brainpower).

wnight 15y ago

The entity boss part seems like it's just an array of objects you perform actions on. It's not a description of the goal of the object, it's an internals-level view of how it does it. Maybe there's another more fundamental behavior or dataset that would suggest a better name? Perhaps Scene or World, depending on the things the EntityManager was doing. If it's reloading them it's like a scene, if it's changing gravity it's more worldy...