Monday, December 25, 2006

Wii wish you a Merry Christmas

It’s a rule. You’re not allowed to make any kind of Wii related article, without having some kind of pun in the title.

I’ve had a couple of goes on a Wii now. I’ve played Excite Truck, Wii Sports, a Monkey Ball mini game, and I’ve had a go at creating a Mii. I’ve also seen one connect to the internet and visit a regular website. Here are a few impressions:
  • Wii Sports is fun. It has about five main game types, of which some offer limited longevity (boxing), but some of the others, such as golf and tennis are worth coming back to.
  • It’s really cool that it connects wirelessly to the internet and gives you a proper web browser (Opera based). As a test, we connected to YouTube and watched a video. It all works, but due to the limited resolution, you generally need to zoom in and scroll around the page to read it. For text entry a virtual keyboard appears, which you type on by aiming the Wiimote at the screen and shooting the letters sort of like a light gun. I’m sure a third party hardware manufacturer will do a keyboard before long.
  • When the Wiimote is used to point at the screen like a light gun / mouse, it’s very nice. The pointer is nice and steady and easy to control. One fun thing is that the pointer icon on the screen rotates if you twist the remote. In Excite Truck I noticed the pointer jittering. I’m going to take a guess that when the pointer position is smooth, the application is doing some averaging out of the position to hide the jitter. If this is the case, then there might be a slight lag in how well the pointer follows your actions, but I didn’t notice a problem.
  • Monkey Ball has something like 50 mini games, which each find different uses for the controller. I didn’t play it much, but this would very likely be a good game to get for Wii, as the original was good.
  • I find the Mii creation to be great fun. You personalize a little 3D person to look like yourself (or whoever) and then games can give you the option to play as your Mii. In Wii Sports, the little character who’s doing the sport can be the Mii you created. You can configure multiple Mii’s on one box, and I believe that when you see which of your friends are online, you see their Mii’s. Very cool. It’s quite reminiscent of the south park character creator.

Pros:
  • The controller works well.
  • It’s great fun for everyone, even people who never play games.
  • Free online service (as opposed to monthly payments for things like Xbox Live).
  • Nice and small.
  • $250.
Cons:
  • The limited resolution is going to detract from the usefulness of the browser (I think).
  • The CPU and GPU aren’t the best, but then that’s not the selling point.

Overall I’m greatly impressed. I’ll be picking on up as soon as the drought is over.

Thursday, December 14, 2006

My Life Story (abridged)

Oh come on, it’s my blog, I can be self-absorbed.

I was born in England at a young age.

When I was about 8, we got a ZX Spectrum computer (similar power level to the Commodore 64). This came with a version of basic pre-installed, and it was at this point that I started trying to code. I also decided that ‘when I grew up’ I was going to be a games programmer (as well as an artist and an author – two areas in which I’m no more skilled than I was when I was 8).

Ten years on, I still wanted to be a games programmer, but really, my skills were pretty poor. I went to Sheffield University to study Software Engineering, and then managed to land a job at Gremlin Interactive. I’d done some 3D graphics in my dissertation but hadn’t done much C coding.

I worked there for two years. It was the time when 3D accelerators were starting to appear, and everyone on PC was moving to DirectX 3. After my two years there, I’d become somewhat disillusioned. We’d spend a year or more slogging our brains out to make a game, which then has a shelf life of two weeks and sinks without trace (which happens for a lot of games). I wanted to work on something with more meaning!!!

So I packed that in and went to work for a company that made software for call centers! I learned Java, beans, server stuff, COM, JSP, ASP and a ton of other stuff I have almost no recollection of. It was fun for a couple of years, but then I came to the realization that, short of joining/forming programmers without borders, there wasn’t a lot of meaning to be had, and that I was finding serious software, seriously boring.

At this point, my old workmate from Gremlin called to invite me to a new studio that ‘Rage’ started. It didn’t take much deliberation. I was back in games, and I enjoyed it more than ever.

I planned on staying at Rage for a long time, but after a couple of years the company folded. We were all allowed to spend our last days of work time applying for other jobs, and someone mentioned to me that experienced people could get jobs in America. I applied to a few companies, and after a few months secured my position at Heavy Iron.

At first I did some porting of games to Xbox, then I was lead programmer on a couple of games, and now I manage the programming department. I’m glad to say that I’ve been at Heavy Iron for four years so far.

Without this turning into an Oscar speech, I really appreciate the cards I’ve been dealt so far. Having a job that allows me to work overseas is great. I find living abroad to be a wonderful experience. Also working in games is inherently interesting to me, and presents constant new challenges to be overcome.

Yay life!

Bad news for coders...

It turns out that the free coke is bad for you. Whatever next?

Thursday, December 07, 2006

Work/Life Balance

Working hard, for long hours, is pretty common in the games industry, especially for programmers. In this post, I’ll not go into whether this over-working is a good thing or how we could move away from it, we’ll just accept that it’s the way it currently is at many games companies.

It’s very common for programmers to spend a long time at work. Some do it for the love of coding, some as a show of how macho they are at working hard, and some to show how much they’re being a martyr for the good of the game. And for the most part, it works OK. The programmers have some fun, spend time with other dedicated individuals, the oh-so important deadline gets met, the company gets its game on time, and everyone’s happy.

The point where this falls down is when you scale it up to, let’s say, 20 years. If you’re not careful, you could quickly flit by the whole 20 years in a blur of deadlines, the snack cupboard, pizza, cola, high-stress, and shabby living.

You can pay a high price for all the years of bad posture, no exercise and no ‘life’, from not prioritizing people outside of work, and for not exploring hobbies and interests away from the computer. You could find yourself looking back at a string of AAA titles, but find little solace in it. Worse still your health could suffer, tales of work-a-holics having heart-attacks before their time are not uncommon, and unfortunately they can hit anyone. Carpul tunnel, repetitive strain injury, neck and back problems also have a high likelihood.

