All fields of games development (programming, art, writing, design, sound, etc) require concentration and the application of skills learnt over years. There’s an intangible “zone” where you feel fully focussed and do your best work that’s not easy to get into, and far too easy to fall out of. Some days you can spend hours in the “zone”, other days not at all.

The Internet

Being honest, this is the big one for me. A friend might send me a link to a webcomic I’ve not seen before and before I know it, an hour has passed and I’ve read half the archive, or I’ll look something up on Wikipedia and end up reading a stream of completely different (though fascinating) articles.

A Welcome Distraction?

This isn’t always a bad thing though. Sometimes when you’re stuck on a problem, you need a welcome distraction to help your mind see it from a fresh perspective and the internet is more than willing to provide this.

Social networks are an example. I’ve certainly found twitter to be very useful as you can get advice and tips from other game devs who have tackled similar problems to what you’re working on, but social networks are still a bad distraction at times (facebook in particular is becoming much more noise than signal these days for me).

Also, now that I’m an indie developer, the social networks provide vital channels for promoting and building awareness of the game I’m building.

Dealing With The Internet

Simply pulling the plug doesn’t help, because the internet is a vast and immensely valuable resource used all the time for our jobs, so it takes a conscious effort to stay productive with an onslaught of information and entertainment at your fingertips. The trick is in limiting the time spent, and it’s something I’ve struggled with at times, but there are strategies.

For example, I recently went on holiday for a week and returned to find almost 1,000 unread items in Google Reader – that’s in the order of 50,000 a year! I immediately decided to remove the highest volume subscriptions (mostly comedy sites such as Memebase), and now the flow is much more manageable.

Closing browser tabs is another good plan and only checking the networks at particular times of day rather than leaving them open all day. The social networks all seem to put an unread message count in the browser tab, which is a siren call for the easily distracted. Close the tabs till later, and the temptation is gone.

“AAA” Office Distractions

For most of my career, I’ve worked in open plan offices with many other people. This is the usual layout in most “AAA” game studios. There’s a certain background noise to all this that you learn to tune out – air conditioning, PC and dev kit cooling fans (who remembers the noise of the early PS3 dev kits?), traffic outside, etc. If this was all there was to it, then avoiding distractions would be easy, but there are other things which need to be managed in this sort of studio.

Meetings

You’re working away, deep in the middle of a problem when “DING!”, up pops Outlook’s meeting reminder on your screen telling you there’s a meeting in five minutes about a feature the team is due to start in a few weeks’ time. You have to then shunt all the things you were thinking of out of your mind, gather your notes and start thinking about what you need to say in the meeting. When the meeting is over, it’s going to take a while to get back up to speed on what you were working on.

Unfortunately, the human mind can’t suspend and resume threads as thoroughly and quickly as a computer can, so this  process of switching thought processes from one subject to another has an overhead. It not only takes time to get from one train of thought to another, but I find it saps mental energy and makes you tired quicker than focussing on one task for an extended period.

There isn’t really an ideal solution for this. Meetings need to happen to help the people working on a feature or team all understand what each other is doing, and they can’t realistically be scheduled for times when everyone has just finished a task and has the time.

The only workable strategy is to think hard when you get a meeting request about whether you really need to be there, rejecting those for which you believe you will have little input. You ought to be able to read the minutes of the meeting afterwards if you need to know what happened (assuming anyone is actually taking minutes, which I’ve found is uncommon in the games industry). Rejecting meeting requests has another benefit, in that meetings with fewer people tend to be more focussed, so are more likely to finish on time and stay on topic (I have no scientific data for that, only my own experience and anecdotal evidence).

If you’re creating meetings, sometimes the conclusions of a small meeting can be passed to most people in a daily catchup rather than inviting them all. However, it’s sometimes a good idea to mark the other people as “optional” in a meeting as sometimes people don’t like things being decided in meetings without their input. If they know that the meeting is going to take place and decide not to attend, they can’t complain about this.

I’ve also known people and teams that enforce a “No Meeting Day”, once a week or fortnight, which lets people concentrate and get work done without this distraction.

“Can I ask a quick question?”

You’re deep in concentration when you get a tap on the shoulder. Someone want to ask you a question. You don’t know the answer, but you know (or think you know) who does, so you point them in the right direction. You turn back to your work, blink a few times and realise you can’t remember exactly where you were up to, so it costs you a few minutes to get back on track.

This is a tricky one to manage. I like to be open and would much prefer to answer any questions people have for me straight away, then have people sit there stewing because they think I’d shout at them for distracting me. In theory, the people to go to with questions are the leads, because it’s part of their job to mentor their team and deal with communication with people in other teams.

However, in reality you will sometimes know that Person A knows the most about a particular feature/level/thing because they built it, so it’s best to go directly to them rather than disturb their lead, who will then disturb Person A, which would lead to more people distracted and losing time. I guess what I’m saying here is, when you have a question to ask – try to make sure you know who to ask directly – if not, go to the lead. Person A could also help minimise this by creating an intranet wiki page about the feature which answers common questions.

Another way to deal with this distraction is to tell people something like “This afternoon, I want to really concentrate and get X finished, so can you please ask me no questions unless it’s an emergency. Thanks!”, although you probably wouldn’t want to do that too often as people might then become reluctant to ask you anything.

Background Chatter

With a lot of people in an office, there’s inevitably going to be chatter going on. The usual remedy is to put on a pair of headphones and listen to music in your own little world instead (I prefer non-vocal ambient electronica when working, but the choice of music is up to you – if death metal works, then so be it). Just make sure the headphones aren’t leaking sound to other people. This works well in an office, but I’ll talk a little more about music being a distraction later on in the article!

Indie Distractions

You’d think that without meetings, people asking questions or background chatter it’d be easy to get more work done. Think of all that time spend in the “zone”!

This is partially true – I’ve certainly found that I’m more productive in general working in our spare bedroom on my own than I was in a large office, but indie life comes with its own distractions.

Making Money

Like many indie developers, my project is self-funded (but YOU CAN HELP – shameless plug!). I say self-funded, what I really mean is wife-funded because the vast majority of the money that’s paying the household bills comes from her part time work and contracting. I’ve earned a little bit of money here and there, but she’s definitely the bread winner at the moment. As we have two pre-school children, this means that whilst she’s out earning money, I’m at home looking after the children otherwise that money would be going straight into the coffers of the local nursery.

This week is an extreme example. I had a few hours to work on Monday morning, and today (Thursday), I’ve found enough time to write this article. Next week I should be able to work a normal 40 hour week, but it varies wildly and it’s something I’ve had to get used to. It’s a problem that will mostly solve itself when both children are old enough to go to school, but for now it’s a constant frustration.

Lots Of Different Tasks To Choose From

When you’re making a game on your own, you do everything. However, with freedom comes a lack of structure, which means that it’s easy to put a tricky task off (such as building levels) and do something else (such as optimising shaders) instead. It’s all progress that adds up to the final game, but really the levels need building before shaving cycles off the lighting code.

I guess the solution is to hire a producer, though I can’t afford one so instead I’ll just have to become more disciplined with my scheduling.

Music

Earlier, I said music is a good way to avoid the distraction of background chatter in an office. When I started as an indie developer, I continued this habit, but then realised that without any conscious effort, I sometimes wasn’t putting my headphones on when at my desk. Eventually, I realised that the music itself was a distraction from work, though a lesser one than background chatter. Now I rarely listen to music when working, only occasionally when the children are being particularly noisy downstairs or a neighbour is trimming their hedge or something like that. So little music that I cancelled my Spotify subscription (saving a valuable £60 a year) as the ten free hours a month is more than enough for me.

