Xbox 360, PS3 or Wii – My Vote

Well it just wouldn’t be a game programming blog without talking about the next generation consoles.

Microsoft Xbox 360 has been out for a while now, and the price starts at $300 for the trimmed down version. Sony PS3 is meant to be out in November it’s reportedly going to sell for $399. Nintendo Wii is out around the same time and should be ‘under $250’.

At E3 there were plenty of really nice looking games. Frankly though, they don’t excite me all that much. Multiplayer doesn’t float my boat (I’m a slow learner and bad looser). New shader effects get old pretty quick. And paying a million dollars for consoles and games just seems a bit much (I’m a slow learner, a bad looser, and cheap).

I’m most excited by the Nintendo Wii at the moment. The controller is totally new. This means more new and imaginative games will get made. Developers can’t just line up 100’s of first person shooters and driving games. Similar to Xbox 360 Arcade offering an alternative to normal full price games, Wii will provide a way of playing almost all Nintendo’s back catalogue of games. It’s also cheaper for the machine, and likely the commercial games too.

I think I’ll get a Wii first, and then pick up a PS3 or Xbox 360 later on when the price point comes down a bit, and the games are really getting good. Talking to people around the office, it seems almost a given that everyone will buy a Wii. It’s just a matter of whether to buy an Xbox 360 or PS3 to go with it.

Don’t get me wrong, Xbox 360 and PS3 are great machines, and more powerful than Wii. The Xbox 360 Arcade is a great move, and PS3 will likely have a few tricks up their sleeve too. I’m looking forward to the 360 and PS3 games too, but my heart belongs to Wii.

The Wii site is worth a look around if you haven’t been.

PS. To anyone developing an FPS for the Wii. Please strap a flashlight to the shotgun, and have the direction of the Wii controller point the torch around. Then reload the shotgun by holding the controller up and jerking down/up as if cocking the pump action slider. Mail me when it ships. Thanks. :)

Getting a game programming job – Tip 2 – Writing demos

Something I recommend to anyone trying to get a game programming job is to work on some little projects on your own, in addition to any formal schooling you're getting. There’s no better way to learn how to make games than trying to do it yourself. The benefits I see are:

• You get good at coding, preferably in C/C++. This means you’ll do better at school, during interviews, and when you start working.
• Beyond just knowing the language, you’ll be used to compile errors, link errors, and wrangling different pieces of third party code. You will also likely pick up other skills like using Perl, LUA, building websites, and using art and sound programs.
• It’s great fun, and you get to make something.
• It shows a company that you’re self motivated and capable a lot better than just writing it on your resume.
• It really makes your resume memorable if it contains a link to a demo.
• If you're on a break from school, it improves your skills instead of them rusting away. You'd be surprised how quickly you forget how to code when you're not doing it. Though you'll realize during the interview :)
  

What’s a good demo?
Here are some ideas:

• Write a particle system.
  
• Write a cloth simulation which simulates a flag being blown by the wind.
• Write a rope simulation.
• Write a water ripple simulation, which makes use of fancy HLSL/GLSL.
• Write a heightmap renderer which can render a good distance without slowdown.
• Write a simple game like pong.
• Write a game, like asteroids or pacman.

Tips for choosing a good demo:

• Avoid choosing something that will require a lot of art such as 3D models and textures. You’ll end up spending way more time making art than programming.
• Avoid choosing something that requires you to write tools. For instance, you don’t want to have to write a world editor. You can build levels for games like pacman or bomberman in notepad, but when you start getting to R-Type or anything in 3D, you quickly start needing a complex editor. Writing a nice usable editor can take months of effort.
  
• Try and do several small demos rather than one big one. If you've attempt to make a rope simulation, an AI route finding demo and space invaders, you've got a far greater chance of finishing them to a decent quality level than if you try an make the next World of Warcraft killer.
  

How can I get started?

• Free compilers are available. I recommend Visual C++ Express.
• There are lots of free engines around which will take care of some of the hard work for you. I’ve used Ogre, but there are plenty of others. SDL is one that has been mentioned before.
• Start by running a tutorial application, and then gradually modify the app until it becomes your demo.

