Ogre Forums

hi,

i would like some advice from games programmers. what i mean by this is, people who are actually games programmers by profession, and not just people who develop games in their spare time.

i am a c++ programmer by trade, but not in the games sector. my job deals mainly with writing printer drivers, which involves implementing protocols over TCP. i have a few years experioence now, and a top degree in software engineering.

i would like to work for a games company as a programmer, however i am a little apprehensive about just applying for a job as i understand most games companies require you to show them examples of some games you have written.

so my first question to people who have already applied (and succeeded !) to be a games programmer, would be, is this usually the case, and what sort of stuff did you show ? was it a game(s) written whilst at uni ? or was it a bunch of games written in your spare time? how complex were they ? did you use Ogre or OpenGL, or something else ?

on a couple of web sites i have been to for well-known games companies (both were in the UK), their recruitment page said something like "fancy a career in the games industry..?", or something like that. so that would suggest to me that games companies do not necessarily expect the inteviewees to already be games programmers, just C++ programmers in general. so my second question would be, in your experience, how acurate would you say this is ?

cheers !

I think it really depends on the position you are applying for. Most games now are done by a team of programmers, and from what I have observed in the job ads, it usually involves a mix of Graphics, Audio, AI, , Network and Tools programmers.

So if you are interested in a job in Graphics programmers, it might be a good idea to have a demo, so you can show your skills. I think it doesn't really matter if it's in OGRE, OpenGL or DirectX...

If your thing is Audio, maybe it's better to code something audio-related, and the same for the others.

From what I've been said most new programmers breaking in the Games industry start in the Tools programming category, so if you already know how to program GUI applications it might be a good way to start.

I'm still a student, and not working (yet), so take what I said with a grain of salt...

Hopefully more experienced people here can correct anything wrong I have said.

What the professional wants in this industry, is that you show that you know how "hard" it is to make a game. A little game, as far as it's core gameplay implementation is complete enough, show that you have an idea of this difficult craft.
This is enough i think.

I did show the bigger game i made at the end of school (i learnt basics of c++ with this project) that was a 2D RTS. I showed too a prototype for a game concept of an action puzzle game.

They were pretty simple (the RTS was not verry simple but if i was'nt a novice at the time i would have done it with finger in the nose). The RTS was made with DX8 and Fmod. The prototype was made with a game engine that don't exist anymore.

So, what you need is simple to show you understand the basic problematics of making games, like the "interaction with player" concept that is specific to games, the way a game is made (that looks like only a little part of most computer software projects out there).

You don't have to make a killer game or anything. Just show a game.

If you have years of experience in computer software, then you have an advantage as a good dayjob game programmer is not always a game programmer in his heart. I know some game programmers that simply like the difficulty of certain challenges we encounter in this industry but don't specially like games.

If you want to go to a big company, then maybe your specific skills will be required for specific task and then you'll have to don only one domain of work, like networking, or something like that.

Good luck!

Klaim wrote: the RTS was not verry simple but if i was'nt a novice at the time i would have done it with finger in the nose.

un doigt dans le nez ?

fortunately my girlfriend is french so i understood that !

Oui, un doigt dans le nez et avec une seule main certainement

Different companies look for different things. And as Triton said, the best approach depends on whether you've chosen a particular specialty (graphics, AI, networking, etc) you'd like to apply for.

Still, I highly recommend making a game, even a simple one, before looking for a job. It will teach you a lot about game programming, which is useful for your personal development, looks good on your resume, and will give you something to talk about in an interview.

Try to come up with as simple of game idea as possible, with simple art requirements, which still includes everything you want to learn about. Estimate how long it'll take you to finish it, and then multiply that number by 4.

If you're most interested in creating a real game prototype, use as much middleware as you can find - Ogre for graphics, plus libraries for physics, sound, input, and whatever else you require. This will make it at least somewhat realistic to achieve something decent in a reasonable amount of time. Plus, working in a large project with a lot of code/APIs to understand (such as an Ogre-based project) will help give you a feel for a real game environment.

If instead you're interested in specializing in a particular aspect, such as graphics programming, then I would work at a lower layer (skip ogre, work with OpenGL / DirectX) and educate yourself that way. Although it's unlikely a complete greenhorn would land a highly specialized position such as graphics programmer right away.

[Edit: mostly echoing what Jabberwocky posted while I was composing mine ]

Klaim wrote:What the professional wants in this industry, is that you show that you know how "hard" it is to make a game.

As one who has to interview engineering candidates...

What we *actually* want, is for you to demonstrate:

a) you are not a muppet -- you have a clue
b) you can in turn demonstrate that you have that clue (and hopefully many others)

