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:

Engine

- 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.

Render

- 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.

Scripting

- This project only contains the code for AngelScript and Scripting::init() for setting it all up.

Runtime

- 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?

Your going to need these as well

UI : handles logic and events from user and handles stateful transitions of UI views.

Persistence and Packing : handles the serialization and deserialization of game states and objects.

AI : handles higher level intensive AI logic ( visibility checks, A*, optimization algor, behavior trees, etc.. ) which ever is appropriate for your game.

Making a "full" game engine is a herculean task these days, even pros don't do that anymore. They usually license out a 3rd party engine like Cryengine, UDK, Unity, etc.. The ones which do go for it, usually spend years on their engine only to see tech eclipse them and pass them buy ( unless your R*, EA, Bungie which can spend lots $$$$ on it to evolve with the times ).

If this is jut for learning go for it, but don't try to make the be-all engine.. Just get a handle on the overall picture..

Good Luck!

If is a larger software, take a look at the Component Based Entity System Architecture. Can be a little off-topic, but can save your time if you are interested to get a modular engine.

ddn3:

Thanks!

You didn't really answer my question though, its not so much what I need as how I'm going to organize everything. Also as for what you've said about the troubles of developing a custom engine, I've thought long and hard about its merits vs. acquiring a license, and I've decided that for what I'm trying to achieve there doesn't seem to be anything out there that is well geared towards my goals. I'll be using plenty of libraries and middleware to ease the development process, and as far as staying on the tip of the technology curve, that has never really been my concern; as long as my game looks good, runs well, and is fun, then I'm happy.

Anyway, thanks for your reply!

irlanrobson:

I've had a lot of experience with the component-object model with Unity and other engines that employ a similar architecture, and I've decided to get as far away from it as possible. I'm sure there's people out there like yourself that work well with that particular solution, and I think that's great because you should be able to use whatever you find works best for you. Personally, I've found it to be a truly awful way of dealing with game logic and development, because you end up with random behavior scripts all over the place, and modifying behaviors can create unexpected domino effects as you can't be sure exactly what is using that component. In a strictly OO scenario, if I modify a class I know exactly what is being affected: instances of that class and those that inherent from it. If I'm creating a Katana, I want it to be an instance of the 'Sword' class which extends the 'Weapon' class, not an object with an equip ability and a swing ability and a damage ability and whatever other components it might need. Maybe its just how I think, I don't know, but I really don't like that system (believe me, I've tried to get used to it). I don't mean to offend you at all, if that system is how you like to develop games then that's awesome. I just personally don't like it.

Again, thanks for the response!

ddn3:

Thanks!

You didn't really answer my question though, its not so much what I need as how I'm going to organize everything. Also as for what you've said about the troubles of developing a custom engine, I've thought long and hard about its merits vs. acquiring a license, and I've decided that for what I'm trying to achieve there doesn't seem to be anything out there that is well geared towards my goals. I'll be using plenty of libraries and middleware to ease the development process, and as far as staying on the tip of the technology curve, that has never really been my concern; as long as my game looks good, runs well, and is fun, then I'm happy.

Anyway, thanks for your reply!

irlanrobson:

I've had a lot of experience with the component-object model with Unity and other engines that employ a similar architecture, and I've decided to get as far away from it as possible. I'm sure there's people out there like yourself that work well with that particular solution, and I think that's great because you should be able to use whatever you find works best for you. Personally, I've found it to be a truly awful way of dealing with game logic and development, because you end up with random behavior scripts all over the place, and modifying behaviors can create unexpected domino effects as you can't be sure exactly what is using that component. In a strictly OO scenario, if I modify a class I know exactly what is being affected: instances of that class and those that inherent from it. If I'm writing a 'Weapon', I want it to be a weapon, not an object with an equip ability and a swing ability and a damage ability and whatever other components it might need. Maybe its just how I think, I don't know, but I really don't like that system (believe me, I've tried to get used to it). I don't mean to offend you at all, if that system is how you like to develop games then that's awesome. I just personally don't like it.

Again, thanks for the response!

No problem. I've just gave you an option. Personally I never got a full implemented ECS. The communication between components becomes hard stuff. I'm currently doing a mixing of OOP Strategies, Component-Based, Functional Programming to get my engine working. Otherwise, I'm the creator of the engine and I want to get things made by me not just copying Unity's code and putting on my project even knowing that Unity has a powerfull Component Based System.

Thanks everybody for the helpful feedback! I've decided I'm going to go with the first solution I proposed, which is to spend more time encapsulating everything.

Krohm:

I respectfully disagree. While writing this game engine, I've learned so much more and had so much more fun than I've ever have had in my coding experience, so I don't see why you would ever tell someone not to write a game engine (besides, they're probably sick of people telling them that anyway, as I can tell you that every time I've asked a question, somebody has tried to tell me not to do it). I'd go as far to say that every aspiring game programmer should at least attempt to write a game engine at some point in their career. This engine is the product of my free time over the past four months, and I have no intention of stopping now. I'm sure you mean well, but I have to ignore you on that point.

Aldacron:

I already own that book, and I also highly recommend it to anyone interested in writing their own game engine. There are a few points it does not cover (this being one of them) but over all it has plenty of tips that will save you hours of pain.

Anyway, thank you all again!

When it comes to physics I can tell you we're talking about <1000 LOC.

Really? I'm extremely skeptical of that one. Seems like the rudimentary collision logic for my tile-based 2D game was at least 500, all things considered. Granted, it was pretty bad and I wrote it while running a pretty high fever (it all made perfect sense at the time, and it even almost worked).

I'm in the early stages of working on a simple C++/DirectX engine as well, and found this topic while looking for discussions on the subject. Surprisingly difficult to find useful information; mostly just sloppy "here's how you render a single cube" tutorials and posts linking to said tutorials, or to that Game Engine Architecture book*. The biggest problem I'm having is figuring out in what order to work on things; I keep running into situations where I need a functioning x to test y, but I can't write x without a functioning y. And, of course, before I can think of a resolution, I get distracted by the realization that I have no idea how to handle z and spend the rest of the day reading z-related topics here and on stackexchange. I think a step-by-step list of generic steps/goals for incrementally putting together a game engine would be immensely helpful, but I've yet to find such a thing.

One useful tidbit I learned over the weekend: don't try source diving the various open source 3D engines in hopes of finding some best practice, or a common architectural thread that'll make everything clear--you won't find one. But you will find demotivation. And a headache.

*Off-topic, but seriously, they've delayed the 2nd edition by over a year at this point--Amazon had it listed as coming out early May 2013 when I first saw it, then October, then March, and now it's late May 2014. I'm not going to buy the first edition with a second imminent, nor will I preorder the second edition with it looking like it's going to pull a Duke Nukem Forever... Bad marketing strategy, tbqh. If they hadn't announced the second edition, I'd have bought the first a year ago.