Jump to content

  • Log In with Google      Sign In   
  • Create Account


Game Engine, Implementing Physics (Code Layout)


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Danicco   Members   -  Reputation: 449

Like
1Likes
Like

Posted 14 February 2014 - 03:17 PM

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
    {
        _currentState->Update(); //Updates the Game's state
    }
}

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();
    //Load, etc

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

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, 14 February 2014 - 03:19 PM.


Sponsor:

#2 Buckeye   Crossbones+   -  Reputation: 4363

Like
1Likes
Like

Posted 15 February 2014 - 11:49 AM

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! smile.png


Edited by Buckeye, 15 February 2014 - 11:50 AM.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.


#3 Krohm   Crossbones+   -  Reputation: 3040

Like
0Likes
Like

Posted 17 February 2014 - 01:12 AM

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?



#4 Danicco   Members   -  Reputation: 449

Like
0Likes
Like

Posted 17 February 2014 - 06:51 AM

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()
{
    Image* someImage = gameEngine.Resources.Load("someImage");
};

//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()
{
    Image* myImage = gameEngine.Resources.Load("Image");

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

    gameEngine.Scene.Add(myImage);

    //"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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS