🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Where to put the game engine....
Author
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.
I think it''s pretty easy to do DLLs, though I haven''t done it. Pretty useful if you need to patch your game, only have to replace one file.
The major benefit is if you load different DLLs at run-time depending on configuration. Such as a 3D wrapper for OpenGL, Glide, Direct3D and a software-renderer.
Also a nifty way to store AI code for each unit: .dat for graphics and such, .dll for implementation.
---
I personally am going the exact opposite direction. I''m planning to tac a compressed data file to the end of my EXE and make some smaller games that don''t require installation.
- n8
nathany.com
The major benefit is if you load different DLLs at run-time depending on configuration. Such as a 3D wrapper for OpenGL, Glide, Direct3D and a software-renderer.
Also a nifty way to store AI code for each unit: .dat for graphics and such, .dll for implementation.
---
I personally am going the exact opposite direction. I''m planning to tac a compressed data file to the end of my EXE and make some smaller games that don''t require installation.
- n8
nathany.com
the best place to put the game engine is in front, under the hood, unless you''re a VW engineer in which case you may consider putting it in the back.
--
Float like a butterfly, bite like a crocodile.
--
Float like a butterfly, bite like a crocodile.
Author
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
