• Advertisement
Sign in to follow this  

Unit Pool Idea's

This topic is 4738 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

The only type of pool I have tried is a simple self written array which literally acts like a pool. Units are stuffed in as a base class, each with their own virtual derived functions. This prooves to work but increase's rather linear. As each time a unit needs to be injected a free index is found, if none is found then it is resized; the max size is doubled. I read a thread below stating a message system which would have improved my way of getting around objects vs object interaction. What I did was simply create Collision() functions for each unit -- if two units collided, both called their collision functions. It worked fine, but the game was asteroids so not much important or different interations. I am wondering if there is a more fast way of working with the dynamic array part of the UNIT POOL. A tree maybe? A template list class which can be injected into a pool, each list is for each type of unit?

Share this post


Link to post
Share on other sites
Advertisement
Well, since you need to support a certan number of units, the size could be static. You motivation is to save memspace, but when you have MAX number of units, you use it all, and there is no reason to save this mem when you have fever units (since you need it all at one time or another)

A Unit system where the number of units is limited by aviable memory sounds unfair to players with less mem.
Also, you have a limited number of units you can render whitout frames dropping, ex: 1000000000 units is probably going to kill your fps, and destroy the funness of the game.

Another point is that if you are going to support multiplayer, dynamic unit structures are bad, since you want unit 244 to be unit 244 on all machines,
an simple array is what you want.

When it comes to Colission, you could use a Matrix, witch indicates witch unit that can collide with another.

One simple trick here would be to calc the distance, and then find the shortest time they possibly could move to eachother (dist - A.max_speed - B.max_speed)

Other then that, start your collision function with a simple eliminator.

D = A.pos - B.pos
if ( D.x*D.x + D.y*D.y + D.z*D.z < (A.radius + B.radius)(A.radius + B.radius) ) return;

dont know if this help, but i hope so.

Share this post


Link to post
Share on other sites
It gives me a few ideas...I never did think that a player on one comp could essentially allocate more units (more ram) than another comp (less ram). So obviously a max has to be set.

Due to the high capacity of comps these days whose software is barely CPU draining, one can safely assume that 3D Model/Paint programs and games are probably the biggest drain. I can then assume a very large max number of units, but there is no need to allocate that space pre-compile or during game-init-time. The max should act more like a cap -- like the old starcraft game which has a max of 255 units per game or per player..ah i cannot remember -- but the unit allocation was dynamic to say the least.

Thanks.

Share this post


Link to post
Share on other sites
I'd have a pool that grows by a certain multiple of the object size each time (eg: x64 or whatever), causing less smaller allocations to be needed if you need to 'resize' often. In my game, I use a freelist system which is part of a dynamic memory pool. If an object is reclaimed, it goes back in the pool to be reused later by future allocations. In my system you can tweak the growsize at runtime (or compiletime) to try and make sure you're allocating an optimal amount of memory.

You could probably build a fixed size limit into it, but as you said, RAM size isn't really the issue these days, but fragmentation could become a real problem if you're frequently allocating small pots of memory.

Share this post


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

  • Advertisement