Conclusion

I certainly don’t have all the answers on avoiding distractions, and I still have to force myself to concentrate on the task in hand, but I hope there are a few useful titbits in this article for people. I’ve certainly made a more conscious effort to think about this in the last year or so. Thanks for reading – even if doing so has distracted you from something else!

The reason I’m writing this post is that none of the above presentations show any shader code. I hope I’m not alone in saying that I can understand an algorithm quicker with a small piece of shader code than a mathematical formula – it’s just the notation I’m used to given my day to day job.

I won’t go into detail with the many reasons why physically based shading is better – you can read all of that in the links above – suffice to say it looks better, simplifies the lighting interface for artists, and makes materials that hold up better in different lighting conditions without manual tweaking. It’s important to note that “physically based” does not necessarily mean “absolutely physically accurate” – after all we still need to run within a tight performance budget so all of the calculations below are still approximations, but it’s a big step forward compared to the old ad-hoc hodge podge of lighting that we’re used to.

Another benefit of a physically based model is that you can scale the calculations for a performance/quality trade-off as I will show further below.

Disclaimer

A prerequisite for all of this is that lighting takes place in linear space and it’s highly recommended that it is done in HDR.

It is infeasible for me to post an entire shader here as the interface for such code depends entirely on the engine in question – instead I’ll just post snippets showing the actual lighting calculations, and assume that the input have already been calculated using a method of your own choosing – perhaps interpolated from the vertex shader, fetched and decoded from a g-buffer, or some other method.

I’m not going to take into account any texture colour (albedo) – you might be doing that in the same shader as your lighting, or later on in a composition pass – but at whatever stage you do this, it’s still the classical “colour = diffuse * albedo + specular;”.

Also, I’m not taking into account any light attenuation. It’s up to you and your game how you do this.

The calculations below refer to a single light. For multiple lights you will need to repeat the calculations for each light and accumulate the results.

Lastly, please let me know if you spot any errors below! Any errors here are my own, not of the presentations linked above!

Diffuse

I’ll start with the easy bit, as the diffuse part of physically based lighting is the same Lambert model we’re all used to.

1

float3 diffuse = saturate( dot( normal, light_direction ) ) * light_colour;

From now on, I’ll refer to the saturated dot product of two vectors in the form “n_dot_l” to simplify the code, so the diffuse simply becomes

1

float3 diffuse = n_dot_l * light_colour;

Easy!

Specular

Now things start to change from what we’re used to. We’re going to use a microfacet BRDF. If you want an explanation of the equation, the presentations linked above do a far better job than I can. In shader code form, we can translate the specular BRDF into the following form

1

float3 specular = (PI / 4.0f) * specular_term * cosine_term * fresnel_term * visibility_term * light_colour;

I’ll go through each of the terms in turn and describe them.

Specular Term

A good choice for a physically based specular term in a game is Normalised Blinn-Phong. You can read the presentations linked above for the reasons and some images showing that it is a good choice. The “Normalised” part is particularly important, as it means that the specular highlight is energy conserving – as the specular power increases, the highlight should get brighter, as well as smaller. Code that implements this model looks something like this

1
2
3

float normalisation_term = ( specular_power + 2.0f ) / 2.0f * PI;
float blinn_phong = pow( n_dot_h, specular_power );    // n_dot_h is the saturated dot product of the normal and half vectors
float specular_term = normalisation_term * blinn_phong;

Earlier, I showed a (PI / 4.0f) constant multiplied into the BRDF. We can remove this by pre-multiplying it into the normalisation term as follows

1

float normalisation_term = ( specular_power + 2.0f ) / 8.0f;

This means that the specular BRDF is simplified to

1

float3 specular = specular_term * cosine_term * fresnel_term * visibility_term * light_colour;

Cosine Term

The cosine term exists to prevent specular highlights leaking to the unlit side of the objects, and helpfully also saves a conditional in the shader.

1

float cosine_term = n_dot_l;

This is the same n_dot_l from the diffuse calculation earlier, so it is essentially free.

Fresnel Term

The Fresnel term captures the phenomenon from the real world in which a specular highlight is relatively dim when the view and light vectors are both close to the surface normal, but gets brighter as the angle becomes more glancing. To show what I mean, here are two photos of a black piece of cardboard – excuse the poor quality of my phone’s camera!

When looked at head on, the specular highlight is quite dim

At a glancing angle, the specular highlight is much brighter

To do this in shader code, we shall use Schlick’s approximation of the Fresnel term, modified for microfacet rather than mirror reflection.

1
2
3

float base = 1.0f - h_dot_l;    // Dot product of half vector and light vector. No need to saturate as it can't go above 90 degrees
float exponential = pow( base, 5.0f );
float fresnel_term = specular_colour + ( 1.0f - specular_colour ) * exponential;

The specular colour is what you see in the situation in the first image, and this will interpolate towards white as the angle becomes more glancing. The surprising thing is that the colour bears very little relation to the diffuse albedo. For most non-metallic materials in the real world, the specular colour will be quite low, around 0.04, for metals this increases to 0.5 or more. You can use a monochrome or RGB specular colour (and by extension a monochrome or RGB Fresnel term), but for most materials, monochrome is fine as the specular power has a much greater impact on the visuals than the specular colour.

Visibility Term

This term describes whether the microfacets are being shadowed by the microscopic structure of the surface. It changes the appearance of the specular in a subtle but important way. Mathematically, it is the G (geometry) term from the specular BRDF equation divided by the foreshortening term (n_dot_l * n_dot_v). In the following shader code, I am using the Smith shadowing function, based on the formula in the Call of Duty presentation.

1
2
3

float alpha = 1.0f / ( sqrt( PI_OVER_FOUR * specular_power + PI_OVER_TWO ) );
float visibility_term = ( n_dot_l * ( 1.0f - alpha ) + alpha ) * ( n_dot_v * ( 1.0f - alpha ) + alpha ); // Both dot products should be saturated
visibility_term = 1.0f / visibility_term;

Now we have all the terms we need, we multiply them all together to get our final specular lighting value.

Performance/Quality Trade-off

Put together this shader code is clearly more expensive than the old simple Phong or Blinn-Phong specular, but we don’t have to do it all on slower hardware. The first thing we can do to make this quicker is to make the visibility term equal to 1. As the visibility term is G (from the BRDF equation) divided by ( n_dot_l * n_dot_v ), we simply make G the same as the denominator, making the entire visibility term equal to 1. This will only be a small drop in quality – comparison images are available in the Call of Duty presentation.

If this is still too slow for the target hardware, the next casualty is the Fresnel term, which also can be changed to a constant 1. This will mean that the specular highlights will be the same brightness from any angle, but we still get the major benefits of normalised Blinn-Phong specular. Therefore, we can have three variants of our physically based specular calculation, depending on the performance of the hardware.

1
2
3

float3 slow_hardware_specular = specular_term * cosine_term * light_colour;
float3 mid_hardware_specular = specular_term * cosine_term * fresnel_term * light_colour;
float3 fast_hardware_specular = specular_term * cosine_term * fresnel_term * visibility_term * light_colour;

Conclusion

I hope that anyone considering physically based lighting may find this article useful. Any comments and/or corrections are welcome below!

Rendering the light takes 297.2 microseconds

