How do you handle having multiple physics worlds?

mike.rp99 · February 15, 2013, 12:46pm

I am making a game that has a level contained in a lua module. Something like this.

level.lua:

function newLevel(data)  
 local level = display.newGroup()  
 level.physics = require "physics"  
 level.physics.start()  
 -- make the level here  
 return level  
end

And in my main.lua I am creating these levels.

main.lua:

require "level"  
level1 = newLevel(data\_for\_level1)  
level2 = newLevel(data\_for\_level2)  
level1.start()

At some point, the user will finish level 1 and I will send them to level 2. The physics world created in level 1 looks like it is still around and makes the play for the next level not work properly. I would like to be able to keep all of the levels in tact because the user can go back to previous levels in their last state.

So what is the appropriate design for circumstances like this? I’ve tried to do a level.physics.stop() but that doesn’t seem to work. Saving all of the world data and destroying it upon going to another level and recreating upon reentering sounds like ugly design.

Thanks in advance! [import]uid: 213270 topic_id: 35957 reply_id: 335957[/import]

bjsorrentino · February 15, 2013, 3:57pm

Hi @mike.rp99,
I’m not sure what you mean by “new physics world”. Different gravity settings for example? More sensitive to collision iterations? Clearing the previous objects? Can you specify a bit clearer what kinds of changes you wish to make from level to level?

Thanks,
Brent [import]uid: 200026 topic_id: 35957 reply_id: 142953[/import]

mike.rp99 · February 15, 2013, 10:33pm

Hi Brent,

It’s not so much that I want to be able to establish different parameters to the physics worlds (although that sounds like something interesting to play with) but rather I want to be able to create multiple levels and ‘flip’ between them on the fly. So flipping would entail me hiding the display group for one level and showing the display group for another and should a user revisit a level, the objects will all be exactly as they were when he left it.

My assumption about how creating instances of physics (what I thought were called “physics worlds”) were that they would both have separate processes of the physics engine. I also assumed that objects in one instance would not interact with objects in another instance. In this below example, I expected that c1 and c2 wouldn’t interact because I put them in different physics instances.

[code]local physics1 = require “physics”
physics1.start()
physics1.setGravity(0,0)
local physics2 = require “physics”
physics2.start()
physics2.setGravity(0,0)

local c1 = display.newCircle(10,10,25)
c1:setFillColor(255,0,0)
physics1.addBody(c1,“dynamic”)
local c2 = display.newCircle(600,10,25)
c2:setFillColor(0,255,0)
physics2.addBody(c2,“dynamic”)

c1:setLinearVelocity(150,0)
c2:setLinearVelocity(-150,0)
[/code]

But they do interact.

If this separation isn’t how it currently works that’s fine. I’d like to

suggest that this sort of separation of physics engine instances be given consideration
ask how to handle having multiple levels loaded in memory at the same time, without the physics objects in each level interacting with physics objects in other levels

As I see it, when I leave a level, I have to save the state all of it’s components and remove each object from the physics engine, and if the user needs to come back to a level in it’s previous state, I have to add each object back to the physics engine.

I haven’t implemented it, but seems like it should work, but is this the expected design of an application using the Corona SDK? This is my first game with it and want to understand the best practices.

Thanks again! [import]uid: 213270 topic_id: 35957 reply_id: 142981[/import]

bjsorrentino · February 15, 2013, 3:57pm

Hi @mike.rp99,
I’m not sure what you mean by “new physics world”. Different gravity settings for example? More sensitive to collision iterations? Clearing the previous objects? Can you specify a bit clearer what kinds of changes you wish to make from level to level?

Thanks,
Brent [import]uid: 200026 topic_id: 35957 reply_id: 142953[/import]

mike.rp99 · February 15, 2013, 10:33pm

Hi Brent,

It’s not so much that I want to be able to establish different parameters to the physics worlds (although that sounds like something interesting to play with) but rather I want to be able to create multiple levels and ‘flip’ between them on the fly. So flipping would entail me hiding the display group for one level and showing the display group for another and should a user revisit a level, the objects will all be exactly as they were when he left it.

My assumption about how creating instances of physics (what I thought were called “physics worlds”) were that they would both have separate processes of the physics engine. I also assumed that objects in one instance would not interact with objects in another instance. In this below example, I expected that c1 and c2 wouldn’t interact because I put them in different physics instances.

[code]local physics1 = require “physics”
physics1.start()
physics1.setGravity(0,0)
local physics2 = require “physics”
physics2.start()
physics2.setGravity(0,0)

local c1 = display.newCircle(10,10,25)
c1:setFillColor(255,0,0)
physics1.addBody(c1,“dynamic”)
local c2 = display.newCircle(600,10,25)
c2:setFillColor(0,255,0)
physics2.addBody(c2,“dynamic”)

c1:setLinearVelocity(150,0)
c2:setLinearVelocity(-150,0)
[/code]

