Games as a plugin

[Laurens]

Hi guys and gals,

 

Last night I was reading a chapter on plugins in C++ applications in "C++ for Game Programmers" and it got me thinking.

 

Conventionally people create an engine, compile it into a DLL and end-users use the functions the DLL supplies to create and compile it into a game executable. But what if you turn it around?

 

I was thinking it would be possible to wrap Leadwerks around an executable who's sole purpose it is to load a game from a DLL. Additionally the engine could provide some basic structures such as a state manager, networking and whatnot but really the only thing a developer would have to do to get a game going is override the plugin interface defined by the engine and he/she would be able to run it in the engine.

 

It would require no main function, no initialization, it could all be contained within that engine wrapper around Leadwerks. Of course this does impose a pretty serious architecture for the game developer but it would also make setting up a game easier with a lot of structures already present.

 

Another example would be a console window. The engine could define a console window so there is no need for game developers to implement their own.

 

What are your thoughts?

 

Cheers!

[Rick]

I created something like this at work. We have tons of programs that get data, format it, then load it into a database. They were all separate programs written by different programmers, and had no consistency at all. So I created a plugin based system. There was a class you would extend from that provides Start(), Process(), Finish() methods that you overloaded. It also provides a logging object and some standard config information. It works really well.

 

I think someone around here also tried to do something like this if I'm not mistaken. Maybe on the old forums.

 

I think it's a good idea, but one still has to create the game logic to make a game, which is where the real problem is.

[Laurens]

I created something like this at work. We have tons of programs that get data, format it, then load it into a database. They were all separate programs written by different programmers, and had no consistency at all. So I created a plugin based system. There was a class you would extend from that provides Start(), Process(), Finish() methods that you overloaded. It also provides a logging object and some standard config information. It works really well.

 

I think someone around here also tried to do something like this if I'm not mistaken. Maybe on the old forums.

 

I think it's a good idea, but one still has to create the game logic to make a game, which is where the real problem is.

 

Thats exactly what I was thinking. I look around the net some more and it turns out C4 is built this way as well. It has a main engine executable and several DLL's for not only games, but also the level editor and the model/texture importer.

[Canardia]

I thought that is what gamelib/gemini is already doing

You call high level functions like LoadMap, MovePlayer, DamageEnemy, etc...

 

For the next version I will also add a RunGame() function which doesn't return until the game is exited with the ExitGame() function from inside the loop inside the RunGame() function. That's how FreeGLUT does it also.

The user can add then standard callback functions like KeyboardHook, RenderHook, DrawHook, etc...

Of course RunGame() is not needed, but you can still write your main loop.

 

RunGame will be a method in the Game class, so for your own game, you can inherit the Game class and add your own additional code to the KeyboardHook, RenderHook(), etc....

[Rick]

It probably is, but gamelib is a crazy mess. It's nice to get examples from, but it's just messy C.

[Canardia]

That's because it's still not even a 0.1 version yet, but only 0.0.19.0

Industrial version numbering goes like this: major.minor.plannedchanges.bugfixes

 

The first 0.1 version, so the full version signature will be then 0.1.0.0, will be much less messy, as it's not needed to use C99 anymore, but we can use full C++98 now (MinGW 3, VS 2008 C++), maybe even C++0x (MinGW 5, GNU 4, VS 2010 C++).

 

The reason to use C99 initially was to keep the gamelib API a set of standalone functions instead of classes, while still getting some benefits from OOP. Now people have learned C++ better, and more advanced C++ programmers use LE, so it's time to go with the majority.

 

And hey, we are offering a way to get rid of the main loop now too, which should make every true C++ lover's heart beat higher

I've also played around with the idea to use events (thanks to Rick, our event fanboy), since it would allow gamelib to execute things in the correct way, and not be easily broken by the user's wrong order of commands (like putting update+render at the top of the main loop and causing entities to lag behind in motion).