13
First, I wouldn't say that in this case you are optimising too early, depending on your use case. In any case though, you've asked an interesting question and as I have experience with this myself, I'll weigh in. I'll try to just explain how I ended up doing things and what I found on the way.
Each entity holds a vector of generic component handles which ...
10
The simple version: don't.
One could argue that you have perhaps a slight misunderstandings about how to build an ECS (why would you sent a list of Entity* to a system to update? the System is supposed to have its own self-contained collection of the components it cares about, and the global entity list should barely ever even be used... a "true" ECS doesn'...
9
For a simple start you can implement steering behaviors. Specifically seek behaviors.
In addition to seeking the characters should use avoidance to steer away from obstacles.
Once you have those aspects working, you can implement some more intelligent following. That would include path finding. Now instead of steering towards their foes, enemies will ...
5
To answer just this:
My question is, since I am not iterating linearly one contiguous array
at a time in these cases, am I immediately sacrificing the performance
gains from allocating components this way? Is it a problem when I
iterate, in C++, two different contiguous arrays and use data from
both at each cycle?
No (at least not necessarily). ...
5
TL;DR Entities SHOULD NOT auto-register to systems based on component signatures; prefer instead to explicitly declare component sets/nodes to register your entities to systems that operate on specific component signatures.
It’s been almost a year since I’ve asked the question, and I’ve played with both approaches to take a step away from theory and see how ...
4
This is just another category of collision detection. Your server needs to be able to tell if two bounding shapes are colliding for any number of reasons and this needs to be efficient; there are many ways to achieve this. The world is then capable of having thousands of entities (including triggers) and information about which ones are currently in ...
3
Basically speaking, your systems should not need to talk to each other. There may be cases where systems implicitly interact, but this interaction should not be explicit. If you need to have systems interact with each other, then you probably did not define the systems properly.
Before I dig into some examples to illustrate the point I want to define what ...
3
If you only have a single SDL_Renderer, it should be managed outside of the ECS code and just passed to the rendering system when you call it to render the visual data for each entity. In this way it's like you are associating your single SDL_Renderer with all renderable entities. If for some reason you had multiple, differently configured SDL_Renderer ...
3
Messaging is a common way of handling this. So your health system would subscribe to messages about collision, combat, etc. Then the health system is the only place where health is modified.
Messaging also allows multiple systems to subscribe to the same events. For example, when a collision happens the health system can be notified, sound system and the ...
3
I almost voted that this is too opinion-based, but on thinking on it further, I think it's safe to say with some sureness that the second option presented is just bad. Don't do that.
Among other things, it means that any components which must create objects needs a dependency on another component, potentially a different component for each type of thing it ...
3
It's a year old question but now I'm facing the same trubles with my home made game while studying ECS, thus some necromany. Hopefully it will end up in a discussion or at least few comments.
I`m not sure if it violates ECS concepts, but what if:
Add an EventBus to let Systems issue/subscribe to event objects (pure data in fact, but not a component I guess)...
3
My advice here is coming from past experience on an RPG project where we used a component system. I will say that I hated working in that gameside code because it was spaghetti code. So I'm not offering much of an answer here, just a perspective:
The logic you describe for handling sword damage to a player... it seems one system should be in charge of all ...
3
I think the Observer Pattern may fit here. Instead of sending a message to your button, let your button observe some component.
3
I think you may be overthinking this.
The point of ECS is to be simple:
An entity is nothing more than an aggregate of components.
A system is only interested in a subset of those components. For example: A rendering system would only be interested in Transform and Graphics data components,and a physics system would be interested in Position, Motion and ...
2
Posting the solution I finally settled on, similar to Yakovlev's.
Basically, I ended up using an event system since I found it very intuitive to follow its logic over turns. The system ended up responsible for the in-game units that adhered to turn-based logic (player, monsters, and anything they can interact with), real-time tasks such as rendering and ...
2
Short Answer:
Profile then optimize.
Long Answer:
But, when I am to iterate component arrays to do something with them
from a system on an actual gameplay implementation, I notice that I
almost always am working with two or more component types at once.
Is it a problem when I iterate, in C++, two different contiguous
arrays and use data from ...
2
Serialization can be implemented in any number of ways, but I would strongly suggest that you find ways to decouple entity/component semantics from network serialization as it will make it easier as new things are added to keep them in sync.
For for creating of entities, I would have a packet that gets sent perhaps on some periodic basis that contains all ...
2
A method I use for dividing scenes up, is to create a zone, which is essentially just an invisible cube, within this cube you can have sub-zones which are children to the parent zone. Depending on the environment you are rendering, you can optimize in relation to how you partition your world with these zones.
If you have an internal environment, you can ...
2
Whenever a Entity is added to a Entity Controller (EC), this EC registers to ComponentAdded and ComponentRemoved events from the Entity.
When a Component is added or removed from an Entity, fire the proper event.
The event handler of EC is called, then you can insert or remove the Entity from Systems according to the Components it has at the moment.
2
You are possibly conflating two separate things. I'll explain them below, but first I'll strongly note that you should spend some time playing around with existing game engines and get a sense for how they solve problems before trying to write your own game/engine from scratch.
Transform Hierarchies
Most engines have some form of hierarchy of transforms, ...
2
Your onEntityFall method is not registered to the event bus. Notice where your yourPlayerHarvestEvent method is and how its context differs from onEntityFall.
Additionally, you should use a complete class, rather than a runtime generated object, for your event handlers. This class can also be static (with static methods) and registered with annotations. See ...
1
I can see you going about this two ways without changing too much of your core data model.
Kind of a lazy way to do it if you know that there will be no more than 3 bonuses per item.
bonus_1_type (NSInteger)
bonus_1_amount (float)
bonus_2_type
bonus_2_amount
bonus_3_type
bonus_3_amount
This would give you the flexibility to use an Enum for type and float ...
1
That is a fine way to do it. Alternatives would be
A field on the item specifying which attribute the bonus applies to, with a modifier ie
[{"fire_rate", 5}, {"health", 10}]
Each item could have a pair of delegates so you can make changes programatically. One applies the item's attributes, and optionally, the other removes them (like for equipment)
...
1
If you need to store entities in chunks it's probably better to actually store them in the chunks rather than a separate array.
public class Chunk {
public int SizeX;
public int SizeY;
public Entity[] Entities;
public Chunk[] Neighbors;
}
public class Entity {
// ...
public Chunk CurrentChunk;
// ...
}
You can still maintain ...
1
Your template definition needs to be in the header file. More specifically:
template<typename ComponentType>
ComponentType* Entity::GetComponent() {
for(unsigned int i = 0; i < m_components.size(); i++) {
if(ComponentType* cmp = dynamic_cast<ComponentType*>(m_components[i])) {
return cmp;
}
}
return ...
1
Move the definition of Entity::GetComponent to the header, Entity.h. In general, template definitions must be put into header files. See this related question:
https://stackoverflow.com/questions/495021/why-can-templates-only-be-implemented-in-the-header-file
1
Unity's Entity-Component-System implementation isn't an ideal model on which to base a custom ECS. Unity favors ease of use over strict adherence to the ECS paradigm and made lots of trade-offs to serve that end.
Where Unity falls short of a pure ECS is the lack of separation between data and logic. In a pure ECS components contain only data and the logic ...
Only top voted, non community-wiki answers of a minimum length are eligible