The draw call for the light takes 0.3 milliseconds to render, which sounds fast, but we can do better. The darker yellow area of the timing bar represents pixel shader time and this is the majority of time taken for this draw call. Therefore we can make this light render faster if we can reduce the number of pixels drawn. The next screenshot shows a wireframe of the light’s geometry overlaid on the final render. For every pixel within the wireframe (strictly the back faces only), we run the lighting calculation. The pixel shader does a lot, it reconstructs a view space position from the depth stored in the g-buffer, reconstructs the view space normal from two channels (using Lambert azimuthal equal-area projectionif you’re interested) and then calculates diffuse and specular light colour, taking into account distance and spotlight attenuation. As you can see, there are a lot of pixels within the wireframe that are black in the final image. This is because these areas of the light’s geometry don’t intersect the world geometry so we’re wasting work. If the wireframe is hard to see below, click the image to see it full size.

We render more pixels for the light than are actually affected by it.

If we can somehow make the GPU only render the pixels that are affected by the light, then we can make this quite a bit quicker. Luckily, there’s an old technique for calculating the screen space intersection between different volumes – namely “stencil shadows”. What we do is we split the render into two stages. In the first stage, we fill the stencil buffer for areas where the cone intersects the world geometry, and then for the second stage we render the light testing against the stencil buffer. To do this efficiently, we make use of double sided stencil and the zfail stencil technique (also known as Carmack’s Reverse). The eagle eyed amongst you may have had a warning flag go up in your head regarding patents, though I believe that the Creative patent only refers to stencil shadow rendering, not use of the stencil buffer for optimising light rendering. Perhaps someone with more legal experience can confirm or refute my thoughts in the comments. We create a depth stencil state with the following parameters. I’m using DirectX 11 here, but this should translate directly into more or less any modern graphics API.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

D3D11_DEPTH_STENCIL_DESC depthstencil_desc;
depthstencil_desc.DepthEnable = TRUE;
depthstencil_desc.DepthWriteMask = D3D11_DEPTH_WRITE_MASK_ZERO;
depthstencil_desc.DepthFunc = D3D11_COMPARISON_LESS;
depthstencil_desc.StencilEnable = TRUE;
depthstencil_desc.StencilReadMask = D3D11_DEFAULT_STENCIL_READ_MASK;
depthstencil_desc.StencilWriteMask = D3D11_DEFAULT_STENCIL_WRITE_MASK;
depthstencil_desc.FrontFace.StencilFunc = D3D11_COMPARISON_ALWAYS;
depthstencil_desc.FrontFace.StencilDepthFailOp = D3D11_STENCIL_OP_INVERT;
depthstencil_desc.FrontFace.StencilPassOp = D3D11_STENCIL_OP_KEEP;
depthstencil_desc.FrontFace.StencilFailOp = D3D11_STENCIL_OP_KEEP;
depthstencil_desc.BackFace.StencilFunc = D3D11_COMPARISON_ALWAYS;
depthstencil_desc.BackFace.StencilDepthFailOp = D3D11_STENCIL_OP_INVERT;
depthstencil_desc.BackFace.StencilPassOp = D3D11_STENCIL_OP_KEEP;
depthstencil_desc.BackFace.StencilFailOp = D3D11_STENCIL_OP_KEEP;

The important bits we’re doing here are leaving depth test on as normal, setting depth writes off, enabling stencil and setting the stencil depthfail operation for both front and back faces to D3D11_STENCIL_OP_INVERT. If your graphics API does not support an INVERT operator, you can use INCREMENT on the back faces and DECREMENT on the front faces.

Then we render the light geometry with back face culling off and no pixel shader. It is important that the stencil buffer is completely clear before this is done. The stencil buffer is then filled as in the next screenshot.

Stencil buffer contents overlaid on final render. You can see it fits the areas of the image affected by the light more closely than the cone wireframe above.

The next stage is to render the cone again with the following depth stencil state.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

D3D11_DEPTH_STENCIL_DESC depthstencil_desc;
depthstencil_desc.DepthEnable = FALSE;
depthstencil_desc.DepthWriteMask = D3D11_DEPTH_WRITE_MASK_ZERO;
depthstencil_desc.DepthFunc = D3D11_COMPARISON_LESS;
depthstencil_desc.StencilEnable = TRUE;
depthstencil_desc.StencilReadMask = D3D11_DEFAULT_STENCIL_READ_MASK;
depthstencil_desc.StencilWriteMask = D3D11_DEFAULT_STENCIL_WRITE_MASK;
depthstencil_desc.FrontFace.StencilFunc = D3D11_COMPARISON_ALWAYS;
depthstencil_desc.FrontFace.StencilDepthFailOp = D3D11_STENCIL_OP_KEEP;
depthstencil_desc.FrontFace.StencilPassOp = D3D11_STENCIL_OP_INVERT;
depthstencil_desc.FrontFace.StencilFailOp = D3D11_STENCIL_OP_KEEP;
depthstencil_desc.BackFace.StencilFunc = D3D11_COMPARISON_NOT_EQUAL;
depthstencil_desc.BackFace.StencilDepthFailOp = D3D11_STENCIL_OP_KEEP;
depthstencil_desc.BackFace.StencilPassOp = D3D11_STENCIL_OP_ZERO;
depthstencil_desc.BackFace.StencilFailOp = D3D11_STENCIL_OP_KEEP;

The important bits here are that depth testing is off, and the stencil test for back faces is set to D3D11_COMPARISON_NOT_EQUAL, which will mean only pixels with a non-zero stencil will be shaded. We also set the StencilPassOp for back faces to D3D_STENCIL_OP_ZERO so the stencil buffer is cleared for the next light. The FrontFace settings are ignored as we’re only going to render back faces in this stage. Then we render the light geometry with the full pixel shader and front faces culled. The visual result is exactly the same, but what of performance? Let’s see how long those two draw calls take with another GPA grab.

Total draw time is now 266.3 microseconds

This is about 11% quicker for this particular light, with only minor code changes. Savings will vary depending on how the light and geometry intersect and also depends on where the camera is. It should only be marginally slower in the rare case where the light affects every single pixel on the screen.

I hope you find this article useful.

EDIT: Based on a few twitter comments I’ve further optimised this by modifying the first stage from depth testing with D3D11_COMPARISON_GREATER_EQUAL and inverting stencil on depth pass, to testing depth with D3D11_COMPARISON_LESS and inverting stencil on depth fail instead. This is equivalent, but crucially, it allows hierarchical depth/stencil optimisations that the GPU does to remain in place, further optimising the rendering which now takes less than 0.2ms. Yay!

Last Thursday I went to the Develop Indie Dev Day in the English seaside town of Brighton. My reasons for going were threefold. The sessions themselves sounded interesting, I’d get a chance to chat and socialise with friends my indie lifestyle is preventing me from spending time with, and lastly to try to show my game prototype to a few people.

I live in Guildford, which is around 45 miles away from Brighton, but due to a quirk in the layout of the railways in the South-East of England, the train journey would be close to 80 miles. The reason for this is that railways radiate out from London in all directions, but there’s very few lines going around London so you’re forced to go into London on one line, and back out on another. For me, this meant I got out of bed at 6am, which is something I’ve not done for a long time, and I spent two hours trying not to fall asleep on the train.

The Sessions

The majority of the day was spent in sessions – there was a programme specifically targeted towards indie developers, mostly talking about the business side of things rather than the actual game creation process as it’s assumed we can already do that. This is in contrast to the main Develop sessions that were mostly focussed on the actual production side of games development.

The opening keynote from my old colleague Sean Murray of Hello Games was particularly interesting as it cut through the glamour of indie development and talked about the difficult realities of money, the fact that failed indie studios are never reported in the press – distorting the chances of success, happiness (or the lack of it), hating your game at various points in development and so on. On his graph, I was still on the first happiness peak after forming a studio. Perhaps the session was a depressing way to begin the day, but it felt like a very honest account and there is still light at the end of the tunnel as his own survey showed that the vast majority of indie developers would rather do nothing else.