But they do interact.

If this separation isn’t how it currently works that’s fine. I’d like to

suggest that this sort of separation of physics engine instances be given consideration
ask how to handle having multiple levels loaded in memory at the same time, without the physics objects in each level interacting with physics objects in other levels

As I see it, when I leave a level, I have to save the state all of it’s components and remove each object from the physics engine, and if the user needs to come back to a level in it’s previous state, I have to add each object back to the physics engine.

I haven’t implemented it, but seems like it should work, but is this the expected design of an application using the Corona SDK? This is my first game with it and want to understand the best practices.

Thanks again! [import]uid: 213270 topic_id: 35957 reply_id: 142981[/import]

bjsorrentino · February 23, 2013, 3:05pm

Hi Mike,
Almost forgot to respond to this, sorry about that… anyway, pertaining to your suggestion…

“how to handle having multiple levels loaded in memory at the same time, without the physics objects in each level interacting with physics objects in other levels”

…I think you could accomplish this easily enough by just setting physics bodies in one level as inactive (body.isBodyActive = false), thus removing them from the physics world, but later you can restore them to active.

http://docs.coronalabs.com/api/type/Body/isBodyActive.html

That being said, if you have your levels composed of -hundreds- of physics objects, I don’t recommend you do this, because while those objects will not be interacting with others while inactive, they’re still sitting in memory. But, if you’re only dealing with a handful of objects per level, I think you’d be safe in doing this.

Brent
[import]uid: 200026 topic_id: 35957 reply_id: 143959[/import]

mike.rp99 · February 24, 2013, 12:04am

Thanks again for you help, Brent. A quick loop through all my objects doing a obj.isBodyActive = false/true turns them all on and off.

I’ll make sure to mind my memory usage too. [import]uid: 213270 topic_id: 35957 reply_id: 143998[/import]

bjsorrentino · February 23, 2013, 3:05pm

Hi Mike,
Almost forgot to respond to this, sorry about that… anyway, pertaining to your suggestion…

“how to handle having multiple levels loaded in memory at the same time, without the physics objects in each level interacting with physics objects in other levels”

…I think you could accomplish this easily enough by just setting physics bodies in one level as inactive (body.isBodyActive = false), thus removing them from the physics world, but later you can restore them to active.

http://docs.coronalabs.com/api/type/Body/isBodyActive.html

That being said, if you have your levels composed of -hundreds- of physics objects, I don’t recommend you do this, because while those objects will not be interacting with others while inactive, they’re still sitting in memory. But, if you’re only dealing with a handful of objects per level, I think you’d be safe in doing this.

Brent
[import]uid: 200026 topic_id: 35957 reply_id: 143959[/import]

mike.rp99 · February 24, 2013, 12:04am

Thanks again for you help, Brent. A quick loop through all my objects doing a obj.isBodyActive = false/true turns them all on and off.

I’ll make sure to mind my memory usage too. [import]uid: 213270 topic_id: 35957 reply_id: 143998[/import]

bjsorrentino · February 15, 2013, 11:57pm

Hi @mike.rp99,
I’m not sure what you mean by “new physics world”. Different gravity settings for example? More sensitive to collision iterations? Clearing the previous objects? Can you specify a bit clearer what kinds of changes you wish to make from level to level?

Thanks,
Brent [import]uid: 200026 topic_id: 35957 reply_id: 142953[/import]

mike.rp99 · February 16, 2013, 6:33am

Hi Brent,

It’s not so much that I want to be able to establish different parameters to the physics worlds (although that sounds like something interesting to play with) but rather I want to be able to create multiple levels and ‘flip’ between them on the fly. So flipping would entail me hiding the display group for one level and showing the display group for another and should a user revisit a level, the objects will all be exactly as they were when he left it.

My assumption about how creating instances of physics (what I thought were called “physics worlds”) were that they would both have separate processes of the physics engine. I also assumed that objects in one instance would not interact with objects in another instance. In this below example, I expected that c1 and c2 wouldn’t interact because I put them in different physics instances.

[code]local physics1 = require “physics”
physics1.start()
physics1.setGravity(0,0)
local physics2 = require “physics”
physics2.start()
physics2.setGravity(0,0)

local c1 = display.newCircle(10,10,25)
c1:setFillColor(255,0,0)
physics1.addBody(c1,“dynamic”)
local c2 = display.newCircle(600,10,25)
c2:setFillColor(0,255,0)
physics2.addBody(c2,“dynamic”)

c1:setLinearVelocity(150,0)
c2:setLinearVelocity(-150,0)
[/code]

But they do interact.

If this separation isn’t how it currently works that’s fine. I’d like to

suggest that this sort of separation of physics engine instances be given consideration
ask how to handle having multiple levels loaded in memory at the same time, without the physics objects in each level interacting with physics objects in other levels

