adding and removing physics

11 replies [Last post]
jazzarssoul
User offline. Last seen 5 years 23 weeks ago. Offline
Joined: 31 Aug 2011

Just wondering is it possible for physics to be added to objects onscreen and removed to objects off screen? I'm making a pretty big sandbox game that requires free roaming and for objects to be spawned off screen to the player

I have followed danny's tutorial for spawning objects - the right way!

and my code goes somewhat like this.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
local function spawnPeeps(params)
        xRandom = math.random(1,10000)
                        yRandom = math.random(1,10000)
                local peeps = display.newCircle( xRandom, yRandom, 15)
                
                --Set the objects table to a table passed in by parameters
                peeps.objTable = params.objTable
                
                --Automatically set the table index to be inserted into the next available table index
                peeps.index = #peeps.objTable  + 1 
                
                -- local peepsNumber = display.newText(peeps.index, xRandom, yRandom, nil, 12)
                -- peepsNumber:setTextColor(0,0,0)
                print(peeps.index, #peeps.objTable   )
                --Give the object a custom name
                peeps.myName = "peeps : " .. peeps.index
                
                --If the object should have a body create it, else dont.
                if params.hasBody then
                        --Allow physics parameters to be passed by parameters:
                        peeps.density = params.density or 0
                        peeps.friction = params.friction or 0
                        peeps.bounce = params.bounce or 0
                        peeps.isSensor = params.isSensor or false
                        peeps.bodyType = params.bodyType or "dynamic"
                        
                        physics.addBody(peeps, peeps.bodyType, {density = peeps.density, friction = peeps.friction, bounce = peeps.bounce, isSensor = peeps.isSensor})
                end
                
                -- checking whether it's a peep
                peeps.isPeep = true
                
                --check if alive
                peeps.isAlive = true
                
                --checking collision with phys trig
                peeps.isActive = true
                
                --The objects group
                peeps.group = params.group or nil
                                
                --If the function call has a parameter named group then insert it into the specified group
                peeps.group:insert(peeps)
                
                
                --Insert the object into the table at the specified index
                peeps.objTable[peeps.index] = peeps
                
                return peeps
        end
 
        --Create a table to hold our spawns
        local spawnTable = {}
 
        params = {
                        objTable = spawnTable,
                        
                        hasBody=true,
                        friction = 0.4,
                        bounce = 0.4,
                        bodyType = "dynamic",
                        group = group,
                }
        --Spawn two objects
        for i = 1, 2000 do
                local spawns = spawnPeeps(params)
        end

Replies

Brent Sorrentino
User offline. Last seen 1 year 24 weeks ago. Offline
Staff
Joined: 28 Nov 2012

Hi @jazzarssoul,
You can definitely remove physics bodies when you need to, and you should, especially if your intention is to create 2000 physics objects as in your example. In fact, creating that many would probably crash and burn, or perform terribly slow at least.

Even better would be a method in which you "recycle" similar objects... but the player never sees it happening. Meaning, you find a way to use a very small set of physics objects and swap them in and out of a "repository" as they enter or exit the screen. I did this in a recent game and it gave me the best performance boost of any others I had attempted.

Brent

jazzarssoul
User offline. Last seen 5 years 23 weeks ago. Offline
Joined: 31 Aug 2011

Hey Brent my situation may need to be described a little more clearly.

I have a certain amount of xp the character needs to work up to, to level up.
To make up for the fact that the higher the xp required the higher amount of people that get eaten needs to respawn.
So per eat of people spawn either 1/2 and to make up for said numbers I was wondering through the spawning method as mentioned is there a way to add and keep physics to the objects on screen + 1/2 the screen width and remove and keep physics away from the objects outside these bounds

Brent Sorrentino
User offline. Last seen 1 year 24 weeks ago. Offline
Staff
Joined: 28 Nov 2012

Hi @jazzarssoul,
Certainly this should be possible. You might also consider a screen "region" which is an invisible sensor object. Objects that move outside that region are either made inactive or the physics body removed. Objects that move inside the bounds are reactivated. Ultimately, the implementation is up to you... but the scenario sounds feasible, absolutely.

Brent

jazzarssoul
User offline. Last seen 5 years 23 weeks ago. Offline
Joined: 31 Aug 2011

I had imagined this particular scenario would be the case in which there is an object region that follows the movement of the player and triggering physics as it goes but I however have tried this strategy and failed miserably...

So I kinda ditched the effort and hoped there was an easier way. Is there a way you can provide me with an example or start me in the right direction Brent?

Brent Sorrentino
User offline. Last seen 1 year 24 weeks ago. Offline
Staff
Joined: 28 Nov 2012

Have you implemented some kind of "camera" movement? Meaning, the entire world is moving and all of the offscreen objects are entering/exiting the "viewport" at different times? If so this becomes a bit more complex, but should be solvable. If the "camera" is moving around a world, does the character stay centered in the screen or push the scrolling around as it reaches near the screen edges?

Or, do the offscreen objects move independently of each other, moving about at different speeds and velocities or something? And then the screen "sensor" I described could be locked in place?

Brent

jazzarssoul
User offline. Last seen 5 years 23 weeks ago. Offline
Joined: 31 Aug 2011

Hey Brent I do have a camera system where it's just the group.x & y following player.x & y

very basic,

and literally everything on the playing field right now to a 10000 x 10000 sized app with about 200 people are all moving and all have physics.

The view in this scenario is limited to 1280 x 720 so max, I would dealing with about 5 - 10 people on the current screen and hope to not allow other objects to be requiring physics at this point as it really lags it down. Also as mentioned I need to incoroporate some form of one eat will spawns 2 more people off screen with hopefully no physics attached at this point until they become on screen items because it would truly lag it out exponentially

Thanks :)

