A buddy from work and myself are wanting to get into the indie scene for game development. I've done a few tech demos demonstrating different ideas and approaches for various problems. Now, I feel it's time for us to commit to a project in order to develop a portfolio for later down the road.

I've been struggling greatly with how to begin an actual project, more specifically to create an engine or use an OTS package, or use one then create one, or create one then use one.. etc.

Which looks better to potential employers? A smaller portfolio of games that includes your engine or a (possibly) larger one that was built using something OTS?

I am a programmer. I'm not an artist. I will be performing most of the programming for this project. My buddy is also a developer, but he is also proficient with graphical tools (thus, he becomes the art guy).

At work, we are both .NET developers (C#). I know, I know "Well then use XNA" some will yell at me. The demos I've completed thus far have been in XNA. But I have some concerns with building an XNA portfolio. While it is nice to abstract DirectX, I worry that I may not build the necessary knowledge base to extend beyond XNA easily. The counter to that argument is probably "you can more easily move on to DirectX after XNA", but since I will move careers from Business Development to Game Development, is it even worth while to focus on XNA currently? Or will potential employers giggle when I say XNA?

Should I embrace the experience of XNA knowing the concepts and lessons learned will mostly transfer? Or spend my most valuable resource (time) else where?

Looking for some advice from any industry vets out there.

  • \$\begingroup\$ Ask yourself what you want to demonstrate more: flexibility or attention to detail. That's your answer. Personally I go for flexibility. \$\endgroup\$ Sep 27, 2011 at 8:37

5 Answers 5


I've been a programmer in the console game industry for almost fourteen years, and have often been involved in hiring decisions.

So speaking as one of those potential employers, when evaluating a possible employee there are three things I look for in a new hire, and I look for them in this order.

  1. Will this person fit into my team? (social, hygiene, etc)
  2. Is this person a quick learner? (often incorrectly phrased as "is this person smart?")
  3. Does this person have any relevant experience that will help me?

Now, addressing your question. This whole "which type of project should I do" issue is addressing by far the least important of the criteria that I care about. I care far more about whether you'll fit into my team socially, and about how well you'll be able to learn new things quickly, than I care about whether you used XNA or your own game engine in some previous project. By and large, I'm assuming that I'm going to have to train you up in our own in-house game engine, and so your earlier projects don't really matter to me at all. That is, of course, unless you magically happen to have experience with a particular tool or technology that I need someone to know about. But this is unusual; usually, I'm assuming that I'm going to have to train you up to use our API.

All of this isn't to say that I don't want you to have done home projects. I absolutely do. But I don't really care about what those projects are, or what technologies they used, because they probably aren't going to be relevant to what I need you to do for me, since we'll be using different libraries or APIs.

But I do want you to tell me about your projects. I want to see how enthusiastic you get when you talk about them, because that tells me about what sort of person you are (see point 1, above). I want to hear about the problems you ran into, and how you overcame them in developing your project (see point 2, above). I absolutely want you to have completed at least one project -- being able to push through the pain and actually complete something says a lot about the sort of person you are, and tells me that you're somebody I'll be able to rely on if ("when") things get tough.

So honestly, neither option is "better"; the important thing is to complete something, anything. Any technology you learn along the way is icing on the cake, but almost certainly isn't what would make me hire you.

(But with all that said.. I will expect you to be proficient in C++. One way or another, you really need to learn C++ in order to get hired into the mainstream games industry. Your home projects don't necessarily need to be in C++, but I'll expect you to be able to demonstrate fluency in it.)

  • 3
    \$\begingroup\$ This is a fantastic answer. Thank you very much for actually changing my perspective on the hiring process. \$\endgroup\$ Sep 27, 2011 at 5:39
  • \$\begingroup\$ Being able to use third party software is always a big plus, that might go under 'learns quickly' though. \$\endgroup\$
    – Valmond
    Sep 27, 2011 at 9:39
  • \$\begingroup\$ I don't think it's likely you'll ever meet a programmer who doesn't know how to work together with third-party software. Everybody is already writing to a documented third-party API, whether libc or STL or OpenGL or DirectX or the Windows API or whatever. It's the same skills in the commercial industry, just often less well-known libraries being used. :) \$\endgroup\$ Sep 27, 2011 at 9:55
  • 2
    \$\begingroup\$ +1 Portfolio pieces don't need to follow rigorous standards. The point of them is to serve almost as conversation pieces for an interview, so that they are interesting from a programmer's point of view. \$\endgroup\$
    – ChrisC
    Sep 27, 2011 at 17:47
  • 1
    \$\begingroup\$ @ShuvoSarker For big companies, this is still true. EA will not expect you to be an expert in their Frostbite engine when they're thinking about hiring you. Ubisoft will not expect you to know Snowdrop. This has perhaps changed for smaller companies, though, in the six years since I posted this answer. Unity has become a big enough force in the small-studio space that it's very realistic to think that knowing Unity could certainly help your chances in a way that wasn't the case back when absolutely everyone used their own proprietary engines. \$\endgroup\$ Jun 10, 2017 at 5:33

One thing others haven't mentioned yet is that it's important to finish your projects.

Having a portfolio with a bunch of unfinished things isn't nearly as impressive as a portfolio with one finished, well-polished thing.

Also, if you base your work on someone elses' existing work (such as some open source engine, or freely available art assets), make sure you mention on your portfolio which part is yours.

  • 1
    \$\begingroup\$ Not 100% sure I agree, we get a lot of people with unfinished stuff, it's very common, and it doesn't have a lot of correlation with the quality of their stuff. Finishing something demonstrates dedication, not capability. \$\endgroup\$ Sep 27, 2011 at 8:40
  • \$\begingroup\$ To each their own, I suppose. \$\endgroup\$ Sep 27, 2011 at 9:02

It seems to me that the answer depends on what kind of game programming you want to do.

If your goal is to be an engine coder or graphics coder, you'd benefit from going under the hood and learning how engines work. This doesn't mean you can't use XNA or another off-the-shelf engine, framework, etc. Gaining familiarity with the innards of a high-quality engine is a great way to learn how to build a high-quality engine! If you go this path, you don't necessarily even need to write any actual games. A portfolio of standalone graphics demos and/or nontrivial extensions to an existing engine (e.g. implementing a new shader in an engine or suchlike) will do you well. You can take a look at my portfolio of graphics demos here; it's a few years out of date now, but this is basically what got me a graphics programming job at a game studio.

On the other hand, if you'd rather be a gameplay coder, one of the people who work on the game mechanics, controls, enemy AI, etc. then your time won't be well-spent digging into Direct3D. Of course it's helpful to have a general, high-level understanding of how graphics works, but in a professional context you probably won't be coming into direct contact with low-level graphics stuff very often. In this case I would absolutely recommend using an off-the-shelf engine so that you can spend your time building actual games.

So, to sum up, if you want to do gameplay then just use an existing engine; if you want to do engine/graphics then build your own stuff and/or extend an existing engine.

  • \$\begingroup\$ I appreciate your answer. It gives me a better sense of direction. I see myself more as an engine programmer. For the time spent (based on your experience), do you think it is better to skip the abstraction and dive into D3D? \$\endgroup\$ Sep 27, 2011 at 4:49
  • 1
    \$\begingroup\$ D3D would be a great place to start. Later on, you may also want to check out some open-source engines to get a feel for how others have done the large-scale structure and organization. It's also good practice to jump into a large and unfamiliar codebase and try to understand it without reading every line of code. \$\endgroup\$ Sep 27, 2011 at 5:48
  • \$\begingroup\$ Ok, your answer combined with Trevor's really gave me what I need. Shame I can't choose two answers; so +1. Thanks, Nathan. I really appreciate it. \$\endgroup\$ Sep 27, 2011 at 14:48

when i was just finishing uni my portfolio was featured in this article. it does seem a good idea on what to do and what not to do when getting your portfolio together



Don't do your portfolio based on how you perceive the "standard" to be. You should work on projects that interest you. If you like game mechanics, go ahead and make a bunch of games. If you like creating interesting AI, maybe make a demo for an RTS-like setup. As an example, I have a growing interest in graphics programming, and putting more time into learning rendering concepts and applying them in my engine. (Consequentially, my game project has been temporarily put on the shelf.)

When you work mostly on things you like, it really brings out the "you" in the portfolio. On the other hand, having at least one completed game shows that you can pull through the "uninteresting" parts of making a game. It's good to have some degree of flexibility to break into less familiar territory, but don't force yourself into it extensively. You can tell good portfolios from the level of enthusiasm and interest put into the work, and projects based on your areas of interest are naturally gonna get the most polish. So whatever your area of interest is in, you will eventually have to focus towards that area of programming for a job.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .