Building Up Your GameDev Resume

[WILL]

Now, this might not be an interest for everyone, but I felt that it would be great to talk about how one goes about building up something of a resume when it comes to establishing yourself as a competent game developer.

Save for a small percentage here on PGD, I don't think we have too many 'professional' game developers, but I'm sure that some of us can provide a clear picture of what someone looking for work in the gaming field should do to create an effective porfolio.

So who here has actually gone this route? How does it compare with the application development side of the house? What kinds of things are potential employers looking for? Is freelancing a viable option? And how else can you promote yourself?

Anyone who has other questions or insights please contribute to this topic.

[HopeDagger]

I'm not a professional game developer, but one solid piece of advice -- which makes sense, but many don't seem to follow -- that I keep on hearing (and also am a proponent of) is the following:

Focus on finishing games. Don't aim for the sky with overambitious projects. People who look at your resume will definitely hire someone with 10 completed smaller projects, rather than the other person who has 30 unfinished projects. Completing and polishing a game is far more important than an unpolished game with more features than the former. In summation, it's completion that counts. :)

[WILL]

Very solid advice. :thumbup: I'll be sure to take it to the bank, so to speak.

I'm curious though, how do you yourself regulate how complex your own projects should be? I mean... there is indeed such a thing as too simple, right? At least that would depend on what you are doing I would think.

Just food for though.

[HopeDagger]

I'm curious though, how do you yourself regulate how complex your own projects should be? I mean... there is indeed such a thing as too simple, right? At least that would depend on what you are doing I would think.

Exactly -- people also need to learn their capabilities and limits. Getting good at writing games means having a lot more failures than successes, generally.

In other words, the more you fail projects, the more (hopefully) you learn from your mistakes and get a better 'feel' for what you can do within certain timeframes. Years ago I was dropping the majority of my attempted projects because they were often overambitious and beyond my skills, but now I finish almost every one I take a stab at, because I know what I can and cannot do (yet! ). The more you know your own abilities, the better you'll become at game development, I say.

[jdarling]

Another thing, is to focus on a target market or niche. Trying to sell yourself as a "Game Developer" is not as productive as saying that you are a "Casual Game Developer", "Role Playing Game Developer", or "Backend Systems Developer". When we look for companies to develop games for our clients, we look for specialized personel, not general practice.

This is the same as not only calling yourself a "Software Engineer", augmented it with "specializing in ECO" or "specializing in Reporting Systems". This gives you a specific area of focus, and a value associated with that focus.

You should build your portfolio around that area in you want to specialize. There is no sense building a 2D RPG and placing it on your resume if you want to build 3D Shooters. It's ok if you do build a 2D RPG or Tetris, in fact you probiably should or have, but it doesn't impact the direction of your career though, and thus doesn't matter to a potential employeer in your target market.

Hope that this post makes some sense to someone .

[tanffn]

I disagree HopeDagger, the majority of the projects I get into are project I know nothing about to begin with. Not only from the technical/algorithmical/programming aspect but I don’t even know the IDE/language that is needed to be used.
You do need to know how to break down your problem and how to gather/learn the subject.

+ Doing what you always do isn’t fun/challenging, and you gain nothing (knowledge) after the project is completed.
I agree that if a person wants to code a game for fun, and knows only to code 2D game, the bar shouldn’t be half-life 2 3D engine. (but it CAN be 3D)

[HopeDagger]

I disagree HopeDagger, the majority of the projects I get into are project I know nothing about to begin with. Not only from the technical/algorithmical/programming aspect but I don’t even know the IDE/language that is needed to be used.

I think we're actually saying the same thing.

I never said that you need to know the language/IDE/API/library/whatever ahead of time, but that you need to know what you're doing. If you know how to problem solve, break a project down into managable pieces, and turn a project you know very little about technically into a complete project, then that's synonymous with knowing your limits/abilities.

+ Doing what you always do isn’t fun/challenging, and you gain nothing (knowledge) after the project is completed.

Agreed. It's always good to take what you know you can do, and take it one step further when you tackle the project. As long as there is a challenge present, but said challenge isn't outside of your grasp, it'll be a beneficial experience.

[NecroDOME]

Well, for my part. So far I'm still at school, being a "Software Engineer". However I need to do a "stage" (no clue how to call it in English, but it's that you work, but still at school for about a half year) . So me is gonna work by a game studio

[pascal]
While (Work) do
Say('It''s a dream come true');
[/pascal]
(however, they don't program in pascal )

EDIT: Syntax check

[savage]

Congratulations Necrodome! Succumb to the dark side, will you?