How to get Game Coding Complete's directory structure working in Visual C++ 2012

I like Mr. Mike's directory structure he uses for his Visual C++ projects, but I use a slightly modified structure. Either way can be a pain to set up, so I thought I'd write up some instructions how to get my structure working. I'm using Visual Studio 2012, but it should be the same in 2010 as well. Also, I only use two configurations: Debug and Release. If you ever want to add a Profile configuration you should be able to follow these instructions to configure it similarly.

Be sure to buy Mr. Mike and Rez's book, Game Coding Complete 4th Edition. It's an epic tome of game programming knowledge written by proven veterans of the AAA game industry.

Let's get started..

Here's what the folder structure will look like:

MyGame/       -root folder
  Assets/     -raw image and sound files (files NOT used by the game)
  Docs/       -documentation files
    Internal/ -internal docs
    External/ -external docs
  Game/       -game executables and data (images/soundFX/music/etc)
  Lib/        -game engine library files
  Source/     -code root folder (no files go directly under Source)
    MyGame/   -code files for MyGame project
      MSVC/   -solution/project files for MyGame
  Temp/       -temporary linker/build files

* Open Visual Studio
* File -> New -> Project
* Visual C++ -> Empty Project
* Name your project, click OK
* Create the folder structure above within Windows Explorer

At this point, the solution file is saved in the root folder, but we want it under the Source/MyGame/MSVC/ folder. Select the Solution in Solution Explorer, then click File -> "Save MyGame.sln as...". Save it under the Source/MyGame/MSVC/ folder. This will save the .sln and .suo files without breaking the references.

* Close Visual Studio (save if prompted to save).
* Open the new .sln file under the MSVC folder.
* You may now delete the .sdf, .sln and .suo files in the root folder.
* Right click MyGame project -> Properties

* Select "All Configurations" from the Configuration drop-down at the top.
* Select Configuration Properties -> General on the left.
* Set Output Directory to: $(SolutionDir)..\..\..\Game\
* Set Intermediate Directory to: $(SolutionDir)..\..\..\Temp\$(ProjectName)$(PlatformName)$(Configuration)\

* Select "Debug" from the Configuration drop-down at the top. (Save changes when prompted)
* Set Target Name to: $(ProjectName)_d

* Select "All Configurations" from the Configuration drop-down at the top.
* Select Configuration Properties -> Debugging on the left.
* Make sure Command is set to: $(TargetPath)
* Set Working Directory to: $(OutDir)

* Select C/C++ -> Precompiled Headers on the left.
* Make sure Precompiled Header Output File is set to: $(IntDir)$(TargetName).pch

* Select C/C++ -> Output Files on the left.
* Make sure "ASM List Location", "Object File Name", and "Program Database File Name" are all set to: $(IntDir)

* Select Linker -> Debugging on the left.
* Make sure "Generate Program Database File" is set to: $(OutDir)$(TargetName).pdb
* Set Map File Name to: $(OutDir)$(TargetName).map

Now you can set up your filter folders under the project to mimic our folder structure above.
* Delete Header Files, Resource Files, and Source Files under the MyGame project.
* Right-click MyGame project -> Add -> New Filter. Name it "Assets".
* Keep doing this until you have the same structure, minus the Game and Temp folders, since those are the output/intermediate folders. Basically, you want anything that would belong in Source Control in your project.

Last step is to move the project files the default location of MyGame/MyGame/ to MyGame/Source/MyGame/MSVC/
* Close Visual Studio
* Move all the files under MyGame/MyGame/ to MyGame/Source/MyGame/MSVC/
* Open the .sln file in a text editor. (located at MyGame/Source/MyGame/MSVC/MyGame.sln)
* Change the path to the vcxproj file from "..\..\..\MyGame\MyGame.vcxproj" to "MyGame.vcxproj"
* Save .sln file.
* It's now safe to delete the folder MyGame/MyGame (which should be empty now).
* Done!

------------------------------

References
Game Coding Complete 4th Edition
How to relocate a Visual Studio project Solution (.sln) file

Keyboards - The Three Key Problem

When choosing default keys for your game, you might be inclined to use the spacebar in combination with the arrow keys, but there's a big problem with using those particular keys. A lot of keyboards don't allow you to press certain combinations of more than two keys at the same time. I had forgotten about this and just recently, while working on my bullet hell shooter, I started out using the spacebar and arrow keys to get my player shooting and moving. I quickly noticed that I couldn't move my player to the upper-left while pressing the spacebar. This is a pretty common problem.

So first of all, why does this happen? Shouldn't we be able to use the spacebar with two other arrow keys? Seems crazy, right? There's a simple explanation for this. This isn't a problem with the programming language or API you're using. The problem is actually the keyboard itself, and it stems from a design decision so that manufacturers can cut costs making Keyboards. Shawn Hargreaves has a good explanation, so no need for me to go into detail here.

So how do we fix it? There are better keyboards available that are tailored to gamers, but obviously you can't expect everyone who plays your game to go buy one. :) The answer is to simply use different default keys, while providing a way for the user to configure those keys. Looking at other shoot-em-ups, I've found that default keys are indeed not the spacebar and arrow keys. The Touhou series is a good example of this. The current Touhou game, Touhou 13, uses left-shift, z, x, c, and arrow keys, and doesn't use the spacebar at all. Avoiding the keyboard entirely and only supporting a gamepad is definitely not a good idea. I still have yet to hook my gamepad up to my PC, and I'm guessing there's a lot of gamers in the same boat.

A Path-finding Scenario

A* algorithm example

One big reason why I enjoy game programming so much is it makes us think outside the box. In a lot of situations, we as programmers must come up with custom solutions. One solution doesn't always work in all situations, especially when dealing with platforms with limited resources such as mobile phones. I also like to see other programmers' thought processes.

The article Path-finding For Princes by Rod-Mathisen, is a classic example of combining path-finding solutions to work best for his scenario for the iPhone. Of course, there are probably several number of solutions for his scenario, and I'm sure there are critics, but a lot of times, "whatever works" or "appears to work" in game programming is acceptable, especially if the solution is a fairly simple one.

.NET Memory Management and Garbage Collection

Clive Tong (from Red Gate) has an excellent post on The Top 5 .NET Memory Management Misconceptions, which does a great job of explaining how the .NET garbage collector works.

Now those Performance Counters listed under ".NET CLR Memory" (and debugging .NET memory issues in general) make more sense.

There's also a nice post by Ian Nicolade on High-End Performance Optimizations on the XBox 360 and Windows Phone 7 which explains some common ways to keep from generating huge amounts of garbage in apps that use potentially never-ending loops (such as games).