# Standard Project Structure Layout

This topic is 1331 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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.

##### Share on other sites

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.

Edited by DiegoSLTS

##### Share on other sites
You can use the Module Approach. Make a library for each module you have. Eg.: Graphics Library, Terrain Library, Spatial Library (Octree, BSP, etc.), etc., Math Library, etc.
The final application (your Engine in the simplest case) links everything. Note that the library itself can include the header of other libraries if it wants to do, don't make the mistake of link one library to another. Also, this helps on creating interfaces for the modules. I'm currently using this approach and if you want more information shoot me an PM!

Eg.:

Model Library includes GraphicsLibrary.h, MathLibrary.h
ModelConverter (an application) links MathLibrary.lib to make an final .exe.
Engine (an application for the sake of simplicity) include and links GraphicsLibrary.lib, MathLibrary.lib to make an final .exe.

This way you can define a Game just being a State Machine.
Edited by Irlan

##### Share on other sites

First, you can create file-system folders that mirror the project folders ("filters" in VS parlance) so that you don't have name collisions, not that you should anyhow, but it helps for general organization. When you add a new file through the VS interface, just be sure you're creating it in the place where you want it to be, and to use the context menu of the filter you want it to appear under. (right-click, add new-file / add existing-file)

Other than that it sounds like you're over-complicating things, and are experiencing paralysis by analysis. If this is your first real C++ undertaking, my recommendation is to not try to build some abstract engine. Yes, keep engine code separate from game code as best you can, but your first project, fist engine, first anything in C++ is not likely to be something you'll do well enough that you won't want to do it over next time. Make your game, make a little-e engine to support it, and only it -- don't try to make a Big-E Engine from the start.

A typical structure I have for a game project is three folders -- One for game assets, one for game code, and one for engine code. In a simple project, these are usually just folders/filters under a single VS project. In something a little more complex, these are each projects under a VS solution, with dependencies set accordingly to facilitate the correct build order. Game assets include graphics, sounds, music, maps, configuration data, and possibly scripts (I put them here, some people might consider them part of the game code,) I make a folder for each type of asset. Game code includes all code that implements game-specific features or logic (possibly with scripts), if you put scripts here, I'd make it a folder from the start -- for other code files, I don't separate them out into folders by feature area until it seems necessary -- often on moderate-sized projects, it never becomes necessary. Engine code is basically the same, but you generally have a better idea of what broad feature areas exist and can make some broad organizational bins early -- Graphics, Sound, Input, Platform, Math.

In general, you should prefer to avoid making deeply-nested folders as an organizational technique. Extra layers of folders can make things more complicated than they need be, if you ever need to make custom build rules. Try to stay relatively flat until you're convinced the extra layers give you value. You don't have to have the right, final structure from the start. Moving things around is just another kind of refactoring.

##### Share on other sites

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!

##### Share on other sites

Here is my latest attempt:

##### Share on other sites

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.

Edited by Irlan

##### Share on other sites

I would suggest actually implementing the thing before going overboard organizing your project. Drafting a quick hierarchy to get you started is fine, since you will eventually refactor it by pushing things around over time while implementing your code. But spending inordinate amounts of energy architecting your project before having even started is a surefire way to spin your wheels in the mud - so to speak - and completely lose motivation in my experience (and is kind of a waste of time since you will be modifying your project layout later on anyway - no nontrivial project ever gets designed 100% right on the first day).

##### Share on other sites

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 ;)

Edited by Slyvampy

##### Share on other sites

I would say from my own perspective that things like assets and scripts certainly do not belong in the engine folder. They're part of what makes the game the game, not part of what makes the engine the engine. Your engine might have a scripting directory that implements the scripting engine and/or binds it to your other engine facilities. Likewise a scripting directory in your game directory that binds it to game-specific facilities.

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.

Looks like you're planning for War and Peace to me. The danger of over-engineering your directory structure so early is that it informs your mental-model of how your engine "is" even before you've written it. You risk not allowing correct lines to emerge for themselves because they might not fit your pre-existing notions. Planning is good, and broad-strokes are appropriate at this stage, but anything more is premature.

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 ;)

Stay away from Singletons in C++. Technically, with a C++11-compliant compiler (The "magic statics" feature) you can finally implement singletons without technical impediment, however, they're still a poor design for many reasons. They sometimes have a place retrofitting old code, or in systems where there really, truly is just one of something (typically, only in embedded programming or OS development) but they are not appropriate simply because you "only want one". Singleton is appropriate only when two of something cannot coexist, when that thing is globally important, and when that thing must live for the entirety of the code. Often, people make singletons because they find themselves wanting a global data structure of some kind, they know "globals are bad", and since a singleton "feels like object-oriented programming", they use it to feel better about it. If you really do need exactly one global something that exists for the life of the program, just define one in the global scope, you don't need to convolute that with a singleton -- but you should prefer to avoid globals (and singletons) where you can (almost always), and prefer explicit dependency injection.

I have a small-moderate-sized engine I've evolved over the years that includes typical "singleton manager" candidates like resource management and I have exactly zero singletons in my codebase. Not in the engine, not in the game code. Nowhere.

• 45
• 12
• 10
• 10
• 9
• ### Forum Statistics

• Total Topics
631373
• Total Posts
2999631
×