Making a portfolio

Portfolio for what?

Artists need artwork and possibly a demo reel.
Animators need a demo reel or two or three.
Programmers should be able to show source code and executables, but it is much less of a requirement than it is for artists since they can write code in person during an interview.


As far as the purpose, there are two questions any employer wants answered:

* Can you do the job well?
* Will you fit in?

Your demo should answer both of these questions.

Note also that every position is different. Art that would land you a job as a concept artist could get you rejected for a technical artist. A demo that what may fit the culture in with one company could be appalling to another.

Keep in mind the two questions and you should be fine.

Sorry, my bad, I meant Games programming.

General Suggestions:

1. Some programs you created yourself.

2. Titles you've worked on, and your role in the development.

3. General resumé.

My advice would be that while a completed game or few would look very good, don't spend all your time just making full games. Besides a game or two, pick a discipline about programming you like (AI, Graphics, Networking, etc) and create little focused demos of various techniques in use by games today. Make sure you keep it simple too - so don't have 3D characters running around a 3D world for an AI demo, just use 2D with lines and shapes, that's all you need to demonstrate the technique. One of the trends in the industry is the breakdown of fields into specific roles, so don't try to learn everything there is in making a game - that's way too much stuff these days.

PM'ed you.

While having lots of demo's is good, I strongly believe that also having a fully completed game is a big advantage as well as it shows you are able to take a project from start to finish.

Quote:

Original post by Gaiiden My advice would be that while a completed game or few would look very good, don't spend all your time just making full games. Besides a game or two, pick a discipline about programming you like (AI, Graphics, Networking, etc) and create little focused demos of various techniques in use by games today. Make sure you keep it simple too - so don't have 3D characters running around a 3D world for an AI demo, just use 2D with lines and shapes, that's all you need to demonstrate the technique. One of the trends in the industry is the breakdown of fields into specific roles, so don't try to learn everything there is in making a game - that's way too much stuff these days.

Ah. Thanks for your post man. I'm currently working on a demo and I'm trying to learn everything there is about game development. Guess I should follow your advice to stick to a specific subject....or two.....or three.

Thanks for all the responses, some very useful information here, should help with building my Portfolio, thanks :D

The good thing about learning a little of everything is once your bored of one thing you can hop to the next (cyclic) but I suppose getting a specialty is a good idea

Quote:

Original post by Aiursrage The good thing about learning a little of everything is once your bored of one thing you can hop to the next (cyclic) but I suppose getting a specialty is a good idea

Being "bored" doesn't matter to an employer. Generally you're hired for one position, not other positions as you choose. Fine for a hobbyist developer, not so good for a professional.

Quote:

Original post by Weebo While having lots of demo's is good, I strongly believe that also having a fully completed game is a big advantage as well as it shows you are able to take a project from start to finish.

I agree - everyone has a demo of this or that, but unless it's really impressive it does little to distinguish you. Few people have a completed game, and it says a lot more about your ability to follow through and actually finish a project.

As an interviewer myself I have to say that both arguments are correct to an extent. A full game demo shows good well rounded capabilities, a willingness to see a project through from start to finish, and a drive to create video games. A concept demo on the other than shows a good deal of detail to the work done, and focus and desire to be good at a given field.

More importantly is what the demo's don't say about you. You're looking to distinguish yourself from everyone else. If you come in with a full game, what kind of game is it. Is it a big game, or a simple game. Is it bug free, or are there simple glitches. Can i play it, or did you bring it with you to walk me through it? Full games open you up to a world of questions, most of which the interviewer will not ask. We make assumptions based on behavior and information presented. The demos are no different.

Now if you come in with a concept demonstration for a focused field. Less questions are available. The concept tells me what you want to do for a job, and your current capabilities. With concept demonstrations, make sure it is very clear what you are showing with your algorithms and code. Date everything. Make sure your portfolio shows growth in the field, not simple task after simple task. Simple concept demos are just as pointless as bringing a crayon drawing to a painting gallery. But by the same token, not every concept demonstration should be in theoretical fields, or cutting edge. Show you can do the normal stuff, but try and place those in cohesive groups covering more than one general concept. Again, show growth through your portfolio. If it matches up with your education, so much the better, but not a necessity.

Most importantly... remember you're looking for a job. Be professional, and make your demo's professional. Remember to provide all the source code, an a pre-built executable. I shouldn't need to compile it. But don't assume they wont. The code should include a project file for some very common source code compiler for whatever language your programming in. Use the tools that are readily available or very well known. VisualC++, Eclipse, etc. Make a readme for every demo. Include it with the source code. It should say when the project was started (date) and when it was built (date again), who worked on it (everyone, if it was more than just you) but no contact information. This is your demo, even if you made it with someone else. Showing you've worked with others is not a bad thing, despite the stigma of "Oh you cant do this on your own" that seems to be so pervasive in the online community. Document everything. The average source code to comment ratio is generally 1:1.5 depending on the criticality of the system. So comment your code well, but again keep the comments professional. If a portion of the code is broken, comment it. Don't be afraid to discuss failures as well as successes. Never showcase a total failure. When I say don't be afraid to discuss them, i mean if you failed to get a feature fully functional. If the entire project is a failure, do not include it....

I'll stop here. That should be a good push in the right direction.

I find that a good thing to show is something that you had to research, so tackle something that you haven't done before, either a new area or something in an area you're comfortable with but more advanced than what you've done in the past. Don't copy and paste your solution, rely heavily on descriptions and white-papers and don't look for existing code unless you're absolutely stuck and just need a nudge in the right direction. This is a good way of showing that you can make code, on your own, from high-level discussion of a topic and that you are not just another "copy & paste coder."

Its also good to show a complete game, but be aware that the definition of "complete" is different from a potential employer's perspective. From their point of view, "complete" means something close to "Demonstrates all technical and gameplay aspects" it does not mean "27 levels, 14 mini-bosses, 12 weapons and hours and hours of gameplay." In fact, its probably better to give them a big bang, rather than a slow burn -- They're busy folks, don't make them play to level 10 before you bust out your neat particle systemor they'll never see it.

Polish is VERY IMPORTANT! This applies to both applications and code.

For applications this means that the experience is clean, that the UI is sensible, that everything for the most part "just works" and, while you don't have to be an artist, there's no excuse for you "programmer art" looking like Technicolor Vomit.

For code, this means that you should be on your best behavior -- Pick some sensible coding conventions and use them consistently. Use descriptive variable names (even if they're verbose) -- you want your code to be easily understood (and therefore hardly misunderstood). Comment before each function with its description, parameters, return values, exceptions, etc (Doxygen or similar tools are great for this). Comments in the code should be *useful*, don't comment on "what" a line of code does, comment on "why" it does it and "how". Show proper software engineering (but don't over-engineer).