Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

share|improve this question

closed as too broad by Josh Petrie Jul 10 at 0:42

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Ask yourself what you want to demonstrate more: flexibility or attention to detail. That's your answer. Personally I go for flexibility. –  Chris Burt-Brown Sep 27 '11 at 8:37

5 Answers 5

up vote 41 down vote accepted

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.)

share|improve this answer
2  
This is a fantastic answer. Thank you very much for actually changing my perspective on the hiring process. –  ultifinitus Sep 27 '11 at 5:39
    
Being able to use third party software is always a big plus, that might go under 'learns quickly' though. –  Valmond Sep 27 '11 at 9:39
    
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. :) –  Trevor Powell Sep 27 '11 at 9:55
    
+1 thanks for a great answer. –  Amr H. Abdel Majeed Sep 27 '11 at 11:20
1  
+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. –  ChrisC Sep 27 '11 at 17:47

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.

share|improve this answer
    
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? –  justnS Sep 27 '11 at 4:49
1  
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. –  Nathan Reed Sep 27 '11 at 5:48
    
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. –  justnS Sep 27 '11 at 14:48

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.

share|improve this answer
1  
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. –  Chris Burt-Brown Sep 27 '11 at 8:40
    
To each their own, I suppose. –  Jari Komppa Sep 27 '11 at 9:02
    
+1 for importance to finish projects. –  Stephen Sep 27 '11 at 23:24

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

http://leewinder.co.uk/blog/?p=23

share|improve this answer
    
+1 good link. Thanks sharing. –  justnS Sep 28 '11 at 2:15

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.