Feedback: Simple game engine beginnings

I've decided to make a small game for the experience. I have a project with a grander scope in mind, but I'm doing this first to familiarize myself with some of the problems I may run into.

The game will be of the 2D variety, probably using SFML.

Anyway, this is sort of the basis for the framework I'm thinking about using.

Include guards have been elided for brevity. Pardon the class names, they obviously aren't final.

GoInterface.h:
1
2
3
4
5
6
7
8
9
10
11
12
namespace ems
{
    class GoInterface
    {
    public:

        virtual ~GoInterface() {}

        virtual void go()=0 ;
    };
}
#endif 


Typical.h:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include "GoInterface.h"

namespace ems {
    class TypicalInterface : public GoInterface
    {
    public:

        // calls setup on function entry, then loops through pre-event, 
        // event processing, and post-event while active() returns true.  
        // Calls cleanup on exit.
        void go() final ;

        virtual void setup() = 0 ;
        virtual void preEventProcessing() {}
        
        virtual void processEvents() = 0;

        virtual void postEventProcessing() {}
        virtual void cleanup() {}

        virtual bool active() = 0;
    };
}


Typical.cpp:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#include "Typical.h"

namespace {
    class GoGuard
    {
    public:

        GoGuard( ems::TypicalInterface & ti ) : _ti(ti) 
            {_ti.setup() ;}

        ~GoGuard()
            {_ti.cleanup() ;}

    private:
        ems::TypicalInterface& _ti ;
    };
}

void ems::TypicalInterface::go()
{
    GoGuard guard(*this) ;

    while ( active() )
    {
        preEventProcessing() ;
        processEvents() ;
        postEventProcessing() ;
    }
}


I've toyed with the idea of inserting a boolean data member in the TypicalInterface to sort of the replace the active() function (which I would set to true in the implementation of go(), and that would allow me to give a default do-nothing definition for setup(),) but I think it's cleaner this way, if a little less convenient when I go more concrete.

I would be happy to hear any thoughts, recommendations or possible caveats.
An engine should only concern itself with resource management and low-level I/O.
For example:
* Getting events from the OS belongs in the engine. Handling events and triggering in-game events belongs in the script.
* Loading and playing a sound effect belongs in the script. Opening a file, interpreting its contents as sound, and sending them to the sound device belongs in the engine.
* Opening an XML file and reading its contents belongs in the engine. Describing the contents of a save file and loading save files belongs in the script.
Thanks. The definition of a "game engine" seems to be rather nebulous.
Topic archived. No new replies allowed.