As I see it, when I leave a level, I have to save the state all of it’s components and remove each object from the physics engine, and if the user needs to come back to a level in it’s previous state, I have to add each object back to the physics engine.

I haven’t implemented it, but seems like it should work, but is this the expected design of an application using the Corona SDK? This is my first game with it and want to understand the best practices.

Thanks again! [import]uid: 213270 topic_id: 35957 reply_id: 142981[/import]

bjsorrentino · February 15, 2013, 11:57pm

Hi @mike.rp99,
I’m not sure what you mean by “new physics world”. Different gravity settings for example? More sensitive to collision iterations? Clearing the previous objects? Can you specify a bit clearer what kinds of changes you wish to make from level to level?

Thanks,
Brent [import]uid: 200026 topic_id: 35957 reply_id: 142953[/import]

mike.rp99 · February 16, 2013, 6:33am

Hi Brent,

It’s not so much that I want to be able to establish different parameters to the physics worlds (although that sounds like something interesting to play with) but rather I want to be able to create multiple levels and ‘flip’ between them on the fly. So flipping would entail me hiding the display group for one level and showing the display group for another and should a user revisit a level, the objects will all be exactly as they were when he left it.

My assumption about how creating instances of physics (what I thought were called “physics worlds”) were that they would both have separate processes of the physics engine. I also assumed that objects in one instance would not interact with objects in another instance. In this below example, I expected that c1 and c2 wouldn’t interact because I put them in different physics instances.

[code]local physics1 = require “physics”
physics1.start()
physics1.setGravity(0,0)
local physics2 = require “physics”
physics2.start()
physics2.setGravity(0,0)

local c1 = display.newCircle(10,10,25)
c1:setFillColor(255,0,0)
physics1.addBody(c1,“dynamic”)
local c2 = display.newCircle(600,10,25)
c2:setFillColor(0,255,0)
physics2.addBody(c2,“dynamic”)

c1:setLinearVelocity(150,0)
c2:setLinearVelocity(-150,0)
[/code]

But they do interact.

If this separation isn’t how it currently works that’s fine. I’d like to

suggest that this sort of separation of physics engine instances be given consideration
ask how to handle having multiple levels loaded in memory at the same time, without the physics objects in each level interacting with physics objects in other levels

As I see it, when I leave a level, I have to save the state all of it’s components and remove each object from the physics engine, and if the user needs to come back to a level in it’s previous state, I have to add each object back to the physics engine.

I haven’t implemented it, but seems like it should work, but is this the expected design of an application using the Corona SDK? This is my first game with it and want to understand the best practices.

Thanks again! [import]uid: 213270 topic_id: 35957 reply_id: 142981[/import]

bjsorrentino · February 23, 2013, 11:05pm

Hi Mike,
Almost forgot to respond to this, sorry about that… anyway, pertaining to your suggestion…

“how to handle having multiple levels loaded in memory at the same time, without the physics objects in each level interacting with physics objects in other levels”

…I think you could accomplish this easily enough by just setting physics bodies in one level as inactive (body.isBodyActive = false), thus removing them from the physics world, but later you can restore them to active.

http://docs.coronalabs.com/api/type/Body/isBodyActive.html

That being said, if you have your levels composed of -hundreds- of physics objects, I don’t recommend you do this, because while those objects will not be interacting with others while inactive, they’re still sitting in memory. But, if you’re only dealing with a handful of objects per level, I think you’d be safe in doing this.

Brent
[import]uid: 200026 topic_id: 35957 reply_id: 143959[/import]

mike.rp99 · February 24, 2013, 8:04am

Thanks again for you help, Brent. A quick loop through all my objects doing a obj.isBodyActive = false/true turns them all on and off.

I’ll make sure to mind my memory usage too. [import]uid: 213270 topic_id: 35957 reply_id: 143998[/import]

bjsorrentino · February 23, 2013, 11:05pm

Hi Mike,
Almost forgot to respond to this, sorry about that… anyway, pertaining to your suggestion…

“how to handle having multiple levels loaded in memory at the same time, without the physics objects in each level interacting with physics objects in other levels”

…I think you could accomplish this easily enough by just setting physics bodies in one level as inactive (body.isBodyActive = false), thus removing them from the physics world, but later you can restore them to active.

http://docs.coronalabs.com/api/type/Body/isBodyActive.html

That being said, if you have your levels composed of -hundreds- of physics objects, I don’t recommend you do this, because while those objects will not be interacting with others while inactive, they’re still sitting in memory. But, if you’re only dealing with a handful of objects per level, I think you’d be safe in doing this.

Brent
[import]uid: 200026 topic_id: 35957 reply_id: 143959[/import]

mike.rp99 · February 24, 2013, 8:04am

Thanks again for you help, Brent. A quick loop through all my objects doing a obj.isBodyActive = false/true turns them all on and off.

I’ll make sure to mind my memory usage too. [import]uid: 213270 topic_id: 35957 reply_id: 143998[/import]