5 replies to this topic

[bbqroast]

Hey, I was wondering about this method I came across in a tutorial:

enum GameStates {

    STATE_NULL,

    STATE_INTRO,

    STATE_TITLE,

    STATE_QUIT,

};

class GameState {

    public:

        virtual void handleEvents() = 0;

        virtual void logic() = 0;

        virtual void render() = 0;

        virtual ~GameState(){};

};

From what I understand, first we create a custom variable, which can be STATE_NULL, STATE_INTRO, etc. Then we create a class called Game State with a set of "virtual" functions- I believe they are functions that are meant to be inherited and thus don't require themselves to be present (No need for GameState::handleEvents()) or is this what the = 0 does??

class Intro : public GameState  {

    public:

        void handleEvents();

        void logic();

        void render();

        Intro();

        ~Intro();

    private:

        SDL_Surface *slide;

        int yVel;

        float y;

};

Ok here we have the Intro class which inherits from Game State, I pretty much know what is going on here.
To save on space I won't attach all the functions.

currentState = new Intro();

This is what interests me, does the "currentState" variable have all the properties of Intro??? So for example could I create an array of pointers that are all of type "GameObject" but actually point to different classes that inherit from "GameObject" for example a "BlockWall" and "EntityPlayer" class and could I pass the pointers to other functions (eg when "EntityPlayer" hits "BlockWall" each would have their CheckCollision(GameObject* other) function called with the other objects pointer).

The reason I am interested is that I wish to write a 2D basic physics engine and this could be what I need to handle different types of classes that all have the same functions that just do different things, eg "BlockWall" would just show its self and have a empty checkCollision() function while "EntityPlayer" would have a checkCollision() function full of different switches (eg if it hits "BlockWall" it would stop).

Excited.

[WingedPanther]

GameState is implementing "pure virtual functions". That means that you cannot create an instance of GameState because those functions are deliberately not defined. However, you can create a pointer to GameState (in this case currentState), and have it point to a child-class of GameState, as in this case. When you call a method declared in GameState, because the method is virtual, the implementation of that method will be the child-class's implementation (in this case Intro).

GameState is similar to what Java and C# refer to as an interface.

[Flying Dutchman]

I don't want to discourage you, but you should be making a game rather than the engine. See this great post that explains why.

[bbqroast]

He is saying why not to write a standalone engine... You see what I am really trying to achieve is a collision system that will be coded into my game, allowing me to spend less time writing millions of collision detection calls and more time making the game.

So it's more of a part of a game... Besides some of the best games I know use in house engines, and I just read an article about how these days their is no reason not to implement a engine in any game. Besides that article was about writing graphical engines I wish to write a physics engine- I use SDL for rendering.

BTW it will really just be an array with a couple of looping functions to a. check for collisions b. call the show() function (that uses SDL to render).

[RhetoricalRuvim]

Do you use meshes for the collision-detection?

SDL is 3D?

[Flying Dutchman]

@RhetoricalRuvim,

SDL is 2D but can be used with OpenGL.

@bbqroast,

Whether it's graphics or physics engine, the task is still the same; provide an interface which can be used in (several) projects. Even if article talks about graphics, those guidelines still apply to physics.