My aim here isn’t to depress you though. It’s a not-so-gentle reminder that you need to look after yourself and live a balanced life. If you’re too ‘one sided’, coding all the time, then in the long run you’ll suffer. It means doing tricky things like exercising and forcing yourself to get out and socialize in the real world, but it’s hugely worth doing.

Aren’t I shooting myself in the foot here, scaring off new recruits? Not at all. Happy balanced workers get sick less often, will hopefully never ‘burn out’, will work as well or better than the stressed ones, and make the work environment a better place to be.

So there we have it. Exercise, have hobbies, socialize, get away from computers, and be aware of when you need to take a break. You’ll live and code for longer, and enjoy life more.

Oh, and always wear sunscreen.

Saturday, December 02, 2006

Ratatouille

THQ has now announced that our studio (Heavy Iron) is working on the game of Ratatouille (the next Pixar movie).

Here's a video of an early proof of concept... ;)



(Not my video, just one found on youtube)

Friday, December 01, 2006

How to get a job as a Game Designer

Being a game designer can be a very creative pursuit. Spending time thinking about how to engage the player, building it, and then getting feedback from players is great fun.

So what’s a good way of going about getting a job as a games designer?

  • There’s no standard academic route in, like programming and art, though a degree in something wouldn’t hurt.
  • One, not uncommon, route is to work as a games tester, and to work on getting promoted up. If you show an interest, someone will hopefully get you set up with the tools, so you can learn them and show off what you can do.
  • Similar to my recommendations for programmers, doing demos is a great way in. Download free editors for PC games. Design and build your level. Publish it on the internet for others to play, and then check out the feedback.
  • From your demo work you should be able to show paper maps, screen shots of the editor and game, and links to your published level and its feedback.
  • You can put all your demo work on a website to show off your work. Also, putting it on a website will demonstrate important skills of technical literacy and good presentation.
  • Doing several demos, to cover different game genres, is a good idea.
  • Play lots of games, and think analytically about them. Why are they fun? How could they be better? How do they handle a range of skill levels? What editor tools would have been needed to create the game.
  • Play lots of different games. The more the better. Don’t just play good games, play bad ones, and play random ones so you can make your own mind up without the suggestions of others.
  • There are also plenty of books on game design now. You may benefit from reading a good book on the subject.

I can’t guarantee it, but if you do all the above with some dedication, then you shouldn’t have too much difficulty getting your foot in the door. In fact, some companies who release editors will actively recruit from the pool of hobbyists who are already building levels with their software.

Friday, November 24, 2006

What's a game designer?

I’ve spoken quite a bit on how to get a job as a games programmer. I’d also like to mention the position of games designer. The role of designers varies greatly from company to company. Some companies have no designers at all, some will have a couple, and some can have more designers than programmers. Designers spend most of their time building levels of a game, and also working on the games’ design.

Game designers spend most of their days building levels in a level editor. Editors normally come in one of three flavors, custom level editor, in-game editor, or an augmented 3D package (e.g. Maya with some custom bits which are specific to the game). Designers tend to need to work very closely with the art, animation and programming departments to ensure that the level is built correctly, and that all the required pieces get made. Also, depending on what the programmers have provided, designers may configure game logic using either a simple scripting language, or some more visual way of configuring logic.

Designers focus on things like:

  • Making the experience fun.
  • Making the game accessible to novice and expert players.
  • Building in ‘replayability’ so that people can play the game for a good duration.
  • Gradually ramping the difficulty of the game across the levels.
  • Perhaps integrating the gameplay with some kind of running plot.
  • Ensuring all the available systems get used in the game, so that no effort is wasted.
  • Helping to get levels to fit into memory or performance constraints.
  • Building main levels, but also building other things like mini-games, and bosses.
  • Depending on the company, the designers may also do other things like design and implement the functionality of the menu screens, or writing the dialogue scripts for the game.

Next time: How to become one…

Thursday, November 16, 2006

Getting a job, and how much it pays...

There are a couple of good articles on the GameCareerGuide website at the moment. Steven Messinger from Rockstar writes on how to get into programming games, and there's an article on the results of this years Game Developer salary survey.

Monday, November 13, 2006

Coding4Fun site

Microsoft has a great site 'Coding4Fun' which has lots of fun apps to write for people getting started with coding.

Actually though, there's a lot of cool stuff for people who are pretty good at coding too. There are tutorials on making web services, windows utilities and AV related programs. If you've got a bit of time, there's bound to be something worth tinkering with here...

Sunday, November 05, 2006

Weekend Project - Microsoft Virtual Labs

Last weekend I happened across the MSDN Virtual Labs. Basically they have a bunch of tutorials on how to use .NET to do snazzy things. The cool thing is that the tutorial takes place by you doing ‘remote desktop’ control of a machine that’s all set up for the tutorial. This means that you don’t have to spend ages getting all the software set up, you just jump in, following the step by step guides, setting up projects, building web apps, configuring databases etc.

In a bit over an hour I followed a tutorial which had me set up a server database, a C# application which view/modifies the database, and a web app which did the same. To go from knowing nothing to having all that working in around 60 minutes is fantastic.

It reminds me a little of the film Amelie, where she leads the blind man along the street for a few moments. I’ve just been exposed to a load of information, which I can’t immediately recall, but I got a good feel for the landscape.

Lots of different types of labs are available. I didn’t see anything game related, but it’s good to know what kind of technology is out there for when you have to build other things like tools.

