Back to For Beginners

Better way to make entities and map comunicate in a Hierarchy Component System

For Beginners

Started by educk April 22, 2014 01:25 PM

5 comments, last by dworm 10 years ago

educk

236

Author

April 22, 2014 01:25 PM

@Edit: I can't edit the title, I mean Hierarchy Entity System, sorry.

I've been working on a simple game with C++/SDL using hierarchy entities and I've been running into some problems to make the entities deal with the map in a intelligible way. I'm using the common way of states, currently having a Start Menu state and a Main Game state.

Short story: I want my entities to know about each other current states (though they should be ideally independent), what would be the most efficient way to do that, and what would be the most readable/organized way to do that?

Long Story:

I had a class called Map, which holds a bi-dimensional array, each position representing a "square" of the map. Also, I had my entities Enemy and my entity Player. My first problem came when I needed to make entities communicate to the map, like "I want to walk to square [x][y], can I do it?"

The first solution I thought I was declaring the map Static, this way everyone could access it in their classes. But I personally dislike using static objects, and I heard it's not a good idea to do it on games, so I tried thinking in something else.

Then, after thinking one more time, I thought of putting the Player and the Enemies INSIDE the map class. It sounded a little weird at first, but considering I had this only one map for the entire game, it seemed plausible. This way, to make entities communicate with the map, I had something like this:


Map::Update()
{
	Player->Update();
	(for each Enemy) Enemy->Update();
		
	int MoveParam = IsMoveValid(Player->MovingDirection, Player->X, PlayerY);
	Player->Move(MoveParam);
	(for each Enemy) MoveParam = IsMoveValid(Enemy->MovingDirection, Enemy->X, Enemy->Y);
	Enemy->Move(MoveParam);
}

Basically, it works like that: The player and enemies updates will set the directions they WANT to move.

Then IsMoveValid will get that direction they want to go, their currently X and Y position, will check if the X and Y position they want to move is ok, and will return a parameter for them (like "Ok, you can move", "You can't move this way", "You can go down but you have to move a pixel to the right first", something like that).

Based on this parameters, the Move function of each entity class will decide if they are moving or not. This implementation sounded really okay at first, but them suddenly I realized that I moved EVERYTHING to the map class, the Main Game state was basically updating and rendering the map object.

Then, considering the map class held only a bi-dimensional array of positions, I moved everything back to the state class and eliminated the map class. This is the version I currently have in here. It's working fine, but I thought on looking for more options to deal with this.

I saw some other feasible ways to implement it, like making your entities hold a pointer to the map and tho each others, or make the class that hold them implement a message system so they can communicate. I'm also reading a lot about Entity-component-system and it may (or may not?) offer some solutions for this question, but considering that there are so many games developed under Hierarchy Entities, I guess a lot of ways should have been thought already.

What's you guys thoughts on this? What is the way you usually implement your entities communication?

Burnt_Fyr

1,668

April 22, 2014 01:39 PM

I think the entities having a reference to the map, and vice versa is the way to go. when the entity needs to get a path, it can query the map, which can use a* or other pathfinding to return the path to the entity. If your entity needs to query for nearest enemy or what not, it can query the map, which knows all entities already. In an ECS system, I would have a pathfinding system to handle the logic, which would have a reference to the map, and use the entities position component to get starting information for the graph search.

Strewya

2,802

April 22, 2014 02:05 PM

You could pass the Map object by reference:


 player->update(theMap);
 (for each Enemy) enemy->update(theMap);

There's really nothing wrong with passing objects through function calls to the objects that depend on them.

devstropo.blogspot.com - Random stuff about my gamedev hobby

educk

236

Author

April 23, 2014 02:01 PM

You could pass the Map object by reference:
 player->update(theMap);
 (for each Enemy) enemy->update(theMap);
There's really nothing wrong with passing objects through function calls to the objects that depend on them.

