# Game Engine, Implementing Physics (Code Layout)

This topic is 1431 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi,

I've been coding a game engine for a while and now I'm trying to implement physics on it.

The engine has a SCENE class that holds various arrays of objects (Image, Text, Model, etc) that will be draw.

void GameEngine::Update()
{
while(_timeModule.NeedsUpdate()) //Fixed Time Step
{
}
}

void Scene::Draw(Camera& camera, float& interpolation)
{
for(unsigned int i = 0; i < _objects.size(); i++)
{
_objects[i]->Draw(camera, interpolation);
}
}


How can I implement the Physics code in this layout? What's the best way/consensus on how it's done?

I've been thinking in three ways:

#1: All Objects in the Scene

void GameEngine::Update()
{
while(_timeModule.NeedsUpdate()) //Fixed Time Step
{
_currentState->Update();
_scene->Update(); //I'll call this method here
}
}

void Scene::Update()
{
for(unsigned int i = 0; i < _objects.size(); i++)
{
if(_objects[i]->PhysicsComponent.isEnabled == true) //Checking if I want physics on this object
{
//Do whatever Physics code I want to do on them, based on their physicsComponent properties
//I have access to the object's properties here, such as Position, Rotation etc so I can add Speed and such and compute
}
}
}


For this first option, I'm guessing it would be hard to code some specific changes or event calling (like when a collision happens) back to the object.

Also, using the Scene to loop through the objects... not sure if it's a good idea.

#2: Per Object

class MyCharacter
{
public:
void Update(); //Physics here
private:
Image* characterSprite;
};

void Scene::Update()
{
for(unsigned int i = 0; i < _objects.size(); i++)
{
_objects[i]->Update();
}
}



For this second option, the Scene would call each object's Update() function so I can code specific stuff in there. I'm thinking of adding some basic general physics functions such as gravity so I don't have to type it for every object, but just call the function inside their Update() function.

For now this is the most... reasonable option I've thought of.

#3: Totally New Class

void GameEngine::Update()
{
while(_timeModule.NeedsUpdate()) //Fixed Time Step
{
_currentState->Update();
_physicsObjects->Update();
}
}

void PhysicsClass::Update()
{
for(unsigned int i = 0; i < _objects.size(); i++)
{
//Apply physics
}
}

void MyGameCode::Start()
{
Image* someImage = new Image();

}


For this third option I don't think it's bad, but it's just like the first option as it's hard to call back the object when, for example, a collision happens.

For example I'd tag the object with collision and a bullet hits it, I have no idea how I could call a specific function when that happens to their "parent" object.

What would be a good way to implement this?

Edited by Danicco

##### Share on other sites

As that all depends on how your Physics object is implemented, it's difficult to say. Are you rolling your own? Are you using or have you looked to see how other engines are implemented? Box2D? ODE? Bullet?

In any case, if collisions are to be detected and resolved in a physics engine, that object will have to have information about all collidable objects at some point. That information need not be a pointer to the object itself, just information needed by the physics engine.

By the way, there have been innumerable discussions about physics engine implementations here on gamedev, including in what order various routines should be called. It may well be worth your while to search around a bit. You should have done that before posting, in any case!

Edited by Buckeye

##### Share on other sites

Of course (3), where the _physicsObjects object  would be Bullet (or other library) world state.

gameEngine.Physics.Add(someImage); //adding to the physics array so it'll be computed


What does that even mean? Physics and images... what?

##### Share on other sites

Yes, I want to do one on my own. I've checked one or two other physics engines (just looked over some tutorials) and noticed they did the same thing, provided a class that I think I should inherit or put as a member, and probably fill some values and it'll do the rest.

For this I would need to add a "layer" of code that I really don't want to, and I'd like to study how to do one as well so...

By layer of code I mean something like this, currently, I have a huge class called "GameEngine" that does everything for the "Game":

class MyGame
{
public:
//MyGame's functions, specific for each game
private:
//And they just use this
GameEngine gameEngine;
};

void MyGame::Update()
{
gameEngine.Update();
gameEngine.Render();
};

void MyGame::Start()
{
};

//etc


So I'd like to provide Physics within the engine class, without having another class parallel to the GameEngine. Just to make it easier to code the Game itself, like setting a few variables and values and the engine doing everything automatically.

The more and more I thought about it, it makes more sense to create another vector of physics-able objects... dunno why I'm trying to save class space.

What does that even mean? Physics and images... what?

I don't have anything else other than an "Image" object to work for now, and I really want to simplify development of the game.

I want the engine to provide a few basic classes to the game: Image, Model, Sound, Text, etc

And I was thinking of putting physics together with these objects (wrapped in a member or something) so the Game code would look like this:

void MyGame::Start()
{

myImage->Position.x = 100;
//etc

//"myImage" is ready to use and has everything needed to deal with 2D images
};


So I was thinking of adding a line like "myImage->EnablePhysics();" and it would start computing Physics for that object (based on some configuration).

I am thinking as the GameEngine programmer to the Game programmer, I don't want to say "hey to use Physics in the Engine you gotta create your class, add an Image member, add an Physics member, configure parameters of XYZABCDEFG, then add to the engine, then..."

I want to make it as simple as possible for the Game programmer, but I'm still thinking and balancing what the engine should simplify and what it shouldn't.