Brent Sorrentino
User offline. Last seen 1 year 24 weeks ago. Offline
Staff
Joined: 28 Nov 2012

Hi @jazzarssoul,

I still think you can implement some kind of physics sensor solution, BUT you must remember that you can't shift display groups around independently (in regards to your camera) without breaking the physics collision environment. In other words, you can't just put a "screen size sensor" locked in place (in one display group) and then have the "camera" move the underlying world around. It will not detect the collisions properly.

You might try to attach the sensor to the player, so it follows it around, and gets the proper collisions when other peeps come into contact with it.

Brent

jazzarssoul
User offline. Last seen 5 years 23 weeks ago. Offline
Joined: 31 Aug 2011

how do you mean can't just put a "screen size sensor" locked in place?

do you mean if I was to place the physicsBox I've created and set that to a constant update to the player.x and y? and not place it in the display group

Brent Sorrentino
User offline. Last seen 1 year 24 weeks ago. Offline
Staff
Joined: 28 Nov 2012

Well basically, the physics engine requires potentially-colliding objects to be in the same "coordinate space". This is not a new factor, but developers tend to stumble on it because they move an entire display group containing physics objects (to move them all at once), and then they are perplexed why those objects are not colliding with physics objects in other non-moved groups.

How this pertains to your project is that you're likely moving the entire "world" to simulate the camera. So, if you imagine that you have a stationary "screen sensor" that is positioned in a different display group (not moving with the world), then you won't get the proper collisions... thus rendering the approach pointless, since it's that sensor which is supposed to collide with those off-screen objects and "activate" them as they come into range.

What you might be able to do is link this sensor to the PLAYER, either as a secondary body, or using a pivot joint. This way, the sensor would remain in the main group and it should receive the proper collisions. Does this make sense? It's hard to describe what I'm talking about without actually showing it in action. :(

Brent

jazzarssoul
User offline. Last seen 5 years 23 weeks ago. Offline
Joined: 31 Aug 2011

Is this what you were getting at?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
-- for the lack of throwing in all the code I've devised you will notice the commented sections
-- are functions/actions
 
 
 
-- created the group & ending as you would
 
local guy = display.newRect(0, 0, 15,15)
guy.x, guy.y = display.contentWidth/2, display.contentHeight/2
 
group:insert(guy)
 
-- I have a joystick moving the player
 
 
-- as you have seen in my above mentioned people creater this is how I'm creating the people
-- even attaching physics
 
-- collision event creating other people at random points, spawning on screen would be fine
-- I'm not going for complete realism.
 
-- so now what you're saying is I have to create this physics sensor?
 
 
 
local physicsSensor = display.newRect ( 0, 0, 1280, 720) -- 1280 and 720 are screen bounds
-- not insert it into the group?
 
-- add physics to the physics sensor for a pivot point to be able to apply?
 
physics.newJoint (physicsSensor, guy, --etc --etc --etc)???
 
-- and not insert physicsSensor to the group? even though by default if no display objects have been added they get added anyway?

Brent Sorrentino
User offline. Last seen 1 year 24 weeks ago. Offline
Staff
Joined: 28 Nov 2012

Hi @jazzarssoul,
Yes, this is basically what I considered, but you'll have to test it out to see how well it works. Just remember:

1) yes, the sensor is a physics body (sensor). It can be a dynamic object attached to the character using a pivot joint. Its rotation should be fixed using .isFixedRotation = true so it doesn't go swinging all over if the character rotates.

2) the sensor MUST be in the same group as the character and anything else it might need to collide with (so, all of your other game world characters). It's the only way to maintain the system receives the proper collision handling.

Brent

Viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.