Ohh, plus you can enter to win an Xbox 360 if you take the survey after the lab. When I did it though, they had ‘technical difficulties’ with that part :(

Friday, November 03, 2006

Game Studio Express - Beta 2 Released

Microsoft have just released Beta 2 of Game Studio Express. It's the SDK which helps you make games for Xbox 360 Homebrew, and Windows.

I think it's fantastic that they're opening up the console to homebrew developers, and also giving so much help for people to get started. The one thing which irks me is that it only supports C#. Professional game development is currently C++ based, and I don't see it changing for a while. C# is a great language which is easier in a lot of ways than C++. It's great if you're just getting started, or you don't care about non-Microsoft platforms, but if you're looking to get into games, remember to work on your C++ too. Having an Xbox360 demo, but not knowing C++ well, is not as good as having a Windows only demo which is written in C++. C# is good to know too though, as it can be used to quickly develop tools.

Thursday, October 26, 2006

Getting a games programming job - Tip 10 - More interview question topics

When I recently posted about finding programming interview questions online, I neglected to mention a couple of other areas that games companies like to ask about.
  • 3D Math is popular. Here's a bit of a sample of it I found on a quick search.
  • 3D Rendering. There's a long article here which takes you through most of the important concepts.
  • General Math is pretty important. I'll not give a link to it, it's a bit too big.
One more note is that there are quite a few sites which list interview questions which Microsoft has asked in the past. A quick search will show up sites of questions like this.

Sunday, October 22, 2006

Getting a games programming job - Summary

One of my main topics has been giving tips on getting a job in console game programming. Here's a summary of all the posts on the subject:

Tuesday, October 17, 2006

Books on games

I just came across the following article. It's a pick of '50 books for everyone in the games industry'. There look to be some interesting books in there.

Friday, October 13, 2006

How much does it cost to make a game?

There’s quite a range of games being made. A simple flash game might take under one man month to develop all the art and code, whereas a high-end console game could take in excess of 2000 man months across all departments (e.g. 100 people for 20 months). If a game can generate a profit that covers the cost of development, marketing and publishing, then it is in one sense, a success.

I’m not very familiar with the money end of game production, but lets make up some quite inaccurate numbers for fun. Lets say that the average worker costs $60,000 per year. We’re working on a 1000 man month project. This means that the salaries for the team add up to $5 million. Then we add a marketing budget of another million. And lets throw another million on for things like publishing, middleware and recording of music and voices. So in total this makes $7 million. I think this number is in the right ballpark, but many games will have a far higher budget, and the trend towards more and more impressive games keeps on pushing it up higher.


If the game is selling in the high street for $40, let’s say that half of that money makes its way back to the publisher (I’ll treat the publisher and developer as one entity for simplicity). That means we need to sell 350,000 copies before we start to make a profit.

I don’t have a particular point or statement to make, I just like throwing numbers around and explaining roughly how things work. You can see from the above that developing large scale games is a risky business. There’s potential for a lot of money to be made if you have a hit, but it’s expensive to build the game in the first place, and if you fall short of the numbers then you can fail to make back your millions.

Working on small-scale games on the other hand gives less risk, and generally speaking, less potential rewards. This said there’s a lot of interest in casual games these days and money being made.

One thing I like is that there’s quite a large spectrum of games being made – cell phone games, hand held consoles, next generation console games, Xbox360 Arcade games, serious games and casual games. It means lots of different niches for different groups of companies, rather than everyone just trying to make high-end console games.

Note: This post contains a lot of made up numbers. They’re just rough guesses built up from working at a few different companies.

Thursday, October 05, 2006

Getting a games programming job - Tip 9 - Working on group projects

I interview quite a few people who’ve worked on group projects at university. In an average group project, I’ll often see that two people did almost all the programming work, one person did a trivial bit, and then one person performed some other role like writing the fluffy game design doc (which is far beyond what gets implemented:) and doing graphics.

If this was isolated, it wouldn’t be too bad, but what normally happens is that on the next project, people perform the same roles. The coders code, and the people who worked on other things last time, again work on things other than code. By the time university is over, the code dodgers may well have the same GPA as the coders, but when it comes to interviewing for a coding job, they can have a hard time.

Recommendations:

  • Don’t let it happen to you. When there’s code to be written, jump in, and do as much as you can.
  • Don’t let it happen to your friends. Help to structure your team so that everyone codes. This is both ‘being nice’, but also building up skills you’ll need in working in a team of programmers.
  • If you somehow get stuck in a non-programming role, then do more coding on your own outside of your class projects. Writing demos and games on your own can be one of the most important things you do in terms of getting a job.

The more coding practice you get, the easier job interviews for programming positions are.

Thursday, September 28, 2006

Getting a games programming job - Tip 8 - Post Interview Feedback

After the interview, what’s next?

The Slow
Hopefully the company will follow up with you pretty soon after the interview. Sometimes though, either through them being busy, losing track of you, or waiting to see how other candidates turn out, they are slow at replying.

I recommend giving a polite nudge at first. A mail along the lines of “Thanks very much for taking the time to interview me the other day. I had a good time and am very excited about the prospect of working with you. I look forward to hearing from you.”

The Good
If the company liked you and wants to hire you, then they’ll likely want to check your references before making you an offer. If they take a long time with any particular stage (e.g. more than a week), then polite nudges are recommended.

The Bad
Almost everyone gets rejection letters at some point. The key here is to use it as a learning experience and move on, don’t be upset and get depressed. It doesn’t necessarily mean that you were bad, there might have been a stronger candidate, the position might have disappeared due to team restructuring, they might have been after someone with very specific skills/experience etc.

What can you learn?
  • Take another look at your resume. Is there something you should add or remove? E.g. Perhaps they liked it when you mentioned that pong game you wrote, and it’s not on your resume.
  • Work through the interview questions again. Research the best answers. Make little test programs which implement the solutions to the problems.
  • How did you cope with doing answers on a whiteboard? Could you practice this with friends/family in some way?
  • If you’d been sat on the other side of the interview table, how would you describe the impression you gave?

Don’t take the rejection too hard - when I applied for jobs in America, five places didn’t even return me a mail (thanks guys:), and then the sixth hired me. Just don’t get bitter, keep coding, and learning from everything you can.

Sunday, September 24, 2006

Moonpod Developer Diary

Before working at Heavy Iron, I worked at a small doomed games company in England called Rage. After our studio was closed as a cost cutting exercise I came to America. A few of my other friends started Moonpod. Since then they’ve released a game called Starscape and are currently in the final stages of their second game 'Mr Robot'.

Moonpod write a monthly developer diary, which talks about what they’re working on, shows lots of pictures, and discusses the issues they’re facing. I find it a great read, and highly recommend it to any novice or professional game programmer.

Monday, September 18, 2006

Tools - Distributed Compilers

You might have guessed by the amount that I talk about speeding up compile time, that compilation time becomes a big problem when working on big projects. A full rebuild of something could take 15 minutes or more depending on the project, machine speed etc (though most builds are a lot smaller). Multiply this by the number of programmers, and you start to have serious amounts of wasted time.

The techniques I’ve mentioned in the past help speed things up, but there’s also a tool solution. Commercial products like Incredibuild (for VC++ projects) and SN Systems DBS (SN make compilers and tools for console development) work by sharing the compilation across several machines. Let’s say there are 8 programmers. At any one moment, usually only one or two people are compiling. When a person compiles, it farms out individual cpp files to the different machines, and they compile in parallel.

There are eventually diminishing returns to the parallelism due to the amount of coordination that needs to happen, and the fact that linking is still done by one machine, but overall a good speedup can be attained.

How do these systems work? I’m not entirely sure about the internals, but my suspicion is that the PC which initiates the task does all the preprocessing of the cpp file, so that all the headers are already included. This means that one file can be moved to the client, and that the file doesn’t ‘need’ anything else.

The downsides are the cost of buying, and the reduced amount of time for juggling.

Friday, September 08, 2006

These are a few of my favorite things...

I’m going to take it easy this week, and just mention a few sites which I like to watch.
http://www.fun-motion.com/ - Blog about physics based games.
http://www.gameproducer.net/ - Blog about indie game development.
http://www.xkcd.com/ - I was just introduced to this recently, but it’s quickly becoming a favorite. Geeky humor.

Tuesday, September 05, 2006

Game Career Website

Gamasutra have launched GameCareerGuide.com. At a quick glance, it looks like it's worth a read.

Wednesday, August 30, 2006

Faster Build Times - Reducing Header Dependencies


Long compile times are a pain in the neck. They waste time, cause frustration, interrupt your ‘flow’ etc. They do cause a lot of programmers to learn how to juggle, which is a slight positive, but lets proceed with the assumption that long compile times are bad.

As I’ve already mentioned in the past, a lot of compilation time goes into parsing headers. Using pre-compiled headers is a good way to reduce them, but there are a couple of other ways.

You can wrap your header with the following kind of pre-processor directives:

#ifndef _MYFILENAME_H_

#define _MYFILENAME_H_

… normal header contents go here …

#endif // _MYFILENAME_H_

So what does this do? Well the defined value “_MYFILENAME_H_” is arbitrary, it’s just some unique value, the filename with some underscores is commonly used. The first time this is encountered, the parser will process the contents of the header, but also define the property. If the header gets included again (for the current cpp file it’s compiling) the value will already be defined and the contents of the header will be skipped. This is a time saving, and also avoids cyclic loops of headers.

But wait! For that trick to work, the parser still has to read the header to get to the point where the #endif is, so it still has to read the whole file.

Microsoft have an answer for this. You can put:

#pragma once

at the top of your file, and the parser will only include the file once. The parser knows that if it encounters this pragma for a second time for one cpp file, it can just stop there. This is good, but it only works on the Microsoft compiler, and so might not meet your needs. Also even though we’re preventing repeated parsing of the same file, we could still be including a lot of files.

The best thing is for us to reduce the amount of headers getting included. Most people know this, but it’s still a very common problem. A header can need to include another header for several reasons, including:

  • So a class/struct from another file can be embedded in a class.
  • So that functions defined in the header can ‘use’ another data types' functions and data.
  • So pointers to other classes/structs can be used in structures and function prototypes.

The last bullet point here is interesting. The header that’s doing the including is not needing to know the size of the other structure, or call functions related to it. In this case, we can just make a forward declaration instead of including the other header. So to embed a pointer to the class 'Foo', instead of:

#include “foo.h”

we can just say:

class Foo;

This tells the compiler “there’s a class called Foo, and all you need to know right now is that it exists and I’m going to be dealing with pointers to it”. You’ll then likely need to put the #include into one or more cpp files where the pointer gets used. This can seem like a pointless exercise at first, but it reduces the overall amount of headers which need including, by breaking the chains of headers which rely on other headers.

You can also think about the other cases – do I need to implement this function in the header, or can it be moved to the cpp, allowing me to remove the include.

If you want faster build times, turn on build timing so you can see how long your compiles take. In .NET, go to “Tools->Options->Projects and Solutions->VC++ Project Settings->Build Timing” and turn it on. Then turn on “Project->Properties->C/C++->Advanced->Show Includes” to show a list of all the included files when you compile. Then look at the build output and find header include chains you think you can break up.

It can be tricky to reduce header dependencies, it requires many large rebuilds of your project. But assuming you can find some optimisations, you get paid back in shorter compile times and the benefits they bring.

Friday, August 25, 2006

Getting a games programming job - Tip 7 - Practice Answering Interview Questions

During a phone interview, programming test, and interview, the chances are that you’re going to get asked a load of questions. Many of the questions you’ll be asked are general programming questions, perhaps dressed up with a game related theme. Doing a quick search for “programming interview questions yields a bunch sites which round up the types of questions you get asked.

Reading and answering a few questions probably isn’t going to suddenly make the interview process a cakewalk, but it can show you some areas to practice and can give you an idea of the type of questions you’re going to be asked. Beyond standard interview questions, in a games interview you’ll likely also get asked questions about 3D math, and lower level operations like memory allocation, pointers, bitwise operations, and hardware and operating system concepts.

One more thing. It's easy to read a question, read the answer, and fool yourself into thinking you'd be great at answering. Put a bit more effort into it, write your answer out, talk out loud as if you were talking to an interviewer. You might find that the answer is harder to write down than you think, or that you've forgotten your impressive vocabulary of cromulent words. Another good idea is to code it up and make it work - if you've not written a linked list class in a while, an interview is a pretty rough place to re-learn it. This is why I recommend working on demos, and keeping on coding while you go through the interview process.

Thursday, August 17, 2006

Getting a games programming job - Tip 6 - Submitting Your Resume

The first stage in your application process is sending in your resume and cover letter. Here are a few of my tips, mainly aimed at people new to the industry:

  • It doesn’t hurt to personalize your application by mentioning the name of the company, and saying why you’d like to work with them in particular. If I read ‘I liked playing ‘The Incredibles’ and would like to work on similar titles’ then that makes the person stand out. It shows they’ve researched the company, and are particularly interested in it. It’s the difference between getting junk mail that says Dear Sir, and Dear .
  • If you’ve been doing little demo projects like I suggest, mention it, and give a link to your web page. Being able to quickly show someone what you can do can make a massive difference.
  • I like it when the application includes a cover letter, and perhaps a note about hobbies/interests. It gives a chance for me to see the applicant as a person, and not just a completed University course. Expressing why you want to work in games, and the fact that you’re crazy about playing the Sax lets your personality show, and makes you memorable. You become ‘that Sax guy’. It also shows your communication skills. The ability to communicate well is important in almost any job.
  • Be honest about your abilities. If you get an interview, and people find that you’ve been exaggerating in some area, then it casts doubt on everything you’ve put. Don’t undersell yourself either, as you might not get called.
  • If you’re proud of your GPA, don’t forget to put it.
  • Format what you’re sending nicely. Check the spelling and grammar.
  • If you’re coming from an educational establishment, then they likely have a group who will check your resume for you. Make sure you use this. If you don’t have this kind of service available, then find one or two people who can proof read it for you.
  • It’s best to apply directly to the company instead of using a recruiter. Using a recruiter would be free to you, but would usually cost the company several thousand dollars to hire you. You’re saving the company money by applying directly. Another thing is that sometimes your resume gets mangled down to a badly formatted txt file, which can give a bad impression.
  • At some companies, the online job application database, or centralized corporate HR department can be a bit of a quagmire that applications get stuck in. Whenever possible I try and avoid this route by contacting the studio directly, or finding a contact there through a friend of a friend.
  • While you’re going through the interview process, keep on coding for fun. It’ll keep your skills nice and sharp, and you also wont have much time for your own coding once you get a job.
Hopefully, with your resume in good order, you'll soon be contacted and then move onto the next stage. As it's videogames, you have to complete three stages and then you face a big angry boss.

Oh come on, that was a good one...

Monday, August 14, 2006

Homebrew Xbox 360

In the news today.

"Microsoft Corp. on Monday will announce the availability of software tools aimed at encouraging independent and hobbyist video game makers to create titles for its new Xbox 360 console."

"A test version of the tool kit will be out by Aug. 30. The final product will be available this holiday season for an annual subscription of $99 per year for Xbox 360 game development. The software will be free to people making games to run on Windows."

I think this is great news. It really opens the door to people wanting to get into the industry, to creative new game ideas, indie developers, all sorts...

Saturday, August 12, 2006

Blog Update - August 2006

I thought that today would be a good day to post an update about the blog.

As you’ve hopefully noticed, I’ve been tweaking the layout. There’s a beautiful picture of me, less ads, and generally a cleaner look. Thanks to Scott Chiu for helping to squeeze the DVD tray into my mouth.

I use Google Analytics and AdSense to track some stats on the site. For the month of July the site averaged 27 hits per day. I can also tell that 75% of hits are ‘returning visitors’, and traffic spikes at around 50 each time a post is made. I like this, as it hopefully means people are getting something out of the site.

Some might wonder how much money AdSense is making. Well I’m proud to say that in the first three months I’ve managed to rack up a whopping $3.88. I hope all this money doesn’t corrupt me and send me down a path of ruin. :)

