Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411539 Posts in 69383 Topics- by 58439 Members - Latest Member: isabel.adojo

May 02, 2024, 03:59:56 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Where does Box2D fit in my code?
Pages: [1]
Print
Author Topic: Where does Box2D fit in my code?  (Read 1658 times)
Falmil
Level 6
*


View Profile
« on: February 09, 2010, 08:11:37 PM »

I am trying to learn how to use Box2D for some basic gravity, collision detection, and maybe pushing objects around in Flash programming. I am still trying to make sense of all the classes and how they fit together but for the moment I am confused about how it would fit into my code. If I have Game Objects and a Game Object Manager, both of which handle the Model side of the Game Objects, then should I compose Box2D into my objects or make my objects build upon the Box2D objects. I was thinking compose would be simpler, but the procedure for adding a body to the world will make things a bit complex, I would think. Also, I am completely unsure if/how I can access b2Body properties like position, rotation, and velocity for me to use.

Or alternatively, am I just in over my head?
Logged
st33d
Guest
« Reply #1 on: February 10, 2010, 05:14:03 AM »

Box2D is like a factory that generates parts.

You can't build upon those parts without changing the factory.

It's better to get your physics simulation running, and then monitor what's going on inside. You shouldn't be fully integrated with it unless you know what you're doing. Keep it separate from your game engine and just listen to what's happening in it until you're confident enough to take a direction.

There's a really basic tutorial here:

http://www.emanueleferonato.com/2009/01/27/box2d-tutorial-for-the-absolute-beginners/

Box2D won't come naturally, but if you keep at it, you'll start having fun pretty soon.
Logged
bateleur
Level 10
*****



View Profile
« Reply #2 on: February 10, 2010, 05:57:30 AM »

If I have Game Objects and a Game Object Manager, both of which handle the Model side of the Game Objects, then should I compose Box2D into my objects or make my objects build upon the Box2D objects.

I generally have the Box2D object as a property of my game object (because an object's physics behaviour is quite naturally a property) and the Box2D world object as a property of my game level (which may or may not be the same thing as your game object manager - I'm not quite sure what you mean by that).

For each object, ask "does this object correspond to something within the Box2D environment"? If the answer is yes, add that something as a property.

The tutorial st33d linked is a good starting point, but be aware that Box2D's "debug draw" facility (which the tutorial uses) is doing some of the hard work for you. You will need to extract info about the position and rotation of each object once per frame to use as input to whatever drawing procedures you employ.
Logged

BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #3 on: February 10, 2010, 01:09:43 PM »

Inheritance is not possible, so composition is usually the way to go, but I wouldn't generally call it composition either as the box2d world owns each body, not some user object.

My setup, and what I'd recommend to everyone, is to have some class (usually Actor), imlementing all my game objects, and any non physical behaviour. Actors have a reference to the body they hold, and bodies (via the user data propery) reference their actor, and it is more or less one-to-one. Usually I'd create a body even for things that don't need one (e.g. signs, background images, etc), and I'd create Actors for bodies that don't need one (e.g. sensors), as it's just easier to have a consistent system.

I usually have Actors seperate from the sprites I use for them, too, and have references between them, but some people prefer a simpler setup where Actor inherits from Sprite, and fills both purposes.

So your game objects with their own manager fits easily into that scheme. Just remember to create and destroy bodies as you create and destroy game objects, and tie them together.
Logged
Falmil
Level 6
*


View Profile
« Reply #4 on: February 10, 2010, 04:43:50 PM »

@ st33d: Well, I just thought it would be possible with the new features of AS3 and object oriented polymorphism. I don't know if I would say I wanted "full integration", just a good way to connect a b2World to a "Game Object Manager" and a b2Body to a "Game Object".

@ bateleur: Yeah, I meant "Game Object Manager" as a kind of game world/level kind of thing. I'm mostly talking about b2Worlds and b2Bodys at this point.

@ BorisTheBrave: I wasn't aware inheritance was not possible. Sometimes I forget about using references in AS3 since it isn't something that I've seen explicitly advertised as a feature. But yeah, this sounds like a good plan to use. I plan on using some simple MVC to at least separate the data and internal logic from the graphics and audio and other stuff.

Thanks. You all have been helpful.
Logged
bateleur
Level 10
*****



View Profile
« Reply #5 on: February 11, 2010, 01:16:41 AM »

Sometimes I forget about using references in AS3 since it isn't something that I've seen explicitly advertised as a feature.

Most likely reason it isn't discussed much is because everything in AS3 is a reference. Not unusual for a garbage collected environment.
Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic