   Game design: Engine and game logic relationship
  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]
  I agree that the second approach seems more natural, though both work.Dosen't Quake use the first one?   ;  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.Of course both ways are 100% correct and you should choose whichever is more natural to yourself. You are the one developing the game and I doubt it really matters speedwise.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.   ;Quote:Original post by Sr_GuapoI 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 ?   ;  I'd use #2.  I've used a #1 system before and it was quite annoying.  I just didn't feel I had enough control over the engine, and that became a problem later on.  Plus, the engine is mainly functionality?  Why not have it in a functional library?   ;  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.   ;  There is a third option that you haven't considered -- both the game engine and the game logic are in separate libraries. That seems the most logical to me.;Quote:Original post by JohnBoltonThere is a third option that you haven't considered -- both the game engine and the game logic are in separate libraries. That seems the most logical to me.And don't forget that the engine will probably need several DLL's (OpenGL and Direct3D renderer implementation for instance), and that most of the game logic will actually be scripted in a scripting language [grin]   ;  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   ;  I decided to make my engine available through a Dll, not to seperate the logic from it, but so that I could link to it from a windows app.  Now I can have a full blown windows application that I can use as my editor, and with a little care you can make it available to a .NET application.As far as seperating the logic from the engine, you should look into some scripting languages.  Most games nowadays write all their game logic in a scripting language that the engine can execute.  Google DoomC, UnrealScript, Lua, Pyton, Squirrel, Angelscript, etc...   