• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Danicco

Game Engine, Implementing Physics (Code Layout)

3 posts in this topic

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
1

Share this post


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

Edited by Buckeye
1

Share this post


Link to post
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?

0

Share this post


Link to post
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()
{
    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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0