How to Make a Game Programming Demo Portfolio [12.02.08]
- Lee Winder
Another question aspiring game programmers have asked me is how good their games should look. Programmer art is more than acceptable for demo portfolios. Junior programmer applicants will not be viewed in a negative light for not being a fantastic modeler or pixel artist (and while it never hurts to team up with an artist or two, all applicants must explicitly point out any work on their demo that they did not do).
In an ideal job candidate, all the content I've discussed so far will have been made outside the university curriculum, so graduates will also be able to show the work they completed in their academic programs. In all likelihood, the quality of this work will be high, too, and thus suitable for the portfolio.
One thing I recommend is making a clear distinction between which demo pieces are course work and which are independent projects.
Making Sure It All Works
The games and sample work included in a standard demo usually use a wide range of external libraries and APIs, such as DirectX, OpenAL, and OpenGL to name a few. Unfortunately, the applicant's PC is probably the only one that has the right combination of installs to make the demos run; every programmer portfolio should include (or provide a link to) the relevant installers that will be needed. It's crucial that the reviewer have instant access to everything they needs to make the demos run.
Still, it's common for game demos to fail to run, no matter how many times the applicant tested them on computer after computer. No matter how many times the demos are tested, they still might fail.
This is another reason a lot of applications get rejected, and while it's impossible to ensure that every game demo will run perfectly and smoothly, there are other things programmers should give the reviewer as back-up, such as high-quality screen shots of all major features of the portfolio and videos of each demo showing the best or most impressive parts.
There is one more thing programmers can provide, and this can be one of the most important parts of a good portfolio: source code.
Reviewers loves to see the source code to all the demos included in a portfolio, as long as it's easily readable and accessible (this is where free copies of various .Net IDEs come in handy).
Providing source code is important because a lot of the time, the journey is more important than the destination. People like to see how programmers have approached a problem and how they worked around common dilemmas. But most importantly, it shows whether the applicant can write consistent and safe code. It can also open up another line of questions when the applicant is hopefully being interviewed later.
The source code must be clean and suitable for other people to read. Any abusive or inappropriate comments and variable names need to be removed (although, really, they should never exist in the first place), and it needs to be well structured and laid out. It's best to do this from the start, rather than correct it later (you wouldn't believe how easy that is to spot).
Finally, the source code allows reviewers to find out one of the most important aspects of any demo: What part of it is the applicant's and what parts were done by someone else. This needs to be clear in the code (and in the portfolio itself).
To recap, a programmer's portfolio should include:
- a collection of small complete games or technology demos
- all the required installs needed for the demos to run
- screenshots and video footage of everything in case the demos don't work
- source code
- clear notations about who created what work.
Not all game programmer candidates will have a portfolio like this, but the best ones will, and it is these people who will get jobs in the game industry. It is these people who set the bar, and it is these people that every other applicant needs to stand out against.
How a portfolio is presented comes down to personal preference. That said, companies are looking for the best applicants, and the best applicants always add the finishing touches.
A well-presented portfolio shows hiring committees that the applicant cares about what is being showcased, and that they are willing to finish what they started. It also allows reviewers to actually find and view all the work -- the executables, screenshots, videos, and source code for each project in the portfolio. The goal is to present the materials in such a way that the reviewer cannot easily miss or gloss over anything, which they are likely to do if they are reviewing dozens of candidates' works.
A good presentation will also group relevant information and projects to highlight how the candidate is a good fit for a particular job. For example, a folder of elements called "Gameplay Experience" will be the first thing a hiring committee looks at if the job they're hiring for is a gameplay programmer. A good presentation puts candidates in control of how the reviewer approaches their work.
One of the most important parts of a creating a portfolio is understanding the audience. This is designed to be a professional portfolio being presented to other professionals for a valued role in their company. It helps if the writing style is tailored to contain a suitable level of technical language, without going overboard (don't be a term-dropper and don't try to hide behind big words). Humor is always welcomed, but only if it is in good taste and is natural, not forced.