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.'"
Shocking... (Score:1, Insightful)
Re:Shocking... (Score:5, Insightful)
There is a saying for this in real life... (Score:5, Insightful)
He's wrong (Score:3, Insightful)
So in a sense, the author is correct: game development is hard; but its about 10 times harder than he is making it out to be because he is focussing on the 'easy' bits.
Re:Shocking... (Score:5, Insightful)
Sure, it's complex if you're copying complexity (Score:5, Insightful)
Nice article, but I think it misses a key point. Game creation is only more complex these days if you're trying to build/copy a complex title.
Of course a Lone Wolf isn't going to be able to knock out myHaloTribes2! But s/he sure as heck can still tackle a simpler game, with even less effort than "days of yore" in my opinion. OpenGL, a slew of commercial games engines, cross-platform solutions, even SDKs for mobile phones.
The opportunities abound, even if the market is drowning in noise these days. The bottom line is don't try to compete with a big studio if you're not a big studio! Skip the $150K intro/cut-scene movies, etc. Don't aim for a MMORPG. Just build something fun, dammit!
Think of it as the development equivalent of asymetrical warfare.
Can see where he's coming from... (Score:5, Insightful)
Let me elaborate, splinter cell was an amazing game but the storyline was very linear and interacting with the environment pretty much restricted to shooting out lights.
Halflife 2 on the other hand allows you to use some magnetic levitating weapon that can tear metal objects like radiators from the wall and hurl them at the opposition. Boxes and furniture pushed against doors to stop attacking enemies.
I can't even begin to imagine the complexity that has not only gone into the code design but also the level design. That's the crux of it, without amazing and clever levels that leverage all of this new complexity a game falls flat on its face.
Re:He's wrong (Score:5, Insightful)
Story lines, I don't think are that tricky, or important, at least for many game genres. To quote John Carmack: Story in games is like story in porn movies, you expect it to be there, but it's really not that important.
Game design is hard, because that's the thousand little decisions you have to make that separate the great from the merely average. There's just no substitute for talent here.
Content creation is hard, in the sense that you need an awful lot of it. And because there's a lot of content, then managing that content becomes a problem in itself - but that's basically an engineering problem. Artistic talent is certainly required in content creation, but ultimately this is not something that's become harder, just something that you need a lot more of.
Re:He's wrong (Score:5, Insightful)
For Doom, sure, but in every other important genre, he's wrong. Too many games are like they are designed for teenagers who are flunking out of literature classes. The dialog, the characters, everything is just awful.
Re:Outsource it! (Score:5, Insightful)
Games are art, more specifically they are art of the same kind as books and movies in that they have a strong cultural bias. Paintings and music are also culturally baiased, but they're much more open to apprecation by members of other cultures. Video games, books and movies all tend to make assumptions about the backgrounds and experiences of the audience that are necessary to fully understand the work.
Sure, EA could set up a team in India to develop games for a lot cheaper than a team in the US or Japan, but the resulting games probably wouldn't sell very well. Even games transfered between the US and Japan tend not to sell very well statistically speaking (and i say this as an american who likes Japanese RPGs, but i know i'm part of a small group.) Companies in one country have tried to design games that they thought would appeal to the other, and as often as not they have bombed. I believe Final Fantasy Mystic Quest was one such experiment.
So in order for the game to have decent odds of selling well in the targeted area, the designers need to be from the targeted area or an area that has close cultural ties, such as US and the UK.
Ok, so keep the designers in america, and ship everyone else off to India. There are probably people capable of doing the work in India, but you'll run into another problem. Designers frequently don't know what the hell they're doing. I appologize to any designers out there reading this, but all the ones i've worked with know it's true. The programmers will write some tool for the designers to use, and the designers will get lost and come to us for help. We'll tell them how to do that, and they'll be fine for a few days until they run into another problem. Sometimes the problem will be something they can deal with if they just learn the scripting lanague or whatever the issue is, sometimes it will be something new that we need to implement, and sometimes it will be something we told them to do or not to do weeks earlier. They'll do A and complain that the enemy does blah, and we'll tell them that they can't do A, they have to do B or C instead. Then they'll come back a week later saying if they do A, the enemy does blah. You'll explain again, and they'll say "Oh yeah, you told me that before didn't you?" Designers just seem to think differently than programmers, which is why designers are designers and programmer are programmers i suppose.
So if you attempt to outsource the programmers, you're going to run into huge communication difficulties between them and the designers, both in terms of developing what the designers want and explaining to them what they're doing wrong. You'll have possible langauge barriers, time delays from emailing back and forth across multiple time zones, the difficulty of not being able to actually _show_ the other person what you're talking about, etc. The reason why companies frequently have onsite QA even when there's an offsite QA team is because often you can't figure out what the offsite QA team is talking about just based on the write-up they email you. You either need to fiddle around for it for a long time yourself, or have local QA spend the time reproducing it and then show you.
There are similar issues between artists and programmers, and i imagine there are also issues like that between designers and artists. If you seperate any section from the others you're going to introduce masive delays and complications to the project.
The only area that i've seen effectively outsourced is sound. However it's interesting to note that the only company i worked for which had it's own in house sound department was frequently cited for the quality of the sound effects in the reviews of the games. And this is just with outsourcing the sound to another american person or group, even within the same state.
So yes, they could save money if they outsourced the labor to India, but if they only out-sou
Re: class public interfaces... (Score:4, Insightful)
Your god, Carmack, is wrong. (Score:5, Insightful)
Of course Carmack says story is not really that important... Look at the games he designs-- FPS almost exclusively without story. It's a pretty narrow vision to be making such sweeping judgements from and it hardly makes his word gospel.
Re:Too many designers? (Score:5, Insightful)
There are plenty of game programmers too. Look around at the console homebrew development websites. Plenty of programmers there.
What's really lacking is artists. You generally need a huge amount of artwork for a given game, and you need talented artists for a game. Someone who simply knows how to use Photoshop filters won't cut it.
The worst part of doing a homebrew game is finding people to do the art. Very few artists are willing to get involved in a project without money up front, and those that do are often hard to keep motivated enough to get things done.
Re:He's wrong (Score:5, Insightful)
Re:He's wrong (Score:3, Insightful)
From what I can tell, story and game are completely orthogonal. To make it more clear, imagine describing the quality of a game on a left to right scale or spectrum. The quality of the game's story can be placed on a scale up and down, with no relation whatsoever. Seems like far too many critics can't distinguish between the two. Why else would Xenosaga do so well with critics?
Instead of writing about how story is critical, and how every game needs a story, and even has one (this leads to stretches like the plot of a football game), maybe these critics should spend some time examining if their ideas even work. There's a whole world out there of game design and its relation to story, but you're not going to find it by tacking on story to a game.
Re:He's wrong (Score:5, Insightful)
Content development (game design, story creation, etc) is harder than it should be. But that's mainly because the tools aren't very good. Why aren't the tools very good? Because it was all your programmers could to to scrape the basic game together; they hardly had any energy left to do more than cruddy tools.
I would have gone into this in detail, but the article was already over its length budget.
That said, even though content development is hard, it's still easier than programming. You have to have done them both in order to understand. Programming is always like building a fragile house of cards; content development isn't. That's the difference.
The hardest thing about content development in fact isn't making the content, but managing the content creation process; it's difficult for the producers and art leads to hold it all together.
Re:He's wrong (Score:5, Insightful)
Is story important in RTS games?
Is story important in puzzle games?
When was the last time you gave a shit about story in a sports game?
Games are not typically linear pieces of narrative, i.e. stories. Games are pieces of entertainment.
Chess is the greatest turn-based strategy game ever devised. It has no story.
Tetris is the greatest puzzle game of all time. It has no story.
Re:Oh come off it... (Score:3, Insightful)
They are, however, one of the most challenging kinds of software engineering there is. And that's how I'm hoping the article is taken -- as a call to challenge for people who may be interested.
And there is no spoon.
Re:Too many designers? (Score:5, Insightful)
I think in the game industry the situation is actually the opposite of this. Most game companies, despite having been in business for years, still underestimate the difficulty of the task (because it keeps getting harder every year) and hire people who are underqualified (often because they just can't get anyone else).
Like, all the time I see job listings like "Lead programmer for massively multiplayer game, must have 3 years of C++ experience, must know Direct3D , Visual C++" and I just think "Wow, these guys don't have a chance -- if their stock was public I'd short it."
too many designers and not enough programmers (Score:2, Insightful)
BS. Programmers are like actors in movies. Sure they're vitally important but without the huge support group making scores, costumes, scripts, sound effects, CGI, directing, producing, and just shooting the damn thing you wont end up with much of a movie.
Just like with any modern game you'll need a soundtrack, sound effects, level design, textures, models, animations, voice-overs and a good story.
Honestly one good texture artist is worth their weight in gold. Far more than any coder but the lead at any rate.
complexity (Score:1, Insightful)
If putting together a 3D engine on a real time schedule means 50-75 core components but 5 different IDEs and 3 or 4 compilers not all the parties have to vest themselves with alike design interests. As a matter of fact to stimulate creativity and competition it should be emphasized complexity is encouraged in game development but tolerated only to a point and cut there when it gets crazy.
The point is making money from well written, well executed code and delivering it to the clients!
Harder every year... (Score:5, Insightful)
The game industry looks like the equivalant of the comic book industry in the eary 90s, lots of eye-candy, gimmick covers, etc and little substance. Seems its a technological arms race to build games that run on the newest hardware and that gameplay is the last thing on the 'to do' list.
Re:He's wrong (Score:4, Insightful)
I think you're right, but I'm not sure how warranted this generalization is. The game itself is more dependent on whether it needs a story or not, the genre is a secondary consideration for it. Wing Commander pops into mind. I loved that game, but part of the fun of it was the story that went with it. Take the story out, the game's not as interesting despite that it doesn't affect the gameplay much. Take the game out and just leave the story, and it's stil just OK.
Part of the problem with Carmack's comment here is that he's treating it like there's some big formula for making games. In a sense there is, afterall you are targeting a wide market. However, the reality of it is, that if you're expressing yourself artistically, then each aspect one can bring up is entirely up to the creator to make.
Be careful about comments like this. They can stifle one's creativity if taken too seriously.
Oh yes! (Score:2, Insightful)
The reason?
Far more diverse challenges from different areas of software development come to play. Network engineering, including bandwidth, server stability and scalability issues, performance of processing large amounts of data in an unimaginable amount of different ways, compression algorithms, design and architecture of APIs, use of often many different (often poorly documented) 3rd party APIs at a time, efficient use of dedicated video, audio and other hardware, strong knowledge of human audiovisual perception, asset management, database design, knowledge of several different programming languages, scripting, SQL, SOAP, development of tools and applications using MFC,
In addition to that, any software engineer working in one or more of graphics, animation, audio, tools, to name a few, will need to have good knowledge of how the modelling, animation, audio and texture artists go about creating assets, in order to be able to make asset integration into the systems they develop, work as smoothly as possible.
Add about a teaspoon of multi-platform development (let's say, PC, XBOX, PS2, GameCube, sometimes Mac, for example).
Combine that with tight deadlines (the game industry isn't infamous for crunchtime for no reason), publisher's big wigs constantly looking over your shoulder and asking 'is it ready yet?', and dealing with (and this is the result of some people not knowing what they're doing as you stated) poorly specified requirements, and with the fact that hardware and technology in game related fields is advancing faster than anywhere else.
Stir frequently, and you have a recipe for the software development time of your life.
To summarize, in my opinion, a software engineer working on large scale interactive entertainment projects has to be far more flexible, have a higher level of self-motivation to take on problems and acquire the necessary skills and knowledge to do so, and be more team oriented and communicative than developers in other fields of software engineering.
We are not a bunch of kids hacking in hundreds of thousands of lines of spaghetti code without any consideration of software design and architecture principles, to release a game to make a quick buck. Those times are long gone.
Sarcasm follows (Score:3, Insightful)
Listen here whippersnapper, destructable environments are nothing new. Why, I remember, way back in... musta been ninteen hunderd and nintety four - when I played a game called XCOM. It displayed soldiers and aliens in an isometric format, and just about everything could be blown up. In fact, that was probably the thing that most contributed to how much fun that game was...
I take you back in time, for this conversation when I was viewing the game for the first time:
"They've got the door to the barn covered."
"OK, well, lets just make our own door, with this handy grenade..."
"What?"
"Yeah, kaboom, instant door."
Look, I know destructible, interactive environments in 3D games are new. (And no, the horrid piece of software called "Tresspasser" cannot be called a game, and thus does not count.) And I applaud game developers to finally getting around to it. But it isn't something that hasn't been done before. Added complexity, yes. A new age of 3D gaming? Perhaps. But I'd say a bigger advance was present in the first Half Life game - an AI that put up a decent challenge and displayed some level of realistic enemy behavior in a FPS.
All that said, good luck to the HL2 guys. I really do hope they succeed. I look forward to the day when playing first person shooters involves some level of problem solving, rather than testing reflexes with the mouse and keyboard.
Re:He's wrong (Score:5, Insightful)
There's a huge difference between a bad story that's barely there and a bad story that's in-your-face. If you have a lot of dialogue-heavy cut-scenes, or especially a long cut-scene before the game even starts, then yes, the writing had better be good. If the story is a few lines of text before dumping you right back into the gameplay, it doesn't matter so much.
Now that people are calling for story in all games, this is fairly independent of genre. I've played action games with an up-front story that destroyed an otherwise-decent game for me. Moral of the story: if you can't write, don't write. Or at least make the cut-scenes skippable, for christ's sake.
Reasons: Schedules, Competition, Hard Market (Score:4, Insightful)
I would add several reasons to why game development is hard. All the technical issues Mr. Blow mentions, can be fixed given enough time. But there is never enough time.
To keep funding $10M+ game projects, a corporation needs to release a steady stream of games during major buying periods. This means, unless you're the likes of id or Valve, development cycles are 18 months, rarely negotiable. If you are late you will start loosing consumer awarness and marketing budgets. You also need to schedule time to do several demo disks and generate assets for the media. A senior programmer said that our primary target is management, and only later the gamer.
Second, unlike many software markets, you constantly feel your competition at your heels. The graphics, realism, complexity is an arms race. This makes games better and it also makes developers stay at work extra longer past midnight to implement that extra rocket launcher effect to stand out from the competition.
Then the market judges you on purely subjective measures. You can't lock yourself into a market like MS Office or Windows would. It doesn't even matter if you are technically the most advanced. As a game developer you are fighting for gamers attention. This is why you see games that are mostly sequels and based on established IP.
Then again these challanges are the reason I'm a game developer. Mr.Blow does point out a good deal of inneficient practices in the industry.
This should be seen as a call to arms for middle ware vendors and ISVs. Whenever there is a problem there is a buisness plan!
Oh no! 30 minutes for a full build! (Score:2, Insightful)
I will agree that the cost of game developmetn is skyrocketing. The cost of developing an engine alone is more than many game houses can handle and things are not improving. It can't be too long before more third party suppliers spring up who do nothing but build game engines and design tools. In a way it's kind of silly that game houses still have to build most of their stuff from scratch.
Fun Games Don't Need a Mega-Budget (Score:1, Insightful)
It's made with PHP, crappy black and white stickman graphics, and a warped sense of humour.
Probably took a while to make but certainly didn't need a blockbuster budget.
This game is easily as much fun as half the crap filling the shelves of stores today.
Re:Your god, Carmack, is wrong. (Score:4, Insightful)
Halo is the same (although I havn't finished it yet, I just got the PC version). It has some of the tensest gameplay I've seen since Half Life (which also had a B movie plot) - I just played the bit where you work into an alien base, and meet... nothing. Absolutely nothing but a few low level aliens at the begining, for 10-15 minutes.
It's terrifying, because you *know* something big is about to go off... you can just tell. And then you find some privates recording of what killed him, and the whole time your watching it, you're just sat there thinking "shit.", because you know you're about to have to fight it.
It's genious - a perfectly crafted piece of storyline, using the same plot device as some of the worst games ever, it's how it's pulled off that does the job.
Re:Shocking... (Score:5, Insightful)
I think the problem isn't a lack of programmers, but that the design isn't focussed enough that the programmers aren't wasting their time on stuff that makes no difference to the gameplay. Some of this is attributable to the publisher who wants some new feature to advertise (realtime wart-growing!), or some overly ambitious designer that wants things that add nothing to the gaming experience (did MGS 2 really have ice cubes you could watch melt? If so, then WHY?).
I really think that every designer should be made to play Super Mario 64 and Tetris. SM64 was huge, and Tetris was small, but both are very tightly focussed on the things that make the game FUN.
Re:Too many designers? (Score:5, Insightful)
Or it could just be that many games programmers work stupidly long hours, particularly as stupidly close deadlines approach, while being expected to write code of a quality unseen in most of the programming industry because of the need to keep performance up and support the latest and greatest AI algorithms, without much of the fun and glamour they thought would come with the job because the production people get most of that, in exchange for financial compensation that barely beats what a Mickey Mouse business apps developer can pick up in his first job, assuming the company lasts long enough to get the game finished and published so there's any pay cheque at all. Nah, that's a silly idea...
I have to laugh... (Score:4, Insightful)
This is funny. A few years ago, after working on successful but boring software projects for the past ten years, I decided that I wanted to work in the game industry. I have no debt, and was willing to take a pay cut. I live in San Diego, home of a number of game companies, EA, Sony, etc. I figured it wouldn't be too difficult to get myself at least an entry level position with 10-years experience, just to learn the ropes. Nobody seemed willing to hire someone that didn't have several previously delivered games under their belt, despite a number of other successful consumer products and happy customers. I had sent resumes to all the companies in the area, as well as working briefly with a "game headhunter" which didn't work out as well. After roughly six months of trying, I gave up, and went back to working on my boring jobs. I'm guessing that the writer of the above quote isn't all that tied into the needs of the industry.
wake up (Score:1, Insightful)
Blow was problably called into to rescue fucked up projects. And Carmack is good, but he's not worthy of such worship. If you've read Blow's columns (which I doubt) you'd know that he's pretty sharp.
retard fan boy.
Re:Why 20 hour RPG's do not quite work (Score:5, Insightful)
Style vs. Substance (Score:5, Insightful)
The game industry looks like the equivalant of the comic book industry in the eary 90s, lots of eye-candy, gimmick covers, etc and little substance.
I think the way this works is this: there's three types of games- those with fluff, those with substance, and those with fluff and substance (and gradients inbetween of course). Substance, by itself, does not sell.
The thing about substance or gameplay is that it requires a certain amount of attention that cannot be extracted from an audience until they have bought the product and invested some amount of minutes or hours into it. The sure-fire way to get that investment is to attract the eye- visuals can transmit much more information about something much faster than sound or text, so discerning quality of visuals is easy for nearly anyone. There is no shorthand to communicate gameplay other than simply playing the game, though screenshots and videos and short text descriptions may at least indicate what is to be expected.
If I'm going to play a crappy game, I'd rather play a crappy game that looks good than the alternative- and the same goes for other visual media.
An addition to that last statement is that there are a lot of people for which style is substance. The obvious ones are artists, or people with ambitions in that direction or simply an appreciation for it- playing something with really cool level and character design and etc. is the main thing while the story and interface should drive it along- if they're really good, that's a great bonus. Bad story isn't really a showstopper, but bad interface is - so I don't mind seeing the 'cookie cutter' approach get used there because I'd rather not every game try to reinvent the wheel when I just want to move the camera/character/units around.
Re:The complexities of modern software development (Score:3, Insightful)
Sure is. Do you have a reference for that 50 000 lines of code estimate for Monkey Island? And do you know if that included both the engine code and the game/story code (which were probably written in different languages, as far as I've heard).
I'm not disputing your figures, you understand, I'd just like to know where you got them from. :)
Wow. That sounds like it contradicts every bit of guru advice I've ever heard on optimisation, most of which boils down to "optimising too early is a mug's game" (pun intended). Or, to quote Knuth more directly: "Premature optimisation is the root of all evil." The "performance" section of these so-called pearls of wisdom [mtsac.edu] :) is particularly appropriate.
And while searching for one of the above quotes I found this article [propylon.com], which explains the concept even better.
In any kind of programming, if you start optimising too early, you're almost certainly just going to be wasting your time (and massively fucking up the system design, too, if you're coupling modules together unnecessarily, as suggested by "You often want your modules to talk directly to each other.").
Well-designed interfaces also make it much easier to profile and do effective optimisation - when it's appropriate to do so, ie. when it's all working correctly, just too slowly.
Sounds like it, yes. You have my sympathy. :)
Pete, who is very glad he isn't involved in the game industry, as he already has precious little sanity left from other industries...No alternatives!? (Score:2, Insightful)
(from the second page)
What about Intel's excellent compiler? Or AMD's? Or GCC?
I think someone needs to think outside the box here. Surely if you're good enough to write a game like UT2003 (or something) you could deal with emacs* and use a great compiler. Oh well. Whatever, I don't play games (often) anyway.
* Saying "dealing with emacs" is like complaining that your girlfriend loves you too much. In other words (slashdotters may not relate to the gf example
Re:Too many designers? (Score:3, Insightful)
With respect to open-source projects, that's certainly true.
I think it's harder to collaborate on art- Software forces a certain degree of conformity, while in art freedom is absolute- there's a huge proliferation of different styles that wouldn't look good next to each other in the same game.
Tools are partially to blame- they are prohibitively expensive and hard to master. There are some good open-source solutions: Gimp is okay for 2d stuff (please someone give it a docked interface rather than having to shuffle through dozens of independent windows...), though interface-wise I'd rather be using a copy of Deluxe Paint from ten years ago (and is there any paint program that allows you to assign one color and tool to the left button and another color and tool to the right button?). Wings 3D and Blender can do some good 3D stuff, but there's a lot missing for creating more complicated objects
The other problem is that the open-source community spirit hasn't infiltrated the art community yet. It may take a few years- I see in a site like deviantArt [deviantart.com] indicating a future where sharing and collaboration are more the rule. Artists may be less susceptible to the gpl ideology, or simply lack leadership- who would be the RMS or Linus of free software-art? And what is the standard license for distribution- something from Creative Commons?
Re:Too many designers? (Score:5, Insightful)
Isn't that pretty much the state of the whole software industry?
Re:Too many designers? (Score:4, Insightful)
Actually everything I've read in the press and in B&N game books is that the industry can't keep it's top dogs, because they get burnt out.
I would say not only that, but since EA just closed office(s) in Austin... of forget it. Game Publishers close offices all the time after a great game is shipped,etc and this article states there aren't enough programmers?!
Well I personally know of a great programmer who left for the business world since it payed double what he was worth and the corporate bullshit stings pretty bad in game companies.
Maybe that's what happens when real greedy CEOs and businessmen collide with very immature geeks and developers.
The industry needs to reward better it's programming heros and keep them in the game.
Re:Harder every year... (Score:2, Insightful)
As we become more comfortable with basic technology (3D graphics and physics and stuff) it will probably become easier to get the basics done. At some point a lot of the risk will be mitigated, and you'll start seeing more creativity because we start developing with a higher baseline. Hopefully within the next few years!
Yes and no. There isn't a whole lot left to discover and become familiar with in the engines that already exist, because, well, they already exist. I mean, what does the Quake 3 engine really have that people aren't familiar with? On the plus side maybe future engines will be a little easier to work with, in theory.
But there's another side about continued development. It gets mentioned all the time on slashdot, so I hate to use, but it's the old "I'll NEVER need more than xx amount of RAM" argument again. New technologies, methods, etc will be developed, and developers will need to become familiar with them, and release dates will be pushed up even as programmers are still feeling out the system, so they'll be forced to cut out what they really want to make.
The solution won't come through familiarity with the technology, it'll come through a change in the way that games are developed.
Re:Design Patterns? (Score:3, Insightful)
Hmmm...I liked the article, but I don't think I'm going to let you get away with that. I found the "build times are really long!" part of the article the most troubling. Here are some observations, which I'm not suggesting you're completely unaware of, it's just a convenient place for me to impart information that people don't know. Before anyone flames me, yes, they should know, but they don't. That's not my fault.
First of all, stop having a go at Microsoft's tools. You try using the PS2 dev tools for a while, and you will ache to go back to the MS tools - incremental compilation and linking, decent debugger, etc. I know you weren't really moaning (and maybe you have used PS2 tools - my sympathy), but if you're using VC6 or higher, then I don't think tool quality is going to be a major problem. Enough said.
Most big C++ projects have long build times because everyone bitches about them but nobody tries to do anything about it. I think this is often down to programmers not really understanding how compilers/linkers work, or actually being any good at performance tuning.
Job #1 when solving slow build times is really easy - all you need is some money - and not much. It's real easy - buy some more RAM. If your developers don't have at least 1Gb of RAM in their PCs, then there's probably something wrong. The good news is, it's easy to fix (buy some RAM), and RAM is so cheap that it'll pay for itself in improved productivity in a couple of weeks in extreme cases (I've experienced that first hand myself).
Yes, yes, code bloat, I remember when all you got was 16k, blah blah, "7167 bytes free", Windows sucks, etc., etc. - yes, very nice, but the fact is that buying a dev $50 worth of RAM usually saves them shedloads of time, so suck it up and do it.
After the easy stuff, here's some more easy stuff. When it comes to C++, there are trivial things you can do wrong (and often) to make your build times balloon. The single most important question to ask in C++ with respect to build times is: do I need to include that file, or can I use a forward declaration?
If no thought goes into choosing which files to include, then you don't really notice it that much on smaller projects, but on larger projects it kills your productivity (due to large build times). A few months back, I spent a couple of days pruning include directives from our project's source files. In only two cases did I actually change any implementation (on both cases, to use the pimpl idiom on a couple of choke point classes). It took me about 2 days and was hell, but at the end of it our build times were half what they used to be.
On other projects where the tools support pre-compiled headers ("Luxury!"), I've reduced build times by a factor of 4-6.
The effects are two-fold - first, each source file takes less time to compile, because it isn't including the whole bloody project, and secondly, less files get recompiled when you change stuff. Again, obvious, I know, but you'd think it wasn't, judging by the lack of effort most people put into fixing this. This addresses the "I just changed the animation file format, so why the hell is the physics system being rebuilt?" problem.
In short, more people need to read Large Scale C++ Design [amazon.co.uk] by John Lakos.
As for not being able to use design patterns, etc, in something as complicated as a game, that's a bit of a cop out, as I suspect you know. If you don't plan and manage your design rigourously, then your development time will usually be longer, due to bugs in the design and code. Essentially you're saying "Games are too complicated to be designed". Put like that, it doesn't sound that defensible (but: possible Straw Man alert
Re:OSS seems to help with this.. (Score:3, Insightful)
I've heard this said a few times, but you have to bear one important thing in mind - which I'm sure a few mod creators who've transitioned into an actual paid job in the industry have found:
When you write a game, most of the time, you don't get the finished tools at the start of the project. They're not finished, usually buggy, or maybe they're being started from scratch. They're usually incomplete for most of the project lifecycle.
For example: if HL2 comes out (ever), then take a look at the tools they provide you with the SDK. I can pretty much guarantee you that the artists, designers and programmers didn't have those complete finished tools ready to use at the start of the project.
Using unfinished tools, having to rework content/code all the time as the tools improve, takes a surprisingly large amount of time in a project. Or perhaps it's not surprising.
When creating a mod, although some of them extend the game in ways the creators are surprised by, you're generally working in a fixed universe and feature set. Either the game can do X, or it can't. This cuts down your design decisions hugely, and you go down fewer dead ends.
When working on a game project, anything is possible, because the game isn't finished yet. Can we add feature X? Sure we can, if we have the time and resources. Sorry designers, we're not sure if we'll be able to get that feature in - we'll let you know in about 3 months' time. Can you just carry on designing the game anyway?
Like the man said, it's not as easy as it seems.
Incidentally, could you give me an example of a total conversion mod that is much better overall than the original game?
Re:Too many designers? (Score:1, Insightful)
1. Let their name be on it. Let their name come first. Let it be their vision. Let them do it the way they think it should be done. Let them get the credit, and I mean all the credit. Let them brag about what they did. Let the work be done in a way that gives them status among *their* peers, which is probably different from the way you would do it to have status among *your* peers. Let the success of project be a reflection of *their* foresight, vision, planning, execution and achievement.
2. Not willing to share the spotlight? Cough up the bucks. If you insist on keeping the glory to yourself, then you face the same problem as anyone else in that position: how to find someone who will work for you instead of with you. The typical solution is to pay them, because why else would anyone work for your gratification instead of their own?
Re:here is a clue (Score:3, Insightful)
I cannot deny that many programmers have multiple specialties. I have worked in shops that do SQL all day, and presentation software, and remote sensing, and scientific computing, as well as the game industry. I've worked with programmers that range from high-school dropouts to PhD earners. I believe I've seen most of the full range.
That's where I disagree with you. It is not just a matter of being more specialized. I believe there is a completely different, almost fundamentally different, degree of difficulty and requirements for game developers.
I'll go through the places I'm comparing it against. Feel free to disagree about any of them, but I feel that each is fairly typical of programming environments.
When I was working with SQL on POS, there were 7 of the about 35 programmers there who were the SQL and communications experts. They could literally do anything that anybody else was doing. The remaining 80% of the programmers were just doing grunt-work, basically commodity programmers. Yes, people had specialties, but they weren't really used. There were approximate deadlines, but they were very soft.
Next, I worked with presentation software, specifically it was interactive polling in focus groups and larger corporate meetings. The owners were all psychologists that ran these corporate meetings. The owners stated exactly what the presentation software required for their industry, had contracts with keypad vendors that basically gave us serial-port input, and all we had to do was tabulate the results, record them, and stick them into graphs. Nobody on the group was required to do anything spectacular that a college grad with 3-5 years of general programming experience could not do. Additionally, there were approximate deadlines, but they didn't really care as long as some specific feature was in place before some specific presentation -- these were known months in advance.
Moving up to remote sensing hardware, people were starting to specialize. There were the hardware folk, many of them were highly specialized. That's partly because the company owners were two university professors who had some good ideas, and started a business with their best grad students. Everybody at the company was expert in mathematics, and had at least a BS. About half of the company had MS degrees or higher, and the only people without a BS were the interns -- they were still in college. In addition to lots of math, about half the people were quite good in one or more other areas. I know this is not the typical company, but it may be typical of your experience; in which case it does seem that everybody has several expert areas. Again, there was no real hard deadline, customers were mostly governments and they only cared about it being done within a certain fiscal year.
In my job with scientific computing, multiple specializations was almost required. At a minimum, you needed to understand all the nuance of floating point numbers, and how they are different from real-world values, and when that it a problem. There, I spent most of my time dealing with compatibility and networking issues. But I also had a lot of time in spatial partitioning and distributed computing. Most co-workers were also working on three or more complex issues. From my experience, I know that most of the programmers from the SQL/POS shop couldn't jump into those roles, and only one other person from the presentations software could have made that transition. Most of the people who worked with me at the remote sensing job could probably have made it though, a