Ok, so this week I've been setting up the file directory, the coding standards, and the testing framework that our engine is going to use.
These things are might seem minor, but they have a huge impact on your project over it's lifetime. Well, maybe the file structure isn't as important, but it's very important to be able to test your code easily and to have a uniform code layout across the project. Code standards, a file structure, and a testing framework should be in place early so that everyone can code with them in mind.
File Structure
The file structure I'm probably going to go with for the SqueakyClean project looks like this:
Docs/
TDD/
GDD/
Milestone Reports/
Assets/
Audio/
Textures/
etc../
Source/
Math/
Meta/
Test/
MathTests/
MetaTests/
Temp/
Game_2010Win32Debug/
Lib/
vs2010/
Debug/
Release/
Proj/
vs2010/
Math/
[sln goes here]
Dependencies/
python/
gmock/
Game/
Help/
Data/
bin/
ini/
res/
[exe, dlls go here]
Docs contains any of the documents that the team might create, these don't ship with the game.
Assets is any of the raw assets that are going into your game, these aren't converted into a game format yet.
Source and Test contains all of your .h/.cpp/.etc files that get compiled with your game. I separate tests from game source because I don't want to ship or compile test code for submission builds. Some people separate header and inline files from their source files so that they can ship an include directory with their library, so that's something to keep in mind depending on your project.
Temp stores all of the .obj files and other temporary files that are created when compiling the solution.
Lib stores the compiled static libraries (and pdbs) for libraries that get compiled by us. (Ie not external libraries like gmock or python.)
Proj is where the solution and the project files get stored.
Dependencies is for where all external libraries (libraries that the game doesn't build) are stored. If there are dlls that need to be next to the executable, I copy them into the game directory when I build the game.
Game is where the games executable is built. Any other files that get shipped to the player are also stored here, like manuals and readmes. Compiled are assets are stored in the Game/Data/bin/ folder and all config files are stored Game/Data/ini/. Other game resources are stored in Game/Data/res/ (including json object serialization files).
This set up allows me to only ship a few folders to other devs on the team if they need to build the game ( the Depedendencies, Source, Test, Assets, and Docs folders ).
Premake
In order to build the game, I use premake4. premake is a build configuration system that makes setting up new projects a lot easier than doing them manually through Visual Studio. (Oh, I pretty much only use Visual Studio for development. Other than for school assignments, I've never had a reason not to use it. ) Especially early in a project, it's important that devs can make new project easily. premake makes that possible.
My premake file automatically makes a test file for every library file that is created (because I don't want there to be any reason not to test code in the engine!) and force included a precompiled header in each project. Some people don't like force included files (and their concerns are valid), but I believe that force including a precompiled header is ok. It makes one less step for a dev to remember when adding new files in the game.
Testing
Testing is the most important thing you can do to give your game a chance at success. There are so many benefits, that I'll probably end up writing another post about it. But to summarize: By testing your code you're making it easy to make changes later; you're making it easy for someone to look over your tests and see how your code is used; and you're making it easier to design great code. The best part about it is that all of these benefits come with very little downfalls. Testing doesn't require any more time, but it does require a little more thought. (Thinking before you code is a good thing, I assure you!)
To that end, I use the google testing framework. It is super easy to use and seems to be designed for games. gtest makes testing very easy and very effecient, meaning there's no reason not to test code.
Ok, so that was a quick overview of the very, very beginnings of the project. Next I'll post a roadmap of what the first things that need to be coded are.
Cheers!
These things are might seem minor, but they have a huge impact on your project over it's lifetime. Well, maybe the file structure isn't as important, but it's very important to be able to test your code easily and to have a uniform code layout across the project. Code standards, a file structure, and a testing framework should be in place early so that everyone can code with them in mind.
File Structure
The file structure I'm probably going to go with for the SqueakyClean project looks like this:
Docs/
TDD/
GDD/
Milestone Reports/
Assets/
Audio/
Textures/
etc../
Source/
Math/
Meta/
Test/
MathTests/
MetaTests/
Temp/
Game_2010Win32Debug/
Lib/
vs2010/
Debug/
Release/
Proj/
vs2010/
Math/
[sln goes here]
Dependencies/
python/
gmock/
Game/
Help/
Data/
bin/
ini/
res/
[exe, dlls go here]
Docs contains any of the documents that the team might create, these don't ship with the game.
Assets is any of the raw assets that are going into your game, these aren't converted into a game format yet.
Source and Test contains all of your .h/.cpp/.etc files that get compiled with your game. I separate tests from game source because I don't want to ship or compile test code for submission builds. Some people separate header and inline files from their source files so that they can ship an include directory with their library, so that's something to keep in mind depending on your project.
Temp stores all of the .obj files and other temporary files that are created when compiling the solution.
Lib stores the compiled static libraries (and pdbs) for libraries that get compiled by us. (Ie not external libraries like gmock or python.)
Proj is where the solution and the project files get stored.
Dependencies is for where all external libraries (libraries that the game doesn't build) are stored. If there are dlls that need to be next to the executable, I copy them into the game directory when I build the game.
Game is where the games executable is built. Any other files that get shipped to the player are also stored here, like manuals and readmes. Compiled are assets are stored in the Game/Data/bin/ folder and all config files are stored Game/Data/ini/. Other game resources are stored in Game/Data/res/ (including json object serialization files).
This set up allows me to only ship a few folders to other devs on the team if they need to build the game ( the Depedendencies, Source, Test, Assets, and Docs folders ).
Premake
In order to build the game, I use premake4. premake is a build configuration system that makes setting up new projects a lot easier than doing them manually through Visual Studio. (Oh, I pretty much only use Visual Studio for development. Other than for school assignments, I've never had a reason not to use it. ) Especially early in a project, it's important that devs can make new project easily. premake makes that possible.
My premake file automatically makes a test file for every library file that is created (because I don't want there to be any reason not to test code in the engine!) and force included a precompiled header in each project. Some people don't like force included files (and their concerns are valid), but I believe that force including a precompiled header is ok. It makes one less step for a dev to remember when adding new files in the game.
Testing
Testing is the most important thing you can do to give your game a chance at success. There are so many benefits, that I'll probably end up writing another post about it. But to summarize: By testing your code you're making it easy to make changes later; you're making it easy for someone to look over your tests and see how your code is used; and you're making it easier to design great code. The best part about it is that all of these benefits come with very little downfalls. Testing doesn't require any more time, but it does require a little more thought. (Thinking before you code is a good thing, I assure you!)
To that end, I use the google testing framework. It is super easy to use and seems to be designed for games. gtest makes testing very easy and very effecient, meaning there's no reason not to test code.
Ok, so that was a quick overview of the very, very beginnings of the project. Next I'll post a roadmap of what the first things that need to be coded are.
Cheers!
Categories:
SqueakyClean