Jump to content
  • Advertisement

DapperCam

Member
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

147 Neutral

About DapperCam

  • Rank
    Newbie
  1.   What about entities that don't have a position component? Do you mean keeping the identifiers of the entities that do have a position component in a separate data structure outside of the entity component system pattern?
  2. I've read all of the responses/articles/source posted in this thread and it's been very helpful. I didn't even know there was a such thing as a CPU cache until yesterday (I develop business apps in managed languages). It's clear to me that no matter which design you choose, it's important to keep homogeneous data packed tightly in arrays that are looped over to apply game logic. Thanks to everyone who responded!   I also posted this thread to reddit yesterday: http://www.reddit.com/r/gamedev/comments/31c4ik/how_should_systems_pick_which_entities_to_process/ This excellent article was posted by its author that was very informative: http://t-machine.org/index.php/2014/03/08/data-structures-for-entity-systems-contiguous-memory/
  3. I'm seeing some comments in this thread suggesting that like components should be in an array (and not stored on the entity that they "belong to"), so that they will be laid out sequentially in memory to take advantage of spatial locality when they are processed each game loop. Is this a premature optimization, or is this an important design decision to make? If the data is stored in component objects, will it make a difference anyway (won't the references to those objects be stored sequentially, and not the actual data)?   If I'm planning on this engine to be used primarily for mobile platforms does this matter more, or less (I know in Java, you are kind of at the mercy of the JVM for stuff like this, objective-c, I'm not sure)?   I'm a noobie game developer, so how important is being "cache-friendly," and should it affect how I implement my entity-component-system engine?   EDIT: If anybody is interested, I found an older thread with a similar topic (the thread starter uses method #1 from OP). Similar answers are given there before the thread goes a bit off topic: http://www.gamedev.net/topic/617256-component-entity-model-without-rtti/
  4. Hey Josh,   Thanks so much for replying! I believe I understand what you're saying.   What if there is a component that is used by several systems, but doesn't necessarily belong to any particular system. Like, say for instance there is a PositionComponent that is used by the PhysicsSystem, RenderSystem, AiSystem, ControllerSystem, etc.  You suggest placing components on the system, and then having systems communicate to get components that belong to other systems. Which system would you place the PositionComponent in, in this case?
  5. Hey all,     I'm writing a basic 2d isometric tile-based game engine, and trying to follow the entity component system design pattern. My understanding is that Entities are generic containers that contain Components. Components are the different types of data that you associate with that entity. Systems are the game logic, and loop through entities that have the correct combination of components that the system needs to process. So, my question is: How do these systems pick which entities have the correct combination of components? I can think of a few ways, that I'll suggest below in pseudocode, but I was wondering how other people do it.     #1: Each system loops through all of the entities in the game, and explicitly checks if they contain the correct components.   http://vasir.net/blog/game-development/how-to-build-entity-component-system-in-javascript ("System" section)   function RenderSystem.process(entityList) {       // Loops through all entities (maybe inefficient if there are a lot of entities in the world?)       foreach(entity in entityList) {           if (entity.componentList.contains('PositionComponent') && entity.componentList.contains('SpriteComponent')   {               graphicsContext.render(                   entity.componentList['PositionComponent'].x,                   entity.componentList['PositionComponent'].y,                   entity.componentList['SpriteComponent'].image               );           }       }   }   #2: Have some sort of bitmap that represents the components an entity can have. Each bit position represents a component type.   http://gamedev.stackexchange.com/questions/31473/role-of-systems-in-entity-systems-architecture/31491#31491   function RenderSystem.process(entityList) {    // Loops through all entities (maybe inefficient if there are a lot of entities in the world?)       foreach(entity in entityList) {           // Let's say that position 1 and 3 represent the position and sprite components.           if ((entity.componentBitMap & '1010') == '1010') {               graphicsContext.render(                 entity.componentList['PositionComponent'].x,                  entity.componentList['PositionComponent'].y,                  entity.componentList['SpriteComponent'].image             );         }     } }     #3: Have strongly typed "Nodes" that represent collections of components. http://shaun.boyblack.co.za/blog/2012/08/04/games-and-entity-systems/ ("Nodes and Systems" section)   class RenderNode {     public PositionComponent position;     public SpriteComponent sprite; } function RenderSystem.process(renderNodeList) {     // Loops through all nodes that have been added to some linked list of nodes.     foreach(node in renderNodeList) {         graphicsContext.render(             node.position.x,              node.position.y,              node.sprite.image         );     } }     #4: Have separate hash maps of components where the entity that they belong to has it's id as the key. Do an intersection on the hash maps required by the system, and only process those entities whose id was in all required component hash maps. I have seen some posts alluding to this sort of approach, but I haven't seen any articles or tutorials implementing it.   function RenderSystem.process(entityList, componentManager) {     // Get the set of entityIds that we want to process by intersecting the required component hash maps     entityIdList = componentManager['PositionComponent'].keys.intersect(componentManager['SpriteComponent'].keys);     foreach(entityId in entityIdList) {         graphicsContext.render(             componentManager['PositionComponent'][entityId].x,              componentManager['PositionComponent'][entityId].y,              componentManager['SpriteComponent'][entityId].image         );     } }     Some notes: #1 through #3 have components on the entity object itself, while #4 has components stored in a separate data structure.   #3 would require some sort of registration with other data structures upon entity creation. This would have some overhead when attaching components dynamically at run time (for example, what happens if your character gets frozen by an ice monster and can no longer move, and you want to remove its "MovementComponent," you'll have to find all of the nodeLists that have movement components as one of their properties, and remove the entity from the list). #3 allows the system to just process the required components. No need for filtering entities, or performing intersections on lists of components. By increasing overhead in attaching components to entities at run time, you've decreased the overhead of filtering within the system processing. #3 allows for strongly typed collections of components. My pseudocode above is for a system that is dynamically typed, but in a static language, I would have to explicitly cast the components before accessing their properties. For example... entity.componentList['PositionComponent'].x  ...would become...   (PositionComponent)(entity.componentList['PositionComponent']).x ...because componentList would just contain IComponent or something like that. It wouldn't know about x.  
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!