Having AdSense does give me a good way of tracking traffic though, and it’s amusing to see how irrelevant the ads can get. I also had some Amazon ads, and they did quite literally nothing.

Analytics gives a fun graphical display of where in the world people are reading from. A big shout out to the New Zealand, India and Philippines crews. :)



I’m enjoying writing the blog. At first I thought I was going to run out of ideas, but more and more topics keep coming up. That said, I really enjoy getting posts and mail, as it helps me shape what I write about, and it’s nice to make the connection.

Thanks for reading so far!

Mark.

Thursday, August 10, 2006

Favourite Tools - Inkscape

I recently came across Inkscape. It’s an open source vector graphic editor. An example of vector graphics is windows clip art. The image is stored as lines and colored areas rather than pixels, which means you can zoom in infinitely without pixelation.

I find it absolutely brilliant. It’s very intuitive and easy to use, and comes with interactive tutorials.

A big hurdle for small scale independent coding is that programmers are usually pretty bad at art – hence the commonly used term “Programmer Art”. I find that this program allows me to ‘build’ my art, rather than ‘draw’ it. It allows me to make much better images than I get when I try and use something like Photoshop. You could use it for in game art, website art, icons, all kinds of things.


Now for something really cool. It saves in Scalable Vector Graphics (SVG) format, which is an open source XML format. You could use Inkscape as a level layout tool for a game. For example, red circles are where enemy tanks go, the player starts on the blue circle, walls can be made from lines, etc. You can even import textures into the art, which could be a way of bringing texturing into the world. Using Inkscape in this way could save you months of effort compared with making an editor yourself. You can then use an open source XML parser like Xerces to parse the file. Your whole tool chain is written for you!

