Tag Info

New answers tagged

0

There isn't necessarily a reason to have all these action classes you are defining but instead have a component that represents specific state about a certain use case. So your movement component has a series of booleans that indicate forward, backward, left, right, etc. Now each game tick, you have system that inspects all movement components and sees ...


0

In our engine, the component class only manages the scene graph, dirty state management and notifying the root scene that the scene graph has changed.. components may implement IUpdatable and IRenderable as needed, and the root scene tracks any graph changes and maintains lists of updatable and renderable components to process during a frame update. This ...


0

Normally different sub-engines take care of ticking their associated components in game objects. For example your rendering engine ticks only the rendering components of game objects that are visible on the screen, while your AI/physics engine could tick what's on the screen + outside with some decreasing frequency based on the distance. You don't tick all ...


0

You are on the right track about keeping the HUD out of the ECS. HUDs and game screens in general benefit greatly from inheritance, as the flow of gameplay is essentially one tree where you can branch out in different paths or backtrack in a manner that makes sense to the player. I use a variation of state pattern, where However, the HudLayer and GameScene ...


0

It seems to me that you're mixing the visual representation with the logical representation of what you're trying to create. Lets discuss your two scenarios. Equipment Screen In this situation, I would simply have the Equipment UI be capable of querying the inventory system for the current player. This allows the inventory system and it's management to ...


1

Class coupling can occur when you have classes that work collaboratively to provide functionality that the classes alone couldn't otherwise. One way to avoid coupling is to abstract the coupling away into a layer above the classes in question. For example, remember that the classes you are talking about are part of a larger system called the Game Object ...


0

Another approach is to register your subsystems with the game object system. During registration, they provide component configuration parameters that identify what components must exist to consider an entity of interest during it's update pass. Now you simply create your entities and associate components to them. These entities by default are inactive ...


0

The approach I have taken in the past was to separate the behavior and the AI aspects into two systems much as you described. On the behavior side, you have a series of predefined aspects that can be chained together into a behavior tree like patrol, attack, threat detection, etc. The behavior tree describes how these behaviors interact, which has ...


1

Interfaces are probably the answer. Your ComponentManager, EntityManager, and SystemManager do not really need each other, they only need each other's types. But an object doesn't have to be a type definition. It can be merely an implementation of a type by fulfilling an interface. Your objects can serve their current roles, but they still can be removed ...



Top 50 recent answers are included