Other sessions of particular interest to me were covered the legalities of running a small games studio (IP law, defending against patent trolls, etc), and another on how to raise funding. The funding one in particular was an eye opener as it showed that most investors are not interested too much in the product you’re creating – they’re more interested in you and your business as a going concern and on building a long-term relationship with them, even before any money changes hands. It also showed me that if I’m to secure funding in this manner, I have a lot of skills to learn outside the field of games development.

Networking

Networking is a skill I clearly need to develop (pun intended?). When I’ve attended conferences like this in the past, I’ve always been there as part of a large company, so I can spend time between sessions and at the end of the day just catching up with friends and avoiding talking with the scary new people. However, when running a small business you need to promote, this clearly isn’t the best option as you need to get out there and talk to everyone. I’m afraid to say I did end up spending too much time “safely” with friends and perhaps not enough time talking with potential publishers, investors and other useful people to know.

Perhaps my social awkwardness caused some wasted opportunities, but I did pluck up the courage to talk to some people, especially after a beer or two had been consumed. I swapped lots of business cards and shook hands with a lot of the attendees. I also wore my company logo t-shirt all day with pride, so hopefully more people are aware of my company now – which may or may not translate into future sales. The Google Analytics for my company website shows there was a definite boost in traffic during the day – huzzah!

I also got good feedback on my game prototype – everyone “got” the game mechanic straight away which was good, but with a programmer art white-box level I wasn’t wowing anyone. This showed me I was deluding myself in thinking I could build this game single-handed to a high enough standard. The day made me realise the project needs input from artists – probably from some cunning level designers too. The trick is going to be achieving this whilst not running out of money. I’m not about to give up just yet!

The Aftermath

The next day I felt utterly drained and depressed. I was not expecting this at all. I don’t know whether it was just down to tiredness, or the reality of what’s required to build and sell my game hitting me like a ton of bricks – “It’ll take me forever to build this”, “We’ll run out of money long before it’s done”, “What’s the point? I should just go and get a job”. I’ve not felt that down for a long time. I went to sleep early that evening and didn’t get out of bed again till lunchtime on Saturday. I didn’t really feel fully awake for the whole day. This AltDevBlogADay post was due on Sunday, but I just felt like there was no point opening WordPress and starting to type. Only yesterday (Monday), did I start feeling like myself again. I looked after my two children all day and they have a happy tendency to always cheer me up.

Today, I’m back to working on my game again – getting a ton of email out of the way, organising a potential concept artist, working out a plan for the next engine feature. From here, I’m wondering what I was so down about, but I have to say my mood for the last few days has taken me (and my wife) by surprise.

A (Humorous?) Story About Trains

I posted on the social networks yesterday that I would include a story about trains in this article. I don’t like to end on a down note, so here it is.

On the way back from Develop, I had make sure I caught the last train home. It was a three part journey to Guildford. I walked to Brighton station on time and caught the 22:33 to Haywards Heath as planned. The next train was from there to to Clapham Junction, so I boarded the train and got myself comfortable. I might add at this point that I’d had rather a few beers before beginning this journey. After what seemed like an endless journey, which fely like the train was stopping at every tiny village on the way, we reached Clapham Junction.

Or so I thought…

I got off the train, found a member of staff and asked them what platform I needed for the Guildford train. He looked at me puzzled – “You need to go to Clapham for that mate”. WTF? I look around and a lot of very clear and well lit signs pronounce that I’m actually in East Croydon. EAST CROYDON! By this point, the train I had just disembarked had already gone off without me. I won’t repeat the string of expletives that went through my brain, and probably through my mouth too, but suffice to say, it was time to PANIC!

I sent a message to my wife who told me that there was a later train to Clapham at 11:58, which would get there in time for me to catch the train to Guildford. Panic over I thought and went to the correct platform to wait.

The allotted time arrived. The allotted time passed. No train arrived

Then, an announcement stating that the train was cancelled! Noooooooooooo!!! I waited longer still for an even later train, but by the time I eventually got to Clapham Junction I had missed the last train to Guildford by some margin.

Thankfully, my wife was an absolute star and came to pick me up in the car with the children bundled up in the back, still wearing their pyjamas. Home safely, I collapsed in bed.

Microsoft released DirectX 9 to the world at the end of 2002 (source – Wikipedia). It had many enhancements over previous versions (most notably fully programmable vertex and pixel shader pipelines), and has proved to be a very popular graphics API with PC game developers.

Over the years, DirectX 9 has recieved several minor updates, culminating in DirectX 9.0c in 2004. This eventually became the graphics API for the Xbox 360 with a few enhancements specifically for that hardware, further extending its reach.

Since then, DirectX 10 was released with the launch of Windows Vista in 2006, and DirectX 11 with Windows 7 in 2009.

PC Games Today

Most PC games released today still use DirectX 9. For example; Portal 2, Fable III and Crysis 2 were all released in 2011 and all use DirectX 9 as their graphics API (though in Crysis 2‘s case there is a DirectX 11 patch available, offering graphical enhancements as seen in this pretty video). The only major game I can think of that does not support DirectX 9 at all is Battlefield 3 (source - Battlefield 3 Blog), though that game has not been released yet. A lot of games from the past few years do support Directx 10 or 11, but almost all of these also support DirectX 9 as well.

This pattern is contrary to the behaviour of game developers for previous versions of DirectX, whereby most would jump onto the new version as soon as practical. So why is this?

Reasons

In my opinion, there are several reasons for this. In no particular order…

1. Windows XP – DirectX 10 was the first version of the API to completely break backwards compatibility. It will only run on Windows Vista and Windows 7. This was necessary due to a fundamental change in the driver model for DirectX, but as a result of this, adoption of the new technology was slow. For a game to support only DirectX 10 in 2006 when Vista was launched would have meant losing almost all of the game’s sales as the vast majority of gamers at the time were still using Windows XP. However, this is changing fast as Valve Software’s monthly Steam Hardware Survey (probably the best publicly available source of information of this type) shows that less than 20% of gamers were still using Windows XP in June 2011 and the figure is dropping. Personally, I think now is the time for games to be written using DirectX 11.
2. Xbox 360 – A lot of games are released on multiple platforms. For games that are on both Xbox 360 and PC, it makes sense to use DirectX 9 on both versions to minimise the work required rather than maintain two separate graphics engines. On the other hand, it is tricky to do some things with DirectX 9 on PC that are simple on Xbox 360. For example, on Xbox 360 it is simple to read a depth buffer from a shader, but on PC with DirectX 9, you have to resort to either writing depth to a second R32 format texture (which is slow) or using driver hacks such as the INTZ texture format and then deal with different graphics cards separately. This issue is (of course), solved in DirectX 10/11.
3. New driver model - Due to the change in driver model for DirectX 10, all the graphics card manufacturers had to write new drivers to support the new system. This resulted in bugs and performance issues in DirectX 10 games at the time. This is entirely understandable as any new complicated piece of technology is bound to have teething issues (and the issues have since been solved), but it feels as though DirectX 10 gained a (perhaps undeserved?) poor reputation along with Windows Vista. When Windows 7 was released, the new version of DirectX was numbered 11, rather than 10.2 which perhaps shows that Microsoft was aware of the perception and wanted to make a clean break.
4. DirectX 9 was revolutionary, Direct X 10/11 are not – What I mean by this is that DirextX 9 opened up a wealth of new graphical possibilities. The ability to write long HLSL shaders meant that games suddenly had the ability to use more sophisticated lighting models, more varied materials and post-processing – all with some quite straightforward programming (and a good understanding of maths). There are many DirectX 9 games that simply would not have been visually possible beforehand (ignoring OpenGL for the purposes of this post!). For this reason, DirectX 9 is still visually good enough for modern games. DirectX 10 and 11 have added new features – geometry shaders, DirectCompute, tessellation, etc, which are all good, but not the technical leap that DirectX 9 allowed. For me, most of the new features of DirectX 10/11 are designed to make things easier for developers or enable performance increases, rather than adding entirely new graphical possibilities. I think the improved graphical features of the recent  DirectX 11 patch for Crysis 2 are probably mostly possible in DirectX 9, though would either have been a nightmare to implement, or would have been very slow at runtime.
5. Perception that a new DirectX means buying a new graphics card – This is only partially true – it was true for DirectX 10 which mandated a minimum feature set, but DirectX 11 has added a new feature to allow older graphics cards to be used. To take advantage of the latest features of DirectX 11 (e.g. hardware tessellation), you need a graphics card that implements those features, but it is entirely possible to run DirectX 11 games on older hardware so long as the developer allows it using the correct feature level. For example, the developer can test for the supported feature level and replace tessellated geometry with normal mapped geometry on hardware where tessellation is not supported. I am developing my own game engine with DirectX 11 using a GeForce 8800 GTX (a DirectX 10 graphics card), and I can even support older DirectX 9 level hardware if I want to (Steam Hardware Survey says YES). The feature level system in DirectX 11 allows me to simulate older hardware and the debug layer will warn me if I try to use a feature that is not available on that level. However, I have not yet tried a real DirectX 9 graphics card with my engine, so I’m using this feature on faith for now. I’ll find out for sure when beta testing begins.

