# How do I make a Box2D object that makes objects passing through it slower?

I wish to have a sort of "slow motion" or "slow down" effect on a players character when they walk in a mud area, usually the character velocity is 3f constant in any one direction. The problem is I tried to declare a rectangle to cover the object mud area but I am only able to get a solid rectangle area and therefore the character cannot walk through or over this area, the desired action would be having the character movement slow down while walking in the mud area. The code below is what I have tried to make this sort of region, but this code only makes a solid object which the character cannot pass through.

 final Rectangle rect = new Rectangle( object.getX(), object.getY(), object.getWidth(), object.getHeight(), vbom );

final FixtureDef fixDef = PhysicsFactory.createFixtureDef( 0.0f, 0.0f, 1.0f );
Body body = PhysicsFactory.createBoxBody( physicsWorld, rect, BodyDef.BodyType.KinematicBody, fixDef );
body.setUserData( typeOfObject );
physicsWorld.registerPhysicsConnector( new PhysicsConnector( rect, body ) );

• I'd suggest making a trigger object and increasing the friction of any object colliding with that trigger. – MichaelHouse Sep 30 '13 at 3:30
• You can use a friction joint; it was designed to do what you're asking. – RandyGaul Sep 30 '13 at 3:52

If I understand your problem correctly, you are trying to create an area that can detect the player is in contact, but without preventing the player from walking in it.

In Box2D, what you want is called a Sensor. A Fixture is a physics object which will actually cause collisions with other physics objects, thereby preventing them from intersecting an area. A Sensor does not cause these collisions, but does generate BeginContact and EndContact events, which you can use to track whether your player is in the mud. Here's some more info. A Fixture is turned into a Sensor but setting the isSensor property on the Fixture.

On contact with your mud sensor you can set a modifier on the player's velocity, such as multiplying it by 0.4. Or, if you'd like the player's animation to slow down as well, you could use a modifier on the deltatime the player receives, causing him to literally operate in slow motion.

• This might just do the trick, because as it stands I use a contactListener which has BeginContact and EndContact events. But I am not very clear on how I would define the Sensor for my area, could you assist with a simple example or so? – kabuto178 Sep 30 '13 at 3:47
• I don't know andengine too well, but according to this implementation you can pass a fourth argument to createFixtureDef which indicates whether it is a Sensor. Give that a shot. – kevintodisco Sep 30 '13 at 4:02

Ah concepts of time.

What you usually have is a concept of "real time" and "game time"

• "Real Time" is actual physical time. its the time we experience here in the real world. This is useful for things which always animate at the same frequency/velocity regardless of game time. Eg: UI components.
• "Game Time" is the time that has elapsed in the game. We can speed this up, and slow this down as needed. We typically animate and simulate using "Game Time".

So, for slow motion we simply reduce the rate of "Game Time" updates relative to "Real Time". eg: we increase "Game Time" at half the rate of "Real Time" to get a 50% slow down. We can also do the opposite, and run "Game Time" faster than "Real Time" to get a fast forward effect.

This is why there's usually two concepts of "Time" within a game engine.

As per your question. Its important to know whether the game is networked or not, as if the game is networked you need to keep "Time" synchronized between all clients (including both concepts of game, and real time).

For slowing things down within a field, you could use a temporary modifier to "Game Time", however this may cause fun deterministic issues if your game is networked. You may need to confirm the position of objects as they enter the field, and the position of objects as they leave the field to ensure consistency across clients. Lockstep engines will be pretty much fine, but ones that do clientside prediction will have issues with entering/leaving the field and subsequent deterministic calculations of position.

• Noted as well, a more in depth understanding of game time vs real time, and also gave me a few ideas – kabuto178 Sep 30 '13 at 15:23