Tag Info

New answers tagged

0

A possible solution is a ComponentManager class. This one is similar to a tuple of vectors in that it should keep a mapping of types to the index of each Component type vector. After that it all comes down to representing the components of an entity using indices to the appropriate vectors.


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 ...


2

If you are using a State Machine and are worried about it being modular and extensible, you can follow the Strategy Pattern using Interfaces to define the various states. This answer gives a fairly good idea of how to go about doing that. To make it even more extensible, you can drive the state transitions from a State Transition Table and populate that ...


1

Here's what I normally do with my states. It might not be the best way, or even the second best (but remember, the thing that matters is not the architecture of your game code, but the actual end result.). I start with a basic State-class (all code in Pseudo-C++): class State { virtual void Event(Event e); virtual void Update(float deltaTime); ...


3

Here is my suggestions Dealing with Trees You can do any tree by using tables. It can serve as dependency counter for what ever tree you are doing. Already tested by me some time ago were skill tree, knowledge tree and my favorite, item tree. For this example we are going to use "Item" tree. Each item will be a record for the table name ItemTree. They ...



Top 50 recent answers are included