Moving Forwards

Like the Battlefield 3 team at DICE, I’m writing my game engine using DirectX 11, and have no plans to write a DirectX 9 version. I’m doing this mostly for the ease of use and flexibility of the newer API as I can literally build the game quicker without worrying about different driver hacks for different graphics cards. Also, over 80% of PC gamers can theoretically play my game (according to the Steam Hardware Survey) – certainly an even greater proportion by the time my game is released. The reasons I’ve listed above for the extended life of DirectX 9 are mostly historical and I don’t think they apply for a game engine written today. I read a quote (I forget by who I’m afraid) from one of the presentations at GDC this year from developers saying that they write their new graphical features in DirectX 11 first, then port across to the Xbox 360 and PS3 as it it easier that way and allows their PC versions to shine (rather than just be a port of the Xbox 360 version).

Let’s give DirectX 9 a nice retirement and let it live the rest of its time in peace and quiet – undisturbed by us pesky game developers!

What Went Right

• Productivity - When I began, I was excited and determined to write a game on my own. I was also somewhat apprehensive about having the mental discipline to remain productive on my own. A common reaction from people when I told them about my new studio was to ask how I was going to get any work done at home with a family. So far, I’m happy to report that those fears were unfounded – or at least so far, my enthusiasm has overridden my natural laziness and the kids have proven less of a distraction than expected. We’ll see if this extends to shipping a game, though I’m quite optimistic at present.
• Learning - Even with a decade’s experience, I would never claim to know everything (or even a substantial portion) of the knowledge required to build a game. In the last two months my learning has accelerated. Subjects such as physically based lighting, better knowledge of rigid body physics, DirectX 11 and a smattering of the Win32 API have since entered my lexicon.
• Great Free Software – I’ve been able to build my game at an accelerated rate due to some very handy open source code that is available at no cost. Bullet Physics, AssImp, Blender, etc have all saved me significant chunks of time. When I finish my game I may be able to donate code or money (if I make any) back to the projects.
• DirectX 11 – It may be seen as a gamble to limit myself to a smaller portion of PC gamers (though not that small according to the monthly Valve Hardware Survey), but supporting only Windows Vista/7 has made development of the game engine a lot simpler. This is because I haven’t had to rely on any vendor specific DirectX 9 driver hacks (INTZ, RAWZ, instancing, etc) in order to make things work, plus DirectX 11 has a much better debug layer and useful new features. Although I’m developing my engine with only the GeForce 8800 GTX I have at my disposal, I hope there will only be minor issues in making the game work with any other DirectX 10 or 11 hardware – and there’s simply a smaller set of hardware to test which helps with my limited resources. Also, the knowledge gained in using DirectX 11 will be useful if I need to do any contracting to top up the coffers. If nothing else, this technology also gives me something to differentiate my game from most other indie games.
• Finding Free Days Out At The Weekend – I’ve been keeping my weekends free so far to spend with the family rather than with my PC. My wife and I became National Trust members a few months ago, so there’s plenty of free (except for fuelling the car) days out locally that we can take the family to at the weekends. For those of you not in the UK, the National Trust is a large organisation which looks after lots of old houses, gardens, monuments, castles, palaces, etc around the country, and a large chunk of those are in or near Surrey, where I happen to live.
• #guessmycompanyname – I ran a little Twitter/Facebook game in May where I invited people to guess the name of my new company, and posted periodic clues. I offered a copy of my first game to the first person to guess correctly. The game lasted a few hours, generating lots of Twitter messages (though not much Facebook activity) before two people correctly guessed “Razorblade Games” at the same time – I’ll be giving them both the prize when the time comes. At that point I turned on the company website, Twitter and Facebook accounts for business. After an initial flurry of interest things have waned which is no surprise since I’ve not announced my game yet. I was a little disappointed none of my twitter followers who work in the press reported on the new studio, but that would have been a bonus as that wasn’t the objective – I plan to start talking to the press when the game is demo-able and I have screenshots/video to back it up.
• More Time With The Family – I’m almost always home for mealtimes, am keeping weekends free and have time to play with the children every day. As a result I feel as though I’ve grown closer to my family.
• I’m Generally Happier – I’m on the way to achieving a lifetime ambition and this is a great boost for me. I feel less stressed about work, there’s no office politics or bureaucracy to deal with, I can work more or less when I feel like it (exceptions below!), My wife often comments that I’m happier now than I’ve been for years.

What Went Wrong

• Very Little Social Life – My social life has declined massively since working for myself – mostly down to the lack of money, but also because there’s no pub to nip into on the way home from work. I’ve been to a couple of parties since and had the occasional beer or five with friends, though I can quite easily go an entire week without leaving the house or having a face-to-face conversation with an adult other than my wife. If we can solve the money issue (detailed below), this problem may fix itself.
• No Work Colleagues – Related to social life, I miss working with my friends and having people to chat about what I’m actually working on. My wife will listen to me, but she doesn’t understand the details of normalised specular, or rigid body interpenetration so it’s harder to have any work conversations. Twitter and MSN are proving to be a substitute of sorts, but it’s not really a replacement for a good old chinwag. In future I may collaborate with others, but I want to at least get one game done on my own. I’m also going to the Indie Day of the Develop Conference in Brighton in July (and hopefully to other, future meet-ups), so that will be a great opportunity to chat with other game developers in person.
• Sharing the Office With My Wife – My wife also does some work from home and we started out time-sharing the office, but that turned out not to be practical. Currently, my wife’s PC is on the dining table downstairs so we can both work in parallel in the evenings, but this isn’t a permanent solution and we’ll have to fork out for a desk for her soon and move some stuff around to fit it in. She’s a little annoyed I’ve essentially booted her out of what used to be her office, but she understands the necessity.
• Looking After The Kids Is Time Not Making My Game – When my wife does her contracting work away from home, I have to look after the children as paid childcare is out of our budget and neither my mum or her parents live nearby. This has occasionally meant 2-3 frustrating days at a time where I’m unable to work (the kids’ afternoon nap times excluded). There’s not much we can do about this though, my wife’s contracting work brings in essential funds, so we’re just going to have to grin and bear it for the time being.
• Game Hint On The Website Is Too Subtle – On the company website there’s a little square to the left of the logo that is slightly darker than the background. Click on it, and the website’s colour scheme will reverse and the text will change slightly. Now there’s another square slightly darker than the background to the right of the logo, click this and things will go back to how they were. This is actually a hint about the game I’m building and I was hoping this would generate some chatter and interest, but this seems to have not been the case. I don’t think anyone has found it without being told there’s something there to find (and those people found it by looking at the source code, not finding it naturally). However, this sort of ARG style thing is something I’m interested in playing with further when it comes to promoting my game, so keep your eyes peeled.

