Hello ! In order do design my first game and get as much experience as possible form that, I decided to make both an engine and a game (using that engine, if it isnt obvious) I think that I have 2 basic choices for that: 1) Make my engine the executable and the program entry point, then link it to the game logic dll whose functionality will be exposed through an API. 2) Make my engine a DLL, expose its functionality through an API, and make the game logic an executable that will use the engine. Which do you think is the best ? (If any at all ?) I just want to mention that I have been working with 2 professionnal "real-world" game titles so far and both used approach 1, which at first glance seems less natural than 2, IMO. Regards, Janta. Edit: I got myself confused with the numbers. Now it is fixed. [Edited by - janta on May 28, 2006 9:46:23 PM]

Quote:Original post by Sr_Guapo
I would personally choose the second path. It seems more natural to me to have the game running and request the engine to do tasks (initialize, update, render, etc). It seems silly to have the engine request the game logic to process itself.

True, but in fact, things would happen like: run the engine > call the dll entry point.

From that point the the GL dll will issue all sorts of commands to the engine API. So in fact, the GL API is in fact just some sort of GameLogicMain() function.

It seems to me more simple to build something like that, because befor you create the game, you have to create the engine. So if your engine is a dll, you have to write a sample game from the begining (ar write all your engine and test at the end which seems crazy)

Well the truh is that there probably isnt just one truth, but I'm still interested in what people think.

Quote:
Edit: Of course, a hybrid approach may be the best. You have a small driver application that calls the engine through a DLL. Also, all the game logic (game state, AI, etc.) is controlled by external scripts, run from the driver app. That seem to be a perfectly logical approach to me.

Do you mean that the GL and the engine would not communicate directly with each other ?

It makes more sense to me to have the engine in the executable, although that's probably harder to set up and debug. The Half-Life series works like that with it's mods - the mods are just DLLs that are loaded by the executable.

While I agree that the 2 are similar and both correct, the first one is more widely used in video games, as far as I know. The reason is that your engine should be the game's abstraction layer. It can be thought of as your game's OS. So, with the game in a DLL and the engine in binary, you can run 2 copies of the game in memory at once. While you could do it the other way, keep in mind that a DLL only contains one instance of its code in memory, which is shared among all EXEs that use it. So with the GL in a DLL, you can share all game logic code between instances, while keeping the actual data (loaded resources, network connections, etc) seperate from each other.

To understand this, you have to think of your engine as the program, not the library that the program uses. Think of it like the operating system that runs your game, not just the API that your game uses. This is the most common approach, as far as I know. This also allows your game to stay the same, even if you update the engine. Because the game will load the same resources and play exactly the same as previous versions, while your engine may be continuously updated to add new Graphics API features, more in depth physics support (or support for that new physics card that I want so badly...) or faster AI processes.

Hope this helps. And if I have incorrect information here, please let me know.

- Enosch