Seperating Engine and Game code
Author
I'm almost done writing my new Game Engine, and I'm at the point I want to start adding things specific to a game that uses the engine rather then the engine it's self.
And I want this code to be totally independent, so the engine code doesn't have to have any knowledge of the game classes and such at compile time.
My idea is pointing the engine at the game code some how at run time.
But the engine is cross platform so DLLs are out of the question right?
So how is this commonly gone about?
The engine and the game are usualy projects in the same solution. So there are simply two choices here:
1. you select the engine project to compile as a dynamic library (.dll); you will have to load the dll when you need it, this is just for Windows, so you'll probably want the other choice.
2. you select the engine project to compile as a static library (.lib); Therefore your game project will simply link to the lib and use or not whatever is in the engine. This is the best choice for portability - I use it too.
My game template looks like this:
So, when I want to make a game, I simply copy this template and start work with the GAME project.
1. you select the engine project to compile as a dynamic library (.dll); you will have to load the dll when you need it, this is just for Windows, so you'll probably want the other choice.
2. you select the engine project to compile as a static library (.lib); Therefore your game project will simply link to the lib and use or not whatever is in the engine. This is the best choice for portability - I use it too.
My game template looks like this:
DXUT projectCORE project (my basic engine stuff, depends on DXUT)FORGE project (my special engine stuff, depends on CORE)GAME project (the actual game project, depends on FORGE, but may simply not use anything from the engine)MAIN project (contains the main cycle, includes resources and stuff to make the .exe, depends on GAME project)So, when I want to make a game, I simply copy this template and start work with the GAME project.
Author
Awesome thanks for the response man, makes good sense.
This is one thing I had thought of but, after thinking about DLLs it seemed simplistic and I thought maybe there was another way.
But sounds good!
Thanks again.
This is one thing I had thought of but, after thinking about DLLs it seemed simplistic and I thought maybe there was another way.
But sounds good!
Thanks again.
Quote:Original post by Wavesonics
I'm almost done writing my new Game Engine, and I'm at the point I want to start adding things specific to a game that uses the engine rather then the engine it's self.
And I want this code to be totally independent, so the engine code doesn't have to have any knowledge of the game classes and such at compile time.
usually, the game engine/framework merely comes yet another dependency for the actual application, that is your project should minimally be split into two distinct components.
Quote:Original post by Wavesonics
But the engine is cross platform so DLLs are out of the question right?
So how is this commonly gone about?
A lot can be achieved by going the modular route, be it by using a DLL based plugin approach, or one where you embed a scripting interpreter.
Regarding multi-platform DLLs, there are some working solutions available, such as for example "KoreLib" (theKompany) or "SharedLib" (poco: http://poco.sourceforge.net)
Quote:
http://www.appinf.com/poco/info/index.html
Features
* threads, thread synchronization and advanced abstractions for multithreaded programming
* streams and filesystem access
* shared libraries and class loading
* powerful logging and error reporting
* security
* network programming (TCP/IP sockets, HTTP, FTP, SMTP, etc.)
* XML parsing (SAX2 and DOM) and generation
* configuration file and options handling
* database access
Platforms & Portability
POCO runs on a variety of platforms, including:
* Windows
* Mac OS X
* (embedded) Linux
* HP-UX
* Tru64
* Solaris
* QNX
http://www.appinf.com/poco/documentation/PoCoOverview.pdf
The linux/unix equivalent of .dll is .so, a "shared object", which works just like dll on windows. Instead of LoadLibrary() you call dlopen() and instead of GetProcAddress(), you use dlsym().
And for .lib you have .a there. One thing about linux/unix is that you can link directly to the .so file instead of the .a file, unlike in win32.
I haven't played with Mac, so I don't know what they use.
For cross-platform I immediately thought that you mean this, not the "windows adaptation" of crossplatform, 2000, xp and xbox?
ch.
And for .lib you have .a there. One thing about linux/unix is that you can link directly to the .so file instead of the .a file, unlike in win32.
I haven't played with Mac, so I don't know what they use.
For cross-platform I immediately thought that you mean this, not the "windows adaptation" of crossplatform, 2000, xp and xbox?
ch.
Quote:Original post by christian h
The linux/unix equivalent of .dll is .so, a "shared object", which works just like dll on windows. Instead of LoadLibrary() you call dlopen() and instead of GetProcAddress(), you use dlsym().
And for .lib you have .a there. One thing about linux/unix is that you can link directly to the .so file instead of the .a file, unlike in win32.
and if you use a wrapper such as KoreLib, Poco or even libtool, you don't have to take care of such subtleties because they are sufficiently abstracted
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