It's by no means essential to have demos. But if you have the time and inclination, you'll be greatly improving your chances of getting a games job.

Updating Particles on the GPU

[Advanced topic]

Someone recently asked me how particles can be updated on the GPU. I’m no expert, but know the basic concept. Basically the graphics card (GPU) has become more and more powerful, to the point that it’s now a kind of super fast programmable parallel processor, which as can do calculations which can be used for things other than blending colors together. In this post I’m going to explain one way in which the GPU can be used to update some particles.

An example of a particle system would be if you opened a treasure chest in a game, and a bunch of 2D stars sprayed out like a fountain. Each star particle is a sprite with a position and velocity, and over time the velocity of the sprite is pulled down with gravity. You get the idea…

Particle Update

• Imagine you have your list of positions and velocities. Each frame we do "pos = pos+vel" and "vel = vel+gravity".
• Lets ignore creating and deleting particles for now, just to get the concept of running the particles on the GPU.
• Pos and vel are each vector3's - i.e. three floats - X, Y, Z. Gravity can be represented as a vector3 too, but with two values being 0.
• A texture is made up of pixels, each of which has an R, G, B and A. We can store a position or velocity in a pixel. R=X, G=Y, B=Z.
• We can now imagine a texture two pixels wide, by NUM_PARTICLES tall. In the left column we have the position, and in the right, the velocity. So it's a texture that's storing data rather than a picture. It would look like some random colored dots - nothing recognizable.
• OK, now we want to update our texture. We run a vertex shader which overwrites the left column. It does "read column one (which is position) and two (velocity) into two variables, add them together, and write the output back into column one." We've just done ‘pos=pos+vel’ for each particle.
• Then we run a different shader on the right hand (velocity) column. It does "read column two, add the gravity constant, and write the output back to the right hand column." This did the ‘vel=vel+gravity’ calculation.
• So we used a texture that contained data, and ran shaders that were just concerned with doing math on that data, rather than the color blending and such that we normally think of shaders doing. And the output of the process was an updated data texture - which we don't show on the screen.

Rendering

• So we've worked out where all our particles are, and that data is in a texture. How do we render it?
• Lets say that we'd normally do it using a buffer of point sprites. Each vertex in the buffer represents one sprite, and has a position, color and size.
• Lets ignore the color and size for now.
• Imagine we want to render 256 particles. We have a buffer of 256 point sprites. But instead of putting world positions into the position values, lets put in the texture coordinates of the pixel we want to read. So the first particle has 0,0, the second has 0,1, then 0,2 etc. (values given in pixels here)
• This then goes into our shader, which instead of using the vertex position value as the world position, uses it as texture coordinates for reading from our data texture. The color value it reads from the texture is then used as the world position of the texture. (You might need to read this point a couple more times for it to sink in.)

Going further

• Extending the above, you could have the update look after a 'life' value for each particle. The life value could be sneaked into the fourth component of either the position or velocity pixels. Using shader 3.0 you could then reset the particle if an 'if' statement said that the particle was too old.
• You could animate the color and size using the life value to index a texture which contained the color/size values over time. E.g. if life ranged from 0 to 256, then you’d read from a 1x256 texture at the coordinates 0,life to read off a color value. The texture could contain a color value in the RGB, and a size value in the alpha.
• If you were a mental giant, you could encode your world collision data into a texture, and bounce the particles off the collision mesh - all on the GPU. It has been done, and I’ve lost sleep just trying to wrap my head around how… J

Pros

• Hey presto. We moved the particle update onto the GPU, which is fast and performs operations in parallel. A GPU can process several (e.g. 8) pixels at once, and also performs SIMD vector operations, so adding velocity to position adds all three components at once.
• The vertex buffer of point sprites that we use is set up once. The texture coordinate indices don't change from one frame to the next.

Cons

• It's technically quite challenging. We have to write three shaders, and debugging is trickier than just stepping through some C code.
• Doing general computation on GPU's is tricky. It's a logic puzzle all its own just trying to work out how to code with all the quirky restrictions.
• Reading data back from textures is super slow, so once the particles are updating on the GPU, you effectively can't 'see' them from the C code anymore. E.g. you couldn't, in C, say "if (particle.y<0)>
• The complexity of coding and limitations implied currently often make GPU particles (or other processing) an unattractive choice in games.
• The GPU is often fully maxed out just rendering the graphics for the game, and the CPU is actually not fully occupied. When this is the case, it is not a speed up to shift more work onto the GPU.

