Handling large amounts of enemies

Started by
32 comments, last by 00arch00 16 years ago
The grid is normally like 100x100 pixels or larger and such. It's not a pixel sized grid.

Draw a grid out on paper that has large cells like 100x100. Then draw little 20x20 pixel enemies. Put little AABB around them. Then look at that code I wrote again and figure out what it's doing. Right now it doesn't sound like you understand.

(I think you might need to learn C++ before working on an mmo :P)
Advertisement
Quote:
for(int x = int(entity.AABB.min.x/cellSize); x <= int(entity.AABB.max.x/cellSize); ++x)
{
for(int y = int(entity.AABB.min.y/cellSize); y <= int(entity.AABB.max.y/cellSize); ++y)
{
//grid[x][y].Insert(entity);//will add it in the cell and also insert add the list node to an array in the entity, the entity has a RemoveFromGrid function.
}
}


Alright upon closer examination I see what you're talking about.
Since you're dividing the bounding box by cell_size, the code will insert the enemy into multiple cells if it's bounding box is inside more than one cell.

Here's what you don't get, my problem is that I can't render an enemy at any more than approximately 64,000x. That's why I was trying to avoid assigning large x,y coordinates to enemies.

I did some research.

I think I found the root of my problem.
int32 –2,147,483,648 to 2,147,483,647

So I was wrong about the size of an int being the limitation.
Apparently the rand() function is the limitation.

"RAND_MAX is a constant defined in <cstdlib>. Its default value may vary between implementations but it is granted to be at least 32767."

I was thinking it was the size of an int that was restricting me, but instead it was the RAND_MAX constant for the rand() function.

I had no idea the output of rand() was restricted to RAND_MAX.

I do see what you're saying, but now that I've explained where I'm coming from, maybe you can see why it didn't make any sense to me, and I was trying to do it the other way.

It looks like I need to forget about using rand(). I was going to use spawnpoints anyway - I was just using rand() for a quick way to place the enemies in the room.

This forum is for people to ask questions. People wouldn't ask questions if they already knew everything. I don't appreciate you insulting my c++ knowledge because I didn't know rand() had a limitation. Evidently you didn't either or you would have mentioned that. Anyway, I think with that out of the way I won't be having as much trouble with this cell class.

Thanks for your help. I can do without the insults though ;)











hmm? I didn't say anything about rand. Found this online:

float Random(float min, float max)
{
return min + (max - min) * rand() / (float)RAND_MAX;
}

There's nothing wrong with using rand. Just make sure you place them in the map. Like I said before put checks in that nested for loop to check if they are in the boundary. I remember when I was working on a C# top down game for class and I forgot to and a bullet slipped past my poor hit detection and crashed the game a few times :(

(also I shouldn't have put the ":P" there, I just meant that using encapsulation would better suit a project like this, didn't mean anything bad when I wrote it. I've actually written 3 incomplete C++/SDL/OpenGL top down shooters and a few incomplete multiplayer ones. Been working on an mmo version with the little free time I have, so I understand exactly what you're going through).
Just for the sake of completeness let me elaborate a little about this.

I was using rand() to assign enemy.x=rand()%ROOM_WIDTH;
If the room was larger than the value of RAND_MAX, the enemy.x would be capped at RAND_MAX. I didn't know this. I mistakenly thought the size of int was capping the enemy.x value. All I knew for sure is that if I made the room larger than a certain size the enemies would no longer go all the way to the end of the room.

Like this
E: enemy
-------------------------------
|EEEEEEEEEEEEEEEEEE
|EEEEEEEEEEEEEEEEEE
|EEEEEEEEEEEEEEEEEE
|EEEEEEEEEEEEEEEEEE
|EEEEEEEEEEEEEEEEEE
|EEEEEEEEEEEEEEEEEE
|EEEEEEEEEEEEEEEEEE
|
|
|
|
|
-------------------------------

This is the reason I was assigning each enemy into a random cell, and then assigning the enemy a random location in the cell. So the enemy x,y coordinates would not be larger than cell_size and I could avoid the enemy.x value reaching the limitation.

The way you're telling me to do it (with nested for loops) is the first thing that came to mind, but it wouldn't do much good if the enemy.x can't be larger than 64,000. The difference is that I was going to have the enemy.x max out at 1000, and if it went farther, start back at 0, and add 1 to the hcell. I originally wanted to do it like you're saying, but I couldn't figure out why there was a limitation being imposed on the maximum coordinates. Now everything makes much more sense.

If you had to modify the cell class to create an unlimited sized room, but the enemies could have no greater than 64,000 as their x,y coordinates how would you do it? That's what I was trying to do lol.
It's like a weight lifted off my shoulders now. Phew.

My question probably didn't make any sense to you because if you know the maximum size of an int you know it would take a very large world to go more than that.

It just dawned on me while I was replying to your post that rand() had to be what was limiting the size of the x,y numbers. And sure enough it has a max value around the maximum x and maximum y I am able to place my enemies at.
I didn't notice the problem until I was testing to see how big I could make the room. When I made the room larger than RAND_MAX you could see that the enemies would no longer make it all the way across. I just assumed rand() could output the size of int32, but I was very mistaken about that.

If I hadn't been so frustrated trying to explain it to you I might not have figured it out. Thanks! :)

Sorry I snapped at you about the c++ comment. I thought you were criticizing my question. Didn't notice you were making a joke about the crappy C code. :P
I hope to get something compiled tommorrow. I shouldn't have any problems with the enemy.x value becoming greater than int now, but I'll still put a sanity check on it. Oh the irony...

It would be a lot easier for me to explain if I could have just drawn a picture. You forum guys need to make a picture drawer thing to insert into posts for me so I can share my ideas and frustrations easier! Now THAT'S a super-secret rocket science invention and I claim the patent to it! ROFL.











This topic is closed to new replies.

Advertisement