Hi All

First post here, and I want to make it meaningful. Bit of a background I have been programming in scripting languages for about 10+ years professionally and although I am new to C++ and game programming as a whole I have had some experiences in the past, but I am stuck on one of the fundamentals of the initial project structure layout.

I have purchased several books, of which talk about different practices (some of which I am already familiar) however there doesn't seem to be a clear indication of what structure layout to use. (I'm using Visual studio's 2013 professional, which creates virtual folders, but means files can't have the same name) - is this good or bad?

So far I have worked out a sort of abstraction:

/Core/
/Engine/
Main

========== This broken down into ==========

/Core/

this includes the main

  Game.hpp
  Game.cpp

It also has class's like timer etc.

/Engine/

This folder has all the components in. (bit like the Entity component model)

/Engine/Entity/
/Engine/Entity/Player
/Engine/Entity/NPC

As well as other things like:

/Engine/Scene/
/Engine/Render/

Now some books recommend having this as a separate project, and saving it as a DLL file.

I also have virtual folders like

/Engine/Graphics/

Inside that we have

/Engine/Graphics/Drivers

and inside drivers, we have

Direct3D.cpp
Direct3D.hpp

and

OpenGL.cpp*
OpenGL.hpp*

* even though I am not using these for a while.

Then in the root of the application i have:

Main.hpp
Main.cpp

Now my question is rather, what is a good structured layout?
im planning on creating a really basic game, with a world, that is drawn up into zones and each zone consisting of many chunks. starting off making it a 2D top down game, then in a few years turning it into a 3D game.

So assuming this I would have a

/Engine/World/

and inside that files like

zone.cpp
zone.hpp
chunk.hpp
chunk.cpp

Now really the question is after hours of searching on the net, I can't seem to find anywhere pointing in the right direction. Some of this feels dirty, even how things are abstracted - where things go, should i be decoupling the engine as a DLL file.
How and where do things like the GUI module go, inside the engine? with a GUIManager and having virtual folders with things like InputBox and a button class?

This leads me to think about a whole host of other things, ie Input does this go in the /engine/ as /Engine/Input/ and a class for keyboard.cpp etc.?
Anyone shed some light on this for me please, I will be eternally grateful.

On a side note, I have been looking to pay for tutoring as well, I have been working with someone previously integrating things like CEGUI and OGRE3D however I think I need to go back to the basics and start small.

Any help is appreciated!

Slyvampy.

You're overcomplicating things, and also seems you're trying to get THE right answer ("standard") for things that are always done in different ways by different people.

You said you don't have experience creating a whole game from scratch, and you need experience to find a good answer to those questions. Usually you're able to plan the project structure in such level of detail if you know how to do those things and have done them at least once, or have started other projects and you can iterate over your previous solutions.

Start making the game, some of this things should take form as you go, you should notice when something is getting bigger than it should and when things are starting to look like a mess. If you notice a class is doing too much stuff, split that class in a way that makes sense. If you see that your "engine" folder has too much files, move a related group into a subfolder.

I've worked in big games and they were even split into different projects and different Visual Studio solutions, but there's no programming rule preventing your game to be just one project.

Thanks for the replies guys. I guess after reading Alan Thorn's book about Game Engine design and Implementation probably wasn't a good place to start.

Forgetting complexity, and going back to KISS, my next question really is about what to leave abstracted in the game engine, and what is considered game code. Example I have started a fresh project, setup my main and game class's so all my window etc. is setup with the 'game loop' (using peek messages etc).

Now I stick the Libraries for the render in the engine (Direct3D as an example) - that's fine. But what about things like the resource manager, does this go inside the engine (as i have it now) or do I put this outside the engine? I don't mean the actual files, i mean things like the resource manager to load the files etc, and re-size them based on the resolution set but the graphics part of the engine. (now i have a folder called Library outside both the core folder and the engine folder, this is for shared code like handling files and timers etc.) However I feel i am now making the engine dependent on an external folder of class's.

I think i am getting a little lost after reading 'Game Coding Complete, by Mike and "rez".

Is there some duplication in instantiating parts of the engine from the game logic? I am really getting lost now. I have ordered two books on structures from amazon that should be here in within the week, however a quick heads up by anyone with any experience in project structure would be awesome!

Here is my latest attempt:

Here is my latest attempt:

I'm not going to say anything about this but you're not doing wrong. The only thing that can improve your organization is to create libraries from these filters. Like the "Render" filter, so later you can use the library in another project to test something or document your engine online to help others. Organization is the primary mission for those that want an project to be good and don't be a completely waste of time.

Again thanks for the fast replies, I know from any web based project a key decision this early on without the correct planning will end up in disaster, I am not planning for 'War and peace' but I want to get off on the right foot.

I am still expanding on things like the entity component model (the entity folder) so I will have a lot of mangers in there. I supposed I have been spoilt over the last 5 years working with frameworks which pretty much tell you how things should be laid out and following best practices.

Thanks for the help so far, i still have a lot of reading to do but I am starting to implement a lot of these singleton managers now and make the glue as I go along. Watch me totally re-factor everything in a weeks time ;)