Another thing you could use it for is laying out UI screens. Using Inkscape could provide a far better development process than hard coding positions, or hand writing a text file of parameters.

One downside is that it doesn’t support making animated vector graphics. Still though, it’s mighty cool. If you’ve got some free time, I recommend downloading it and having a play.

Saturday, August 05, 2006

Favourite Sites – TheFreeCountry.com

I like to use lots of different tools while I’m working. Finding a good tool to help you do a task can reduce a mundane task like renaming 100 files from 30 mind numbing minutes to 5 minutes of feeling smug. Brilliant.

When picking a tool, as well as just generally searching around myself, I usually check the free country as it usually has a good list of programs to try. I usually find it quicker to find a good tool using this site, than searching through other free/shareware directories.

Tuesday, August 01, 2006

Getting a games programming job - Tip 5 - Understanding The Interview Process

To get a games job you’ll go through an interview process. If this is your first proper job, then it’s good to know what to expect. Here’s how an average games company might do things:
  • You submit your resume.
  • If they’re interested in you, someone contacts you to arrange a phone interview.
  • You have a phone interview with someone technical. They probably ask programming and problem solving questions, as well as about the things you’ve listed in your resume.
  • If that goes OK, they might send you a programming test which you do at home and email back to them. This could be 10 questions in which you write a function, or writing just one system.
  • If that goes OK, you’re invited in for an in-house interview. If you’re out of state, then they’ll either fly you in, or perhaps do more phone interviewing first.
  • If the interview goes OK, they check your references.
  • If your references check out they make you a job offer.
  • You choose to accept or reject the offer.
