A few weeks ago a fellow game developer asked me how on earth I can be so productive, having a kid, wife, house, cars, daytime job, etc. I actually did not reflect much on it and I don't feel like I'm some productivity guru. On the other hand I do have picked up some good(?) habits along the way, and I guess making 25 releases of a game in a 50 weeks is somewhat productive. So these are my tips on productivity, they are of course biased towards on making indie computer games in general and programming in particular.

Stay Motivated

Making a PC game is not a 100m dash. At least not if your goal is to release it as shareware and have some people buy it. Making a PC game is more like a marathon, or maybe an ultra marathon. Be prepared for about a year in development time, and the hard part is actually to stay motivated and not jump to another seemingly more exiting project.

For me, key to staying motivated is iterative game development. For years I also kept on developing games, but not making any public releases. Needless to say none of the projects where remotely finished.

You need to find a way to cultivate your burning desire so that you don't spend it all the first month.

Get a Good Laptop

Good tools are a must to stay motivated and there are great productivity enhancing tools out there. I experienced a productivity boost when I got myself a good laptop. It's a high end one, with a full keyboard (including the numpad), good gpu and such. Using it I can stay productive during tv-commercials, 10-minute breaks, when traveling etc.

Leverage Your Compiler

My main tool is my compiler, and I tend to use it as much as possible. Over the years I have developed a style of coding that is intended to produce compiler or linker errors, instead of hard to find runtime errors. I tend to compile and compile for every line I write and having a bunch of compiler errors to fix is an automatic to do list. When I make a code change I want the compiler or linker to tell me where the code is broken, and not have some strange bug show up in some super-generic object oriented piece of over engineered game code.

I also tend to reject script languages for the fact that I don't want another source of bugs. If I need some code, I can simply make it in C++, use the compiler to my advantage and that's it.

Micro Task

To keep productive you need to have a backlog of tasks, and they need to be small. You simply cannot have huge tasks when you get 10 or 20 minutes of coding every now and then. Having a pool of small, micro tasks, that you can just pick up and finish one off is a great productivity enhancer. Also all big tasks can definitely be broken down into many smaller ones.

You should of course use a tool to track and manage your task.

Don't Finish Tasks

You should of course finish tasks, but I have found that the timing when finishing them can increase your productivity.

I have noticed myself is that I have a hard time to start fresh on a new task. It seems as taking those first steps is the hardest part. You can probably get passed this by just using discipline. But I have found that if I don't finish a task completely, (leaving the code broken with some compiler/linker errors) I tend to have a much easier time of picking up the pace. Then I make sure that I start a new task, which now is much easier since I'm already into development mode, before stopping and leaving the code broken for the next time I find a few minutes for development.

Use Source Control

You need to have all files, and I mean all, under some version control. Even if you are the only developer. This also goes for artists creating content and don't forget the original versions of the game assets. Having an optimized, resized texture in source control is actually less important than having the original, huge, layered psd original file under control.

Have a Normal Life

Finally you really need to have an ordinary life, with family, friends, exercise, healthy good food and non development related stuff. You really really need this to not burn out on your first project. I have seen great developers burning out on game projects, leaving their passion for games behind, starting a whole new career.

Making games is at times painful, dreary work, at the same time it can be wonderful, creative, passionate and exiting.

Would be cool to know if you have any similar experiences, or do you have some other productivity tip to share?

In the latest download of our shoot em up pc game TWTPB, iteration 23, I implemented basic game pad support. There are a number of issues with this implementation maybe the most prominent one being that it does not handle plugging in and out the game pad during play. I think that it is probably a common scenario to plug in a game pad after the game has started.

This is a short tutorial on how to get your game to react when an usb device, such as a game pad, is plugged in or removed from the computer. This is handy when using the DirectInput api. XInput handles this in a transparent way which is nice, but alas there are many game controls that are not XInput compatible so when developing a pc game you probably need support for both plain DirectInput devices and XInput devices. This tutorial is Windows specific and in the C++ language.

It is not that hard to get a message when a device is added or removed, but it involves some rarely used win32 code that I spent a good few hour trying to get to work.

To start things off Windows sends you the handy WM_DEVICECHANGE windows message message when a device is plugged in or removed from the pc. So in your window message handling function you should have something like this:


WndProc(HWND a_hWnd, UINT a_msg, WPARAM a_wparam, LPARAM a_lparam) {
   switch (a_msg) {
       ...
       case WM_DEVICECHANGE:
           if (a_wparam == DBT_DEVICEARRIVAL) {
               // Device plugged in code goes here
           } else if (a_wparam == DBT_DEVICEREMOVECOMPLETE) {
              // Device removed
           }
       break;
       ...
   }
   ...
}


The there are also a number of other messages sent in the wparam parameter. So the tricky part here is that you won't get the DBT_DEVICEARRIVAL or DBT_DEVICEREMOVECOMPLETE as a default. You will only get a number of DBT_DEVNODES_CHANGED messages whether a device is plugged in or removed and this is obviously not what we want in our game code.

You will have to tell Windows that you want additional information when a device is added. You can do this with the RegisterDeviceNotification function. This function is quite complicated and takes a number of strange parameters. I for one love when a function has a void pointer as a parameter, it's great, you can just send anything down there

Anyway the thing we want is to listen to in our game is the device broadcast messages. The following code sets that up. I added this to my window creation function since you need a window handle to the main window, declared as m_hWnd in the code below. The setup is actually much easier than you think by looking at the docs.


DEV_BROADCAST_DEVICEINTERFACE notificationFilter;
ZeroMemory(&notificationFilter, sizeof(notificationFilter));
 
