Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Oct 2005
Offline Last Active Today, 01:45 AM

Posts I've Made

In Topic: Getting gameObject components to process in systems...

13 October 2016 - 05:32 AM

Ahh, so so by default, it will have to loop over every GameObject weather or not it has or needs to update the component or not. I guess this is were ECS comes in? Ensuring the entities are processed in an efficient way.

This is not special to ECS. Look at discussions where people argue that the over-powered scene graph is a wrong approach.


The different sub-systems run different algorithms on the data (from components in this case). The algorithms usually work hand in hand with the structure how the data is stored. Hence it is natural that each sub-system manages its own structure(s) of data. Consequently, having all components in a single structure as provided by the GameObjectManager and the entity's component map cannot be suitable for all sub-systems.


That is true, I will probably split it to TransformComponent and PlacementComponent to make that obvious, thanks for that!

Not exactly what I meant. What meaning would the TransformCompnent have?


To explain my question:


Having a PlacementComponent (regardless of its name) means that at any time there is one position and rotation belonging to the object. When the collision sub-system runs it uses this placement; when the rendering sub-system runs it uses this placement. It is like a variable, read by those sub-systems, and hence with static value. Just when other sub-systems come into play, like e.g. AnimationSubsystem or CollisionResolverSubsystem or MovementSubsystem, there are activities to change the placement's value.


With this in mind, having a TransformComponent besides a PlacementComponent brings up the question which sub-system and how the component is used at all.


I do not quite understand what you mean by this? So each loop, i would call PlayerControllerSystem.update() and AiAgentControllerSystem.update(), and they in turn would call the 'lower' MovementSystem.update()?


Not really. Consider that the game loop is a prescription in which order things should happen.E.g. fFirst input is processed. Then player control is run, then AI, then animation and movement, then collision detection and resolution, then perhaps animation and movement again, then rendering. So, letting the player control invoke movement update would disturb this order.


Instead think of the PlayerController (or AI) to set variables, and of the motion sub-system to read these variables and act accordingly. This lets the PlayerController instruct the MotionSubsystem. The PlayerController actually does not need to know that a MotionSubsystem exists, because it deals with a set of variables.


Then later during processing the game loop, the MotionSubsystem's update is invoked from the game loop, and the MotionSubsystem does whatever the variables tell it.

In Topic: Getting gameObject components to process in systems...

09 October 2016 - 03:31 AM

It is okay to pass a pointer to the pool of game objects (here given by the GameObjectManager). At some point there must be an interrelation between systems. And it is also okay to name that class GameObjectManager when it actually manages game objects.



However, I see other problems.


a) When each system fetches components at update time, it has no chance of managing belonging components itself in a way that is meaningful and efficient in the context of the respective sub-system, because the overall architecture prescribes how the components are stored.


b) The fact that a game object has a TransformComponent instance means that it has a spatial placement in the scene. It does not necessarily mean that it is able to move. Using a MovementSystem is one of several possibilities to alter the content of a TransformComponent. So the MovementSystem should not act on a game object just because it has a TransformComponent. (I personally use the class name "PlacementComponent" to make this clear.)


c) The player's game object is something special, of course. However, its movement is usually not, so that MovementSystem should not make a difference between the player's game object and an NPC game object.



To overcome these problems, think e.g. of the following approach:


A) There is a pool of game objects that should be added to the scene at the next opportunity. There is also a pool of game objects that should be removed from the scene at the next opportunity. It can be understood as a service of the game object management. Potentially any system located anywhere in the game loop can cause game object creation by adding a kind of job description "add game object of class X" to the belonging pool (analog for game removal). The said "opportunity to add/remove game objects" to the scene is somewhere at the very beginning of the game loop, at least before any scene related sub-system has done its update. It is nothing than the update() of the game management service. At this point the service will notify all linked sub-systems, and each of them can investigate the pools and manage their internal operational resources accordingly. So each sub-system can drive its own management structure as needed, e.g. holding pointers to all components of type Y and ignoring any game object that doesn't provide Y.


B) Sub-systems need not be all at the same level. It is more like a layered architecture, so that sub-systems on a higher layer may utilize sub-systems on a lower layer. So a MovementSystem is on a more lower layer. For example, a character is mainly controlled by the fact that a PlayerController component or AiAgentComponent is added. The sub-systems running such components may then instruct the MovementSystem when and how to handle the belonging TransformComponent data.

In Topic: Is this practical for a resource manager?

14 September 2016 - 01:06 AM

Just for information: The "generally recommended" implementation of resource management, as crystallized from the many discussions here on GDnet, coarsely looks as follows.  (We speak of assets here, not of operational resources, don't we?)


a) There is an own manager for each kind of resource.


b) Management is not done monolithic in a single object. Instead, the ResourceManager is a front-end that co-ordinates a couple of collaborators. Have a look at the facade software pattern for an introduction of this scheme.


c) One collaborator behind the facade is responsible for caching. It is e.g. derived from a HashMap, using the resource identifier as key and the resource as value. Because it is an own object, storing the resources can be done in a resource type specific way, giving the ability for optimizations.


d) Another collaborator is the resource loader. Its job is to read resources from mass storage when being instructed to do so.


e) The manager is *ever* the owner of a loaded resource. A client that wants to use a resource *ever* requests the belonging manager for the resource, and *never* frees it after getting access.


f) If the manager is requested for a resource, it looks up the resource in the cache and returns it if found; otherwise it calls the loader to load the resource from mass storage, puts the result into the cache and returns it.


g) It may also be favorable to have a resource factory per resource type as a collaborator. If needed by the game, the manager can provide public access to a factory so that clients can generate resources on the fly, e.g. for dynamic content creation. In this case I'd suggest factory functions within the manager's interface.


h) Do *not* use static objects as resource manager. The managers should be accessible from what Sean Middleditch calls "spaces", referred to from game levels. This allows resource groups to be separated and freed in blocks / at once.


i) Resources need not necessarily be derived from a common base class, but I also don't see it as to be avoided obsessively.

In Topic: Reading multiple datagrams from UDP socket

27 August 2016 - 04:28 AM

UDP is about datagrams. It has no conception above that, especially not how to concat datagrams nor how to distinguish them after concatenation. 


However, it is not clear to me *why* you want to do so. What does "all the messages" mean exactly? A sequence of messages from the same source? A soap of messages from different sources? What should happen if one of them is missed on transmission? Such questions need to be handled as well.


IMHO we're speaking of stuff belonging to the application protocol layer!?

In Topic: What's a room?

21 August 2016 - 10:50 AM

A room as a compound (not necessarily an entity as in an ECS) may have


* a NavigationComponent instance (navigation graph or mesh), to be installed with the NavigationServices;


* a set of ColliderComponent instances, perhaps tagged for specific usages, to be installed with the CollisionServices;


* a set of PortalComponent instances (of the entree or exit kind, interconnecting rooms inclusive positional mapping), to be installed with the NavigationServices, used as another level of navigation;


* perhaps a LocationComponent that gives the room a name, a location on a map, or such a thing


* ...


Not a RoomComponent makes the entity a room, but the collection of more generic components. We are not speaking of a strict and explicit typing here, but of a kind of duck typing.