Each company is different. For example, some companies don’t do a programming test, or do the test before the phone interview.

In future posts I’ll spend time talking about the different stages of the interview process. I’ll aim to give some tips which help you know what to expect, keep you calm, and generally improve your chances of landing a job.

MSDN is now free

I just heard that MSDN is now free to download. It was available online before, but if you prefer to have it local and like downloading 1.6GB files, have at it...

MSDN is a huge technical library which covers all the different Microsoft technologies from Visual Basic to SQL server. If you're coding games, the windows and C++ stuff will be occasionally useful, but you can access it all online too.

Wednesday, July 26, 2006

Programming games in Python

I recently found the ScriptedFun website. It’s a blog which gives worked examples of how to create simple games using the python scripting language. I’ve not worked through the examples, but for beginners, following this kind of tutorial would likely be very helpful.

Wednesday, July 19, 2006

Why is coding for consoles different than coding for PC?

I sometimes ask people questions of the format, “If you’re coding on a console, why would you blah blah blah?”. The blah blah part is confusing enough, but also a lot of people don’t know what the differences are between coding for consoles and PC’s. Here’s my little run down of most of the main ones. First, the main technical differences:

  • Consoles (at least if you’re just developing for one type of console) have fixed hardware. You don’t have to worry about grossly different processors, graphics cards, hard drive speed, memory or controllers.
  • PC’s have ‘virtual memory’ as part of the operating system. In simple terms this shifts things from physical memory onto the hard disk when they’re not being used. No current consoles have this feature, and so the program has to use only the physical memory available. This is good for performance, but means that you really have to keep a close eye on memory usage in your game.
  • Consoles have custom hardware like DSP’s, DMAs, SPUs, and areas of memory which are faster/slower than others. Making use of these features often requires low level coding which can get pretty complex.
  • Next generation consoles like Xbox 360 and PS3 have multiple processors. If you want to get the best performance out of the hardware, you have to architect your engine to utilize all the processors as fully as possible. This is a complex task.
  • Consoles can have a different endianness than PC or other consoles. This means you've got to be careful when coding, and sometimes need to 'swap the bytes' when writing data files.

And also some less technical ones:

  • There’s usually no mouse or keyboard. These are often helpful when developing PC games.
  • The machine is just running your game. Your game isn’t running ‘infront’ of windows. When your game crashes the console just sits there doing nothing.
  • If you start by just using the libraries which come with the system, you often start coding with very little support. You start by writing lots of code to do simple things like render debug text, load files, do vector math etc.
  • As mentioned in an earlier article, STL may not be natively supported.
  • The compiler may not support all the language features you are used to using.
  • You are often required to use an IDE other than the one you are used to. This can mean learning different shortcuts, and using a debugger which is less usable than the one you are used to.
  • Console development is a fast paced industry. If you start developing on a system close to when it comes out, you can expect to use very clunky hardware, API’s with bugs in, and compilers which sometimes generate bad output for valid code.
  • Developing a game for a single console means that you can spend time making use of all the features available, and squeezing all the performance you can from the machine. As opposed to basing your decisions on what ‘lowest common denominator’ hardware you will have available, or spending time on feature/performance scalability.
  • You don’t have to worry about writing install/uninstall scripts.
  • You do have to worry about a big list of technical requirements. For example, all the text messages about memory cards need to use the proper terminology, you have to supply an icon for the save card, the on screen text can’t be too close to the edge of the screen, etc. All these things (and more) need to be checked and approved by the console manufacturer before you are allowed to ship.
  • You’re not allowed to patch the game after it ships. On PC it seems that you can ship the game from half way through production and then release patches. J
  • Testing of PC games requires testing on a broad range of hardware. Testing for consoles is a lot simpler in this area.

If you’re looking for how to get some experience with console coding, a good way to get started is to search for homebrew sites and write your own console code. You can use free compilers and emulators, and even buy hardware which allows you to run your code on the console. For fun I wrote some Gameboy code a few years ago. It was a great feeling to see it running on the proper kit.

Note: Using emulators and homebrew development is generally not approved of by the console makers. Personally, if you’re doing it to build knowledge and experience, then I don’t see the harm. Some people use the same tools for piracy – that’s not cool.

Thursday, July 13, 2006

Getting a games programming job - Tip 4 - Create a Website

