Sign in to follow this  
Wavesonics

Seperating Engine and Game code

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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:
DXUT  project
CORE 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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster


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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

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