Modelling an "annotated" path.

[riverwoodland]

Hi!

I'm currently trying to define a data structure to model a path followed by a vehicle, that will consist of several positions at which properties can be assigned. A position in this case is simply an integer that denotes the distance traveled by the vehicle. An example of a property assignable to a position is a point of interest, or an indication that the vehicle is turning.

Some things that are important to note:

• Positions need to be sorted in ascending order.
• Positions are not sequential. There may be a position with value 1 followed by another with value 10.
• It should be possible to iterate each of the positions and their properties in separate, and always in the ascending order of the positions.
• Sometimes it is necessary to iterate positions' properties simultaneously.
• There are some continuous ranges of positions that are special.
• There are some properties that all positions have and some that are optional.
• Paths are short lived they are not maintained throughout the app lifetime.

My immediate thought was to use a AoS, but it quickly became evident that it won't scale properly given the unnecessary space that will be occupied by the optional properties at all the positions.

The idea then switched to use a SoA, with a main sorted vector of structures containing the position value and any associated non-optional properties. For each optional property I would then have a separate vector sorted in ascending order of the positions. Some of the optional properties are already guaranteed to be received in the correct order so I won't even have to sort all of the vectors. To be able to relate optional properties with the corresponding positions' entries, each optional property will store its associated position value and then I would have a bimap to be able to map a non optional position to its position entry and a position entry to any other optional property. This bimap would provide the information to iterate positions' properties simultaneously. The special ranges of positions I mentioned above could then be just a property with a pair of iterators to the position vector. Nevertheless I wanted to find out if anyone had this problem already and whether there was any library or known concept that could help me simplify this.

After a bit of research and discussion the suggestion of modelling this as an ECS came up. I had briefly heard the term before but, for practical purposes, didn't knew anything relevant. However it did seemed like a good fit for what I was trying to do while providing also a lot of flexibility. After reading a bit on it I ended up finding your library and did some code to get used to it. It felt easy to use and there was a lot of information available. So I decided to use it and try to model this as an ECS.

My idea is to have a registry per path with the following components:

• One for the position value.
• One for the Non-Optional properties.
• One for each of the Optional properties.

Then to guarantee the proper sorting I would sort the positions everytime a new one is added and I will make sure that every entity would have a Position component. With the view support it would be easy to iterate entities with the components I want. The only downside is that I would need to always include the Position component in the view to be able to apply the .use<...> construct and get them in the order I need. It would get tricky if the necessity to iterate non-optional properties in a "XOR way" comes up but I think I would be able to deal with it either with an additional component or a vector on the side. Another problem that I thought about is that since the components other than the Positions are not ordered I cannot represent the special ranges of positions as a pair of iterators and would need to resort to a vector of entities for each range.

After all of this I'm starting to have some performance concerns vs the SoA approach since:

• Iterating each of the components forces an indirection with the position components.
• Ranges of positions are now vectors instead of a pair of iterators.
• I still need to do some relations on the side for "XOR iterations" or had tag components to be able to use views.

I've read some documentation and some of the "ECS back and forth" articles bug given that I don't have a lot of knowledge on the library and ECS in general I wanted to ask:

• Do you think ECS is a good approach here?
• If yes am I missing something in the library that could help me to deal with the ordering by position requirement ?
• Would you model a range of positions differently than a vector of identities?

Thanks and sorry in advance if this question is out of context here.

[skypjack]

I'm turning the issue into a discussion as it seems more appropriate to me. 👍

[skypjack]

So, if I get it correctly, you want to use a registry per path so as to be able to use entities for the path positions, right?
Before answering your questions, can I ask you how many positions do you plan to spawn for a single registry?
I'm asking this because many small registries with few entities sound like a waste to me but I might be wrong and it really depends on the use case.

[riverwoodland]

So, if I get it correctly, you want to use a registry per path so as to be able to use entities for the path positions, right?

Yes, exactly.

Before answering your questions, can I ask you how many positions do you plan to spawn for a single registry?
I'm asking this because many small registries with few entities sound like a waste to me but I might be wrong and it really depends on the use case.

My current expectation is that in average we will have between 100 to 1000 points.

[skypjack]

Well, that might work then. 1000 entities isn't that much, so it's a bit borderline but most likely fine.
How many components do you plan to use instead? I'm a little hesitant to say that ecs is the best approach here.
Would it work? Yeah, definitely. However, a bunch of optionals in a more targeted design would also work probably.
Why should you use an ecs model then? It gives you more room for the future if you want to add other components and feature or whatever.
I'd probably use something like that since I'm used to this model. If you don't care about the entry step, then go with it.
You can always join the discord or gitter channel and ask for help if you have any doubts. 🙂

[riverwoodland]

How many components do you plan to use instead?

Right now there are 8 components, but there is still some discussion ongoing.

I'm a little hesitant to say that ecs is the best approach here.
Would it work? Yeah, definitely. However, a bunch of optionals in a more targeted design would also work probably.
Why should you use an ecs model then? It gives you more room for the future if you want to add other components and feature or whatever.

We decided to give it a go : ) The flexibility we get for future developments is a nice plus too.

You can always join the discord or gitter channel and ask for help if you have any doubts. 🙂

Will do, certainly doubts will come up : )

Thanks for your quick feedback!

[skypjack]

You're welcome. Feel free to reach out if you have other questions, change requests or doubts. I'm more than willing to improve, especially when suggestions come from let's say non-standard programs. 🙂