Original post by Thunder_HawkQuote: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.
have the engine in the .exe or .dll file?
Well, there's also the factor that being a .dll, you are defering linking until runtime.
Quote:Original post by BasirorQuote: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.
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 ;) ?
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.
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.
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).
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).
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