You'll be asked to complete programming challenges. Don't go try to copy/paste code snippets from the Internet -- it's obvious, especially when you can't later explain how the code works.

If you don't know something, say so -- trying to bullshit your way through an interview question is worse. We don't expect you to know the signature of every Win32 function in user32.lib -- that's why MSDN Library exists. Of course, answering every question with "yeah, I'd just go Google that" is bad too; you have to have *some* innate knowledge of what you are about.

Be self-motivated -- if you're the type of person who is content to watch Youtube until someone comes and gives you something to do, you need to stay in the corporate development industry and out of games, because we don't have the time or patience for that. On the other hand, if you are the type of person who is always looking for a new challenge and a productive way to stay occupied, you're probably a good fit.

What we want is to see how you solve problems. You'll be asked to do this in person, in the interview, at a whiteboard most likely, and *how* you work through whatever technical design challenge we throw at you is what's important, more important than whether you come up with the "right answer".

Without at least 3 years under you, you're not an industry veteran -- we know that, your resume says so. So please don't try to come off as one. We know you are not going to know all the answers -- otherwise, you'd probably be interviewing us.

So, for the most part, you need to:

1) know C++, and not just recognizing some when you see it -- you'll need to have a clue how the language actually works, and how the compiler actually generates your code.

2) have a problem-solving methodology -- feel free to work through problems out loud and in a collaborative fashion; it's what you'll be doing on the job anyway.

3) be personable and likable -- be interested during the interview



I actually don't care what you may have done during and for school -- it was a school assignment, with a ridiculously short timeframe to boot. It's often zero indication of anything you might be able to do in a professional setting. I personally am more interested in the types of things you do in your own free time -- things you do because you want to, not because you have to.

If you are making/have made a game/engine/piece-of-middleware in your spare time (and even better, have completed it), that's far more valuable than anything you may have done as a school project. It shows (a) you actually are interested in the industry, (b) you are actually self-motivated, (c) most likely have at least semi-developed problem solving skills (if the project or system is in the least bit non-trivial), and (d) that you actually can code. All of those speak volumes, so especially if it's your first foray into professional game development, if you have made demonstrable progress on your side project, talk it up during the interview.


That's about all I can think of at this time. That should be enough though.

xavier> I notice that most of the non-game-dev company that works with embedded software and/or high-quality software (i'm thinking about medical hardware for example) ask for the same requirements than what you say.
So, what you say touch more than video game and should be listened by a lot of developers (if not all)

xavier wrote:If you are making/have made a game/engine/piece-of-middleware in your spare time (and even better, have completed it), that's far more valuable than anything you may have done as a school project. It shows (a) you actually are interested in the industry, (b) you are actually self-motivated, (c) most likely have at least semi-developed problem solving skills (if the project or system is in the least bit non-trivial), and (d) that you actually can code. All of those speak volumes, so especially if it's your first foray into professional game development, if you have made demonstrable progress on your side project, talk it up during the interview.

That's so true. For example the games i made i was talking about were made at school time not game school (maybe there is a better word than school but it seem my english is limited in this domain), i meant that it was made at home when i was a teen yet. The prototype was made while i worked at a embedded system company.

This kind of personal work is essential.

xavier wrote: If you are making/have made a game/engine/piece-of-middleware in your spare time (and even better, have completed it), that's far more valuable than anything

p/s: Emphasis is mine.

I echo what Xavier said above: it is soooo much easier to win the interviewers hearts with a game you make in your own spare-time. All the proofs are all there, there is no need to for other accessories or bullshits since you already have the critical essence of a games programmer.

thanks to all above, very valuable comments. i'll post here when i get offered the job !