🔒 Locked

Game Engine design decisions

Started by Chacha Jun 27, 2004 at 3:04 AM 13 replies 1.5k views

Original Post

Jun 27, 2004 at 3:04 AM

Hey everyone, I am currently doing some high-level planning for my 3D game engine, and I've come to the point where I have to decide on the main architectural design of the engine, and these are the two common options I have: A - Game in EXE, Engine in DLL: This gives the game total control, and it access the engine through certain engine interfaces. B - Engine in EXE, Game in DLL: This gives the engine total control, and it loads the game at runtime. The game part would need to implement certain functions that the engine would use to access the game, such as game-state loops and game scripts. With design A, the game knows about the engine, but the engine does not know about the game. As far as I know, this is what it should be like. The engine should not know or care how the game works. Ok, that's all good and all if I'm going to use design A, but if I choose design B, it's a different story. With design B, the game knows about the engine because it needs to use the engine for all sorts of things like rendering, physics, timing.. etc (just like with design A). BUT, the engine knows about the game too, which doesn't seem right to me. It's probably not such a big deal, but it just doesn't seem right that the engine knows about the game and vice versa. Isn't the engine supposed to be independant of the game?? Any comments on this would be very helpful. Thanks in advance. ~Chacha [Edited by - Chacha on June 29, 2004 6:48:47 AM]

Nemesis2k2

Jun 27, 2004 at 3:36 AM

I just worked through all this stuff for my own engine actually. Personally, I went with option B. I really didn't spend too long on this decision though. I figure, I want the game side to focus on just that, the game. It just makes more sence to me for my engine to initialise my game content than for my game to initialise the engine, though I'm sure a lot of people perfer it the other way around. I guess I just figured most of the time is going to be spent running around in the engine code, and I prefer the majority of time to be spent in my main exe, rather than calling other modules. Well, that's invalid anyway, because the most time will be spent rendering, running code in the opengl or direct3d driver.

Personally, I have no real good reason for the way I chose. Any things I came up with to try and justify it either way were very minor and picky. If anyone else can give a good reason for one way over the other, or some kind of convention that's generally followed, I'll probably just go along with that.

Kibble

Jun 27, 2004 at 4:45 AM

C - Both in a DLL

I went with this way, and I'm very happy with it. each platform would have a small 'kernel' exe that links it all together with the platform dependant stuff in it, and there can be more than one, like an editor.

Jis

Jun 27, 2004 at 6:05 AM

I'm going with it too, with an network dll and an ai dll perhaps(don't know for the moment for the ai)

ApochPiQ

Jun 27, 2004 at 1:16 PM

I'd personally favor Kibble's approach. I've recently started using modular designs for all of my software and the benefits in code reuse are incredible. Basically now I have frameworks for several different types of applications, and the specific behaviors can all be plugged in through a unified interface that I use. Once I get enough code stored up I'll be able to write entire applications without needing to write much new code. It's a great approach and I highly recommend it.

Etnu

Jun 27, 2004 at 1:42 PM

Option D - everything in an EXE, and only put stuff in a DLL if the program gets to the point where redownloading updates would be prohibitive.

Pluggable renderers are largely overrated, honestly. You're not going to be using multiple engines on the same OS, and you're going to be changing other things (besides the core engine) on different platforms anyway (hell, even main() is different on windows vs. other platforms).

At the end of the day, for different distrubtions, you'll STILL need to recompile the game code AND the engine code for each platform you want to support. *shrug*

ApochPiQ

Jun 27, 2004 at 1:50 PM

I can't speak for the others but personally I'm not talking about swapping rendering APIs or anything like that. The approach I use is purely for code reuse, and I've already been able to reuse huge chunks of different apps simply by designing around the kernel/plugin paradigm.

TangentZ

Jun 27, 2004 at 2:16 PM

Option E - Engine in DLLs, everything related to game
in scripting language (e.g. Lua), and a simple driver EXE.

Pros - Modification is extremely easy
Cons - Execution speed is slower (somewhat)

An example of this is Far Cry.

valkyr

Jun 27, 2004 at 9:34 PM

Scuse my noobity, but I have a question about scripting languages for game content.

The only scripting language I'm familiar with is Python, and I'm a huge fan of Python. I'm not to the point yet were I can code games, but I'm sure when I am I'll use Python for scripting.

Now, when you use Python, you're files are interpreted therefore, anyone can just open the files up and view the source, right? Are all scripting languages like this? Is it a bad thing people can just steal your game content source?

I guess not... UT content is viewable and it's good for mods. As long as your engine isn't accessible, right? I suppose it's personal preference, but i just wanna know pro's/cons of scripting besides speed.

Nemesis2k2

Jun 28, 2004 at 1:30 AM

Quote:
Option D - everything in an EXE, and only put stuff in a DLL if the program gets to the point where redownloading updates would be prohibitive.

I'm making my engine with mods in mind. I'm seperating all the game content to allow people to make new AI scripts and whatnot, then compile them into a new DLL without having to rebuild the entire game. I'm using compiled DLL's, so it's not scripting as such, but whatever.

Quote:
Now, when you use Python, you're files are interpreted therefore, anyone can just open the files up and view the source, right? Are all scripting languages like this? Is it a bad thing people can just steal your game content source?

I'm not sure about python, but a lot of scripting languages can be compiled down to intermediate bytecode, where all the names and high level constructs are stripped. This makes your scripts about as intuitive as your main program when its compiled.

Frankly though, I don't think people worry that much about thier scripts being viewable. I wouldn't. It also makes people a lot more interested in making mods for your game, which can build up a huge fanbase and keep your game alive for years longer. I really got into Duke Nukem 3D for example when I started developing my own levels for it. I only even bought the full version because I was making levels and mods for it, and it kept me playing with the thing for about 3 years longer than I would have otherwise. Making your game moddable is a great idea IMO.

evolutional

Jun 28, 2004 at 1:38 AM

Option F) Build a library of functions to acheive a certain task which is then used as building blocks to build your individual game. This has the power of not being tied to a specific genre or type of operation.

Nemesis2k2

Jun 28, 2004 at 1:44 AM

Well, I'll be doing that as well. My main exe will basically just be the OS specific basecode, with all the libraries included and initialised. It still all ends up in one exe file though.

Pxtl

Jun 28, 2004 at 1:39 PM

Loader in exe, engine in C DLL, everything else in C# or Java. Just make sure that everything you could ever want to bind to in your engine is exposed to the C#/Java API.

C#/Java - the power of a scripting language, the speed of a native language... only problem is that its the legibility of a native language - I love reading Python.

Nairou

Jun 28, 2004 at 2:46 PM

Option G - Engine in EXE, Game in scripts.

Like what TangentZ said, though I never really saw the point of using DLLs. Except for maybe the Renderer, but even that isn't something that necessarily needs to be swapped at run-time.

You have the Engine in the main EXE, which starts up the game environment, defines the execution model, and provides all the library bulk. Then use scripts for the game menus, event scripting, gametypes, etc.

No game engine is completely generic, it is always designed with a certain type of game in mind, so there's little point of trying to modularize it at run-time.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.