Making Video Games is a tricky business. While they're most often compared to movies, they have both their own culture and very different technologies driving them. A game is not only a complex computer program, it can have a full-blown GUI and render 3D graphics in real time (as opposed to the nearest non-interactive equivalent, CGI movies, which have the luxury of using existing software to "film" and can spend hours or even days on a single frame, rather than 1/30 of a second). The technologies involved also shift much faster than in movies. TV and movie writers have very little in the way of first-hand experience with their sister industry (even game writing, which arguably overlaps the most with "normal" scriptwriting, requires the writer to make the gameplay and narrative complement each other). The result being Hollywood Game Design. A few simple points that address common misconceptions are below:
The days of commercial, non-indie games being made by a guy in his basement on his own are gone. A commercially viable game made from scratch requires a large team to put together thanks to the many skill sets needed: graphic programmers, physics programmers, AI designers, level designers, character modelers...
- Various "libraries" (collections of pre-written code), some open-source and some paid, have been developed to handle part of this task. Games with smaller teams often use these libraries (for example, a standard API to handle the graphics) or license an existing Game Engine.
- More recently, this idea has made a comeback, since Digital Distribution services like Steam and the iPhone app store allow smaller developers to produce and sell simpler games. The prohibitive cost of "dev stations" (modified consoles which allow prototype versions of a game to be played on them) keeps this from working for big console releases or multiplayer Party Games, and so-called "indie" games tend to be relatively short, with a simple (often retro) aesthetic.
There are a number of distinct groups involved in the technical side of game production. These are not formal or standardized, so the lines between them can be blurred (for example, programmers might know something about design, and designers probably know the basics of programming). In addition, especially in larger teams, each group might have further specialisations. e.g. AI, graphics and physics programmers, some might even be assigned specifically to fix bugs; junior designers might specifically work on balancing weapons, units, creating new characters, etc; writers coming up with the many, many descriptions for items and descriptions in a bestiary while someone else handles the actual story script; teams of 3D animators often have someone specifically working on rigs for the models to make their lives easier; even QA testers might be assigned to keep testing a specific level or other part of the game, or process reports from an open beta.
- Game Designers develop the rules, mechanics, and systems of the game. In an RTS, they decide what stats units have, in FPSes they decide what guns do, and so forth. Generally they are led by a "Lead Designer" or similar, who is roughly analogous to a film director. Though they are arguably the most essential element in production, they tend not to show up much in media, since (unlike programmers, artists, or executives) most people don't have a clear handle on what they actually do.
- Programmers write the skeleton and muscles of the game (as it were); they create the actual program which makes everything move, allows enemies to think, and so on. When their job isn't done you end up with Vaporware (i.e. nothing), or at best, an obvious Game Maker work.
- Artists (including visual artists, writers, animators, musicians, etc.) put the flesh and skin on this skeleton; without their sounds and visuals Pac Man Fever would still be a Truth in Television. One of the major debates in game design is whether good games tend to start with designers or these guys — obviously, designers are essential for good gameplay, but starting with a solid story or art tends to make a more "cinematic" experience. It's often helpful for the two to not have a brick wall between each other.
- Quality Assurance, as their name suggests, extensively test the game for bugs, balance issues, and hardware/software compatibility. While sometimes dismissed as glorified testers, a good QA developer is invaluable for making sure the game's design and programming are all working like they should. When their job isn't done right, you end up with an Obvious Beta. Note that being a QA tester is not a slacker's dream job where you get to play awesome video games all day and get paid fat bucks for it. This
Penny Arcade comic (and its accompanying news item) provide some insight.
- Producers foot the bill for the project as a whole and have various oversight roles, making sure that everybody else is doing what they're supposed to be, and is on time and budget. They have a reputation for being curmudgeonly bastards with no respect for Art, but they have an important role keeping the project grounded in reality. Often the producers are a separate company from the developers, which certain people — fans, the media, Jack Thompson — are apt to forget.
Game developers have a variety of working environments (as one might imagine given the number of different jobs).
- Programmers have Stereotype A, the screen full of unreadably-tiny code; most programmers are given small chunks of the game to work on, so only the head honchos usually have actual working copies of everything. Later in development, once the game has reached the alpha/beta stage, programmers will be called on to bug-hunt or otherwise make small modifications in the code, but the ability to see those changes in real time remains rare. (Most games take a non-trivial amount of time to compile, especially if changes have been made to art.)
- Some artists and designers have Stereotype B, the on-screen 3D model. This one shows up especially often in media, but isn't all that common in actual game design. Some games use a setup like this is design their levels, maps, and so forth, but unless it is part of an existing engine, creating utilities for level creation is the responsibility of the programmers. Such utilities tend to be very game-specific and not suited for use with other projects; dress them up a little and they become "map editors" and the like for making user-created content.
- For the most part, artists such as animators and musicians use their own sets of industry-standard tools, not too different from what they might use in film or their own work (although some game specific tools exist, and some areas such as writing can look very different). Many of these specialists are freelancers, contracted by the development studio on a project-by-project basis.
- Designers have unusual workspaces, which tend to vary depending on the type of game and personal preference. Whiteboards and other means of mapping out information are common, since the designers often deal with problems such as interactions between rules, "cycles" of gameplay actions, and other processes that lend themselves well to visual representation.
Making a game follows several stages, which determine who is working on the game and what they're doing at any particular point. Specific steps vary from company to company, but typically include:
- Pre-alpha: This covers the beginning of the game's development, starting from the basic idea. In early pre-alpha, the game generally doesn't exist outside of prototypes and concepts, which means it can be easy to make sweeping changes ("what if it was co-op?" "what if the player was a rabbit?" "what if we added aliens?"). Eventually, a core concept and feature set emerge and are agreed upon, and programmers begin to hash out the essential features — the basic functions the game will need to do what they want it to. At this point, the in-house artist(s), if any, will work on Concept Art that defines the visual and audio styles.
- Alpha: The alpha stage begins once the game is "feature-complete" and has its essential framework in place. Writers, artists, and sound designers are called in to begin fleshing out the game. Levels, maps, etc. are designed and implemented as well. On the programming side, bugs are the rule rather than the exception at this point, and much effort is put toward weeding them out.
- Beta: At this point, the product is sufficiently developed to allow play, if not necessarily smooth play. Generally, a beta will include not just gameplay but also a first pass on story, art, and sound. Testing is the focus at this point, to the extent that "beta" often refers specifically to the testing process. Beta tests can be "in-house", which includes developers and full-time testers, or "open", which recruit much more broadly (often from players of the company's other games). In either case, beta-testers are often required to sign agreements to the effect that they won't reveal any details about the game.
- Release: After a protracted beta period, spent pounding bugs flat and polishing the assets, the game is finally ready to sell. However, this isn't necessarily the end of the job. Often the team is kept on to work on Downloadable Content or sequels. In addition, modern games are expected to be "supported" for a period after launch, meaning that programmers will be kept on to fix bugs and other problems that show up after release.