notificationFilter.dbcc_devicetype = DBT_DEVTYP_DEVICEINTERFACE;
notificationFilter.dbcc_size = sizeof(notificationFilter);
 
HDEVNOTIFY hDevNotify;
hDevNotify = RegisterDeviceNotification(m_hWnd, &notificationFilter,
   DEVICE_NOTIFY_WINDOW_HANDLE |
   DEVICE_NOTIFY_ALL_INTERFACE_CLASSES);
 
if(hDevNotify == NULL) {
   // do some error handling
}


By using the handy DEVICE_NOTIFY_ALL_INTERFACE_CLASSES flag we can skip most parameters in the notificationFilter parameter except type and size.

Also for this code to even compile you also need to have WINVER defined >= 0x0500 like


#define WINVER 0x0500


Now Windows will send you all messages when a game pad is attached or removed from the pc and you can take the appropriate action in your game code.

Hope you'll find this short article/tutorial handy! Feel free to comment or suggest improvements.

Ok... Today I read one of the most sucky articles on game tools ever. Of course it was made by a game industry veteran and published over at gamasutra. I won't link it since it was the suck! The example the author used even involved void pointers being cast to correct internal data structures... omg and these people call themselves professionals!

There are essentially three important things in game tool development:

Integrated Editor

For efficient real time editing the editor must be integrated into your game. This way you can easily switch to an editor when you spot something that is off. You also only have one code base to maintain and it will be true wysiwyg. Another advantage is that the game and editor loads and use the same data files and formats, this also means that if your game changes your compiler will help you since the code will not compile.

The other two points actually are just help to realize this requirement.

Model - View - Controller

The basic architecture of any game should be based on the model view controller patterns. This pattern will help you separate your actual game (rules, ai, whatnot) from your graphics rendering. There are some various flavors and implementation details that is much up to your own taste in things. I use an "it's free to read but writes are formalized via an interface" approach. This basically means that the views use a const reference to the model and get to read public data directly.

Basically your editor is a specialized view for, you guessed it, editing some aspect of your game.

The Model - View - Controller pattern is explained in various books and of course online.

IMGUI

Immediate mode GUI or IMGUI is simply the best way to realize a gui in a real time application. There are excellent imgui articles out there so I will not go into details. Basically imgui is the opposite to a big, bloated, object oriented gui framework where everything inherits from a "window" class.

And yes, you can do drag 'n drop, windows, sliders and all that gui fanciness with imgui.

A good starting point for imgui knowledge

Thats it! If you stick to these points your game editors will be next best thing to sliced bread, and you can focus on making your game!

The site now features nice urls, nice as in readable, for most content. This is supposedly really good for search engines and also it is way better for us humans to have a url that actually means something.

In Drupal this can be easily achieved with the pathauto module that depends on path and token modules. Easily, is of course relative

I've been putting this work off for a long time mainly because it requires you to think about how your site should be organized. This is actually quite hard, since your decisions tend to live for a long time. Also it involves a somewhat risky bulk update of the site and database. These things are always a bit scary to do.

My plan of attack was to use a test installation and make experiments on it, and then go live. I spent a few hours last night making the changes and it did take a while before I got the hang of it and found a structure that I was satisfied with.

Then came the live part ... actually things went great. The servers we are currently running on is way faster than my private dedicated setup, so the update was made in a few seconds. As of now all seems to work just fine. Yay!

And I did some updates to the pc video game list. You now got a small description and a download link readily available.

Some of you might have noticed that I have made a new TWTPB trailer. If not check it out below. I uploaded it to vimeo (among others) I have taken a liking to vimeo as they offer higher quality than most other video uploading services. Anyway I'd thought I'd take a moment and describe how I usually make videos and trailers like this.

Creating a Game Play Video

1. Record Game Play

I use Fraps to record various tidbits of game play. I typically record quite long sessions. I always record without music since it would be very strange to have different snippets of music playing all the time. There are probably ways of stripping the music/sound, but I often want the sound effects in there.

2. Edit

I really have very little knowledge about this and there are probably a bunch of softwares out there in various price ranges. I have found that Windows Movie Maker (that came preinstalled on my Vista HP laptop) works fine for me. I will let you add sound, transitions and texts. You don't have full control and there are probably limitations on what you can achieve.

I have spent the last few weeks using and learning test driven development.

Test driven development means you write a test for your code before you write the actual code. At first it seems like you do more work, but you really gain time from it.

• You spend more time thinking on how a function/class should work before you write it. If you write the test first and the function prototypes (empty functions) so the test fails, you know when you are done (because the test succeeds)
• You can run the tests directly after compiling the code when you make some changes, this gives you confidence that your code works!
• When you find bugs you first try to reproduce them inside the test, and then you correct them inside the code -> Less chance you will run into that bug ever again.
• When you are forced to write tests your code will be easier to test automatically since you write the code for testing.
• It is fun to fulfill tests, it feels good!
• Less manual testing, many manual testcases can be automated, i have rewritten some of my user interface code so it can be automatically tested.
• You get example code for how to use the class

If you can read this it means that my efforts to migrate the site has been successful! We are now working on a completely new host that has more performance and reliability.

If all is ok... I will tell you more in a while

Update!

Seems that all is working ok. There has been some glitches and missing files, but I think I have nailed them down now. The file hierarchy and database was a mess Don't hesitate to tell us if you find something erroneous.

Anyway, we're now live and kicking again, and our new host that is specialized in drupal will allow us to continue to kick ass and develop the community and site further