The Project

One thing I've learned over the course of developing my engine is that how you setup your project is important. If done correctly you can limit the number of crazy project settings you have and generally simplify and speedup development. Ok I'll admit alot of this is just to satisfy my personal coder OCD.

I don't have coder OCD at work but in my personal projects I'm anal to the extreme. Admittedly this is a problem that kills productivity but it does lead to what I consider to be nice code/projects. I'll address my code OCD in a future blog. For now I'll visit what I consider to be good rules for project settings. I suspect that a real build engineer will laugh at some of what I say but I think most of this reasonable.

The first thing to know is what you are trying to accomplish. My goal in regards to my engine is always simplicity. I want it to be as easy to work with and understand as possible. I want to reduce the number of project setting. This makes it easier to add new projects or to copy to a new machine etc. I want to be able to support multiple configurations win32/x64/xbox easily. This way if my target platform changes I can switch with it easily.

I've found there are a couple of categories of components that make up my project. I believe each to be essential but you may find you only have a few. That said here is how my project is broken up.

• Libs


• 3rdParty


• Apps


• UnitTests


• Plugins


• Wrappers


• Resources

Libs this is all the code libraries that make up my engine. I have graphics libraries, xml libraries etc etc. This is the engine really or atleast the portion that I code. I group all my libs under one folder. So it looks like "MyProject/Libs/graphics". There are two great benefits from putting all your cody libs in one folder. You can map one additional include path in your projects and then all your include paths look the same. So if I add "MyProject/Libs" to my include path then in any project that I wish to use my graphics library I can access it's header files by saying #include . This is great because you know where your header is coming from so if you have two myheader.h files it's clear which you are using. This same principle holds true for linking. You set your lib files to export to (soldir)/(Platform)/(debug)/libname. Then you only map one link dir. The use of visual studio macros makes everything work so nicely. Note as a general rule I try to do all my project editing on all configurations.

3rdParty directory is for all external libraries that are going to in general be unique to the game engine. So boost and directx would not go in here but some version of lua or antlr might. Really I think everything should go in here but I basically just put things in here that don't have installers. The reason to put external libs here is if you want to backup or do source control on your stuff it's easy to avoid grabbing this directory. It can also have benefits for include paths and linking similar to the libs directory. Not always though because there's no controlling how third party libs are layed out. Do not manually arrange third party libs. This should be obvious but basically once you change it you have to maintain your change.

Apps is the directory for all the applications you make using your engine. If you make one game or 100 test apps they all go here. The basic idea is you can setup most of the project settings once and then reuse when making a new app. Sometimes for one reason or another you may want to pull your app off into it's own solution. In that case put the .sln file for your new app at the same level as the .sln for the main project. Again this is so project settings stay the same.

UnitTest is the directory for unittesting individual libraries. I highly recommend unittesting libraries but that is another topic. Basically the advantage here is just to group all these together and similar to the apps directory to setup identical sets of project settings.

Plugins directory is just another grouping for items dependant on the libs directory. I try to keep these things seperate because I think it looks nice.

Wrappers is the directory for libs that have been wrapped for another language. If you want to expose a library for use in C# or python then you would put the code in here.

Resources is the directory for sharing common art assets across multiple projects. The idea is it's easy to setup common paths to art resources for different projects. In practice this is likely to change.

A long time ago I learned to setup project for use with make. Then I learned all the good stuff that is visual studio. Now I'm in the process of heading the other direction. I'm going to continue with visual studio for now but I tend to think I might use something different in the future.

I really had a lot more to say about project setup but I'm tired of writing about it. Which in my mind means 99% of people probably didn't read this far. If you take that number out of the 0 people that visit this blog then you see why I'm stoppoing.

Gareth