Tuesday, October 23, 2012

Saving for Tomorrow

One of the bigger challenges when starting a project, particularly if this is your first project, is you have to write so much code before you see anything on this screen. This can be terribly demoralizing as you simply don't have anything to measure progress besides the number of source files in your depot (you are using source control right?). While there are a number of engines freely available that can help you speed up that process, if you are trying to create your own baseline of technology there are a few simple things you can do to make sure you only have to pay that initial code debt once.

Creating a re-usable Framework

The main concept in creating a framework you can use for multiple projects is to distinguish between game specific code(most likely in the form of gameplay related behaviors/systems) and generic systems that have nothing to do with the actual form game itself takes.

As you can see, our framework contains all the code we would use regardless of the type of game we are making. It has handles basic functionality like rendering API calls, entity management, random utilities like random number generators, and anything else any type of game may need. All this functionality is compiled as a DLL or static library (I tend to prefer static libraries myself as they help avoid DLL hell). Once your game links against the library, the game then can access all our frameworks functionality as needed and implement any game specific classes/systems to as required. So, while your framework might contain an abstract interface class for entities (let's call it IEntity), the game itself would create any game specific classes (let's say a RaceCar for a race game, and ShooterGuy for an FPS) that simply inherit from IEntity. The framework's management system will handle those objects just fine(it already knows about IEntity and works within that interface) and your game gets to use a reliable system that you're familiar with without having to write more than a handful of lines of code.  So while you'll still have to write the system the first time, once you've paid that cost it's done. No matter how many games you create, you can re-use that existing code greatly speeding up your development all because you took a few moments to organize your systems properly.
Now the only caveat with a re-usable framework, especially if you are working on multiple projects at once, is that you be very careful you don't put (or remove) anything that another game may be using(or could cause instability). Remember, this framework is linked to by... well, all the projects you link it to. Imagine you have 3 guys at a buffet. Guy A and B love potatoes and keep going to fill up their plate with them. Guy C just doesn't feel like potatoes so he removes them. Guy A and B are going to be pissed. So, leave the potatoes, even if you don't need them right this minute.

Setting Up/Statically Linking against your Framework (Quick Tutorial)

If you've never created a static library before, here's a quick tutorial. It's very easy but I figure it's better to be thorough than make assumptions. Quick note, I'm using Visual Studio 2010 Pro Edition, but this setup hasn't change since... well, a long time (I seem to remember 6.0 still working like this) so it should be fine for 2005 through 2012 and onwards. As always, see your IDE documentation, the MSDN, or Google if you have any questions for your specific version.

  • Create a new Solution / Project. Name it whatever you want. I'll use Framework just to be consistent with what I've written on this post.
  • Right click on your Project in the Solution Explorer and select "Properties". 
  • You're going to want to set the "Configuration" drop down to "All Configurations" instead of just "Active (...)".
  • Set your "Configuration Type" to "Static Library" and hit Ok! Build and you should now have "(yourProjectName).lib" in the respective Debug/Release directory.

  • Create a new Solution / Project for your game.
  • Open the Properties for your game and add the directory your framework library was outputted to your list of library directories. You also want to point the linker to where you are keeping you're header files for your framework.

  • Link to your library and start coding away!

Hope you guys enjoyed it. As always, feel free to comment or email if you have any questions or have your own tips to share.

P.S. The image at the top of this blog is from Game Dev Story, check it out on iOS/Android if you haven't already.

Sunday, October 14, 2012

Setting the Stage

I figured I'd use this first blog post to do something I rarely see other game development focused blogs do, give some hints and tips before you write a single line of code. Whether you are an industry professional or a hobbyist, these items will make your life much easier and help make you more productive. I'm going to skip over things like IDEs as that could swallow a few pages and then some, but in the end everyone has their own preference and that's what it normally comes down to. On to the tools!

Source Control

By far one of the most important items to setup before you begin a project is source control. Even if you are a team of one, source control allows for easy backing up of your code, complete control on what code goes into trunk, branching for risky changes, and a definitive time lapse view of the changes to your code base. I cannot tell you how many times source control has saved my life by allowing me to revert changes I made while debugging or just authoring a system and deciding it wasn't quite setup the way I wanted. You can also double the effectiveness of your source control by signing up for a free online storage solution, like Dropbox, and having your code depot output to whatever folder is watched by that storage solution. This gives you free online back up of all submitted code. Now if your computer explodes at least you still have your months/years of code to comfort you as you recover in the hospital from computer shrapnel.

Perforce (p4v client)

As far as what source control to use, I highly suggest Perforce. Not only is it trivial to setup, it's free for small teams (you're limited to 2 users), has numerous tutorials available online, and is pretty much the industry standard in game development (at least in my experience).

Note: My experience with the Perforce plugin for Visual Studio is that it is dubious at best. I would recommend just using the p4v client and checking things out as you work on them. If you're the only user, you can even be really lazy and check out the entire depot and just revert unchanged files before submitting.

Graphics Debugging

Graphics hardware is becoming increasingly important as GPUs are moving to be extra processors for the CPU to send tasks in addition to rendering vast amounts of geometry. Unfortunately, debugging shader code is a nightmare without any tools to help you make sense of what is happening with all your various buffers and the data you fed to the GPU.

If you are developing using DirectX as your graphics API, the DirectX SDK comes with PIX. PIX is an amazing tool that offers a variety of experiments to help you drill down and see exactly what is in your vertex/index buffers and how that data is transformed as it goes through the pipeline. You can step through shader code (albeit in assembly) and get pixel history information as well.


One of the newer tools that was recently released for NVIDIA hardware is NVIDIA Nsight (for Visual Studio and Eclipse). I've only recently begun using it in conjunction with PIX but so far it is incredibly helpful (you need 2 machines to effectively use it as Nsight will be sending debug commands to the target GPU and could cause the machine to reboot unexpectedly). The support for breakpoints, auto/local variables, and profiling information is a much welcomed addition to my shader debugging toolbox. NSight works with OpenGL / DirectX 9 - 11 / OpenCL / CUDA .


For you AMD(formerly ATI) folks, AMD has a page with all the tools they support with their GPU chip sets. Unfortunately I don't have much experience with these tools so I can't give quite as in depth review of them. Give them a shot and let me know how well they work for you!

A (Better) Text Editor

This one is easy. Get a better text editor besides Notepad, gedit, or vi. Personally I like Textpad but I've heard great things about Notepad++ as well. You will be shocked how a good text editor will make your life much easier whether you are just taking notes as you work on a problem, documenting a system, or editing some text based meta file (i.e. XML).


I think that's about it. I could probably ramble off a few more tools but those 3 categories are by far the most important and what I go to install anytime I'm setting up a new machine or beginning a new project. If you have any questions, or would simply like to add a tool that you find helpful, feel free to comment. Next time I'll talk about organizing your code to create a code nest egg of sorts that allows you to quickly get projects up and running all while building up your technology base.