What Isn’t Decided Yet

• Money – I’m working entirely self funded (more accurately wife funded), but money is quite tight. As I said above, my social life has suffered as a result of this, but we’ve been getting by. Unfortunately, there’s no guarantee my game will make any money, even if it turns out as good as it seems in my head. I’m probably going to have to do some contracting work before too long to top up the coffers (open to offers, hint hint) or try to obtain some outside financing (again, I’m open to any offers!).
• The Game – My game isn’t finished yet. Although it seems brilliant in my head, I worry about whether it will be any good to the extent that it sometimes keeps me up at night. Perhaps this is the life of a tortured creator, but it hasn’t put me off – far from it!

Overall I’d say the good stuff vastly outweighs the bad, and I’m raring to go for another two months and beyond.

Fast forward a decade or two – I’m writing my own game and naturally physics is a key feature. I know just enough about rigid body physics to know that writing my own physics engine is far beyond my current skill-set so I’m using a 3rd party physics engine called Bullet Physics. I won’t go into the reasons for choosing this particular engine (perhaps in another post), but here I will describe the basic concepts that rigid body physics engines all share. I think it vital to understand the basics of how a physics engine operates, even if you’re using an existing codebase as this understanding will help you use it most effectively.

Rigid Body Physics

What do I mean by “rigid body physics”? Quite simply, it is the simulation of forces such as gravity acting upon solid objects. For example, a crate falling off a ledge, a weight pushing down the end of a see-saw, a ball bouncing on the ground, a pool cue hitting a ball. This is contrary to “soft body physics” which simulates objects such as cloth or jelly.

In the real world, physics happens continuously (or does it?), but in a game we run the simulation in discrete timesteps – generally 30 or 60 times a second, often even more often than that (perhaps 120 or 180 times a second). The more frequently the simulation runs, the more accurate it tends to be, but of course there is a performance tradeoff for this. That decision is made for each individual game depending on its requirements.

Step By Step

So what does the physics engine do? Quite simply, for each simulation step, it executes the following operations:

1. Apply forces (such as gravity) to the objects and move them according to their momentum.
2. Detect any collisions between objects.
3. Resolve the collisions.

Of course, there’s a lot of detail to each of these steps (for example, step two happens either discretely – checking only each object’s new position, or continuously by sweeping the object from its previous position to its new position), but I shan’t go into that level of detail here as it would make for an enormously long post (probably a book) and there are other people better far qualified to write that.

Objects

Whilst debate rages on about whether object oriented programming is a good thing or not, in physics everything is an object. There are three classes of physics object.

1. Static – these objects do not ever move, no matter how much force is applied to them. You would use static objects for your world geometry – ground, walls, etc. Whilst technically unrealistic (even a planet can be moved with a big enough force), treating such things as completely static helps to keep the cost of the simulation down.
2. Dynamic – these objects are subject to forces and move freely within the static world. They are acted upon by gravity, being hit by other objects, and so on. Examples of dynamic objects include crates, balls, rocks and grenades.
3. Kinematic – these objects are explicitly moved by the game though user input, scripting or animation and the dynamic objects respond to collisions with these. You would use kinematic objects to represent the player, melee weapons, etc.

Usually, the physics engine will use what are called “Simulation Islands” in order to increase performance. What this means is that rather then simulating every dynamic object in each step, only those that are in motion, or have been touched by a kinematic object are simulated. When these dynamic objects are at rest again, they stop being simulated.

Primitives

To get the best performance and accuracy from a physics simulation it is rarely a good idea to use your render meshes as physics primitives. The physics library will provide a set of basic geometric primitives to use instead. You might model a crate using dozens of triangles, but you are best off using a single cube for the physics simulation in order to keep it fast. For accuracy, you would use a sphere to correctly model a pool ball, rather than the mesh of triangles that is being rendered as this mesh won’t roll correctly. A first person player is best simulated as a cylinder or capsule (a cylinder with rounded ends) rather than an animated character. For a car or a boat, you would use a simple convex hull. Even for world geometry you are probably best off using a simplified version of the render mesh, not only for performance reasons, but also because overly complex physics geometry can cause objects to get stuck or fall out of the world.

In conclusion, I hope this primer is valuable to someone using a physics engine for the first time.

Testing!

A challenge that lies ahead for me is testing the game I’m building. Unlike previous games I’ve worked on I’m working on my own with a minimal budget, so I have no QA department at my disposal with an army of young, keen, cunning testers doing their worst to try to break the game for months on end. There are “for hire” QA teams, but that is far beyond my budget. Therefore I need to do something else.

Beta Testing

Part of the solution is to give close friends a beta copy of the game and let them play it, noting their feedback which they provide in return for a free copy of the final game. I expect that this type of testing will be most useful for gameplay feedback – finding out whether the game is actually fun, whether players get lost in my levels and so on. Of course, obvious crash bugs and other functional things will be found, but I wouldn’t expect any beta testers to play through daily builds of the game, smoke-testing all game assets, getting full coverage on all possible hardware or spending hours trying to find an easy way to reproduce intermittent bugs. For this I need something else.

Automated Testing

It seems that my only realistic option is automated testing. Bear in mind, I’m not talking about Test Driven Development, Unit Testing, and other source code based testing methodologies – though of course they do contribute towards the overall testing and QA of the game. I’m talking about automated testing of builds of the whole game.

In my experience so far, there has been little automated testing of the games I’ve worked on. Perhaps there would be a hastily written script which loads every level, every character, dynamic object, and so on, checking for crashes before QA get the build, but I’ve never seen anything very much more sophisticated.

I think the main reason for this lack of automated testing is that in the large companies I’ve worked for, there’s always a QA department in the building that can do the testing manually – from a producer’s point of view, adding automated testing is extra upfront work that takes time away from making the game. However, I think this sort of testing is worth the effort, even for these large companies. After all, even the most diligent human tester can miss things – on many an occasion I’ve received bug reports that turn out to have been unnoticed in the game for months and thought “How could they have missed that?”. The simple answer is usually that it wasn’t on the test plan and was probably found by a lucky accident. This is a problem that also afflicts automated testing – it can only test what you tell it to test, far more so than human testers. I’m not sure there is a good answer to this short of a Culture Mind.

What I’d Like To Have

What I would like is a framework to perform the following tests on every build of the game and report results for every test, adding failures into a decent bug database. It would also be good to allow easy promotion of an intended fail (e.g. a change in a graphical effect) to become the new baseline for a pass. This is not an exhaustive list. I’m sure I could come up with more things to test – suggestions are welcome in the comments!

