Any tips for an aspiring game developer?

Holy Hand Grenade

I'm just wondering if you guys have any tips on what companies look for when hiring new programmers.

I've been trying to develop some games and set up a portfolio but I work alone and most of them are very simple, 2D, poor graphics and etc.. do you think the art would matter for a potential employer who looked at my games? That's one of the main reasons I've never tried to work with 3D yet.

I've never worked formally in the industry but I've always wanted it since I was a child, I'm turning 24 next month and I'm getting more and more afraid of becoming too old for it, so I would really appreciate any tip you could give me.

Thank you very much!

satchmo

The main thing that prospective employers are going to want to look at is your existing work - personal projects you've worked on that show what sort of programmer you are and what level you're at.

Keep in mind that you're not going to be hired to write the whole game by yourself! Unless it's for a small company (who are unlikely to be interested in someone with no industry experience anyway), job openings are generally going to be for specific programming roles (network, graphics, gameplay, AI, physics, engine etc.). Figure out which area you're most interested in and then concentrate on writing code that shows off what you know about that.

For example if a company is hiring an engine programmer, a candidate that has written a whole small game is not going to be nearly as interesting as one that has written something detailed and specific, like a multithreaded job system, a reflection system, or something similarly low-level. If you try and write a whole game from scratch, you're probably doing yourself a disservice as you'll end up getting bogged down with many small details that won't contribute at all to getting you hired.

What you want to present is a tech demo: something that get straight to the point (presume that you're going to get someone's attention for a maximum of 5 minutes before they move on to someone else), shows something impressive, and has good (robust, readable, commented, well-structured) code behind it.

For programming jobs, the quality of your art is absolutely irrelevant. Coders (myself included) are notorious for their atrocious art skills, so just don't worry about it. Any coder that is looking at your stuff in order to decide whether or not to bring you in for an interview is going to go straight to the code anyway. The demo is just there to show that the code actually works!

Of course nicer art always looks better, so if you're really worried about art quality then it's always better to go more basic than trying to make it look fancy. Use simple geometric shapes, and go as minimalist as possible. Sometimes that looks better anyway.

And I don't think I know any field (except maybe some sports) where 24 would be considered too old for anything! I was 28 when I got my first industry job. You've a long way to go yet before you're over the hill!

satchmo

I dug this up from an post I did on the different programmer roles there are. Some companies (like Ubisoft) also have 'generalist' roles who do a bit of everything, but most of the time you'll see openings listed under one of these categories:

Tools: write plugins and engine-specific tools for artists and designers, including the game editor and DCC-specific tools (Maya, Max, Photoshop etc.). Can be cool and have a huge impact on the game behind the scenes. Can also be boring if you're not the tool kinda guy. Might suit you if you already have UI & tool programming experience.

Gameplay: write gameplay-specific code. Anything and everything that isn't engine code, and is written to make that specific game run how the designers want it.

AI: game NPC AI, pathfinding, and all things intelligent-looking.

Animation: handling the animation of all dynamic in-game objects, primarily characters. Forward & inverse kinematics, motion graphs, animation scripting interfaces etc.

Rendering: graphics programming, 3D engine design, shader programming, artist support and a few other things including optimizations and low-level engine implementation.

Physics: implement or support the engine's physics engine, primarily collision detection and response. For the maths heavyweights.

Network: programming all aspects of the networking component of the engine, transport layer and up. Obviously only applicable if the game has an online component, but many do these days.

Audio: sound engine programming - acoustics, attenuation, and so on. Also scripting interface for triggering sounds.

Frontend: all things not in the 3D game world - menus, loading screens, overlays, movies & HUDs.

Engine: the basement levels of the engine, usually written by some of the most experienced people. Multithreading, memory management, I/O, ... anything close to the metal.

Pipeline: programming the content pipeline, which is the series of modules that turns the art produced by the artists and designers into assets loadable by the engine.

Build: responsible for the build system - code compilation, platform SDK management, build version management & distribution etc.

Holy Hand Grenade

Thank you for such a detailed answer satchmo, I think I'll stick to a specific role I feel more comfortable with then.