info for candidates : Graduates

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? On this page:

• CV advice and general tips
• Demo advice
• Sample demos from some of our previous candidates
• Current vacancies suitable for graduate / entry-level programmers

CV advice and general tips

Be committed! Are you mad about games?

Still with us? Then..

Make your CV scream games!

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

At Datascope we now send our candidates a username and password for logging in to our website so they can see how their applications are progressing. Once you have registered you will be able to see the names of the companies we have sent your details to, and any interviews in the pipeline. (We will of course phone and/or email you if a company would like to see you - the web login feature is in addition to this!) We believe we are the only agency to offer this service.

Prepare examples of your work

[top]

Programmers - Demo advice

This advice is subject to changes and improvements; reader comments are welcome. Please email simon@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- see below) 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!

To submit your demo - please email a zip file (less than 4Mb preferred) or send a URL from which we can download it. Our mailserver won't reject larger attachments but our clients' might. If your demo is bigger than about 4Mb zipped, do you have big .wav files you could compress with e.g. ogg vorbis or mp3? Any image files you could convert to jpeg? Please post CDs only as a last resort.

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?

You can find lots more info on the web, and a good starting point is the Developer Resources section of our Gateway to Games page. There are also some relevant newsgroups including alt.games.programming and comp.games.development.programming.misc. (These links go to Google Groups).

[top]

Programmers - Sample demos To run a demo here download the zip file, extract its contents into a folder and run the .exe file. Controls are either displayed on-screen or in a readme file. A reasonably up-to-date graphics card is a good idea.

Recommended downloads for running demos: - DirectX - latest version available from http://www.microsoft.com/windows/directx/ - Latest driver for your graphics card - available from its manufacturer/vendor (try this list).

Copyright notice: The original authors retain copyright © of all demo and sample work here (except where otherwise stated) and it is published here with their kind permission. You may download material from this page for your own personal, non-commercial use only.

[top]

These vacancies are suitable for graduates or other good programmers who do not have games industry experience. They are also posted on our main games programming jobs page.

If you are interested in any of them please quote the ref no(s) and send your CV and demo work.

No jobs have been posted in this category recently.