1. Smoke-testing. Loading every level, character, model, texture that the game uses to check they all load without crashing.
2. Render and animate every level, character, model in the game, comparing results with screenshots from previous builds.
3. Run a recorded playthrough of the entire game. I was thinking something like the old playthrough that went on behind the main menu in Quake. Of course this wouldn’t suit all game types, though perhaps could be done in a limited fashion for those. This needs to test for crashes, dumping a callstack, game inputs and internal state, and other appropriate data for a programmer to look at.
4. To find performance hotspots (ideally from the playthrough data) and take PIX/GPA/<insert performance tool> grabs. Comparisons with previous builds are essential here as we need to be able to find when and where performance problems occur.
5. To soak test every level for a given number of hours.
6. To test all UI screens, and check that options actually give the correct results from rendering/audio/difficulty/etc (as applicable).
7. To test rendering at all available resolutions (if appropriate).
8. The ability to run any subset of these tests on demand (rather than overnight).
9. The ability to add new tests quickly and easily.

I don’t envisage anything being able to do all of this straight out of the box, but a framework I could gradually add to would be ideal – even better if I can keep as much of its code separate from the game code as possible to avoid further bugs.

If you, dear reader, know of such a framework that can be set up to do this sort of thing I’d be eternally grateful if you could let me know in the comments. I’ve heard of companies having this sort of thing in their tool-sets, but the solutions tend to be proprietary and/or expensive. It’s most probably infeasible to write something myself that would do all of the above without taking longer to implement than the game itself.

If you’re at university, you should research whether there’s a programme to do a summer or year long internship at a games studio. There was nothing like that when I was at the University of Liverpool ’97-’00 (or I wasn’t aware of it), but I’ve seen people come through that kind of programme with much greater practical game development knowledge and it goes a long way towards persuading an employer to take you on. EA, Lionhead and other large companies tend to run this sort of programme so look on their job pages too. Beware that sometimes companies don’t respond to intern applications for various reasons (team is deep in crunch, budget spent elsewhere, etc) and places are extremely limited.

Your best bet is to make a graphics demo, either on your own or with a small group of people. You learn more by doing than by just reading. Pick a modern graphics technique that interests you and implement it. Even better, do more than one. This is also great training for motivating yourself to get a project finished which is often the hardest part of games development, for all disciplines. Make sure you’re prepared to talk in detail about the choices you made, performance (in milliseconds, not frames per second!), quality, alternatives and trade offs in a job interview.

When I was in university I did a straight computer science course – there were barely any games courses available back then, but I still think that employers still value computer science graduates above games graduates as there’s a perception that you learn a greater range of software engineering skills. This could be a misconception though, as games courses are a lot better than they used to be, but you may have to fight your corner in an interview and prove you know your stuff (and not just the curriculum you were taught).

Computer science courses also tend to be quite maths heavy (I would hope games courses are similar), which is vital for graphics programming. Make sure you understand homogeneous coordinates, matrix maths, dot products, cross products, quaternions, normal vectors, tangent bases, etc and how these things (and countless others) are useful for transforming and lighting geometry. Learn big O notation for algorithmic execution time, understand colour spaces, gamma correction, what high dynamic range means and so on. Learn some basic lighting models - Lambert, Phong, Blinn, etc.

Software

