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 the same answer given by two different people.
Recently I have been working through a University Module specifically designed to answer some of the questions often raised about demo portfolios (and hopefully to raise the standard of job applications) and thought it would be appropriate to post that information here so people who do not have access to these modules aren’t left at a disadvantage.
This topic 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 area’s 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
It’s even better if these technology demos are elements of a game included in your portfolio, but that’s usually just a bonus and not usually a requirement.
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. 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.
From a recent quote on a popular Game Development forum
“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 best studio’s in the world won’t have technology that produces the kind of output that that 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)
Now obviously that is a very limited list, and you can make up any kind of game to go in a portfolio but hopefully that gives an example of what it expected. Well thought out, 2D and 3D titles showing a variety of different features (special effects, AI, terrain generation etc.). Go down this road and you are definitely on the right track.
The thing to note is that you do not need to have games that are huge and that take months 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
Why is it better to have a set of complete games rather than just diving into the game when the reviewer boots it up? Simply put it shows you have an appreciation for what a game is and what else is needed other than ‘the fun’ part. This will stand you out as someone who knows what to expect and knows what goes into making a game from start to finish.
Graphics, Style and Good Looks
Another question asked is how good these games should look. If you read my previous 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).
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 (nobody wants to sit through a video showing 2 minutes of menus!)
With those in your portfolio, you are pretty much guaranteed that the reviewer will have the chance to see and admire your work.
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 demo’s 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 part of it is 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.
Say That Again?
So that’s it when it comes to content. To recap quickly what was mentioned
- A collection of small complete games and/or technology demos
- Include all the required installs for all demos
- Provide screen shots and videos of everything in case they don’t work
- Include the source code to everything
- Make sure elements carried out by other people are clearly noted
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.
In the next part I will talk about the various ways in which you can present your portfolio so that your work can been seen and appreciated in the way you want it to be.