A good game architecture and design

[vbrain]

I've been searching for weeks for a good game design and architectural approach. I need a great way to manage entities without having to loop through everything.

I'm developing a Real-time Strategy and I have been trying to figure out how to have the entities communicate and attack without having to loop through everything. I am using a grid manager where every entity is in a cell, then I select all the entity's neighbors to determine who to shoot. However, if there are a total of 50 entities in the nearby cells, and I have them all loop over each other and shoot, the game begins to lag. I'm trying to find an approach that doesn't utilize too many loops.

I have read many articles but so far none give a clear answer.
Please don't mention using an entity manager like Artemis, because I would still have to loop through everything.

[HeroesGraveDev]

You'll find in many RTS's, that unit only attack when a) instructed, or b) are attacked themselves.

[vbrain]

You'll find in many RTS's, that unit only attack when a) instructed, or b) are attacked themselves.

Yes, I have played a few. The units in my game attack automatically when an enemy comes near them. I need someone with a good method to tell me how to go about making my game efficient.

Games published by our own members! Check 'em out!

[65K]

Use a profiler to find out the slow parts. Loops do not imply slowness.
One approach could be an event driven system, another to cut the number of processed entities for each frame / switch the entity chunk to process.
But thats all guessing.

[heisenbergman]

Is your game multithreaded?

Maybe try putting the logic for checking targets into threads and run them simultaneously per entity?

[Shnagenburg]

Do units only attack the closet enemy within range? If so you may want to try adjusting your cell size to remove unneeded collision checks (a collision being an enemy collides with a units sight circle). Start with cells that are very small then expand outward until you get a candidate. Is it the case that units are only going to change their attack target if someone in those cell sets moves? An easy optimization is to only check for a new target if the nearby enemies have moved. Be sure your units are only checking the distance to relevant entities, such as not people on the same team. If you're using the distance formula to check who to attack, keep in mind that sqrt() is more expensive than just using radius^2 for everything.

[lcass]

Id say that you would either have to have them as seperate objects or use polymorphism to make an entity super  that has a tick(){}; and then the object itself handles the rest. there isnt really a better way to see if your troops can do anything other than make them check.

[Grunnt]

However, if there are a total of 50 entities in the nearby cells, and I have them all loop over each other and shoot, the game begins to lag.

50 entities looping over 50 nearby other entities = 50 * 50 = 2500 decisions who to shoot each update. This is assuming that each entitiy will shoot each and every update loop, which is of course not the case I assume. These numbers are extremely low, and it does not make sense at all that this should cause lag.

Without seeing any code I can just say: do some profiling to find out why this is so slow.

[lcass]

Store the x and y of enemys in an array . Scan this array and then check the x and y (usin pythag) if the distance is less than their range kabloowy attack. Yes do put this in a seperate loop.

[philfrei]

If you have 50 entities each in two neighboring cells, are all 100 engaged? or only those closest to each other?

A couple ideas (hard to know without seeing the decision-making code itself, or a better description of the decision algorithm):

1) if you are using distance, remember that distances can be ranked without having to calculate square-roots. (X1-X2) * (X1-X2) + (Y1-Y2) * (Y1-Y2) is sufficient for ranking--no need to get a square root of this if the only purpose is ranking.

2) maybe there should be "sub-cells" of some sort within the cells?

But as several people have pointed out already, if the algorithm is efficient, you can brute force check many more entities against each other than just 50 against 50, so there's probably something in the decision logic that can be honed out.