I thought about doing something like that, but I don't know, it just don't feels right to be passing everything through parameters. Perhaps I'm just too paranoid. I also had some problems with circular dependency when I first tried doing that, but this is probably some mess I did with the code.

I think the entities having a reference to the map, and vice versa is the way to go. when the entity needs to get a path, it can query the map, which can use a* or other pathfinding to return the path to the entity. If your entity needs to query for nearest enemy or what not, it can query the map, which knows all entities already. In an ECS system, I would have a pathfinding system to handle the logic, which would have a reference to the map, and use the entities position component to get starting information for the graph search.

I was thinking of something like that, like the entities storing a pointer for the current map and vice versa, though I feel like I'm going to have some headache to implement that at first. I'll give some more thought and research on the matter before what I'm really going to do.

Thank you guys!

Burnt_Fyr

1,668

April 23, 2014 04:51 PM

You could pass the Map object by reference:
 player->update(theMap);
 (for each Enemy) enemy->update(theMap);
There's really nothing wrong with passing objects through function calls to the objects that depend on them.
I thought about doing something like that, but I don't know, it just don't feels right to be passing everything through parameters. Perhaps I'm just too paranoid. I also had some problems with circular dependency when I first tried doing that, but this is probably some mess I did with the code.

I think the entities having a reference to the map, and vice versa is the way to go. when the entity needs to get a path, it can query the map, which can use a* or other pathfinding to return the path to the entity. If your entity needs to query for nearest enemy or what not, it can query the map, which knows all entities already. In an ECS system, I would have a pathfinding system to handle the logic, which would have a reference to the map, and use the entities position component to get starting information for the graph search.

I was thinking of something like that, like the entities storing a pointer for the current map and vice versa, though I feel like I'm going to have some headache to implement that at first. I'll give some more thought and research on the matter before what I'm really going to do.

Thank you guys!

You may find this a good read

Strewya

2,802

April 23, 2014 04:59 PM

You could pass the Map object by reference:
 player->update(theMap);
 (for each Enemy) enemy->update(theMap);
There's really nothing wrong with passing objects through function calls to the objects that depend on them.
I thought about doing something like that, but I don't know, it just don't feels right to be passing everything through parameters. Perhaps I'm just too paranoid. I also had some problems with circular dependency when I first tried doing that, but this is probably some mess I did with the code.

Well, you're not passing everything, are you? Just the map. If updating your entity requires the map, pass it in. If at some point you find you're passing 10 arguments into your method, perhaps that method is doing too much work, and should be split up into more functions that do specific work and each takes 1-2 arguments. Also, this actually solves circular dependencies, as in this case, the Entity doesn't need to be created with a Map reference.

I think the entities having a reference to the map, and vice versa is the way to go. when the entity needs to get a path, it can query the map, which can use a* or other pathfinding to return the path to the entity. If your entity needs to query for nearest enemy or what not, it can query the map, which knows all entities already. In an ECS system, I would have a pathfinding system to handle the logic, which would have a reference to the map, and use the entities position component to get starting information for the graph search.

I was thinking of something like that, like the entities storing a pointer for the current map and vice versa, though I feel like I'm going to have some headache to implement that at first. I'll give some more thought and research on the matter before what I'm really going to do.

Thank you guys!

If you don't store the Map into entities, but pass it into an update() method or move() method, then you have no headaches on rewriting anything, and the entity updates based on the map you give it. If the entity changes the map it's in, it doesn't need to know that at all, you just pass in a different map.

My advice would be to do what's easiest (which is argument passing), and refactor later if it proves (through usage) to be ineffective or hard to use.

devstropo.blogspot.com - Random stuff about my gamedev hobby

dworm

683

April 23, 2014 06:41 PM

The first solution I thought I was declaring the map Static, this way everyone could access it in their classes. But I personally dislike using static objects, and I heard it's not a good idea to do it on games,

why not using statics in games? can you elaborate?

Better way to make entities and map comunicate in a Hierarchy Component System

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Better way to make entities and map comunicate in a Hierarchy Component System

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines