Sign in to follow this  
McZ

have the engine in the .exe or .dll file?

Recommended Posts

what are the difference in the different aproaches? 1) game in exe file Game.exe - all game specefic stuf and initialize of engine Engine.dll - the engine specefic stuff 2) engine in exe file Engine.exe - all engine specefic stuff goes here Game.dll - all game code would be written here and loaded by the engine at startup 3) both game and engine in dll file Main.exe - just winmain(..) with startup code to initialize the engine.dll Engine.dll - the engine core stuff Game.dll - the game specefic code what are the pros/cons with the different solutions? personally I would choose number 1 or 3 becouse then I can use the same engine in the editor and engine

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Yeah, game.exe + engine.dll is the most logic approach. If you improve the engine code without changing the API, you can get a new version of the .dll without recompiling the .exe. Most of Windows' dlls should (*should*) work this way.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nemesis2k2
The lines between 1 and 3 mostly dissolve when you use scripted content. At any rate, don't use 2, for the reason you already mentioned.


i have to disagree

in my opinion 2 is the best choice of all

1. moving the engine into the exe and the gamecode into the dll allows you to give the game code to the modding community
2. you can update the engine without having to worry about the gamedlls to become uncompatible
3. you can avoid a lot of cheats by moving the engine into the exe
e.g. you can overload function pointers of the engine dll and set a dll between the exe and the engine dll which for example allows you to implement a wallhack

or aimbots .... doing this with the engine in the exe is a lot more difficult

Share this post


Link to post
Share on other sites
That depends.

If you are doing this game for exercise, then put both inside. However if you'd like to make true engine, you should put it in dll with set of neat interfaces.

This way you can :
- optimize engine without touching the game
- split relationship between game object (actor) and engine object (model)
- quickly test some engine stuff (because you already have framework)
- make working on editor and game very easy

The cons are:
- upgrading engine interfaces means rebuilding game code base

Share this post


Link to post
Share on other sites
I was working on an engine for a bit as a side project, and one bonus you get from splitting things into dll's ( or even static libs for that matter ), is that the game compiles faster. I had my engine as one huge project, and it would take minutes to compile and link, but once I turned it into manageable chunks it compiled much faster. So, just a thought.

Share this post


Link to post
Share on other sites
Professional games seem to either have the engine in an executable and the game in a dynamic library (Quake 1/2/3, Half-Life, Doom 3, etc), or have the engine in separate libraries and the game as a set of scripts (Unreal, Unreal Tournament, Serious Sam).

The approach Id Software took with their product is actually the simplest. The engine acts as a sort of "game operating system", and the game code does not have to worry with initialization of anything, it just runs on top of the engine.

Share this post


Link to post
Share on other sites
Quote:
Original post by INVERSED
I was working on an engine for a bit as a side project, and one bonus you get from splitting things into dll's ( or even static libs for that matter ), is that the game compiles faster. I had my engine as one huge project, and it would take minutes to compile and link, but once I turned it into manageable chunks it compiled much faster. So, just a thought.


That's because you stopped recompiling the same code over and over, even though some of it hadn't changed. The same can be accomplished by saving your object files and only calling the linker when you build your project.

Share this post


Link to post
Share on other sites
[quote]Original post by Thunder_Hawk
Quote:
Original post by INVERSED
That's because you stopped recompiling the same code over and over, even though some of it hadn't changed.


I'm not sure if that's the only reason because the time to do a complete recompile on the new project is noticeably shorter than the recompile on the old project despite the fact that the new project has more code.

I've always thought that putting all or at least some of the game code in a dll is kind of cool a la Half-Life. Someone else mentioned it, but you can then distribute an SDK and make the game modable, or to allow for custom interfaces. Of course you could argue that you could just do that through scripting or some other means, but all approaches have their perks and flaws.

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
Quote:
Original post by Nemesis2k2
The lines between 1 and 3 mostly dissolve when you use scripted content. At any rate, don't use 2, for the reason you already mentioned.


i have to disagree

in my opinion 2 is the best choice of all

1. moving the engine into the exe and the gamecode into the dll allows you to give the game code to the modding community
2. you can update the engine without having to worry about the gamedlls to become uncompatible
3. you can avoid a lot of cheats by moving the engine into the exe
e.g. you can overload function pointers of the engine dll and set a dll between the exe and the engine dll which for example allows you to implement a wallhack

or aimbots .... doing this with the engine in the exe is a lot more difficult

There are several critical problems that putting the engine into the exe causes:
1. You bind your engine to the OS it's running on. Porting between platforms will now require you to modify your engine, not your game code. Your 3D engine should be platform independent (IMO anyway).
2. You lock your engine into one specific startup sequence, over which you no longer have control. If I want my engine to run inside my level editor, in a child window of my main window, initialised, freed, and generally controlled by my editor, I would have to make a seperate editor version of my engine in order to do that.

Besides, as I mentioned, scripting removes 99% of your game content from the equasion. For example, in my game, I'm going to have an engine dll, my main exe (which is little more than my basecode), and my scripts (which in my case are actually in dll's, but true scripts would take the same place). My game content is seperated from my basecode, which is seperated from my engine.

And anyway, you can still do what you said in points 1 and 2 in this system. As for security, if you're going to release your game code, that point is bogus anyway, and if you don't, you can always do things like stripping the name decoration on your functions, leaving them to guess the parameters, or even discarding the names entirely, and referring to them by ordinate numbers, which you provide names for and bind to pointers in your include file. Still, the biggest threat is still from simple trainers rather than sophisticated engine hacks. Most of the useful stuff to modify will still be buried inside your game content, which if you're using a dll or a precompiled script is pretty safe. Your 3D engine should be seperate from all that anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nemesis2k2
1. You bind your engine to the OS it's running on. Porting between platforms will now require you to modify your engine, not your game code. Your 3D engine should be platform independent (IMO anyway).


Uh, same goes when you put the engine into a DLL. You're going to need a different version for each platform you want to support.

Quote:
2. You lock your engine into one specific startup sequence, over which you no longer have control. If I want my engine to run inside my level editor, in a child window of my main window, initialised, freed, and generally controlled by my editor, I would have to make a seperate editor version of my engine in order to do that.


I don't see why you would want the engine in the editor... It would be better to have the editor in the engine (See Doom 3), if you're going with such integration approach.

In my case, the editor simply uses components from the engine (like the rendering system)... It has no need for the majority of the engine facilities, but could still use their code if needed.

Quote:
Besides, as I mentioned, scripting removes 99% of your game content from the equasion. For example, in my game, I'm going to have an engine dll, my main exe (which is little more than my basecode), and my scripts (which in my case are actually in dll's, but true scripts would take the same place). My game content is seperated from my basecode, which is seperated from my engine.


Scripting does not really matter here. But I would find it more logical, if you're going with scripting, to have the engine as an exe. That way, you don't have to write up an extra program to load the engine and your scripts... The engine itself can do it. Having the engine in an exe leaves you plenty of freedom for your implementation.

Quote:
As for security, if you're going to release your game code, that point is bogus anyway, and if you don't, you can always do things like stripping the name decoration on your functions, leaving them to guess the parameters, or even discarding the names entirely, and referring to them by ordinate numbers, which you provide names for and bind to pointers in your include file. Still, the biggest threat is still from simple trainers rather than sophisticated engine hacks. Most of the useful stuff to modify will still be buried inside your game content, which if you're using a dll or a precompiled script is pretty safe. Your 3D engine should be seperate from all that anyway.


When it comes to modability, games that follow the Id Software path (Quake X, Half-Life, Doom 3), are king. Id Software and Valve released the code for their game libraries, allowing modders to change the behavior of the game completely. Modders have full access to the game code, and no access to the engine (which they don't need to modify anyways, since it already works). There were hundreds of mods released for Half-Life, many of which are still popular today (CS, Natural Selection, etc). On the other hand, games like serious sam, which go with a multi-library approach... Which other games did that anyways ;) ?

Share this post


Link to post
Share on other sites
Quote:
Uh, same goes when you put the engine into a DLL. You're going to need a different version for each platform you want to support.

True enough. Putting it into a DLL however reduces it to a simple recompile, rather than changing components of the code in order to do it. IMO you shouldn't have to change any code in your 3D engine to port it, or else it's not abstract enough. Putting the OS bound startup code in with the engine breaks that. This is a personal opinion of mine however. Other people might not stick to this rule.

Quote:
I don't see why you would want the engine in the editor... It would be better to have the editor in the engine (See Doom 3), if you're going with such integration approach. In my case, the editor simply uses components from the engine (like the rendering system)... It has no need for the majority of the engine facilities, but could still use their code if needed.

IMO, editors built inside the game itself are ugly and difficult to use, and never as intuitive as a good windows interface. I will be making my editor with a windows interface. The simple fact however is your engine is suppost to be as flexable as possible. I should be able to choose under what circumstances I start my 3D engine, and to what surface it is bound. What if I don't want my engine to be fully initialized as soon as my editor starts? What if I want two versions of my engine running at any one time? Both of these will be true for my editor, and my engine should not restrict me on that point. It shouldn't care when it's started, or what it's drawing onto. That's not its job.

Quote:
Scripting does not really matter here. But I would find it more logical, if you're going with scripting, to have the engine as an exe. That way, you don't have to write up an extra program to load the engine and your scripts... The engine itself can do it. Having the engine in an exe leaves you plenty of freedom for your implementation.

No it doesn't. When you leave the engine in control of both creating the window and setting itself up, then just grabbing the game content when it's ready to go, you totally restrict the circunstances under which you can run your engine (ie, this editor issue).

Quote:
When it comes to modability, games that follow the Id Software path (Quake X, Half-Life, Doom 3), are king. Id Software and Valve released the code for their game libraries, allowing modders to change the behavior of the game completely. Modders have full access to the game code, and no access to the engine (which they don't need to modify anyways, since it already works). There were hundreds of mods released for Half-Life, many of which are still popular today (CS, Natural Selection, etc). On the other hand, games like serious sam, which go with a multi-library approach... Which other games did that anyways ;) ?

If you give them the game code, you always expose the interface between the game code and the 3D engine, which is the security issue that was talked about and I was responding to. This causes the exact same issues of access that putting the engine in a DLL does. If you agree this is doesn't cause problems, then you're just agreeing with me.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nemesis2k2
True enough. Putting it into a DLL however reduces it to a simple recompile


*Yawn* Your engine is going to need to use platform specific code one way or another, and is going to need more than a "simple recompile", even if its in a dynamic library. I would say its actually easier to make a portable executable than a portable library.

Quote:
IMO, editors built inside the game itself are ugly and difficult to use, and never as intuitive as a good windows interface.


The Doom 3 editor is in the doom engine and has its own window. Nobody ever said the editor had to be *inside* the actual game.

Quote:
What if I want two versions of my engine running at any one time?


Run multiple binaries at the same time.

Quote:
It shouldn't care when it's started, or what it's drawing onto. That's not its job.


The engine should initialize itself and worry about the rendering. It should do all that for you. Its job it to take care of the grunt tasks and let you work on the actual game.

Quote:
If you give them the game code, you always expose the interface between the game code and the 3D engine, which is the security issue that was talked about and I was responding to. This causes the exact same issues of access that putting the engine in a DLL does. If you agree this is doesn't cause problems, then you're just agreeing with me.


I was talking about modability. And I said the Id Software engine generations are kind at modability :D And they have the engine in an executable, and the game in a dynamic library.

Share this post


Link to post
Share on other sites
We obviously have different opinions about what the engine should do, and what its scope should be, so I guess I'll just leave this where it is. Suffice to say, the engine being bound to the exe makes the thing too restricted for my purposes. Whether or not it would be too restrictive for another person all depends on your definition of what an "engine" is, what you define its scope as, and what arbitrary restrictions you place on the way it can be used when designing it.

So yeah, I guess this question really can't be answered at all. When you sit down and flesh out all these issues about your engine, it should become quite clear which structure you will need. It really comes back to what you need to get out of the engine. (talking to the topic creator here of course, not you max).

Share this post


Link to post
Share on other sites
Quote:
We obviously have different opinions about what the engine should do, and what its scope should be, so I guess I'll just leave this where it is. Suffice to say, the engine being bound to the exe makes the thing too restricted for my purposes. Whether or not it would be too restrictive for another person all depends on your definition of what an "engine" is, what you define its scope as, and what arbitrary restrictions you place on the way it can be used when designing it.


The restrictions of your engine are those you make it to have. Creating the engine as an executable, you can do everything you would do if you were to create it in a dynamic library. Its just simpler to use.

Quote:
So yeah, I guess this question really can't be answered at all.


All questions can be answered. The fact that so many successful commercial engines go with the engine as an executable approach should give you a hint that this approach is quite efficient. I have played many games, and I do not remember of any that used the approach you described.

I remember the "Genesis3D" engine used it... But I also remember that this engine was very painful to use. I never saw any finished game using it (except the demo they provided with it)... And not, it was not because of the lack of documentation (there was documentation)... Quake 2 had nearly no documentation with the game code, same for Half-Life, yet hundreds of mods were made for both games. And no, this is not because Genesis3D lacked interest... People were interested in it.

Share this post


Link to post
Share on other sites
Quote:
The restrictions of your engine are those you make it to have. Creating the engine as an executable, you can do everything you would do if you were to create it in a dynamic library. Its just simpler to use.

I need to clarify what you mean by having the engine "as an executable". Would this include the engine being in a seperate static lib which is included as part of the executable? If so, I'll agree. If not, you're totally wrong.

Quote:
All questions can be answered. The fact that so many successful commercial engines go with the engine as an executable approach should give you a hint that this approach is quite efficient. I have played many games, and I do not remember of any that used the approach you described.

Just because something is in wide use doesn't mean it's good. There are a few "traditional" things about game engine design I think could be done a lot better (eg, engine "modes". *shudder*), but they're still widely used today. Why? Because most people will just default to tried and tested rather than trying to invent new approaches.

Anyway, once again, if you count the engine being as a static lib, then I agree with you anyway, and we've been debating for nothing. If not, I'll counter this properly.

Share this post


Link to post
Share on other sites
It think it depends mainly on speed but also on ease of use. Quake had physics in the exe while the scripts described the motion needed. The quake engine moved the entities internally and reported events to the scripts. In quake2 the physics moved to the single game dll. Since physics was no longer a speed bottleneck and it gave modders a chance to modify the physics of quake2. Undoubtably, everyone will make different arrangements to meet their needs. One issue of dlls is versioning and that could get a bit complex if everything is in dlls and you're moving thru numerous product releases.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nemesis2k2
I need to clarify what you mean by having the engine "as an executable". Would this include the engine being in a seperate static lib which is included as part of the executable? If so, I'll agree. If not, you're totally wrong.


I don't necessarily mean in a static library. I have my engine compiled directly into an executable. The difference is that I have some shared components, such as the renderer, which can be compiled into any of my other projects (such as the map editor).

Quote:
Just because something is in wide use doesn't mean it's good. There are a few "traditional" things about game engine design I think could be done a lot better (eg, engine "modes". *shudder*), but they're still widely used today. Why? Because most people will just default to tried and tested rather than trying to invent new approaches.


The "engine in a dynamic library and game in an executable" approach is tried and tested. Its not practical.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Max_Payne
The "engine in a dynamic library and game in an executable" approach is tried and tested. Its not practical.


Worked for FarCry.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Anonymous Poster
Quote:
Original post by Max_Payne
The "engine in a dynamic library and game in an executable" approach is tried and tested. Its not practical.


Worked for FarCry.


and a little thing called "Unreal"

-neurokaotix

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
-neurokaotix

and he continues to leave his mark on gamedev....

In my opinion its just personal prefrence. They both work for diffrent magor companies. I personally Im doing game in .lib
(I hate dll files to my core, they had hurt me deep last time I used them) and engine in exe.

Share this post


Link to post
Share on other sites
Quote:
I don't necessarily mean in a static library. I have my engine compiled directly into an executable. The difference is that I have some shared components, such as the renderer, which can be compiled into any of my other projects (such as the map editor).

Well in that case, no, you can't do everything you could with it as if it was in a dll, or even a lib for that matter. It goes back to my original point. When you put the engine in charge of creating its own drawing surface and initializing itself, then have it only call any of your code when it's all ready to go, you can't really do anything with it anymore, other than run the game. In my editor, the engine is going to be running in a child window of my editor. How can I do that if the engine is responsible for creating its own window? Sould I now bloat out that engine basecode and add a thousand functions for overriding the default window creation options, for every situation in which I might want to create that window? What if I decide I want to do something slightly different with my engine, such as render to a movie instead? If I control the drawing surface, both of those are dead easy. If I don't, they're nigh impossible.

Quote:
The "engine in a dynamic library and game in an executable" approach is tried and tested. Its not practical.

What makes it impractical? You're gonna have to qualify this one, because IMO it's totally baseless. You can implement all three of these systems (in the exe, static lib, dynamic lib) in about 5 minutes, and all three of them appear the exact same way when the engine source is bound to your application. You just call a function, you don't know or care if that comes from a lib, dll, or attached source. All you do is include a header. The differences are organisational.



And once again, the real issue here is the word "as". You're saying you should have the engine as the exe, not just in the exe. Hell, if the engine I was using came as 300 uncompiled source files I had to dump into my project, it would still give me all the flexability I would need, it would just be messy. Having the engine as the exe however would make it virtually impossible to use that engine outside the context of just playing the actual game, and that is the problem I have with that approach. I now have no choice over how I can use the engine, it decides that for me. Would you use something like OpenGL or DirectX if they were actual programs that had to launch in a seperate window, the creation poroperties of which you had no control over, and you had no chance to run any code before that window was created? Suppose I wanted to render to a small pane of my windows app instead. I couldn't, unless the afore mentioned million extra functions were added to get around the fact it was too inflexible to start with. That would not be suitable for a rendering API, and it's not suitable for a 3D engine.

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