Entity system component tracking problem

I've been experimenting with creating an entity system in pure C, and have run into a very annoying problem:

I am trying to create an array of pointers that can point to another array that stores addresses to array indexes where the arrays in question are many different types.

I am trying to create entities that can have components added to them. These components are nothing more than indices in an array which are stored in structures. I want to be able to allocate these component structure of arrays dynamically, and so, I can't just use the entity ID to lookup the entry I want... perhaps I making this more difficult than it needs to be. :/

I would appreciate any useful suggestions to make this simpler than the complicated mess I have thought up. :)

This is what I have so far:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
typedef struct
{
	uint32* x;
	uint32* y;
	uint32* z;
} Positions;

Positions* allocate_positions_array(uint32 amount)
{
	Positions* positions = malloc(amount * sizeof(Positions));
	return positions;
}

void free_positions_array(Positions* table)
{
	free(&table);
	table = NULL;
}

void add_position_component(uint32 entity_id, Positions* positions, uint32 px, uint32 py, uint32 pz)
{
	uint32 array_size = sizeof(*positions) / sizeof(positions);
	for(uint32 iter = 0; iter < array_size; iter++)
	{
		if(positions->x[iter] == 0)
		{
			positions->x[iter] = px;
			positions->y[iter] = py;
			positions->z[iter] = pz;
		}
	}
}

Edited by Kyle Devir on
Valmar

I am trying to create an array of pointers that can point to another array that stores addresses to array indexes where the arrays in question are many different types.


This sentence confuse me. Why "addresses to array indexes" or do you simply mean that they are just indices, not pointers?

Anyway, I don't think I can help I'm afraid but entity systems interest me and I would like to get a better understanding of your approach.
Is that the entire system by the way, or is it unfinished? I'm not seeing where the entity id is assigned to the component index. Why do you iterate through the entire array in add_position_component?
Lugen
This sentence confuse me. Why "addresses to array indexes" or do you simply mean that they are just indices, not pointers?

This was my initial design. Now I'm looking for a simpler solution that is easier to implement and understand. I might still use a combination of indices and pointers.

Lugen

Anyway, I don't think I can help I'm afraid but entity systems interest me and I would like to get a better understanding of your approach.
Is that the entire system by the way, or is it unfinished? I'm not seeing where the entity id is assigned to the component index. Why do you iterate through the entire array in add_position_component?

It's unfinished and very much a work in progress.

My approach is to only have to allocate the data that is needed. This means that while a huge number of entities, as simple integers, can be created, the component SOAs will only be allocated as needed. Overall, a stateless system where the developer can add or remove components at any time, and the system can handle the changes without any issues. Hopefully, I can make every component independent of another, with theoretically unlimited combinations, only limited by the developers imagination and cleverness. Writing the actual functions to work on component combinations without conflict will be much more of a challenge, overall.

So, I need a way to reference which components are used by an entity, and that will either require pointers or storing the index of the component that entity is using. Whichever is more efficient, and reduces redundant resources the most. I'm also currently implementing a "free" array which stores pointers no entity is using, but I'm uncertain if it's really needed in the end.

Once the system basics work rock solidly, I'm going to implement other stuff on top of that. I constantly test, build, run through valgrind, everytime I make major changes and know something might have gone wonky.

After that, and implementing some other basic stuff, I'll see about adding my project. :)

Edited by Kyle Devir on