Invisible <voi### [at] devnull> wrote:
> Of course "games programming" sounds fun and exciting, and from what I 
> can gather *everybody* wants to be doing it. But what is it *really* 
> like, and what kind of thing do developers really look for when hiring?

  I think we should distinguish between different types of game programming.
The game programming industry can be divided, very roughly, into two
categories:

1) Big game houses, ie. those which develop games like Doom3 and HL2.

2) Small game houses, ie. those which develop small casual games
   (http://en.wikipedia.org/wiki/Casual_game)

  In the first case budgets are often rather humongous, teams relatively
large (at least a dozen programmers and artists, some kind of management
hierarchy between the different departments, etc.), and development times
which are often counted in years. The development language of the core game
engine is most often C++, in a few cases perhaps with some C, and perhaps
in rare cases some other language. Games often have an internal scripting
language for non-core features, and this can be either an existing language
(such as lua) or the company's own language.

  In the second case budgets, teams and timelines are much smaller, and
the development language of the core game code much more varied. It can
range all the way from C/C++ to Flash ActionScript. Development teams
typically consist of one programmer (or at most a very few) and 2-3
graphics artists, plus perhaps some project leader (who may be a separate
person or one of the main developers).

  I have never worked in a big game company, but from what I have heard
(I have a friend who has worked in several such companies, including
Ubisoft), the development procedures are ofteh much less strict than one
could imagine for such a big software company. I have got the impression
that so-called cowboy coding is much more usual even in very big game
companies than one would think (even to the point of becoming detrimental
and causing problems in some cases).

  Naturally cowboy coding is more or less self-evident in the small game
houses, where there's typically one single lead programmer and nothing
else, and projects are relatively small. I suppose that in many cases
it doesn't really matter how you do it, as long as it works. (But
personally I try to avoid this, and try to develop things so that they
are stable, safe, easy to use and reusable.)

  Most game companies, when they are hiring, always accentuate the
importance of communication. They always state that the applicant should
be fluent in English (or whichever the local language might be) and have
good communication and teamwork skills. Big game companies probably
accentuate this more than smaller ones. I suppose it depends on the
company (and on the applicants) how strongly they really impose this
requirement. I have heard of cases where it's not imposed at all, and
that people who are very poor at the company's native language are hired
anyways. Other companies may have a stricter policy (which may also
heavily depend on who is the project leader).

  If you are applying to a big game company, knowing C++ fluently (as well
as its internal workings) will probably help. It also helps if you have
experience in computer graphics and algorithm programming. Knowing other
popular languages won't hurt either. Extensive programming experience in
general, and game programming experience in particular, is also good.

  For the smaller companies I suppose it depends a lot on which programming
language they are using. It's quite clear that if they are developing Flash
games and you don't even know what ActionScript is, that won't look good.

  In both cases knowledge and experience of the gaming field in general
is important, as well as an interest in developing games. (Everyone likes
to *play* games, but how many *really* enjoy programming them? Programming
games can be much more tedious than it might sound.)

-- 
                                                          - Warp

Post a reply to this message