Spawn Object with Physics and different size

[yuval_forish]

Hi there,

I am developing a game with the following rules:

1. The “enemy” objects are the same image.png file BUT their size are randomly created with different sizes (from 50,50 to 300,300)

2. Each “Enemy” is attach to Physics by addBody() in order to detected a collision.

3. A-lot of enemies are created during the games (Created and removed)

I want to use the pattern of Spawn Object (which means that you create a pool of objects and then during the game use the next available object from the pool).

The problem :

As the “Enemy” are created with random size and each object are attached to Physics how can I use the pattern of pooling of objects?

BTW - A solution to created all random objects and adding it to pool is not feasible as there will be a lot of objects (~200 or even more) 

Thanks

[nick_sherman]

You could make each enemy 300 x 300, and use xScale and yScale to re-size them when they are used.

However each time you re-size an enemy you’ll have to remove the physics body and apply a new physics shape based on the xScale and yScale used.

Why can’t you just create each enemy on the fly and delete it when it’s no longer needed?

[Alex10]

@nick_sherman, this dev most likely ran across the umpteen threads that Rob and Brent have commented on, saying that creating a “stable” of objects with physics properties and adding/removing them is more intelligent from a performance standpoint. Creating them beforehand (which _ might _ slow down the game at launch) rather than creating them each time you need them (possible hiccups in framerates depending on size/density/dimensions) is sometimes a good idea.

@yuval_forish, Are you sure you can’t just create this “stable” before the “gamescene” is started and have the approximately 200 objects off-screen, and bring them into view as needed? If you are running into problems with this, what are those problems? It might make for a better user experience if the player just has to wait ~5 seconds when the game is started rather than 1/10 of a second every time an enemy is created.

 local enemTable = {} local xEnemVar = {} local yEnemVar = {} local enemRnd = math.random local function popEnemTable(a) enemTable[a] = display.newRect(0,0,enemRnd(40), enemRnd(40)) enemTable[a].x = enemRnd(display.contentWidth) enemTable[a].y = enemRnd(display.contentHeight) enemTable[a].id = ("enem "..a) physics.addBody(enemTable[a], { density = 1, friction = 0.35, bounce = 0 }) enemTable[a].gravityScale = 0 print("enemTable.id "..a) end for i=1, 20 do popEnemTable(i) end

[yuval_forish]

Hi,

Alex,  indeed I can create the enemies before the scene has started but the problem is the number of the enemies - I can have about (and maybe more) 200 objects…and all need to detect for a collision so I need to use the addBody(). In each time the game I uses about ~20 enemies out of the 200 objects.

Isn’t it problematic to create 200 objects with physics head of time (not related to the time it will take to first reload but rather of big memory usage?) . Also as I will need to enable\Disable the enemy object by using the isBodyActive() - want it be too much time consuming.

The question what is better approach:

1. As nick_sherman stated to create pool of objects and when in use to Scale it and addBody(). Once finished removeBody()

2. As Alex stated : To create 200 object with its actual size and addBody() to each.

3. Don’t use the spawn pattern i.e. to create the actual object and once not needed to delete it.

[Alex10]

If you’re only using ~20 enemies, why did you say there would be more than 200? Are you saying that the enemies make up just a small amount of the many objects that will exist in your game?

Regardless, the approach is really up to you. Creating all objects, whether it’s 20 or 200, before the user even gets into the game, might be a good idea. You might also be able to get away with creating them on the fly, within the game. You could also use Nick’s suggestion, as it’s a good one and might work for you. 

You should probably try them and see which one works best for you.

[davebollinger]

also consider how often respawn occurs.  if, say, one enemy per second or less frequently, then you probably don’t have the “load” to bother with pooling, just completely remove and recreate from scratch. (assuming that image.png at least remains cached somewhere)

but if player can potentially kill/respawn several per frame, and you DO decide to pool, it only needs to be as large as the maximum number that can be active at any one time.  presumably 20 is that max number, and the player may cycle through 10 or more times giving that 200+ total encounters number, right?