I’ve eluded to this in earlier posts, but once you’ve written a demo or two, why not put them on a web page?

  • It shows you have the technical skills involved in building a web page.
  • It shows off your communication and presentation skills.
  • It makes your resume stand out, and be more memorable.
  • It increases the likelihood that you’ll spend your interview talking about your demos, which is better than answering questions you’ve never heard before.

Here are a couple of tips to bear in mind while making your site.

  • Keep it reasonably professional. We don’t need to know your 100 top films, see your family album, or follow links to your favourite comics.
  • Some words are good, but avoid big essays. Pictures and a few words are enough. We can ask for more details during the interview.
  • Use screen grabs and video as appropriate. It’s a lot easier for people to look at pictures or a video, than to download executables and struggle to get things to run. That said, if it’s a good demo, why not offer both pictures and a download.
  • Get your friends or perhaps teachers to look at the site and give feedback. As with your resume, it’s good to have a few people proof read it.

Thursday, July 06, 2006

Favourite Tools - Copernic

There are some tools which I really love. Near the top of my list is Copernic. Copernic is a ‘desktop search’ program which ‘indexes’ all your Outlook / Outlook express email, and the files on your computer. It’s similar to Windows Desktop Search and Google Desktop Search. I tried a few desktop search programs and Copernic is my favourite.

Using Copernic, you can key in a couple of keywords, and in a couple of seconds – bam – you’ve got a list of every email and file containing those words. You can then refine the search by being more specific about the sender or the type of file. If you’ve ever searched for email using the search feature in Outlook, you’ll never use it again.

If you get a lot of email and you don’t already have a desktop search program, drop everything and install Copernic now. It’s free, and you’ll start raving about it too.

Thursday, June 29, 2006

Getting a games programming job - Tip 3 - Don't rely on STL

STL is a nice library. It allows you to quickly create useful data structures with very little coding. It saves you from writing a lot of code which is conceptually quite simple, but often a source of annoying bugs. It also handles memory allocation for you, so you can have variable sized lists and strings without the hassle of doing a lot of allocation and deallocation of memory.

In game development, many companies make use of STL in tools. It’s reliable and saves development time. Also in tools, we are often less concerned about memory and performance issues. In console game code however, STL is used infrequently.

I’ve met several interview candidates who I would consider overly reliant on STL. When asked to solve a problem which called for an array of non-fixed size, the candidate would not be able to come up with an alternative for an STL vector. Or to give another example, would solve a problem which called for a simple array by using an un-necessarily complex STL type, like a hash.

Being familiar with STL is a good thing. It’s a useful tool when used in the right context. Having the flexibility to use it or cope without it is the best position to be in. I think that a good check for yourself is making a rule that you’re only allowed to use an STL data type once you’ve implemented the structure on your own at least once.

Wednesday, June 21, 2006

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. :)

Wednesday, June 14, 2006

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.

Friday, June 09, 2006

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!

Saturday, June 03, 2006

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.

Tuesday, May 30, 2006

Pros and Cons of Middleware

Coding

Whether you're a high end game maker working on a multi million dollar project, or an indie developer making a game for fun, you'd be very wise to consider what 3rd party systems you can leverage to save you time. Spending a little time to investigate what systems you can use could save you months or years of development effort.
High end commercial projects often license non-cheap systems for rendering, physics, sound etc (e.g. Renderware, Havok, Miles), while indie developers can use cheap or free systems like Ogre, Newton and OpenAL. Both at work and at home I like to look at the different systems out there just to know what's going on.
There are pros and cons to consider. Here are a few of the main ones which would face an indie developer:

Pros
1. Save LOTS of development time!
Taking the example of a rendering engine such as Ogre or Irrlicht. Using a system such as this usually gives you a well thought through and efficient system, which comes with advanced features like exporters, viewers, example code etc. If you attempt to build this yourself will take you far longer than it would to integrate and learn another system, and you'd also unlikely reach the same level of features.

2. Systems are debugged well due to the number of users.
Because open source systems have a lot of users, they tend to be pretty well debugged. The users will be developing in different operating systems, with different compilers, and different hardware. In terms of rendering engines, it's great news if you can be confident from day one that your rendering code has been tested on a broad range of hardware. Also note that the source will normally have a 'stable' branch, and a 'development' branch. The stable branch just gets bug fixes. The riskier new features go in the development branch.

3. You can use features you wouldn't otherwise use.
Engines often come with advanced features which can be easily 'turned on'. It can be trivial to turn on features like audio echo, stencil buffered shadows, full screen 'HDR blooming', etc. You may not have initially planned to need these features, but they can greatly enhance your game with very little effort.

4. Joining a community of developers.
All commonly used engines tend to have a wiki and/or forums to help you use the system. It's even more rewarding when you start to write your own wiki pages and help people in the forums. When you look back at a wiki page you wrote and see that several thousand people have read it and been helped along, it's a real buzz.

Cons
1. Reading licenses
Not so much a Con, but something you'll need to cope with. Each library comes with a license. This might say "do what you want with it", or it might say "don't modify it, and use it only as a DLL", or "You need to show our logo when the game starts" etc. The slightly annoying thing is that they're written in legaleese and distilling the meaning and looking for gotchas can give you a headache. Also look out for one system using another system, and you needing to read the licenses for the subsystems too. Examples of this are a rendering system using someone elses XML reader or true type font renderer. All this said, if you're just doing demos for your own ammusement, then you can usually just ignore the licenses (though that's not legal advice:)

2. Getting things working can be tricky.
Sometimes you get lucky, and sometimes you end up pulling your hair out. Installing all the right downloads to the right places, getting the right versions of everything, setting up project settings, and deciphering wierd crash bugs can be part of the territory when trying to get the first version working. That said, even if it takes you a couple of weeks to make it happy, you're still likely to be well ahead compared with writing it all yourself.

