Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Programming Entertainment Games IT Technology

Anatomy of Game Development 385

CowboyRobot writes "ACM Queue has an article titled Game Development: Harder Than You Think that looks at the complexities of creating a modern game, in comparison with the relative simplicity of doing so ten years ago. My understanding of the industry is that they have too many designers and not enough programmers. From the article: 'Now the primary technical challenge is simply getting the code to work to produce an end result that bears some semblance to the desired functionality... There's such a wide variety of algorithms to know about, so much experience required to implement them in a useful way, and so much work overall that just needs to be done, that we have a perpetual shortage of qualified people in the industry.'"
This discussion has been archived. No new comments can be posted.

Anatomy of Game Development

Comments Filter:
  • by Frogbert ( 589961 ) <frogbert AT gmail DOT com> on Saturday February 28, 2004 @07:11PM (#8419498)
    Page 1 [] Page 2 [] Page 3 [] Page 4 [] Page 5 [] Page 6 [] Page 7 []
  • Design Patterns? (Score:5, Informative)

    by BenjyD ( 316700 ) on Saturday February 28, 2004 @07:26PM (#8419584)

    Many games take half an hour or longer to compile when starting from scratch, or when a major C++ header file is changed.

    Come on, Design Patterns [] is only $50. Surely they can afford a copy or two? Shouldn't the public interfaces to external classes for a module be fixed pretty early on, if not at design time?

  • Full Sail! (Score:5, Informative)

    by Zoko Siman ( 585929 ) < minus painter> on Saturday February 28, 2004 @07:31PM (#8419602) Homepage
    Here in florida we have a college, Full Sail [], it specializez in entertainment industry stuff. Such as: game design and devolpment. It's good to know we have a place that specializes in making the people that are required if world of gaming is to be continued.
  • Re:He's wrong (Score:5, Informative)

    by gl4ss ( 559668 ) on Saturday February 28, 2004 @07:39PM (#8419630) Homepage Journal
    the hard part is that too usually the designers don't seem to have been playing any games at all, ever! the biggest errors usually are all just about game design(and being designed to be something more than what the execution is able to grasp).

    imho what they should do is that they should bring in an outsider(always a different one!) in once a month to take a look at what they got going on and tell them bluntly if it doesn't make any sense or is stupid, frustrating or otherwise sucking(inside testers are too involved, and can't see if something 'just sucks' because they've seen it from the ground up or are afraid to say that it sucks). it often looks that the developers have gotten 'blind' from being too close to the project(and as such the end product ends up having some stupid shit that could have easily been fixed, like lacking keyboard configuration, having frustrating controls, bad camera view and so on).

    "not being able to see the forest because the trees are blocking the view"
  • by Pvt_Waldo ( 459439 ) on Saturday February 28, 2004 @07:43PM (#8419658)
    You're part way there if you go with Valve's Half-Life. Full SDK that allows you to create maps, models, etc. and a ton of public domain tools for sprites and textures. Also there are some neat extensions such as the Spirit of Half-Life [] mod which gives you a ton of nifty extensions.

    The main place you have to code to create the game is if you choose to extend the game entities for maps, do new weapons, etc. But since Valve gives you the source for the code that does their standard weapons, it's not unreasonable to take their code and extend it.
  • by Anonymous Coward on Saturday February 28, 2004 @07:50PM (#8419685)
    Ten or twenty years ago it was all fun and games. Now it's blood, sweat, and code. Project Size and Complexity The hardest part of making a game has always been the engineering. In times past, game engineering was mainly about low-level optimization--writing code that would run quickly on the target computer, leveraging clever little tricks whenever possible. But in the past ten years, games have ballooned in complexity. Now the primary technical challenge is simply getting the code to work to produce an end result that bears some semblance to the desired functionality. To the extent that we optimize, we are usually concerned with high-level algorithmic choices. There's such a wide variety of algorithms to know about, so much experience required to implement them in a useful way, and so much work overall that just needs to be done, that we have a perpetual shortage of qualified people in the industry. Making a game today is a very different experience than it was even in 1994. Certainly, it's more difficult. In order to talk about specifics, I've classified the difficulties into two categories: problems due to overall project size and complexity and problems due to highly domain-specific requirements. Though this will help me introduce the situation in stages, the distinction between the two categories is a bit artificial; we will come full-circle at the end, seeing that there are fundamental domain-specific reasons (problems due to highly domain-specific requirements) why we should expect that games are among the most complicated kinds of software we should expect to see (problems due to overall project size), and why we should not expect this to change for the foreseeable future. PROJECT SIZE AND COMPLEXITY To illustrate the growth of games over the past decade, I've chosen four examples of games and drawn graphs of them. Each node in a graph represents a major area of functionality, and the arcs represent knowledge couplings between modules. Two nodes with an arc between them need to communicate heavily, so design decisions made in one node will propagate through its neighbors. Figure 1 depicts a 2D game from the early 1990s, perhaps a side-scrolling action game for a home console, like Super Metroid. Other genres of game would have slightly different diagrams, for example, a turn-based strategy game like Civilization would gain a node for computer-opponent AI (artificial intelligence), but would lose the node for fast graphics. Certainly Super Metroid itself also has computer opponents, but their behavior is simple enough that it doesn't warrant an extra node; instead the enemy control code is lumped in with "main/misc." By 1996, 3D games had become a large portion of the game industry's output. Figure 2 shows an early 3D game, for example, Mechwarrior 2. Contrast this with figure 3, a modern single-player game. The largest endeavor we currently attempt is the 3D massively multiplayer game (MMG), illustrated in figure 4. Everquest is the canonical first example of a 3D MMG, though a more up-to-date example would be The Matrix Online (expected release in 2004). Contrasting figure 4 to figure 1 should give you a general sense of how the situation has changed. The arcs in these figures assume that code has been ideally factored, but since this is never the case, real-life situations will be more tangled. Keep in mind that each node in these graphs is itself a complex system of many algorithms working together, and that each of these nodes represents somewhere between six thousand and 40 thousand lines of source code. There's another category of game, the non-massively multiplayer client/server game, which tends to house a smaller number of players at once (perhaps 50) and does not maintain a persistent world. The diagram for one of those would be somewhere between figure 3 and figure 4. Tools Tools. To tackle such complexity, it helps to have excellent development tools. Sadly, we do not have excellent development tools. For programming on PCs, we use a compiler development environment like Microsoft Visual
  • by Anonymous Coward on Saturday February 28, 2004 @07:58PM (#8419723)
    I worked in the games biz for 3 years in QA and production, and finally with a hiring team for engineers in our company. Let me tell you, coders in the games industry are payed jack, and work like mad. Most times, the average work week is anywhere from 80-95 hours for the coding team. I personally got out of the industry because of this. I don't think there are a lack of talented people to do it, just there are not enough people willing to put 80 hours a week in to a game for circa 40-50k, w/no OT.
  • by Anonymous Coward on Saturday February 28, 2004 @08:08PM (#8419770)
    There is a school in Dallas called the Guildhall []. They focus on Game Design, Software Development and Art Creation.
  • by Anonymous Coward on Saturday February 28, 2004 @08:12PM (#8419787)
    Lemme see, you want 3D modelling, animation control and editing, object interactivity and dynamics, an API for gaming logic and a simple but effective scripting language to tie it together. You didn't ask, but I'm guessing you'll also want some audio tools to go.
    I'll ignore the crack about DX9, because I know you really wanted a cross-platform tool that'll work with Linux, Mac, Windows, BSD and a bunch of others.

    So here you go sir, here's your tool

    Now did you want fries with that?
  • Not at all true (Score:4, Informative)

    by Perianwyr Stormcrow ( 157913 ) on Saturday February 28, 2004 @08:19PM (#8419821) Homepage
    Even if you make the game in such a manner as not to be "professional", you may still have a winner of a game. Stuff written in Flash is very easy to do yet brings out remarkable results.

    Not every game has to be a 3d FPS or whatever. Uplink was written by a couple of guys in the UK and is one hell of a good game.

    If you want to do more than a Flash game, that's quite doable as well. Writing a high end 3d engine is indeed hard stuff, but that's why we have mods! Not only can you learn a lot from the open sourced engines out there, you can use some of them to make a mod that is high quality stuff.

    You mentioned artwork: well, fear not- the stuff you can do with the right tools is shocking. You can grab a copy of Blender, and after a few weeks of beating it up you will be turning out 3d models that are better than what you figured you could have made at the beginning. The GIMP is perfectly good for texturing models, and has just about all you'll need for the task (while the GIMP isn't professional photo editing software, it's great for making textures and web graphics.)

  • Re:Design Patterns? (Score:2, Informative)

    by VultureMN ( 116540 ) on Saturday February 28, 2004 @08:27PM (#8419857)
    For C++, you gotta recompile even if the interface doesn't change. Since a lot of compile-time linking is done (as opposed to all-run-time linking in Java) any changes to classes require recompilation/relinking. Or else all the offsets are wrong and KABLAMMOSegmentation Fault
  • by Naysayer ( 71120 ) on Saturday February 28, 2004 @08:51PM (#8419938)
    (I wrote the article).

    I don't dispute this... it is definitely easier to write a simple game than it used to be. That was sort of beyond the scope of the article, though -- a different subject.

    There are independent developers right now who are targeting niche markets with simple games and doing okay at it (and some of them are doing great). But the game was focusing on the "high end" of game development -- if you go into a game store and buy something off the front shelf, what was required to make it today, versus 10 or 20 years ago.
  • by Naysayer ( 71120 ) on Saturday February 28, 2004 @09:09PM (#8420045)
    (I wrote the article).

    I have done both business programming ("enterprise middleware development", etc etc) and game programming. And yes, there are commonalities between the two, but all I can say is, games are just a lot harder. Maybe you just have to have tried them both to really understand.

    What I was trying to get at was not just ballooning complexity of application requirements, but also the inherent superconnectedness of subsystems in games. In a game, every subsystem wants to talk to every other one, and you have to work REALLY hard to prevent this from happening, and often you just can't. This changes a lot of things.

    Still I do agree that there are some commonalities with other software development (in fact I say as much in the article; I divide it into two parts, one that's not so specific to games, and one that is...)
  • by Anonymous Coward on Saturday February 28, 2004 @09:10PM (#8420052)
    From what I have seen it is a question of priorities. When hiring programmers, game companies seem to place a high emphasis on how into games the candidate is, and less emphasis on actual programming skills, knowledge of architectures, algorithms, engineering principles, etc.
  • by Animats ( 122034 ) on Saturday February 28, 2004 @09:12PM (#8420071) Homepage
    As someone who's worked on game physics technology [], I agree with this article. Modern game development is really hard. And the people who do it are some of the best programmers I've ever met. Go to the Game Developers' Conference and sit in on a physics or AI session. Watch punked-out twentysomethings fill up whiteboards with advanced math. Those guys are really good.

    The game development community used to take algorithms from other fields. Now they've gone beyond academia in graphics, physics simulation, and AI. Games are a tough, competitive market, and the stuff has to work, or you get trashed in reviews. That makes for real progress.

  • by nzkoz ( 139612 ) on Saturday February 28, 2004 @09:23PM (#8420140) Homepage lists lots of gaming resources. Including some 3d ones.

    It's definitely worth a look.
  • by OOPisForLiberals ( 679919 ) on Saturday February 28, 2004 @10:29PM (#8420430)
    Preface : I'm a programmer in the industry who has worked on 'cutting edge' titles for the entirety of my career. I started in 1997.

    That's only 7 years. In the 7 years I've been in the business, I've become a certifiable 'old man'. That may sound nutty, but our industry moves so fast, it's perfectly sane. An in that 7 years, things have shifted massively.

    When I first started, I worked on a project with a budget of about 2.5-3 million $. At the time, that was considered a pretty large amount. Our team was about 20 people, mostly rookies of 1 year (or less) experience, with 5-6 'old salt' types. This was a PC title at the very earliest edge of 3d acceleration. The voodoo 1 was barely out there. Use of floating point 3d math was finally starting to be possible. Our target for 'great sales'? 200,000. If we sold 100,000 it would be considered 'good'. 200,000 would be fantabulous. 300,000 and up would be massive wild success.

    50 million. The average game that gets greenlit these days has a budget of 12 million or more. When you pitch a AAA title to a publisher the magic number is '1 million units'. This is of course an insane number that no one realistically expects to hit (especially the poor developers themselves). But the expectation of the top-end people is 'if we don't realistically think this can sell 1 million units, why are we considering it'?

    You know what -hasn't- changed in this time? Selling prices. Games still retail for $40-50.

    Yet budgets have quadrupled or worse. Technology has leaped forward by a LEAST 10x in capabilities. We went from the Voodoo 1 (cool! hardware rasterizing!) to the Voodoo 2 (awesome! really -fast- hardware rasterizing with multitexturing!) to the TNT (WOO! Even -faster- hardware rasterizing with multitexturing!) to the Geforce (Yay, no we've got T&L) to the Geforce 2 (Hmm, T&L plus a complex layer of vertex shaders) to the postmodern Geforce 4+ cards (ummm, dang, 4+ versions of pixel shaders now with a dump truck full of crazy, complex techniques which all the artists and designers and producers all have a hardon over). Ah, we've also got 20x the memory available and 30x the processor power. Can't ship anything without an ultramodern physics engine, or an endless streaming arbitrary polygon-soup world now can we?

    And to top it all off, the trend in actual sales is : instead of a largish array of semi-successful to successful games, we now have a huge bundle of big-but-unsuccessful games and a small handful of monster selling uber titles. With very very very little in between.

    Publishers now aren't willing to commit to something unless they think it'll sell a gajillion units. But of course, selling a gajillion units means having lots and lots and lots of risky and expensive features. So doing these big payoff games is a big gamble.

    This 'Inflationary Period' (to borrow a term from cosmology) has resulted in a radically different landscape. Programmers balk (for good reason) at the design requirements necessary to make a competitive game. I have the privelege of working with some very smart people even 'older' than I am. One of them once said to me : 'Practically everything we do is worthy of a PH.d thesis'. And he is right. You can't -not- push the already ludicrous technology barrier with a new title, otherwise you'll be putting forward a design with limited sales appeal.

    It's an ugly ugly situation. Where I work, we are to this very day struggling with coming up with a design for our next project (one of several) that will satisfy these myriad goals. Everyone is so incredibly smart and dedicated, but it seems to me that we're very fast approaching some sort of upper-bound on complexity.

    I don't know where it is going to end, but at the moment, you can be damn sure that the days of the garage-developer are over. Technology has accelerated too fast.

  • by OOPisForLiberals ( 679919 ) on Saturday February 28, 2004 @11:21PM (#8420635)
    Sorry about that. I messed up on the submit/preview button :)

    What I meant to say was :

    Fast forward 7 years. You've got Squaresoft shipping titles with 200+ people on it. Multiple super-games with budgets as high as [50 million].

    Was just pointing out the extremes to which we've seen (Shenmue, the various Final Fantasies, etc).

    As far as getting into the industry, the short version of my usual screed:

    - Be sure you love to program (I'm assuming you're a programmer). This being Slashdot, I'm sure this isn't an issue. There is a lot of hard work involved, not all of which is particularly glamorous or exciting. Be prepared to work very hard early on to earn your stripes.

    - Don't get into it to make money. While it is certainly possible to make significant money via bonuses and royalties, chances are you won't in any significant way. You will probably start at a lower salary than your non game industry peers, but if you're good, this will rapidly change. However, good salary != massive bonuses.

    - In terms of nuts-and-bolts : put together a demo. A real demo. Not necessarily some cookie cutter gee-whiz graphics demo that anyone with ctrl-C/ctrl-V can do. I cannot tell you how boring and uninformative it is for someone to come in with 'Hey, check out my kewl graphics demo!' Unless you're the 2nd coming of Carmack, you're not gonna start as the Graphics Guy for your company (and if you -do-, you should be incredibly suspicious about the competency of those who hired you). Pac-man. Space invaders. Defender. Something original but simple. Basically, something that shows you can see a project throught from start to finish. That's truly impressive.

    - Philosophies : I don't care how many Linux distros you're familiary with or how many Slashdot-approved technophenomena du jours you know - know your C and your basic machine-level basics. Be familiar with all the essential 3d math concepts. For God's sake, know the difference between a dot product and a cross product. Be prepared to abandon cherished modern concepts about OOP and dynamic memory usage. In other words : don't be a Slashdot zealot :)

    - Dedication to games. The running joke in the industry is "Oh, you get paid to play games all day!". Of course this is the furthest thing from the truth. It's hard and has plenty of grueling episodes. Be prepared to occasionally commit 80+ hour weeks for 3+ months for the real humdingers. Game developement is for better or worse, a way of life, not a job (at least until you hit the upper echelons in your 30's :)

  • by Anonymous Coward on Sunday February 29, 2004 @12:03AM (#8420850)
    The problem isnt that there arent enough programmers, it's simply that you need the best ... with artists you can make do with less talented one, since they can simply spend more time on their assignments while you hire more of them to do the work of the single better artist. With programming this doesnt work.
  • Re:here is a clue (Score:5, Informative)

    by Frobnicator ( 565869 ) on Sunday February 29, 2004 @12:31AM (#8420979) Journal
    In reply to your "news to game companies", here is news for you:

    "They think they're doing something special, and that they're above every other type of programmer" [punctuation and spelling corrected]

    That's a common perception from those outside of the entertainment industry. There are those 'stars' in the game industry, just as there are in the movie industry, who really do think that. One of the plain facts is that modern games take a lot of intellectual work, much more than optimizing SQL queries, putting components on forms, or making two computers talk to each other. It's no different than how some professors look down at some software developers. While it does take skill to do it, you aren't really pushing every neuron in your brain to put out form-based apps or SQL-based systems.

    Regarding the amount of learning that has to take place:

    Of the programmers on my team, 4 (including myself) have masters degrees and two have bachelors degrees. Every week I find myself reading several papers from journals and conference proceedings. In contrast, two of my brothers are also programmers. One does POS software for a nationwide company, another works for a small company with photo processing software. Both have seen the things I do at work, and I've seen theirs. Both have told me that they couldn't handle my job, but I know I could do either of theirs. One of them has had to read a few journals and articles, the other hasn't read any since he earned his bachelors degree almost a decade ago. One of them works with mostly BS degree or no degree, the other works with entirely BS degree and one MS degree people. As for me, I've thought about going back and getting another bachelors degree in math just to review some of the advanced topics.

    Neither of my brothers, both competent programmers, can understand the math it takes in writing game graphics engines. Do you understand the math involved in manipulating manifold surfaces, or self-shadowing techniques? Perhaps you can explain to the crowd how to make a 3D model look like it is breathing? Or maybe implement a system to give models joints at hips, knees, ankles, and toes, and make them realistically move, jump, walk, crawl, or stand still, based only on a direction and speed? How about converting between 4x4 matrix form, and Euler angles, and quats? Can you even understand a number that has 1 real part and 3 imaginary numbers, [w, xi, yj, zk], and has no real-world analogue? How about pathfinding; Since you play games, can you explain or implement 3 of the pathfinding techniques you've seen? Maybe machine learning is your forte; Can you implement at least 2 machine learning methods, such as RBF networks or backprop neural networks? [Incidentally, while seldom used, both work well in games since there is practically no cost to use them.] How about cheat-resistant networking; Do you know how to tell the difference between a forged packet and a regular one? How about how to properly get around a NAT device? Since TCP is too slow, do you know how to deal with out-of-order UDP data? Or keep clients in sync when they are missing critical information? I've only met a few non-game programmers who could do all of these, but EVERY PERSON ON MY TEAM knows how to do ALL these. But even then, I can still do most of the things you probably do as a programmer. I frequently help my brothers out when we talk about difficult issues they are fighting in their own projects.

    "first it's 30 minutes of moaning there 12 hour work day. then its talking about there 2 hour lunch, there games of quakes, and shooting nerf darts at each other. then they complain about deadlines, the fact that they have to fly an inconvient flight to some electronics game convention, and the fact that there manager is bugging them to do there work in the schedule that the programmer said it would be done."

    Again, in comparison with my brothers. In their environments, they plan

  • or you could use one of the many game creation tools out there that let you create entire games without programming if you really want to. these days it does cut it complaining that you can't make a game because you don't know programming. you just haven't looked hard enough yet ;}
  • by Paradise Pete ( 33184 ) on Sunday February 29, 2004 @08:03AM (#8422042) Journal
    This is the inherent reason why the Indian software industry will never really challenge the Western (Japanese also) industries.

    Here's a link [] that might help make his post more clear to you.

  • by Triskele ( 711795 ) on Sunday February 29, 2004 @08:09AM (#8422047)
    Yeah, but Indian programmers are not creative

    What utter contemptible bollocks!

    We're working with an Indian games company to create a new console game and the team they've assembled is smart, inspired and better motiviated than most dev teams I've met in the West over the last few years. Remember these guys are doing something new in building the Indian games industry, they're not worn down by comparative low pay and dev studios going bust all around them

    See the announcement here []

    Oh and the going rate is $10/hr not $2.

  • by arose ( 644256 ) on Sunday February 29, 2004 @01:54PM (#8423619)
    resizing frames often left artefacts on the image
    Yes, stable gimp has that. 1.3.* and 2.0pre* work fine.
    I found no way to line up all these popup windows in a sane way [..] with a lot of kludges and work involved, tho.
    Less than you might think. Here are my current gimp (2.0pre*) kludges and a screenshot [] to illustrate them:
    -- GIMP
    winprop {
    class = "Gimp-1.3",
    target = "gimp-tools",

    winprop {
    class = "Gimp-1.3",
    role = "gimp-startup",
    target = "gimp-image",

    winprop {
    class = "Gimp-1.3",
    role = "gimp-image-window",
    target = "gimp-image",

    winprop {
    class = "Gimp-1.3",
    role = "gimp-message",
    target = "gimp-image",

    winprop {
    class = "Gimp-1.3",
    role = "gimp-toolbox",
    target = "gimp-main",

    winprop {
    class = "Gimp-1.3",
    role = "progress",
    target = "gimp-main",
    -- /GIMP
    That takes care of most basic things, as the crop dialog in the screenshot. Some things I use less still require manual shuffling (most could be fixed with more kludges or a bigger screen), but much less than with Gnome/Metacity, which I used before Ion.
  • by Anonymous Coward on Sunday February 29, 2004 @03:44PM (#8424240)
    I would say that the article is half right... I have seen the too many designers case, usually when EA was involved. Designers have too much power a lot of the time. At one point the front end programmer had 9 front ends on the go at once because the designer couldn't make up his mind. So Id agree with that...

    The other problem is we are in a young industry, one where a senior programmer only has 7 years (or less!) experiance. I would say the only "senior" people at the old school coders, who have been in this for over 12 years. But being a young industry has its limits - there simply aren't enough of these people around.

    However, I think some of the article exaggerated some of the tasks in modern games. For example many new nodes were added in 2004 games that were there back in 1996 as well. 3D Exporters, Animation tools AI... were all there. Things have just gotten more complex in construction, its not like its a totaly new field.

    Wild Metal Country by DMA Design, had an amazing physics system...(yes I know it was '99 it came out... but it had been in development for a long time...)

    Quake had 3D exporting and Animation, and it was in 95.

    The MMPG have introduced lots of new boxes to be sure, but its a slowly evolving thing rather than a whole heap of new things. Each single task can still be prefomed by a single coder if they know what they are doing. One gfx programmer, one AI, one physics. (These of course would all be subject to time constraints...)

BASIC is to computer programming as QWERTY is to typing. -- Seymour Papert