Re:creation - a top down action adventure about undeads [hiatus]

[Elias Daler]

@Grimshaw, thank you for encouraging words!
Do you store components contiguously or not?

Sometimes the time you save in development by doing something slightly less correct can pay off as well. Engineering time is a resource as much as memory or CPU, consider that

Yep, but it can improve the engine design a lot and save me lots of time in the future. It's hard to be sure from the beginning.

[Glocke]

It's hard to be sure from the beginning.

That's right! I faced this at my project, too. But finally my major performance problems were fixed after reimplementing my ECS. Btw I use a contiguously approach for components only. More highlevel gameplay elements (like items or spells) are dynamically allocated. I haven't tested this referring to performance yet, but I think (of course depending on the type of game) it might be acceptable.

Btw: Your screenshots etc. look really great! I'm curious about the final version

[dabbertorres]

Just to add other container types to the discussion, I've used Google's dense hash map (I exported from Google Code, I haven't found an official repository since it closed) and haven't noticed issues with it.

In addition, I've found and heard b-trees (not binary trees) can be a good choice as well.

[lezebulon]

Events. Collisions don't happen frequently, so this is not a big perfomance issue.

Sorry I don't get it,
I'm assuming that for collision you run the collision update method on something like std::vector<ColisionCpt> , right ?
In that case, how do you know which entities the event should refer to ? Or does your collision component hold a pointer to an entity ?
And when firing the event, by what system do you know that entity A should respond to the collision by dying (for instance), and that entity B should respond by moving back? Is that because the collision response is a virtual method?

[Grimshaw]

@Grimshaw, thank you for encouraging words!
Do you store components contiguously or not?

Sometimes the time you save in development by doing something slightly less correct can pay off as well. Engineering time is a resource as much as memory or CPU, consider that

Yep, but it can improve the engine design a lot and save me lots of time in the future. It's hard to be sure from the beginning.

Yes I do, but its not a hard requirement. I basically have one pool per component type, which hands me N component instances when I ask for them.. So most of them should be contiguous, most of the time, but the world subsystem will work with even components allocated with new if I prefer it. You should totally commit to making the best library of components you can, either with behavior in component or component + system.

How you put these components together could and should be less hardcoded and allow more flexibility from game code.

[Elias Daler]

@Glocke, well, reworking the system didn't help me. Guess the performance of my game was always pretty okay. Storing components contiguously was more like an exercise, I guess. And thanks!

@dabbertorres, thanks, that looks interesting. Didn't know about those structures.

@lezebulon, yep, all components store the pointer to Entity which owns them. (But I would store entity's id in the future, because I can quickly get entity by its id). So, one system may construct event which contains entity's id and other system will process it.
But I sometimes use the approach which Nexus has told about. Sometimes it's better for system to handle multiple components. In my case, if I need to change some components in one system, I may get this component by another component's owner pointer.

And when firing the event, by what system do you know that entity A should respond to the collision by dying (for instance), and that entity B should respond by moving back? Is that because the collision response is a virtual method?

This is all done by scripting. When two entities collide, a Lua function for each entity is called which does all the stuff.

@Grimshaw, did you notice any perfomance differences when storing components contiguously and not contiguously?

[shadowmouse]

Please forgive me if I'm being dense here (I haven't used Lua) but what advantage does the scripted onCollision function have over a C++ std::function callback? Is it purely so that you can change it on the run without recompiling? Or is it something else?

[Glocke]

Guess the performance of my game was always pretty okay.

This is all done by scripting. When two entities collide, a Lua function for each entity is called which does all the stuff.

On which type of system have you tested that your performance is pretty ok? I'm curious about testing it on my netbook (despite it is of course no gaming computer^^).

[lezebulon]

This is all done by scripting. When two entities collide, a Lua function for each entity is called which does all the stuff.

Sorry I'm really not being clear   what I didn't get was, how do you determine which Lua function to call on the entity? At this point, you only know that 2 entities collided, and each entity is defined only by the list of its component (if I understood). So based on this, how do you figure out which Lua response to call ? I can think of several ways of doing it, but none that would be flexible enough and be in O(1)

Sorry I'm asking so much btw, I've always seens tons of ECS thrown around , but on every implementation it seems they never manage to make the whole thing work in constant time (with respect to the number of total component, system, etc). Whereas for me the point of ECS is that it's really easy to scale

[Nexus]

Implementing a double dispatch system in O(1) is relatively easy: you create a 2D table of function objects/pointers, where each row and column is indexed by the entity type. Each cell contains the function for the combination of the row and column types. The type can be any criterion stored in any component.

You should really have a look at aurora::DoubleDispatcher, it uses std::unordered_map and thus amortized O(1).

[lezebulon]

Implementing a double dispatch system in O(1) is relatively easy: you create a 2D table of function objects/pointers, where each row and column is indexed by the entity type.

Yup, but how is the concept of "entity type" even defined ? Usually the "type" is defined by the class hierarchy, but since there's no class hierarchy in an ECS, for me it's either:
- an entity type is an instance of an entity, which means a full vtable for each instance (still doesn't explain according to what criteria it should be filled)
- an entity type is a given combination of components, which means that they are 2^N possible entity types for a total of N components. Which means that we have to careful think about which combination of component should be dispatched to which virtual function.

I mean, it seems to me that there's always a point where, if we want to keep everything flexible, we are facing a combinatorial explosion simply because an entity could be any combination of components

[Nexus]

Yup, but how is the concept of "entity type" even defined ?

The type can be any criterion stored in any component.

It may be meaningful to store an attribute in the collision component, if dispatching is used for collision response. Make your dispatcher generic so that it can extract the type as you wish -- that's also what Aurora's implementation does.

[Elias Daler]

Please forgive me if I'm being dense here (I haven't used Lua) but what advantage does the scripted onCollision function have over a C++ std::function callback? Is it purely so that you can change it on the run without recompiling? Or is it something else?

Yep, I could have used std::function for the same effect. Yep, I mostly use scripts to make quick changing possible. It also helps me to not search the source code when I want to see how some entity works: all entity properties and callback functions are stored in a corresponding script.

On which type of system have you tested that your performance is pretty ok? I'm curious about testing it on my netbook (despite it is of course no gaming computer^^).

I don't really remember which is the oldest PC I've tested it on, but I must say that my laptop is 5 years old and not that powerful. There's nothing to worry about in terms of perfomance. There isn't many sprites on the screen in one moment. There isn't any physics or complex AI.

what I didn't get was, how do you determine which Lua function to call on the entity? At this point, you only know that 2 entities collided, and each entity is defined only by the list of its component (if I understood). So based on this, how do you figure out which Lua response to call ? I can think of several ways of doing it, but none that would be flexible enough and be in O(1)

I store the corresponding function's luabridge::LuaRef in CollisionComponent (this is like a pointer to a function which lets you call this function). O(1)!

[Glocke]

I don't really remember which is the oldest PC I've tested it on, but I must say that my laptop is 5 years old and not that powerful. There's nothing to worry about in terms of perfomance. There isn't many sprites on the screen in one moment. There isn't any physics or complex AI.

5 years old? So the laptop might have a dual core cpu with >2 GHz per core? That's quite much for 2D gaming Personally, I'm focused to make my game's core (physics, graphics, basic gameplay logic) run on the very low end hardware (e.g. 2 GB Ram, 1.6 GHz Single Core, Intel OnBoard GPU ^^) .. sometimes it's pure pain, especially when using a heavy combination of non contiguous containers and lots of virtual methods (meanwhile is replaced all non contiguous containers and moved away from too much OOP). But I think the trouble is worth it, because it offers to use additional computer power for more highlevel tasks like AI.

Can you give us a short sketch of your architecture? You were talking about your ECS which is object-oriented. What I mean: How do the components message each other? Is there a virtual interface each (sub-)component implements of even overrides? Or do you handle all game logic by calling bound lua functions?

[Otherian]

I really love the screenshots of your project. It is very motivating to see a project wich is already so far in its progress
I hope you will finish it that we can actually try and play it! Keep up the nice work! :3

Have you taught the whole programming stuff to yourself?
And do you recommend the ECS engine for a 2D-SFML-Game or would you like to change it after you've got to experience it yourself for quite some time? I just ask because I'm planning to start a game-project by myself and am still not sure wich approach to choose...