Here are my answers to a few questions about the games industry. You may have different answers, or even different questions. Treat this page as a time capsule from the 1990s, when 16 bit consoles ruled the roost and development budgets were enough for AAA games to easily make a profit.
Q1: What are the different roles in the industry?These are the roles within a developer. There are different roles within a publisher, a magazine/TV series, a distributor and a retailer which may also be appropriate companies for some people interested in games. I have included the newer names for the jobs now; nine years on my descriptions sound somewhat harsh and outdated.
|
Tester = QA EngineerKid hired off the street or on a youth employment scheme who likes playing games and will do it for next to no money. English skills optional (but preferable from the programmers' point of view!) Can also be used as gophers (to buy games and hardware). Tend to crash cars too much for the finance department's liking. Ranking - feels they get less respect than the receptionists; about equal to the cleaners. |
Chief Tester = Head of QAGuy in charge of the other testers, who spends some time testing and other times scheduling the testers and being their line manager. Person passed over for being a producer. |
Assistant junior trainee ProducerTester who wants to be a producer. The producer for the game gives this guy all the work, but the pay is still the same (i.e. next to nothing). Must try to persuade programmers and artists to get along with each other and to do some work. May sometimes help out with mapping and testing. Will get grief by trying to mix social life with working with lead programmer until 3am (at milestones). |
ProducerFormer testers who get promoted after being assistant etc. producer on a successful game. May sometimes help out with mapping and testing, but also must fight with management at the company to get people on his team and to stop the company from canning the project. Note that some companies call this position "Director", and for them "Producer" is a more senior position. May write the specification for the game, some time after the lead programmer has started writing the thing (i.e. too late!) |
Senior ProducerAs producer, but more money. Can be poached from another company or hired using magazines or at trade shows. |
Chief ProducerMiddle management. Line manager for producers. Wants to be a "suit". Can try to help out producers but this may prove counter productive since they don't have the depth of knowledge of the particular game. |
Mapper = Level DesignerCan be an ex-tester, or hired from the street. Lays out levels of games and may write simple scripts. Should have some brains - i.e. be between a tester and a programmer in thinking skills, and between a programmer and an artist in artistic skills. Must love games. Bad maps can ruin a product, but they get paid little more than testers. |
Chief Mapper = Game DesignerPromoted mapper, in charge of the overall design of a game, with the producer and the lead programmer. In particular, in charge of the overall layout of levels. This can be a very prestigious position, since people like Shigeru Miyamoto have occupied it. Can also be filled by burned out programmers who want to create games but don't want to mess with the details any more. |
ArtistsWent to art college, studied art and can draw nicely. Can specialise, i.e. backgrounds/textures, animators, 3d modellers. Can be ranked, i.e. artist, lead artist (for a game), head of art department (manager of artists, who may occasionally dabble with drawing). |
MusiciansPut music and sound effects into a game, usually after the project has taken shape and is "playable". Can specialise in music or sound effects, or do both. In a large developer, one of them can be head of the music department, who composes music as well as managing the other musicians and requesting exotic studio kit. |
Programmers = Software EngineersOften went to university and got a degree in computer science. More interesting ones got a degree in something else (e.g. music). Some self-taught people are still around (but remember, university is a lot of fun involving much sex and drinking!). Writes the game itself. Some companies split off writing the engine, the game code, and the utilities (used by mappers and sometimes musicians or artists) into different people, but I feel a rounded programmer should have done all three tasks. Can be hired from magazines or at trade shows. |
Lead ProgrammerProgrammer who is in charge of the programming for a game. This person may be the only person who is on a project from the beginning to the end. Can be hired from magazines or at trade shows, or poached from other companies. Often paid the most out of the development team, including possibly a royalty (especially for freelance programmers). Freelance programmers face the downside of having fixed-fee contracts (plus royalties) but little control over the other people on the team, which causes delays and financial problems. They can solve this by setting up their own development company, with them as boss, and hiring artists, mappers etc. This is how many development houses have started. There is however a high failure rate, because developers are at the mercy of publishers, who have none. Publishers rarely sign a contract before the developer has mostly completed the game, even if it is a conversion. If they change their mind due to internal politics, the developer is screwed. This happens often, and is a reason why many skilled developers leave the industry. |
Head of DevelopmentIn some companies, this person is in charge of programmers, in others in charge of the heads of departments, in others, this role is filled by the Boss. |
BossIn charge of getting work for the company may be either an ex lead programmer or ex senior producer, or an entrepeneur, or occasionally an outsider (in the case of in house development from a big publisher). In small companies he may be the producer for all their games. In medium to large companies he usually relies on the heads of departments to do the day to day business while he (or she in the case of Angela) concentrates on signing up future licences and other contracts (which can take longer than developing a simple game), and schmoozing with other millionaires and sweet-talking bankers. |
OthersReceptionist, accountants/finance, bosses' PA, human resources, office manager (promoted receptionist). These are general positions which require the same skills as in any other company, although the accountants get a chance to be fairly innovative since much of the money comes from overseas. |
Q2: What is it like programming for the different machines?An OK introduction to this is The Ultimate Game Developer's Sourcebook by Ben Sawyer (Coriolis Books 1996) ISBN
1-883577-59-4 $44.99 Phone +1 (602) 483-0192 http://www.coriolis.com |
Q3: What's the easiest way to get into game programming?Depends on which machine you are writing for, how advanced you are at programming and what your priorities are for getting things done (i.e. how much time you want to spend on it). Let's say you are using a PC. You can get a copy of DJGPP (the 32 bit command line C++ compiler based on GNU C++) for FREE. The GNU assembler is a bit strange, but it will let you write small bits of assembly language. Or you could buy Microsoft Visual C++. I saw a games package being sold that included Visual C++ 6.0, DirectX and a how-to book at the ECTS (Annual European video games show) recently, but did not see the price since no-one was at the stand. For writing 3d stuff, Direct3d (from Microsoft, based on a RenderMorphics core) is well-supported but used to be a bit slow. Glide (from 3dfx) is a bit proprietary, but some people like it better. There are various little 2d libraries around (e.g. fastdraw), but I don't rate them very highly. If you want to program the graphics routines yourself (which is a lot of fun - but only a small part of writing a good game) there are various books available, especially from Coriolis. And if you already are a programmer, getting a job in the games industry will depend on your age, location, skill and experience. |
Q4: What resources are available on the internet?This depends on which machine you are writing for, how advanced you are at programming and what your priorities are. The big site for all things game/demo related is ftp://x2ftp.oulu.fi Here are a few game resources on the internet:
|
Q5: How did you get into games?From New Zealand I applied for a job at Melbourne House in 1986. They suggested I get a degree (as I was going to do anyway), so I got that (B.Sc. (Hons. 1st class) Computer Science at Massey University) and in 1989 when I finished my degree wrote back to them. They said I could emigrate to Australia and work for them (no job interview!) so I did, starting as an assistant programmer (writing panel code). The majority of the people there did not have degrees, and I found the grounding in Computer Science useful, especially the (brief) exposure to lots of different ideas that you don't necessarily come across in industry (e.g. Lisp and Prolog) as well as having improved my programming skills via "toy" projects at university before being chucked in at the deep end in industry. |
Q6: What problems have you encountered, and how did you solve them?Managing Expectations: When you start a project you believe in, you should find out who your customers are. Ultimately you have to sell the game to the public, but before then you need to know who pays for the project, who can can it, and why would they do so. Politics can play a role (as publishers buy and sell developers), and also how well the tie-in of the game is going if it is a licence or a conversion. Also important is how good the game looks, how late it is, and what the vibe is amongst the testers and other people. You need to keep your finger on the pulse. Egos: People sometimes claim that egos are a problem, and the games industry has more than its fair share of them. The age of the "hero" programmer is passing as he (because they were all males) becomes less and less useful as project sizes expand, and diplomatic skills become more important. Perhaps some of those "team bonding" courses would be worth a try. I would say that I get along better with people I know, except that this is not true! For example I argue with Gary Liddon (who doesn't? ;-) but because we respect each other this is soon resolved. Respect can come from knowing a person and their coding style over a period of time. Gameplay: I have had many heated arguments with my producers about gameplay over the years, and it usually results in a compromise - a synthesis between my original (simplistic) and their original (unworkable) idea to behave in both ways (sophisticated) in certain context-sensitive circumstances. It means more work for me but ends up benefiting the game. Technical: Technical issues are a problem for some teams - but after a while you realise that anything is possible, it just takes longer to do (and games usually have tight deadlines). With 3d graphics the ante has been considerably upped though - there are several problems in 3d graphics that are N-P complete for example, so they should be avoided or worked around with approximations. Staffing: It can be hard to find good people. It is even harder to find someone who is smart and easy to get on with. If someone isn't intelligent enough to qualify for the Mensa exams (and bright enough not to join, to avoid the membership fees :-) they should not be a lead programmer on a game. They may well be brilliant in other roles, perhaps because of their expert knowledge in a relevant field. A non-technical design role or a support programmers job would be more suitable (depending on their skills base). It is also important to always try to improve your skills and expose yourself to new ideas to keep ahead of the field. Co-operation: It can be very hard to get the items you need to be able to do your job. This ranges from hardware and development software not being ordered on time to not getting the source code from the original developer when you are doing a conversion. This is a producer's remit, and the way to get results is to specify what you want, and persistantly and diplomatically chase people up until you get it. You should then try to keep on good terms for when you need more stuff. Size: The sheer size of data is often a problem - compression is a must, as is careful allocation of large variables or buffers. Games must fit into a certain amount of RAM and in the case of cartridge games into a certain amount of ROM also. Compression is wonderful - if you implement a proper object management system you can compress everything transparently, including data and code, but you can treat music and video specially by using lossy algorithms such as MPEG. Speed: Speed is also a problem - machines never go fast enough, even though they get hugely more powerful with each passing generation. The problem is that peoples' expectation rise just as much as the power of the machines! Complexity: Complexity of a technique (that requires several objects to interface with each other, or complicated fade sequences for example) can be very hard to write. The best way to tackle this is to stop and think about the problem in general. Then implement a system which allows the actions to take place generically, test it thoroughly and implement the specific behaviour using the system. It is initially much harder to code such systems, but they can be more reliable in the long run, and make it easier for you to add other specific examples of that technique (which makes the game more impressive). Bugs: But the most critical problem as far as getting games out on time is concerned is bugs - if left alone they delay a project by an uncertain amount of time. They must be nipped in the bud when they are first spotted. Attitude: Some programmers (and especially producers) subscribe to the philosophy of bodges - bodge it now to get it done as quickly as possible. The programmers that I respect do not subscribe to this belief - they think that short-term solutions cause long-term problems. This is especially the case for converting a game to other platforms. There may be some advantages in "write-once code" (if there is a bug, work around it in another layer of code) in terms of speed of completion, but I feel these are outweighed by the huge delays in converting the game to other platforms (when the programmers have to fix someone else's bugs) and in quality for the original game. |
Q7: What software engineering techniques do you use?SourceSafe is a wonderful tool for teamwork, enabling code to be worked on by several people without much hassle. On my current game we have chosen the "keep out of each others way" approach to teamwork, i.e. clearly demarcating gameplay, front-end code and utilities. Interfaces between the sections of code are minimised (except for a few basic utility functions which everyone should know how to use). The artists all did very different jobs to each other, and co-operated in a pipeline fashion. There are other, even better source control systems out there also. There are many books on Software Engineering which have good ideas that are of practical benefit. For example "Writing Solid Code" and "Code Complete". If you are using C, use ASSERT() statements everywhere that you make an assumption. They have no overhead in the final version of the game, but in the debug version they can show up potential problems early and help you track down bugs more quickly. This is part of the "Design by Contract" philospohy espoused by Bertrand Myer. Specifications are nice to study the feasibility of a project, but original games evolve substantially from them in most companies. Test plans are great for conversions and regression testing, but many companies would need a culture change in order to use them fully. |
Q8: What do you predict for the future?The corporations are trying to squeeze out the little guys, but I think some freelancers will still be around for a while to come. There is financial pressure to employ cheap people straight from university rather than ego-driven veteran games programmers, but the lack of experience can often show in the final product. The rewards for someone on royalties for a big-seller are very nice, but not extravagant (you could buy a house with it, but not a tropical island) and the average person is on a salary which is competitive with a programmer with similar experience in other industries. Investment banking seems to pay well, but most other corporate jobs are not brilliantly paid and probably a lot more boring than writing games. Internet-based games will take off in a big way over the next few years, so dealing with latency (the speed of light is not going to get any faster, even if modems do) will be an important technical issue. The big publishers will continue to go though a shake-out, but there is always going to be room for a talented person, even if job security remains lower than during the 16-bit boom. |
Go Home
Copyright © 1997, 2006 Carl Muller (carlmuller@hotmail.com).
All Rights Reserved.