Advice for graduate programmers
So, you want to be a games programmer?
Writing computer games may seem like a dream job, but how do you actually become a games programmer?
CV advice and general tips
Be committed! Are you mad about games?
Firstly, having a passion for games is absolutely crucial. Only the best candidates succeed and these candidates are totally committed. You need to be passionate about games. Your programming skills may well transfer into the other (possibly better paid) sectors, but if you want to succeed in games it must be games that you want to make. It may seem as though every job advertised requires industry experience, but there are a limited number of places for candidates who have not worked in the games industry before.
Still with us? Then…
Make your CV scream games!
Make sure your CV screams out your objective of getting into the games industry! Write this at the top in your Objectives, Profile or Career Aims section to grab the reader’s attention. Then, in the rest of your CV, emphasise anything you’ve done which is relevant and/or shows your enthusiasm for and interest in games—e.g. 3D graphics programming during a University project or in your spare time.
Your hobbies and interests section is a great opportunity to show how keen you are. What type of games do you like? Any specific examples? Why? Here is the place to say! When you are playing think about what you like and don’t like – in an interview you’ll need to be prepared to talk about anything in your CV.
Use Agencies
Don’t be frightened of using agencies. Pick an agency which has a longstanding reputation in the games industry. A good agency will know exactly which companies are looking for what type of candidate. One call to an agency can save you many hours of time contacting every games company in the country. They are also an invaluable resource. Agencies look at CVs every day so they know what CV will get an interview and what won’t. Ask their advice. Openness and honesty are crucial. Your agency is working for you; they should keep you fully informed.
Prepare examples of your work
Programmers—Demo advice
This advice is subject to changes and improvements; reader comments are welcome. Please email prog@datascope.co.uk.
1. Which language/tools should I use?
Regardless of the platform(s) you wish to write games for, your demo should run on a typical Windows PC with the minimum of hassle. It’s usually safe to assume Windows 98, a 3D card, a sound card and DirectX 9.
C/C++ — Undoubtedly the first choice because these are the predominant languages used on the main console platforms and PC. If you haven’t already done so, get hold of a copy of MS Visual C++ and download or order the DirectX SDK (or another compiler and/or OpenGL) and experiment. If your C/C++ skills need brushing up have a look at one of the many books on the subject; ask other programmers for recommendations. Also use the web – there are lots of tutorials online, and a good starting point is the Developer Resources section of our Gateway to Games page.
Java—applets are preferable because they’re easier to run than applications. Include an html page in a zip file with your class/jar etc files, or send a link to a web page which contains the applet. If your applet only works with Sun’s or Microsoft’s VM, and/or needs Java 3D make sure you say so, and specify which versions are needed.
GBA and mobile games—please supply the necessary emulator and instructions as necessary.
2. What should my demo actually be?
This is your opportunity to shine! What are you interested in, and what can you show off? 3D graphics, physics, AI, networking? It sounds obvious, but the more impressive your demo is the more it will stand out. Having said that, it probably shouldn’t be at the expense of your formal studies or your entire social life! Even games companies like to employ people rather than coding machines 😉
A playable game is not necessarily the most desirable kind of demo, particularly if it’s 2D. Games companies see plenty of Pong and Tetris clones and tend to be underwhelmed, although by all means try writing a version of your favourite classic game as a learning exercise before trying something more ambitious. 3D graphics will impress most companies much more than 2D, and a demo showing a set of clear, well-implemented algorithms which you have had time to polish is generally better received than a complete 2D game.
Teamwork is crucial! Completing a demo game shows you have the enthusiasm and tenacity to finish what you start, but you won’t be able to do everything when you’re working on a commercial game. As a professional games programmer you’re likely to be working in a team of 5-20 programmers, so think about how your code could work together with theirs. Can you demonstrate how other people could drive your code? You’ll also be working with artists and games designers (and tools for them)—you don’t necessarily need to show the tools needed to author the data for your demo, but you definitely need to know what tools would need to be written.
Use your imagination, but bear in mind that you’re applying as a programmer, not a games designer or artist, so while wonderful new game concepts and beautiful artwork are great, they are certainly not necessary or expected. (Arguably your coding skills stand out more if the artwork you use is deliberately plain!) If you need textures, explosion noises and the like it’s fine to use other people’s stuff provided it is in the public domain or you have their permission; search the web and see our Gateway to Games. Make sure you say what’s not your work, and it’s good manners to credit the original artist/author(s).
Some further suggestions relating to specific types of demo (Graphics, Physics, AI):
Graphics:
1. Consider the sort of custom data you might need to export from the art packages for the artist to be able to control the look of the artwork.
2. When possible, show off 3D maths skills:
- Projected geometry / textures
- Environment mapping
- Complex shadows
- Curved surfaces
- Complex camera tracking
- All of these require a strong understanding of the maths needed for games programming.
3. Special Effects (Explosions, Particle effects, etc.)
Interesting unique effects are good, but not necessary.
Whilst background artwork should be deliberately plain (they are not employing you for your art skills), special effects artwork (usually textures) should be as good as possible. If you can get an artist to help you that’s even better. With special effects looks are all important; how you achieved them is secondary.
Physics:
1. Consider who sets up the various physics parameters and which ones are exposed to the game designer.
2. Show collisions which cope with difficult cases
Stacked objects
Multiple collisions at same time
3. Show management of scale
Keeping physics at a constant frame-rate despite large number of objects
Spatial optimisation to prevent needing to calculate collisions when they are not occurring
4. Show numerical stability
Jittering when close to stationary is bad
Objects gaining unrealistic velocities (including angular) is bad
AI:
1. Focus not just on the behaviours, but also how a game designer might control those behaviours.
AI is no good if game designer cannot get it to do what he wants
Often custom data is required for an algorithm. Consider how that data might be authored and who would author it.
2. The behaviours must be demonstrably interactive.
Dynamic behaviour which can be replicated more simply by a pre-canned behaviour often shows a lack of practicality. What does the dynamism give you?
Consider the type of interaction which you are trying to demonstrate – is it clear?
AI is about the illusion of intelligence—does that come across?
In what way is your AI intelligent and how are you selling it to the user?
3. How should I present and submit my demo?
A good idea is to consider the demo as presentation (particularly if it’s not a complete game) and lead the user through the various visualisations. This avoids the user having to use lots of different controls in order to see everything. Remember your demo needs to make the best possible initial impression on its own because you won’t be there to explain!
Include sound effects if you wish but remember that annoying sound or music is worse than none. Arguably time spent learning the intricacies of e.g. DirectSound could be better spent unless you want to specialise in audio programming. If you do include sound, mention that you have it (perhaps by having an obviously visible option to switch them off) because in a work environment the person running your demo might have the volume turned down.
Offer a choice of screen resolutions, colour depths and windowed / full screen mode when the demo first runs or as an option accessible from within the demo itself. Do not make a user change their desktop display settings if at all possible.
Instructions / explanation of techniques—include a readme but display brief instructions (the controls at least)—in the demo itself, either during or before it starts. Most people will try and run the demo first then look at the readme file later. (Do you read the manual before trying a new game you’ve just bought?) A readme is good idea as well because you can use to explain the techniques you are trying to show, in addition to reiterating the controls and requirements.
Source code—we prefer you to include the source code because then it’s available for clients should they wish to look at it. They are very unlikely to wade through it all so consider also providing extracts of the best and most interesting bits!
Demo Checklist:
- Does your demo work reliably? Try it on several PCs and please make it as bug-free as possible; crashes do not impress!
- Have you included any non-standard DLLs it requires? (It may not be run on a development machine. In particular, compile a Release build (not Debug) if using VC++ / MFC.)
- Does it look good—immediately? Try to grab the viewer’s attention straightway – as with your CV. A game could have a demo mode which plays automatically after a few idle seconds on the title or menu screen.
- Does pressing ‘Esc’ quit cleanly?
- Have you supplied a readme file, or even better instructions within the program?
- They should say:
how to run it (the simpler the better)
how to play or get started; what the controls are (ditto)
system / software requirements—e.g. does it need a particular type of graphics card?