I am logically laying out my game, and am debating where is the best place to put the game engine itself. I am thinking to put it in a DLL and the graphics engine in the main EXE file, since there probably will be a better chance of patches to the EXE itself, and if I want to go to a different engine, I just have to do a new EXE. Kind of a bizzare to look at it, but I hope to make the game modular enough so that I only have to alter the graphics engine and data files to create a new game. Of course then, I''d have to assume that I have embedded the menu options, etc in the graphics engine or in another DLL.
The DLL''s I plan on doing alread are: AI, NET, and SOUND. I might add another for just reading data. I might be making this harder than what I should, but I want reusability, and hopefully portability by simply changing the graphics engine and recompilling the DLL''s.
I think modularity is a great thing. I dont know much about dll''s, but if theyre like .so''s (shared objects) i think it would be cool to have the executable act like a client, and the dll''s like servers.
DLL''s are easy, just do a DLL project under M$ VC++ and make sure that you point your main project to look for the DLL''s .exp and .lib files. When you embed the DLL as a subproject, just make sure that it is compiled before it is needed.
DLL''s are just M$ version of the .so file. I haven''t tried doing shared objects under linux, yet. I''ll do that when I have something tangible to port to it.
I have been playing around with both ideas (engine in exe or dll) and my conclusion was that it doesn''t make any real difference.
The only thing is that if you keep the exe small and load the dll''s during initialization you are able to other things while the dll''s are loading such as showing a small animation or something like that. To do this the exe should not be anything else than a small file and everything else is put in dll''s.