Introduction

Whether you are a graduate or someone who is self taught, your demo portfolio is the key to getting your foot in the door of the games industry. As a junior applying for their first position it doesn’t matter if you graduated with honours from the best University in the country, without a good portfolio you will not even be considered for an interview let alone be offered a job. Unfortunately it’s one of those questions that gets asked again and again, with rarely a concrete answer given and a lot of misinformation is often brought forward.

I started my career in the games industry straight out of University back in 2001 so I know what it’s like worrying about what games companies expect and what you should do to show them you are the right candidate for the job. Over the past few years (on a daily basis depending on the time of year) I have been responsible for reviewing portfolios and interviewing candidates for programming roles at Blitz Games Studios and I have seen some pretty amazing work examples… and some that should have been but were just not there. Hopefully this article will show you what I and a lot of other companies look for when an aspiring Junior Programmer’s CV lands on our desks and how you can show a company just how good you really are.

This article will be broken up into three parts. The first will cover the content of a demo portfolio, the second will cover the presentation of this content (which can be just as important) and the final part will look at real portfolios to see what went right and what went wrong.

What Should Be In A Portfolio?

The first and most important element to decide on is what exactly needs to go into a portfolio. The main thing to remember is that this demo is meant to impress the person who will eventually offer you a job, so it needs to be your best work. There is no point including half-finished, broken pieces of work as it will do nothing to push you forward. You also need to think about how you want to be viewed. Are you interested in general game play programming or are you really interested in special effects, physics or one of the other many things people can now specialise in?

If you are interested in specific areas then you need to include multiple demos’ to prove you’re not just a one trick pony. Physics for example could include technical demos that feature…

• Dynamic cloth
• Rigid body physics
• Deformation

If you are interested in general game play programming (and this is usually where most juniors start) then you can do nothing better than include a range of different but complete games, both 2D and 3D. What kind of games would be expected though is usually the hardest question to answer - though having a specific company in mind gives you a head start as you will already know what kind of games they have a history of developing. One thing you need to understand is that, regardless of whether you have a degree or not, you are not expected to make something as playable as Halo or as good looking as Crysis.

To quote a post from the forums on GameDev.net:

“In modern days you will basically not get through the door without a college degree unless your portfolio is truly astounding. (By astounding I mean you are able to do things that no one can do in realtime; or you have developed an entirely new technique for… ).“

This is simply not true, your demo portfolio needs to be good, but even some of the worlds best studios won’t have technology that produces the kind of output that this statement alludes to.

Complete and Finished Work

So what kind of completed games would be expected for a standard junior entry level position? Try some of the following:

• Asteroids clone (full of special effects, explosions and particle effects)
• Simple 3D death match (AI bots, 3D character models etc.)
• Simple TBS Game (2D like Advance Wars or even 3D with the effects and environment to go with it)

The thing to note is that you do not need to have games that are huge and that take months or years to complete. People understand that you have a life outside your hobbies and that you like doing other things. And taking that further, chances are if you over-stretch, you simply won’t achieve what you want, meaning nothing will be finished and your portfolio will not be as good as if you concentrated on smaller, manageable demos.

Now it’s worth pointing out that in both cases, I stated that you needed a complete game. A complete game is just that, something that has the flow of a full game, from the menus to the game and back out again. Other things that you can include in a complete game would be

• Front End - Start new game, options, exit game etc.
• Loading Screens
• High Score Tables - People love these
• Pause Menus

Graphics, Style and Good Looks

Another question asked is how good these games should look. If you read this blog post you are expected to be a programmer, nothing more. Programmer art is more than acceptable for demo portfolios. If you have friends who can help you out then all the better, but you will not be viewed in a negative light because you are not a fantastic modeller or pixel artist.

University Course Work

Graduates will also have work they did as part of their University program (yes, the content covered so far is generally assumed to have been done in your spare time), and there is every chance the quality of this is high and suitable for the portfolio. One thing I would recommend if adding this is to make a clear distinction between your course work and work you did off your own back. More on this in part 2, but it is worth noting that here.

Making Sure It All Works

So now you have an idea of what to include, there is still a lot more to do to make sure your portfolio is complete and ready to be put together. Your games and demos probably use a wide range of external libraries and API’s (DirectX, OpenAL and OpenGL to name a few). Unfortunately, your PC is probably the only one that has the right combination of installs to make your demos work. So it is vital that you include (or provide a link to) the relevant installers that will be needed. This will mean the reviewer has instant access to what is needed and can install things easily instead of rooting around for one missing library (at which point they may well just decline your application).

It cannot be stressed enough that making sure you include everything, or ideally wrap a games install process into a single executable, is vital to a good portfolio. A reviewer will be willing to spend time on your work, but not if that involves spending 10-15 minutes simply setting it up and chances are that if there are multiple steps involves some of them will be missed. The easier it is to run your game, the easier it is for the reviewer to start enjoying what you have to show.

Right, so we should have everything we need now and everything is perfect, right? Wrong. Imagine what happens when the reviewer tries to run your demos and (even though you tested it on machine after machine) it fails to run. None of your demos do in fact. This is another reason a lot of applications get rejected. So how can you avoid this? The simple answer is that you can’t, as chances are your game will crash on someone’s machine no matter how much testing you do, so the trick here is to make sure they still know what you can do even if they can’t run your work.

So for each demo and each game you need the following

• High quality screen shots of all major features of the portfolio
• Videos of each demo showing the good bits

Source Code - A Window into a Programmers Mind

So, anything else? Just one more thing and this can be one of the most important parts of a good portfolio. You need to include the source to all the demos included in your portfolio, and it needs to be easily readable and accessible (this is where free copies of various .net IDE’s come in handy).

But why is the source code important when you have the most amazing demos ever seen? A lot of the time, the journey is more important than the destination. People like to see how you approached a problem, and how you worked around common dilemmas but most importantly that you write consistent and safe code. The source code will also open up another line of questions if you get to the interview stage which can help you shine even more.

You need to make sure that the source code is clean and suitable for other people to read. Take that to mean that any abusive or inappropriate comments and variable names need to be removed (though they should never exist in the first place), and it needs to be well structured and laid out. Best to do this from the start rather than the day before you build your portfolio, as you wouldn’t believe how easy that is to spot.

The source code also allows people to find out one of the most important aspects of any demo: what parts of it are yours and what parts were done by someone else. This needs to be clear in the code (and in the portfolio itself) as you do not want to be seen as someone taking credit for someone else’s work - this will get you nowhere.

And That’s It?

Now I know some people will be saying that this is going overboard, and not everyone will produce portfolios that have everything mentioned here. And they are correct, most people won’t. But the best people will, and it is these people that will get jobs in the games industry and it is the bar they set that everyone is judged against. It is these people you are competing against and it is these people that you need to stand out against, second best simply won’t do.

Presenting Your Portfolio