Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Oct 2009
Offline Last Active Apr 09 2016 08:44 PM

Posts I've Made

In Topic: entity system questions

05 December 2015 - 01:16 AM

I'm having similar problems with figuring out how to implement special game events such as entering a specific sector playing a cut scene, or having gates bringing players to a completely new sector; should these 2 things be represented as an entity?


If your sector has a collider component, when new entities collide with it (aka enters the sector), the collision system informs other systems of said event.  Your CutSceneSystem may be interested in collisions between Sectors and Entities and if such a collision event is raised, it gets the current sector id/name, locates the cutscene files and begins their playback for the user experience.  In this case, its a combination of the Physics System and a Game System interacting by way of events/messages/callbacks.


As for gates taking players to new sectors, this again is basically a collider component in the ECS that raises a collision event that causes your SectorTeleportSystem to fire.  It begins by playing a wormhole warp cutscene sequence while the new sector is loaded from disk.  After loading is complete the cutscene sequence ends and you find yourself in the new sector.


As phil_t said, some systems can respond to game world events/triggers but are not necessarily manipulating entities.  The events/triggers they do react to however can very much be something that the entity component system triggered based on some component system that manages a particular game aspect.

In Topic: Need help with issues I encountered while writing my ECS

05 December 2015 - 01:00 AM

Also, I was wondering how you could make use of contiguous memory when a system makes use of sets of different types of components as this seems to be the case for most systems, especially if you slice the components into smaller pieces?


In complex situations where a system requires multiple components to perform it's job, I tend to side on the caching approach.  Basically the system uses the notification callback when entities are added, changed, or destroyed to manage an internal list, a list I prefer to call node list.  How and when you elect to transfer component data to the node list is entirely dependent on how the system must update in accordance with your game loop.  You may need to use a command pattern to delay the update until the system's update loop or it may be safe to immediately update the node list directly.


A render system for example may require a Transform and Renderable.  As entities are added, changed, or destroyed the render system maintains a list of RenderNode instances that basically cache the transform and renderable data from the components.  The render system's update loop uses the RenderNode list rather than the components themselves as the basis for it's update loop iteration to maximize on cache friendliness.


Nothing says a system must maintain a single node list either.  In fact, it really should be a system detail that dictates how many node lists it must maintain in order to efficiently perform it's update phase.  Multiple lists are often used to avoid if/else branch statements inside the loop which can be costly on cache friendliness.

In Topic: Entity Component System architecture for a 4X game

29 June 2015 - 10:50 PM

For now, it works. The problem is that all entities belongs to a global entityManager and I can't find a way to split them between several players entity (think of "empires", "races" or whatever). I have a gameInput system that gives order ("build a factory on this planet", "move this vessel"). But I can't see a clean way to restrict those order to a set of entities that would represent a player side. Thus, I have no way of telling if an entity belongs to a given empire.


I though I could have several entityManager, each one handling an empire's entities. Or having an "empire" component that would hold a list of entities belonging to this empire. But none of these solution appeals me.


An entity manager generally doesn't exist more than once, at least not within a given simulation.  So unless we're splitting hairs over terminology here, I certainly would not advocate for such a complex setup with multiple EntityManagers because, if those entities need to interact with entities of another EntityManager; you'll have a bit of work to make that happen.


I would split your problem into two layers.


First, create an empire system that acts as a broker for all entities that exist in a particular empire.  When an empire gets created, this system knows about it.  When an entity is spawned that has an empire component that references a specific empire, this system associates that entity to the given empire.  Any communication among entities within an empire could be funneled through this system since it's goal is to act as a broker.


Next, I would have another system that sits on top of the empire system that acts as a mapper between a Player and an empire or league of empires.  This way if you decide to allow a player to control multiple empires, this system can coordinate that and handles the relationship to a specific player instance. 


If you keep your system contracts clean, you should be able to change how an empire works without it impacting it's relationship to the player and vice versa.  


A little bit of abstraction can go a long way to keeping code clean, easy to maintain, but also allows to future growth in game concepts.  It's just important not to take it too far to the extreme.

In Topic: Implementing a quest/achievement system

12 April 2015 - 11:23 AM

How you interact with the information in-memory at run-time does not have to dictate how you need to serialize it.  For example, if you were using a database to store quest and achievement data, you would typically store that in a normalized manor across several tables.  During the start-up phase of your game, you would read your database and construct in-memory objects of this data that are designed for run-time efficiency. 

In Topic: Movement system low or high level in ecs design

07 January 2015 - 02:22 PM

What's with the EntityXY framework? I look at this, while implementing my framework, the system manager is greatly the same.


But my question to the post of crancran remains, could the message queue for moving the entities combined with an event manager which I need anyway?


The reason you find so many variants of an entity framework is because there is no standard practice.


As for the queue, you could implement a single or multiple queues depending on your needs.  Chances are a single queue would be sufficient as a starting point and build upon that idea long-term if you find you need to separate the queues for any particular reason.