In my experience, Visual Studio is pretty much universal as a code IDE (except for Apple, Linux, Android and Nintendo games), though you can of course use your favourite editor if you really want to, as long as you know Visual Studio. There is a free Express edition available from Microsoft (http://www.microsoft.com/express/Windows/), so it won’t cost you any money to learn. The PS3 is a little different as there is a separate hardware specific debugger, but you should be able to learn that on the job.

You should be familiar with a source control system. Perforce (www.perforce.com) is a good choice as a lot of game studios use it and it’s free for single users. Try to learn it on a project with other people as merging, branching and integration are good skills to have. With all source control systems, similar concepts apply so it’s essential knowledge to have. Shockingly, my university course never mentioned source control and I was naive enough to believe that people just shared code over the network or on floppy disks.

As you’re unlikely to have access to devkits at home or in university, you’ll most likely be learning your skills on PC. In what may come as a surprise from someone with a decade’s game development experience, I don’t know much OpenGL as there’s never been a pressing need for me to learn it. Most PC games use DirectX, though if you learn DirectX 11, make sure you also learn DirectX 9 as it’s still current for Xbox 360 and many PC games still use it to support the dwindling, but still large Windows XP market. DirectX 10 is completely superseded by DirectX 11, so it is not worth learning (you can write DirectX 11 games for DirectX 10 hardware, and even DirectX 9 hardware).

It’s also definitely worth learning a graphical debugger. PIX for Windows isn’t as good as the Xbox 360 version, but there are fantastic free alternatives (Intel GPA - http://software.intel.com/en-us/articles/intel-gpa/, Nvidia Parallel Nsight - http://developer.nvidia.com/nvidia-parallel-nsight). These tools are not just for performance tuning on the GPU – they’re also for debugging your draw calls, working out why something doesn’t draw, why it looks wrong, and so on. You can also learn about how a GPU works as you can see all the renderstates, shaders, meshes, textures, etc for any draw call in a frame and really understand what the GPU is actually doing with the data you give it.

Other Duties

As a graphics coder you’ll probably have to do some tools work too, working with mesh compilers, animation compilers, plugins for Maya/3DS Max or in-house editors for the artists to use. Remember that your job is to provide technology to support the artists in their daily work, so it needs to be presented in a friendly manner. If you give your art team a tool that lets them tweak some coefficients of a fancy rendering algorithm and they have no idea what the numbers mean, they probably won’t use it. Also, technical artists are your friends – they’re the best people to talk about requirements for artists and to work out the best workflow for the content creators.

It’s also good to learn general performance and optimisation techniques as this often falls to the graphics/engine team to do. You probably won’t have to write any (or very little) raw assembler, but you ought to be familiar with what the C/C++ compiler is doing to your code, how to spot problems and what to do about them. For example, one of the biggest performance problem will be L2 cache misses (you lose hundreds of cycles per miss on all modern hardware), so learn techniques to reduce them (almost always changing the data, not the code is the fix).

Online Learning Resources

Online resources are a goldmine, and there’s much better stuff out there than there was when I was at university as a lot of companies publish papers on their techniques which are pretty useful stuff. A few examples…

http://www.valvesoftware.com/company/publications.html
http://publications.dice.se/
http://www.crytek.com/cryengine/presentations

Also there are a few good blogs posting regularly about graphics. A few good examples…

http://aras-p.info/blog/ – Lost in the Triangles. Aras Pranckevičius’s blog (a lead programmer for Unity).
http://www.realtimerendering.com/blog/ – Real Time Rendering has good information (also the book is a worthwhile read!)
http://www.humus.name/ – Another good graphics programming blog.

Make sure you read the relevant presentations from GDC (very useful) and SIGGRAPH (slightly less useful as a lot of it is for non-realtime graphics, but useful as a crystal ball for future techniques).

My last handy tip is that if you live near a big dev studio, find out which pub they go drinking at after work and join in on a Friday night. You’ll learn a lot just chatting with developers. You can also join twitter and talk to many games developers there who are willing to share their experience.

As I’m writing my own engine, one of the first things that needs to be done is input processing. In the latest DirectX SDK, there are two options listed for input, namely DirectInput8 and XInput. DirectInput8 is long in the tooth, being over a decade old and has localisation issues as I’ll discuss below. XInput is newer and is a cleaner API, but seems to exist entirely for using Xbox 360 controllers (presumably as an aid to porting) and supports nothing else. Neither seemed to be an ideal solution to me.

Twitter to the Rescue

I asked about this on Twitter and got a few replies suggesting I use the Raw Input API which I wasn’t previously aware of. Richard Sim pointed me to this MSDN article comparing the APIs (in this case the example is reading mouse input). As you can see, the code for using Raw Input is a lot cleaner and simpler than DirectInput8. The article also says that DirectInput8 is built on top of the Raw Input API and uses a separate thread to capture the WM_INPUT messages, adding overhead in the process. It felt to me that using Raw Input directly was the better solution.

Using Raw Input

The MSDN documentation for the Raw Input API is missing a few things which I’ve had to dig around and find out for myself, so I’ll explain what I’ve found out here. The basic process is that in your initialisation code you register the devices you’d like input from using RegisterRawInputDevices(), and then you receive WM_INPUT messages from the device in the Windows message loop from which you extract the actual keys/mouse input/etc. If you want to register for input from the keyboard, you would use the following code.

1
2
3
4
5
6
7

RAWINPUTDEVICE keyboard_device;
keyboard_device.usUsagePage = 0x01;
keyboard_device.usUsage = 0x06;
keyboard_device.hwndTarget = hWnd;
keyboard_device.dwFlags = 0;
 
BOOL ret = RegisterRawInputDevices(&keyboard_device, 1, sizeof(RAWINPUTDEVICE));

The question is – where on Earth do those UsagePage and Usage numbers come from? The MSDN documentation doesn’t explain, but after a bit of digging I found out that they’re part of the USB HID standard (pdf). On page 26 is table 1 for generic desktop devices, and the keyboard is device number 6, hence the numbers passed to the code above. For the mouse you would use page 1, usage 2. In fact, the Raw Input API lets you register multiple device at once as shown here.

1
2
3
4
5
6
7
8
9
10
11

RAWINPUTDEVICE keyboard_and_mouse_devices[2];
keyboard_and_mouse_devices[0].usUsagePage = 0x01; // Generic desktop page
keyboard_and_mouse_devices[0].usUsage = 0x06;     // Keyboard
keyboard_and_mouse_devices[0].hwndTarget = hWnd;
keyboard_and_mouse_devices[0].dwFlags = 0;
keyboard_and_mouse_devices[1].usUsagePage = 0x01; // Generic desktop page
keyboard_and_mouse_devices[1].usUsage = 0x02;     // Mouse
keyboard_and_mouse_devices[1].hwndTarget = hWnd;
keyboard_and_mouse_devices[1].dwFlags = 0;
 
BOOL ret = RegisterRawInputDevices(keyboard_and_mouse_devices, 2, sizeof(RAWINPUTDEVICE));

I have no idea why the API insists you pass the size of the RAWINPUTDEVICE struct as the final parameter, though it seems to be a common trait for Win32 API functions.

I think the MSDN docs explain actually getting the data well enough, so I won’t repeat that here.

Once your application is registered to recieve WM_INPUT messages, it will also receive WM_INPUT_DEVICE_CHANGE messages whenever a device is added/removed from the system so you can print up “Controller Removed” messages, or switch to an alternate controller as your game requires.

Wrapping Up

I mentioned above that DirectInput8 has localisation issues. What I mean by this is that often in games you need to show the name of the key on screen in control select screens or tutorials. To do this you would use GetKeyNameText() which will return a string from a scan code. Unfortunately, DirectInput8 uses its own DIK_ enums for the keys, which don’t exactly map onto scan codes. On previous games I’ve worked on, we’ve ended up with a large remapping table, with a few exceptions for various locales. The Raw Input API gives you the scan code directly as well as the virtual VK_ enum, so in theory this problem disappears (I still need to confirm this).

Chair – First and foremost, you need a good chair. I can’t stress this enough after having lower back pain from working on a bad office chair a few years ago. If you can afford it (and have space in your home office), get an Aeron or whatever your favourite type of chair is. A really good chair may cost a lot at first, but you’ll be sitting, slouching and wheeling around on it for a long time so it’s a worthwhile investment. It’s not something to skimp on. Make sure you take the type of chair for a test run (test sit?) if possible. A few seconds sat on one in a shop really isn’t enough. If you know someone who has the chair you’re thinking of buying, ask if you can spend an hour or so working on it to see how it works for you (although you may irritate them if you change the settings too much!). Last of all, make sure you’re really happy with your choice before handing over your money.

I’m typing this article sat on a solid wooden Ikea Ivar borrowed from the dining room which is far from ideal, so I need to sort out a proper chair sooner rather than later!

Desk – A desk is easier to sort out. It just needs to be the right height (or adjustable) and big enough to put everything you want on it. Also it needs no obstructions underneath for your knees to accidentally bash against. I’m using an Ikea Galant which is a nice corner desk that fits nicely in the room I’m using, has adjustable height legs, is pretty strong (it is no problem for me to sit on it) and it is easily big enough for all the desktop equipment I need. Make sure you have measurements of the room you’re going to use before buying so you can eliminate anything that won’t fit quickly.

Monitor(s) and Light – A monitor should be big, bright, comfortable to read, well calibrated and more than one if possible. Make sure the height is set up so you don’t strain your neck as you look at it. I’m counting light as part of this category as I think it is intrinsically linked to how well your monitor works for you. I like there to be a good level of ambient light in the room to avoid eye-strain from the monitors, but make sure the light is out of your field of vision or it will irritate you in your peripheral zone. Other people I’ve worked with (mostly artists and older coders), seem to have a preference for working in the dark – though I find that odd as it hurts my eyes after a while. I can (sort of) understand that way of working in the bad old days of curved, highly reflective CRT monitors as darkness would minimise reflections, but these days I think that is minimal. However, it is of course up to you how you light your room – whatever works best for you is most important.

Keyboard – You’re going to need something you can type on for hours without causing pain to your wrists. Ideally you want your hands and forearms fairly flat on the desk and not bent upwards so your wrists aren’t strained. Ergonomic, straight – it’s up to you, but find something that works for you and doesn’t cause pain after extended use. Also, you need to find a keyboard that has a key feel you like (how much travel, how “clicky” it is), sounds right (not too loud, not too quiet). Some keyboards also have extra buttons mimicking browser navigation, application shortcuts, volume control, etc. How useful these features are is debatable (I quite like having volume/mute buttons), but once again what works for you is best.

Mouse – Likewise, find something that fits your hand well, has all the buttons you need (mine is right hand shaped with two handy thumb buttons) and slides about the desk smoothly. Optical mice are all very good these days in terms of ability to read surfaces accurately so unless your desk is made of glass, you shouldn’t need a mouse mat. Alternatively, you might be someone who prefers a pad, trackball or other pointing device – I only have limited experience with these so comments below welcome! I’ve recently bought a Wacom Bamboo pad and am getting used to using a pen as a pointing device (as well as for drawing lines and curves).

Headphones – As I’ll be working in a house with two young children around, I’ll need a way to block out the distraction of their noise whilst they are playing, so a good, comfortable set of headphones is important to me. Find some that don’t hurt your ears and have good sound quality (I find cheap tinny sound tends to irritate after a while). Noise cancelling is an option, though on the ones I’ve tried, sound quality seems flatter (perhaps that’s just me though).

Space – An odd thing to include, but I find that when I’m stuck on a problem, I like to pace back on forth whilst my brain is working on a solution. It’s something I’ve deliberately refrained from at big companies as being watched by an office full of people stops my thought processes, but I do it at home (to the chagrin of my wife). Having an area you can do this without driving the people who live with you insane is probably a good idea!

I’d love comments on this article from people with suggestions of your own. For my next article, I plan to look at the software side of things – those little utilities that make my life as a programmer easier and more productive.