Jump to content
  • Advertisement
Sign in to follow this  

Getting to grips with data oriented component based design

This topic is 1118 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts


I'm playing around with game design and I've been reading about data-oriented component/entity based systems. I must have read about two dozen articles and discussions on the topic, and I'm pretty sure I get the gist of it. I am still, however, struggling somewhat with understanding the implementation. Mostly, I'm concerned with accusing and sharing the data without having to resort to referencing methods that are ultimately going to undermine the performance benefits offered by the approach.
To that end, I was wondering if anyone would be kind enough to comment or criticise the following implementation.
I'm splitting my systems into management, functions, data and library parts. The management area handles registering and deregistering new entries to the data components, as well as interacting with other systems. The function element handles all necessary functionality (typically updates). The data system is essentially a collection of data arrays. The library contains other utility functions and information, and will likely be migrated into a larger lower level library.
The questions I have pertain to the organisation of my data arrays. At first, I was struggling to arrange data in such a way that it will be completely disconnected from other systems, and yet still be identifiable and linkable as necessary. Now I'm thinking of doing the following, and I was wondering if you could point out where I am going wrong:
1. Each system has an array of enrolled entity ids.
2. Each system has a number of arrays of useful data, the indexes of each correspond with the indexes in the array of enrolled ids.
The idea being that the systems themselves can ignore the array of ids, and simply work through the arrays in index orders. The arrays share the initial index number in order that arrays in a system can easily communicate with one another, the first index in every array will be shared by a single entity. The entity array exists in order that information can be easily transferred between systems (when needed) by identify data by entity id, but can be ignored generally in order to minimise the need for such lookups.
Does this seem like a sensible way of arranging the data in these systems? What would be a better way?
Any help is very gratefully received.

Share this post

Link to post
Share on other sites

If that is sensible or not depends on your goals and needs.



In some ways, depending on your data access patterns, having them sequential as a structure of arrays can make sense.  Probably not so much sense in what you described, but with some patterns it can make sense. If you are stepping across many components at once or examining clusters of components where you can look at multiple sets of data simultaneously, then the pattern of keeping data in separate containers can make sense. In other ways it looks like a worse decision.  You have indeces (4 bytes) to point to integers (also 4 bytes).  You could have stored the results directly without issue and in less space; it is scattered across more items but it may improve performance because the data is clustered together if you are stepping one component instance at a time.



If this is the first time you've ever implemented anything like this, I would just store the data directly in the object instances and not in separate data arrays.  

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!