There’s a lot of ways to skin a cat, and above I've done the equivalent of skinning a cat using a mallet, but you hopefully get the idea. This kind of thing would be a cool little demo to write. You could make some funky looking particle effect, show it moving thousands of particles at once, and then bring up the CPU monitor and show that the CPU is pretty much idle. Sweet!

This area is called GPGPU processing – General Purpose Graphics Processor Unit processing. There are some articles in 'GPU Gems 2' about GPGPU which give a good grounding.

It’s cool stuff, but it’s for the brave and insane!

Getting a games programming job - Tip 1 - Watch your language.

I frequently come across people who ask "How do I get a job as a games programmer?". I do a lot of recruiting work for Heavy Iron, and so know the area pretty well. In this first post on the subject, I'm going to cover the best programming languages to practice.

Most games are written in C and C++. Certainly all the home consoles and main handhelds are mostly developed in C/C++. Cell phone and perhaps some web based games may use Java, but I'll ignore those platforms here. Also, if you’re just getting started with programming, you’re probably best ignoring everything I say here and choosing some kind of basic, just to get used to the basic concepts of functions, conditionals, loops, variables etc.

I recommend to university students that they attempt to use C/C++ as often as possible. If you have a choice of which language to use on a project, choose C/C++. When you apply for a job, you're very likely going to need to do some kind of programming test. If you're really familiar with the language, then you'll do several times better than otherwise.

"Well I know Java, and that's just like C++"
With the rising popularity of Java at universities, I've heard this statement a lot. A few years back I left games for a couple of years and did Java programming. When I (thankfully) came back to games I had all the fun of refamiliarising myself with pointers, low level string manipulation, manual memory management, bitwise operators and all the other low level stuff. Yes, Java is like C++ in that the syntax isn't too dissimilar, and they're both object oriented, but they're different enough to mean that there would be a noticeable transition period if we hired a person who just knew Java. I also agree that a person can be a great programmer, and that shifting language is pretty trivial for such a person, but in terms of getting through the interview process people will do much better if they're familiar with C/C++.

"I'm great at C++, and C is just part of C++, so therefore I know it"
This is another statement, or rather assumption, I've come across. It's also a lot more of a grey area than the Java vs C++ issue. Knowing C++ is good, but if you really want to do well in the interview process, make sure that your lower level C is good. If you ask some people to write a string reverse function they'll break it down into 5 classes, and wrap it in accessor functions. These are good skills to have, but it's better to have the low level skills too. Ideally people who know C should be familiar with things like:

• How numbers get represented in binary for signed ints, unsigned ints, and floats.
• The sizes of data types, and the padding which happens in structs.
• Use of pointers, and pointer arithmetic.
• Use of bitwise operators such as And, Or, Not, Bit shifts, and masking. For example, how would you read and write to the middle two bits in a byte without disturbing the rest?

"What about assembly language?"
Having a low level understanding of how processor works, and assembly language is a very useful skill for games developers. It helps one to write optimal C/C++, and we occasionally end up optimizing heavily used functions into assembly (e.g. math functions) or stepping through assembly to work out why our code isn't working. This said, I don't consider this especially important for a junior candidate. Personally, I'd much rather see good strength in C/C++.


Conclusion
C/C++ is trickier to learn than VB, Java, and some other languages. In some ways it would be cool if other languages could be used for console game development. We might spend less time tracking down dangling pointers, off by one errors, and writing lots of code just to build a string. But in the context of getting a job programming for games consoles, C/C++ is the way.

You might be thinking “Isn’t it short sighted to require that people specifically know C/C++, when they might be a great programmer in another language and can cross over quickly after being hired?”. Yes, you’re probably right. But if we interview two people, and one’s already familiar with it, they’ll have an advantage.

If you've never touched C/C++ before, Microsoft has a free IDE (Visual C++ Express) and also has a lot of tutorials online.