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.'"
Too many designers? (Score:3, Funny)
Re:Too many designers? (Score:5, Interesting)
It's the usual story. Companies demand experience on all posts, and then whine about lack of "qualified" applicants. While ignoring the fact that they themselves are creating a qualification that's impossible to get.
free software has a tactical advantage here (Score:5, Interesting)
It's not a qualification, but you can easily learn enough to bluff through an interview. (so long as you can tell that the job is really just a programming job with too many requirements written in the spec to make a manager feel like she's doing her job.)
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."
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:Harder every year... (Score:5, Interesting)
Of course some of this is due to publishers just being imaginative and wanting to pump out the same old dreck as some other game that did pretty well. But really a lot of it has to do with games being hard to make. Often games have to cut tons of features/levels/testing in order to make it out the door only a year late. So usually the game you buy that is mostly fluff, that you're disappointed with, is not much like the game that the developers originally set out to create.
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!
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:Too many designers? (Score:5, Insightful)
Isn't that pretty much the state of the whole software industry?
Reminds me of the ads for unix programmers. (Score:5, Interesting)
Reminds me of the ads I used to see when Unix was first catching on. Entry-level pay jobs requiring 5 or 10 years of Unix experience, obviously written by HR people with no clue.
I guess Kernighan, Ritchie, Thompson, Bourne, and Plauger weren't tempted into leaving Bell Labs by the pay scale. B-)
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...
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.
Making Game (Score:5, Interesting)
We would much rather have that manpower spent to make the system compile programs quickly, or generate efficient code,
Bingo, I think the future of mmg's depends on this. People increasingly will want more variation in gameplay. Concepts like an Architecture Generation Engine (AGE) would benefit greatly from this. An AGE makes a multiplayer map/scenario different every time you play it, so you have to adapt all the time. The ability to randomly generate and compile the new map very quickly, is very important. This for me is the neatest thing in gaming going on right now. Great article!
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: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 d
Re:Too many designers? (Score:3, Informative)
Yes, stable gimp has that. 1.3.* and 2.0pre* work fine.
Less than you might think. Here are my current gimp (2.0pre*) kludges and a screenshot [hopto.org] to illustrate them:
As a programmer and game developer... (Score:5, Interesting)
It used to be, and back in the day when I started programming my first games, that a single "Lone Wolf" programmer (Like I have always been) could develop his own game.
However, now with the crazily complex 3D games, there has to be a whole army of developers, artists, designers, programmers, etc. just to create a game.
Unfortunately that damages lone wolf developers such as myself, in that we cant keep up with the demands of such a large production budget!
Anyway, I have attempted to work as good as I can, see what you think of my game, it is a bit difficult to wear the hats of Programmer, Designer, Developer, Musician, and Artist!
http://abaddon.igerard.com [igerard.com]
Re:As a programmer and game developer... (Score:5, Funny)
You developers need to think more like managers.
Re:As a programmer and game developer... (Score:3, Informative)
Here's a link [reference.com] that might help make his post more clear to you.
Re:As a programmer and game developer... (Score:5, Interesting)
Well, I just downloaded your game. One of the things I like about this is that I take your comments at a higher value seeing that you're actually "down in it" building games on your own. I think your kind of game could really appeal to a lot of people.
First of all, as the article describes, the industry is really stretched by new 3D worlds that require huge investments of time, staff, and money. Getting back to the lone developer model of gaming, or even a 2 or 3 person development team, could be one solution. Also, if you visit Usenet groups like comp.sys.ibm.pc.games.rpg, you'll find a lot of people who miss isometric games with smaller, tighter storylines. I personally would love to buy a few games like Baldur's Gate 1 & 2, but which had only maybe 20 hours of gameplay, instead of 60. Those games would be more "complete-able" by 30-something and 40-something parents (like me), and more "build-able" by developers like you. And we seem to be a bigger part of the market nowadays anyway.
Garage Games [garagegames.com] is also catering to this market, at least in part. Smaller games, simple in scope, faster development & deployment, but great gameplay. I would encourage you to do more of this. I think the only difficulty is getting the word out, especially if you hope to charge money for the game. I don't know how you'd draw in traffic, except to say that Google's AdWords might be useful.
Why 20 hour RPG's do not quite work (Score:5, Interesting)
From a programming standpoint, 20 hours of high quality game play is just as difficult as 60 hours. The bulk of the work for an additional 40 hours is done by artists and level designers creating the additional content.
And a shorter game does not aid its 'beat-ability'. It just aids its re-playability. Most 60 hour games can be beaten in 20 hours or less, typically, you just skip the side quests.
And doing a 20 hour game, but making more of them reeks of what EA does with expansion packs. Its a very shallow marketing ploy.
I would rather play one long well made game, then 1 short well made game and 4 short crappy games tossed off with the aim of turning out a profit.
END COMMUNICATION
Re:Why 20 hour RPG's do not quite work (Score:3, Interesting)
Re:Why 20 hour RPG's do not quite work (Score:5, Insightful)
Re:As a programmer and game developer... (Score:3, Funny)
That and, you know, posting +5, Insightful comments on slashdot with a link to your site
Re:As a programmer and game developer... (Score:3, Funny)
And that, my friends, is irony.
Re:As a programmer and game developer... (Score:4, Interesting)
You sound like an engineering student all right. For the future, real engineers actually analyze problems and give workable solutions. Managers give catchphrases like "you should learn to play nice with others" without apparantly any knowlege of the situation beyond a couple paragraphs of type.
OK smart guy, do the entire indie development community around the world a favour and break this little conundrum: How do you get together a team of dedicated independants who are willing to work hard on a project for years on end? If you can figure this out, please let us know, because I've seen thousands of projects fall by the wayside not due to some internal dispute, but because most independants have lives, and simply can't afford to dedicate that kind of resources to a project for the periods of time needed to finish a production run. Most who do are newbies who will spend a couple hours working on this project before quitting, a week at most. People with experience work alone or with people who they happen to know in real life, or they fail. It's a simple fact of life, one which I've experienced myself in a couple projects I joined with in the past. Eventually all of them folded, because nobody could keep working while critical team members took months off the project to deal with real life matters.
Sure, sometimes a team manages to keep together, as the recent release of "Diver Down", a great indie RPG, shows. The problem is that it often has far less to do with team management and more to do with the fact that people have real lives to deal with, and simply put, shit happens.
The best advantage of the lone wolf model for indie developers is that a single dedicated person can make the game of his dreams, and keep on making it while teams fumble around and lose members like mad. Take me. I've been working on my lifes work, a great RPG, for three years. In that time, the entire community of developers I tend to hang out in has been completely transformed several times, great sites have risen and fallen, great projects have come and gone never to be heard from again, but I'm still chipping away at this, dedicating every waking moment to dreaming up refinements to my original designs, preparing to code great enhancements, or actually going into the engine and adding things. I guarantee you that the odds of me finding another developer as dedicated as myself to this particular project are about the same as me digging up a UFO in my back yard. I'm sure the parent is the same way. Take a look at how long abaddon has been in development. No team will keep working that long. Only a man with a vision can, and so he does. Regardless however, many indie games done with this model achieve steady progress throughout their development, slowly but surely, as a single person fights to complete it through force of sheer will.
It's a beautiful thing.
Outsource it! (Score:5, Funny)
Re:Outsource it! (Score:5, Funny)
You come across Wumpus!
What you do?
> Shoot Wumpus
Wumpus die.
Re:Outsource it! (Score:2)
Re:Outsource it! (Score:5, Funny)
If they outsourced, pretty soon you'd have characters in games saying stuff like "All your base are belong to us..." and "Make your time...."
Re:Outsource it! (Score:2)
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
There is a saying for this in real life... (Score:5, Insightful)
Kama Whoring with ad free versions (Score:5, Informative)
Re:Kama Whoring with ad free versions (Score:3, Funny)
#1. Don't you think it's immoral for you to have viewed those pages based on your argument in #2?
#2. Don't you think this is a pointless argument because of what you said in #1?
Is it just my imagination (Score:5, Funny)
Nice pen name
Re:Is it just my imagination (Score:2)
A Blow job (Score:2, Funny)
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: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:He's wrong (Score:3, Insightful)
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: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.
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.
Too narrow a definition of story (Score:3, Interesting)
Most people interpret "story" to mean "plot", but the two are not the same. A story, broadly speaking, is "setup, conflict, development, resolution", but writing a plot line, with set characters and dialog is only one way to get a "story".
Tetris has a "story". The set up is the rules. The conflict is that the game is throwing blocks at you, but you don't want blocks on the field. The development is the game play, and in Tetris's
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: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:He's wrong (Score:5, Insightful)
Re:He's wrong (Score:5, Informative)
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"
Re:He's wrong (Score:3, Interesting)
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.
A dream far away from here... (Score:5, Interesting)
But hey! What do i know? I live in Mexico, there is a small or not-existant game industry at all!
--
No sig found.
OSS seems to help with this.. (Score:5, Interesting)
You can take jim's physics library and link it into fred's ROAM engine, slap tommy's interface toolkit on top if it then shoehorn bob's network protocol in and actually get a usable piece of software out of it. The SDL libraries are one obvious example of this but it's far from the only place I've seen it.
No it won't be the next jaw dropping engine that will command everyone's respect but that's not really the point, the point is as long as you have enough basic intelligence to learn an API and can manage to glue several of them together the open source world is plenty willing to fill in the gaps of your knowledge.
It isn't really an open source specific thing, this mode of thinking can be found under windows as well, but for obvious reasons it seems to flourish best in the linux world. It's not mature area of development yet, but the foundations are there. As the barrier of entry into developing commercial games increases, so to do the free software options.
I think it'll be neat to wait and see if open source can evolve to present a solution to the "kitchen sink" problems that current game development has to deal with.
Re:OSS seems to help with this.. (Score:2, Interesting)
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 th
Re:OSS seems to help with this.. (Score:5, Interesting)
Older games may not teach a developer all the latest techniques but it would sure as hell let you be able to compare 3 or 4 similar implementations of a function and pick the best or even merge parts of 2 together to make it better still, I know some companies di this but there are more that don't.
Re:OSS seems to help with this.. (Score:5, Interesting)
This is one area where Java is way underrated. Just between the 2D and Midi APIs, there is a lot of gaming potential there. I haven't looked at Java3D, so I'm not sure about mega-real-time-worlds, but perhaps it could work there, too.
Re:OSS seems to help with this.. (Score:4, Informative)
It's definitely worth a look.
Flash to the rescue (Score:5, Interesting)
Working in a restricted environment like Flash eliminates a lot of the hassles described in the article. It's arguably easier to write, say, King's Quest now than it would have been 20 years ago,
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.
what the industry needs (Score:5, Interesting)
Re:what the industry needs (Score:2)
Re:what the industry needs (Score:4, Informative)
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.
Re:what the industry needs (Score:3, Interesting)
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.
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
Design Patterns? (Score:5, Informative)
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 [amazon.com] 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?
Re: class public interfaces... (Score:4, Insightful)
Re:Design Patterns? (Score:5, Interesting)
The problem is that games are just too big and cutting-edge for this kind of design approach to work. You can only do this for relatively simple problems that you completely understand. Games are the opposite of that. They have to be designed incrementally -- if you just sat down and tried to make a bunch of headers, without building the implementations, you would eventually find that your interfaces were completely wrong.
Interface classes can help a little, but only a little. The problem isn't so much having private data in a header file (though that is a problem) so much as the sheer interconnectedness of the dependencies in a project like this. That's the point of those diagrams on the first page of the article. Look at the one for a Massively Multiplayer Game and then think about what the header structure for that is like (considering that each box is not a file, but a cluster of files).
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 d
new technology, designers, engineers... (Score:5, Funny)
:-P
Full Sail! (Score:5, Informative)
Harder than you think? (Score:2, Funny)
Lua (Score:5, Interesting)
Another sad thing (Score:5, Interesting)
I remember when I was 13 writing ASM code code aspiring to write something like Monkey Island -- that was a very attainable goal. I had a friend who was a very good artist, he would whip up a some cells in autodesk animator, I had written a little converter, and we could walk our little guy around the screen against a background. Now truth be told I had NO idea how a game engine worked at 13 years old, but we did end up writing a few neat demos and bbs loaders (I was a weird kid).
Now the level of art work and technical knowledge required to make something that looks half professional is off the scale. I have a great game idea that I don't think I'll ever be able to realize. Thats the loss I mourn... kids wont ever have the fun I had trying to make a game, and we might never be exposed to some new ideas these kids might have.
Not at all true (Score:4, Informative)
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.)
Meh (Score:5, Interesting)
2D used to be the best choice simply because you could do infinitly better looking graphics. 3D is now getting up to par but there's really no reason not to still use 2D. The latest Wario game just took a tile based game and made it a cube based game in 3D. Not a programming challenge at all. Instead of DrawTile you just use DrawCube, increase the dimensions of your map and voila! 3D platformer. I whipped up the basic components in all of a few days (running, jumping, standing on and above things, collision).
The market is so saturated with 3D first person shooter crap that there's a huge market for games that are simply fun to play. You are not going to get rich from a 3D game so why bother making a crappy 3D game in a lame attempt to milk the 3D scene? Make the best of what you can do, even in 2D and it may not make you rich but at least it won't be half-assed crap.
Stop worrying about the million dollar budgets and just worry about making a fun product.
The best application of 2D is in puzzle games which are ginormous. The hardest part is comming up with the new puzzle concept. Programming them is rediculously easy and they're cheap. Which makes it more likely people will buy them as time killers at work to replace solitaire and minesweeper.
Ben
Or perhaps none are willing to do the hours.... (Score:5, Informative)
Oh come off it... (Score:5, Interesting)
All this "Life is so hard! My industry is so cruel!" is just attention grabbing to get readers to an otherwise rather dry review article on the elements of commercial game production.
In other news, games are unimportant. All but a very few games are played by practically no one, and those that do play it throw it away after a couple-dozen hours. Where did this conception that making games was so exciting and dramatic come from? Just because so many other areas of software development are even more mind-numbing doesn't make gamedev automatically interesting!
Design me a new spoon. Design me a spoon that will be sold across the world, used by millions on a daily basis for years of their life. Design me a brilliant spoon, and I will be impressed.
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.
HL2 delay tactic (Score:5, Funny)
Old Interactive Basic Game, one line of code (Score:5, Interesting)
You control an object at the top of the screen it will move left if you don't push shift, right if you do. Blocks "###" are printed at the bottom of the screen and scroll up. If you crash into a block it is game over. Quite complex for 1 line. I would walk into stores displaying computers without games that attracted the kids, type this in and have fun.
I had versions for PET, VIC20, C64, APPLE II, TRS80 machines
Adjust for my bad memory and learning of many other languages since then.
0 poke 32788+a,65; a = a + peek(515)*2-1; print tab(36*rnd()),"###"; if (peek(32788+a) == 32) goto 0;
clear the screen, scroll to the bottom and run
Break down
A) poke - puts player "A" set by ascii 65 at the middle of the top line of the screen plus the offset a
B) adjust the offset a of the players position dependent on the state of the shift key
C) print - puts a block in a random position on the next line. If this is the bottom of the screen, we get a scroll and everything moves up and the players object is cleared off the top
D) check the new position of the player to see if it is clear
Majic numbers
32788 address of the middle of the top line of the screen
65 character for players object
36 + width of block is 1 less than the width of the screen, in this case 36+3 40
515 shift key status updated by system interrupt
The complexities of modern software development (Score:5, Interesting)
Let look at a few examples:
Games have ballooned in complexity-
I think it is safe to say that nearly all software has grown in complexity. For traditional client-centric applications, we have seen interfaces grow more complicated and sophisticated. Unlike software designed in 1996 nearly all applications are now internet aware. Even your wordprocessor has the ability to communicate via the internet, to interact with email and offer colaboration functionality.
Very little software is designed to operate in the vacuum of a stand-alone workstation anymore. Apparently this is also true of games. Wow, brilliant insight.
Tools-
The author is probably correct about a lack of competing products for Windows C++ development. Still Visual C++ is quite a good IDE. A lot of the issues raised are more generic complaints about C++ development than anything specific to game development. While game programming has its own special requirements- 3D rendering for example- other types of software has different but equally complicated needs. For example, the complexities of interating with a wide variety of back-end databases, message-queueing software and legacy mainframe systems add layer up layer of complexity to most business applications. The specific requirement is game-development specific but the problem is one which all complex projects face.
Let face it, the need for source control systems which are able to manage arbitary content is hardly unique to game development. Nearly every project I have ever seen runs into source control issues.
Workflow issues
Now the issue of re-compilation times, debug build load times and other development issues are a problem for ALL big software development projects. Multi-platform issues are equally problematic. This is hardly restricted to game development
Third party components-
Always an interesting issue for application development and not exactly one confined to game development. Think about applications you have seen which manipulate data and display charts and graphs. How many of those apps actually have custom written charting libraries. Hardly any. Nearly ever application OEMs someone's ibrary with all the associated headaches that come with emebedding components over which you have no control. That is the trade-off you make. You save 10 man-years of effort in developing a graphing library and you lose control of the source code, bug-fixing, release cycles and the ability to add new, special or project specific functionality. (Unless of course you go OSS). Big deal. Highly Domain Specific Requirements-
This is the dumbest section in the article. All software has some domain specific requirement otherwise it wouldn't be an application, it would be some sort of generic framework. Games clearly have a set of requirements not found in typical application software- 3D graphics, AI and sound effects for example. However if we look at network security applications for example, I think that we can safely say that there are just as many complex, domain specific requirements involved in TCP/IP protocols, packet sniffing, network tracing , etc.
Profiling-
Profiling all code is hard. Identifying bottlenecks in code which involves a great deal of user interaction is very complicated. Hardly specific to game programming.
Reality check time. All the article says is in 2004 that users expect a far more sophisticated product than have been required in 1996. Engineering complex products is difficult. Welcome to the software industry.
Re:The complexities of modern software development (Score:5, Informative)
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...)
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. :)
Games really are hard (Score:4, Informative)
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.
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!
Rapid inflation is the cause. (Score:5, Informative)
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.
The games industry is going to die. (Score:3, Interesting)
I've said it before and I was modded as troll. But, if one faces reality, he/she would see that games development becomes much harder every year. Only really exceptional developers will be able to make a product that stands out. The smaller ones will die or will be absorbed by bigger ones.
In fact, there are several problems already.
One of the problems is the tools themselves. Although I am not a games pro
Re:Rapid inflation is the cause. (Score:5, Informative)
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 :)
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.
My thoughts... (Score:5, Interesting)
Games are very complex pieces of software these days for sure. Graphics, audio, networking, even UI is a big deal. Just getting something working is only the beginning. Then comes the real work in making your game engines perform such that you are hitting your framerates in every area of the game.
It used to be if your main loop was hitting your framerate, you were done. This is because you did all of your I/O up front (the loading screen). Your user input was always polled each frame, so unnecessary state changes that could possibly disrupt your performance were minimal. Largely it was your graphics theory knowledge that made or break your engine.
Nowadays it is becoming more non-deterministic due to other forms of disruptive state changes. Graphics have become more complex and networking creates state changes that often don't happen within one frame (e.g. picking up an item in Quake 3 requires the server to acknowledge this).
People complain about why studios ask for at least 5 years of experience and on top of that ask for prior experience with a particular console. Getting something working fast isn't the goal. It's getting it working correctly.
How relationships with publishers changes priorities is an entirely different discussion, however...
A C to sail them on. (Score:3, Funny)
But this C is tiny and difficult to sail so I'll hand them all an upgrade to C++ [att.com] and let them wail.
This shrieking is ill met, I stop and look profound as I have a solution it's C pound. [hitmill.com]
My coders all have left me with this ugly stinking mess I should have not given them more and more but merely better less. [cminusminus.org]
Modders will Safe The World (Score:3, Interesting)
So you make a tiny mod for Half-Life, and you have a 1 millon potentian userbase. Cool or not?
Making mods shortcut the problem of very very long development process.
posdata:
Recently a quake guru (FrikaC) has make a Tetris clone in only 2 hours of work. You can download a stand-alone version here:
http://telejano.berlios.de/option/qtetris1.zip
Re:Shocking... (Score:5, Insightful)
Re:Shocking... (Score:5, Insightful)
Re:Shocking... (Score:5, Interesting)
There are countless examples of games that are great in theory, but poor in practice(I'm looking at you Black & White). Yet relatively few that have no business in being so great(And here I'm looking directly at a certain Tetris), and somehow pull of all those intangibles such as playability.
Even taking a great idea that 'will' be purely playable and making it so, is a great skill that only few can accomplish.
It amazes me how certain designers can almost routinely pull off the impossible.
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:here is a clue (Score:5, Informative)
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
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