3. It may not do exactly what you want.
Third party systems, including commercial ones, will often 'like to do things a certain way', or more specifically 'make it really hard to do certain things'. When faced with something like this, either make sure that the system has the feature before you get too attached to it, or be ready to bend your requirements to fit better with what the system is capable of doing. For example, you might want to use Milkshape to build your models, but the system only comes with a Blender exporter - you could either change your choice of render system, join in with the development effort and make the new exporter, or just suck it up and learn the new program...

4. Getting new versions can be a pain.
Generally it's best if you get a version which works well enough for what you need, and then stick with it until you're done. Unfortunately you'll often need to upgrade. This can bring with it problems like needing to upgrade compiler, your data files being of an old format, the API changing, and new bugs being introduced. If the system has sensible people at the helm, these problems will be minimized by ownership of the system staying constant, version numbering which makes it clear whether to expect API changes, seperate branches for stable and release builds.

Tips for Choosing Systems
1. Get recommendations from friends/sources you trust.
2. Download the samples and try writing a simple demo / playing around with it before diving in and integrating it with your code.
3. You could use web traffic monitoring information to gauge how many users a system has. If, for example, Google Analytics shows low traffic, then it might mean that it's not a very popular system. Though that said, a system might get a lot of traffic if everyone is having trouble with it :)

This is quite an interesting topic, and I've only managed to unevenly scratch the surface here. I'll return to this topic in the future, and also detail some experiences with specific systems. (To avoid any legal issues, I'll talk mostly about non-commercial products)

Sunday, May 21, 2006

Experimental Gameplay Competition

There's a website called www.experimentalgameplay.com which encourages people to create quick prototypes of games for fun.

I recently had the pleasure of working with the Experimental Gameplay guys to run a competition to win a summer internship at Heavy Iron. The contestants had about two weeks to make a game based on the theme of "Consumption". Sixteen people submitted games, and from these people we chose two interns for summer internships.

I really enjoyed being involved. The games were great fun to play and the winners are really looking forward to starting. Hopefully we'll be able to do the competition again next year.

I recommend checking out what the experimental gameplay site and playing some of the games there. One important thing that the games demonstrate is that you don't need to have a team of 50 people working for six months to work out whether something is going to be fun. There are some lessons in this for large and small developers.

Tuesday, May 16, 2006

Experiences with Visual Studio Express

A programmers choice of development environment often ranks slightly higher than religion and politics in the list of things which they're fanatical about. Recently I needed to upgrade my version of Visual Studio.

Last November, Microsoft released Visual Studio Express. The name always confuses me, I always want to add .NET 8 2005 to the end, just to be clear. It's a trimmed down version of each of their Visual Studio packages. First of all they said that it was going to be free for a year, but they recently changed their minds and made it free all the time (announcement).

For professional games development, for Xbox[360] and tools, we use the professional edition of Visual C++. This costs around $500 per seat, and so for playing around at home I decided to try out the express edition.

Previous to Express, I was using Visual C++ Professional 6.0. There are lots of enhancements that they've done here and there which I knew would make things better, but I was also worried about dropping from professional to express. I've now made the switch, and the main things I've noticed are as follows:
  • First of all, it all feels very familiar to what I was used to with version 6.
  • While you're editing text, it does a little pre-processing of the code. Among other things, this allows it to grey out code which isn't going to compile. For example, code is in a "#if 0" block would be grey. Good.
  • When debugging, you can hold your mouse over a variable and a tooltip of the current value will pop up. If it's a pointer, it will let you drill down into the structure using the tool tip. Good.
  • When coding, you can hold your mouse over functions, variables, and likely other things, to get tool tips which tell you the type/definition. This is very cool as it saves right clicking and going to the definition. Good.
  • They've disabled source control integration in Express. This means you have to manually task switch to some other application to check things in/out of source control. Personally I have Perforce installed (it's free for under 2 users). I find the easiest way to check things in/out is to right click on the tab of the open source file and select "Open Containing Folder". This opens an explorer window with the appropriate file already selected. I then right click the selected file and use the Perforce context menu options to perform the operation. Also, due to the way that Perforce and VC work, if I'd accidentally started editing a source file which wasn't checked out, the check out operation wont stomp on my changes. I'd prefer proper source control integration, but my workaround is sufficient.
  • I'm not sure but I think that the DirectX plugins for debugging surfaces and renderstates don't work. I can't see them in VC but haven't looked into it. It would be a shame if these weren't present, as they really make development of rendering code easier.
Overall, I give VC++ Express two thumbs up and a cheeky wink. It's hobbled a bit, but still a really great tool for game development.

Saturday, May 13, 2006

Faster Build Times - Pre Compiled Headers

Coding

When compiling C/C++ code, header files get included. Headers often tend to include other headers. When a single c/cpp file is compiled, the compiler has to parse through all the headers recursively and process the contents. You may not realize this, but a huge amount of the build time is taken up with just processing the headers.

There's a concept called 'pre-compiled headers'. The idea is that you have one header which includes all the headers which don't change often (e.g. DirectX, OpenGL, third party rendering or sound APIs, STL etc.). These headers are processed and then stored as a processed binary blob. This pre-compiled header blob is then used by all your files, removing the need for them to parse the common files.

Whenever I've seen pre-compiled headers properly set up in a project, the improvement in build speed has been dramatic. Speed ups between 4x and 10x are normal.

The following web page does a great job of explaining this in more detail, and leading you through the simple (but un-intuitive) steps of setting up pre-compiled headers.

http://www.cygnus-software.com/papers/precompiledheaders.html

(Feel free to post a comment on how much this speeded your build time up)

Welcome to the Game Creator blog!

My name is Mark Pope, I'm a programmer and the Programming Director at Heavy Iron Studios (a division of THQ).

On this blog I'm going to be covering topics including coding, getting into the games industry, indie game development, and likely some random stuff which takes my fancy too.

Thanks for reading. Someone listening makes this a conversation, rather than a lunatic shouting in the park.