I'm writing a game engine in C++ using visual studio 2012, and so far its going great and I'm having a lot of fun! One problem has been creeping up on me for a while now though.
What's the best way to structure a large game engine project?
By structure, I mean how each separate piece of the engine is laid out in the solution. Currently I have it all cut up into four separate VS projects:
- Contains all custom classes and structs, from Materials to GameObjects to Quaternions. This project doesn't really DO much, its just a place to store all the bits and bobs.
- This project solely contains rendering functionality, as all the classes and types related to rendering are stored in the 'Engine' project. At the moment, all it contains is Render::init() and Render::render(), so maybe this is too small to constitute a whole project on its own.
- This project only contains the code for AngelScript and Scripting::init() for setting it all up.
- This project is what contains the main loop and interaction with whatever system you're on. My idea for making this separate is that this project should be the only one that deals with the underlying system implementation (just GLFW at the moment, but if I port to mobile or consoles the idea is that this can change without any of the other projects needing modification). This project handles starting everything up, running it all during the game, and shutting it all down at the end.
I'm also planning on adding 'Physics' and 'Network' projects once I get to those parts of the engine, and possibly a 'Resource' project that solely deals with loading and releasing external resources as the engine uses them.
When the engine is compiled, all projects are linked together as static libraries. My original idea for cutting things up so much, is so that once I start writing an editor, it can hook into rendering and scripting functions without being attached to the final runtime itself, and that if I ever want to change a certain middleware component (for example, from Bullet to Havok or from OpenGL to Directx) I can do so by only modifying the one project it relates to. While I'd like to keep this separation, I'm beginning to think that cutting it up into so many pieces may not have been the best approach. Inevitably, projects are starting to need to reference each other more and more (like the Material class in 'Engine' needs to have some OpenGL code, which should only be in the 'Render' project). The way I see it, I have two options:
- Spend more time encapsulating each project, so that there is no bleeding between them.
- Put Engine, Render, and Scripting all into one monolithic project, so that Runtime is still independant
Any thoughts on what would be the most convenient or "professional" solution to this?
Edited by Salty Boyscouts, 08 February 2014 - 06:04 PM.