Slashdot Mirror
Anatomy of Game Development
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.'"
Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 Page 7
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?
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.
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"
world was created 5 seconds before this post as it is.
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.
(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...)
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.
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.
Again, in comparison with my brothers. In their environments, they plan
//TODO: Think of witty sig statement