if so, as per Alex’s code, but you’ll need Nick’s remove/addBody too.  might help conceptually if you break it up into several helper functions, named whatever you wish, but fe:

“create/allocate” - precreate the pool, with all “static” properties

“activate/spawn/acquire” - finds an inactive in the pool and activates it, including setting scale and addBody()

“deactivate/kill/release” - deactivates the indicated one, returns to available pool, including removeBody()

[nick_sherman]

You could make each enemy 300 x 300, and use xScale and yScale to re-size them when they are used.

However each time you re-size an enemy you’ll have to remove the physics body and apply a new physics shape based on the xScale and yScale used.

Why can’t you just create each enemy on the fly and delete it when it’s no longer needed?

[Alex10]

@nick_sherman, this dev most likely ran across the umpteen threads that Rob and Brent have commented on, saying that creating a “stable” of objects with physics properties and adding/removing them is more intelligent from a performance standpoint. Creating them beforehand (which _ might _ slow down the game at launch) rather than creating them each time you need them (possible hiccups in framerates depending on size/density/dimensions) is sometimes a good idea.

@yuval_forish, Are you sure you can’t just create this “stable” before the “gamescene” is started and have the approximately 200 objects off-screen, and bring them into view as needed? If you are running into problems with this, what are those problems? It might make for a better user experience if the player just has to wait ~5 seconds when the game is started rather than 1/10 of a second every time an enemy is created.

 local enemTable = {} local xEnemVar = {} local yEnemVar = {} local enemRnd = math.random local function popEnemTable(a) enemTable[a] = display.newRect(0,0,enemRnd(40), enemRnd(40)) enemTable[a].x = enemRnd(display.contentWidth) enemTable[a].y = enemRnd(display.contentHeight) enemTable[a].id = ("enem "..a) physics.addBody(enemTable[a], { density = 1, friction = 0.35, bounce = 0 }) enemTable[a].gravityScale = 0 print("enemTable.id "..a) end for i=1, 20 do popEnemTable(i) end

[yuval_forish]

Hi,

Alex,  indeed I can create the enemies before the scene has started but the problem is the number of the enemies - I can have about (and maybe more) 200 objects…and all need to detect for a collision so I need to use the addBody(). In each time the game I uses about ~20 enemies out of the 200 objects.

Isn’t it problematic to create 200 objects with physics head of time (not related to the time it will take to first reload but rather of big memory usage?) . Also as I will need to enable\Disable the enemy object by using the isBodyActive() - want it be too much time consuming.

The question what is better approach:

1. As nick_sherman stated to create pool of objects and when in use to Scale it and addBody(). Once finished removeBody()

2. As Alex stated : To create 200 object with its actual size and addBody() to each.

3. Don’t use the spawn pattern i.e. to create the actual object and once not needed to delete it.

[Alex10]

If you’re only using ~20 enemies, why did you say there would be more than 200? Are you saying that the enemies make up just a small amount of the many objects that will exist in your game?

Regardless, the approach is really up to you. Creating all objects, whether it’s 20 or 200, before the user even gets into the game, might be a good idea. You might also be able to get away with creating them on the fly, within the game. You could also use Nick’s suggestion, as it’s a good one and might work for you. 

You should probably try them and see which one works best for you.

[davebollinger]

also consider how often respawn occurs.  if, say, one enemy per second or less frequently, then you probably don’t have the “load” to bother with pooling, just completely remove and recreate from scratch. (assuming that image.png at least remains cached somewhere)

but if player can potentially kill/respawn several per frame, and you DO decide to pool, it only needs to be as large as the maximum number that can be active at any one time.  presumably 20 is that max number, and the player may cycle through 10 or more times giving that 200+ total encounters number, right?

if so, as per Alex’s code, but you’ll need Nick’s remove/addBody too.  might help conceptually if you break it up into several helper functions, named whatever you wish, but fe:

“create/allocate” - precreate the pool, with all “static” properties

“activate/spawn/acquire” - finds an inactive in the pool and activates it, including setting scale and addBody()

“deactivate/kill/release” - deactivates the indicated one, returns to available pool, including removeBody()