Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Anatomy of Game Development

michael posted more than 10 years ago | from the code-monkey dept.

Programming 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.'"

cancel ×

385 comments

Sorry! There are no comments related to the filter you selected.

Too many designers? (3, Funny)

Motherfucking Shit (636021) | more than 10 years ago | (#8419436)

My understanding of the industry is that they have too many designers and not enough programmers.
Well, you sure would think the opposite if you take Slashdot's "Games" section as an example...

Re:Too many designers? (5, Interesting)

hyphz (179185) | more than 10 years ago | (#8419454)

Yea.

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.

Wait. I'm wrong. mod parent down (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8419524)

I realised I'm full of shit. It's ok; I'm willing to take the karma hit. I've learned my lesson.

MOD PARENT DOWN!

Re:Too many designers? (5, Insightful)

edwdig (47888) | more than 10 years ago | (#8419851)

Well, the problem with too many designers is simply that almost anyone that's ever played a game feels they could design their own great game. I'm sure you know at least a few people that played a few Mega Man games and then came up their own ideas for Mega Man bosses. Heck, the bosses in the last few NES Mega Man cames were all entries submitted into a design a boss contest.

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.

Space cowboy is a lying scumbag! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8419439)

FP! -- Mookore!

That's because the Employers Are Dumb Shits (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8419443)

Look EA hires the dumbest people off my campus UVic. They have no quality control, they also valuable your "experience" way above your theoretical knowledge. Yah Hmm why was iD so successful? ALGORITHMS. Not "GL" experience.

Shocking... (1, Insightful)

Anonymous Coward | more than 10 years ago | (#8419444)

Funny how more people have ideas for games than actually know how to write them...

Re:Shocking... (5, Insightful)

Anonymous Coward | more than 10 years ago | (#8419461)

No it's not. Children make up games to play with their friends all the time. Why is it difficult to make a system? Codifying it formally is where everyone runs into problems. Oh and that everyone loves to reinvent that wheel.

Re:Shocking... (0)

Anonymous Coward | more than 10 years ago | (#8419747)

No it's not.

Uhh... I think he was being sarcastic [reference.com] .

Re:Shocking... (5, Insightful)

tc (93768) | more than 10 years ago | (#8419536)

It's also that there's a huge gulf between "having an idea for a game" and "being a game designer". Frankly, any idiot off the street can come up with a halfway decent idea for a game (it might not be terribly original, but it could probably turn into a reasonable game). The talent in game design lies in the thousand little decisions you have to make in turning the raw idea into an actual game. It's those little details that matter, and that separate a great game from an average game, and an average game from a bad game.

As a programmer and game developer... (5, Interesting)

SisyphusShrugged (728028) | more than 10 years ago | (#8419465)

As a programmer and game developer myself I have experienced first hand the level of complexity that game design and development has approached in recent times.

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... (4, Funny)

nzkoz (139612) | more than 10 years ago | (#8419573)

Just outsource your development to india. That way you can hire 35 guys at 2 bucks an hour and voila! Instant complex 3d games.

You developers need to think more like managers.

Re:As a programmer and game developer... (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8419574)

Your game crashes when I tried to play it. :(

Re:As a programmer and game developer... (0)

Anonymous Coward | more than 10 years ago | (#8419616)

It worked for me man. Dude, your grammer, and speeling need work?

Re:As a programmer and game developer... (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8419654)

Wow someone accidentally hit the "s" key instead of the "d" key. HOW DARE THEY!!! At least they did not invent words like "grammer" and "speeling" and use a comma when they should not have.

Re:As a programmer and game developer... (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8419678)

Actually, I was referring to the dialog contained within the grandparent's game. It was a joke, ASSHAT!

My bad, though, for being unclear.

Re:As a programmer and game developer... (5, Interesting)

Anthony Boyd (242971) | more than 10 years ago | (#8419600)

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!

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.

Re:As a programmer and game developer... (1)

wmspringer (569211) | more than 10 years ago | (#8419623)

I don't know how you'd draw in traffic, except to say that Google's AdWords might be useful.

Maybe he could post about it on Slashdot?

Re:As a programmer and game developer... (1)

91degrees (207121) | more than 10 years ago | (#8419607)

It looks very well polished. Why did you do an RPG type game though? The amount of game design needed for that sort of thing must have consumed a substatial part of the total project.

mod parent down (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8419673)

Spammer!

Re:As a programmer and game developer... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8419761)

setup.exe?

I couldn't play it. So ... it sucked.

Re:As a programmer and game developer... (0)

Anonymous Coward | more than 10 years ago | (#8419783)

Please make a Linux version? :)

Outsource it! (4, Funny)

in7ane (678796) | more than 10 years ago | (#8419471)

No, really...

Re:Outsource it! (5, Funny)

swimmar132 (302744) | more than 10 years ago | (#8419624)

Outsourced games.. ewww.

You come across Wumpus!
What you do?

> Shoot Wumpus

Wumpus die.

Re:Outsource it! (1)

DrMrLordX (559371) | more than 10 years ago | (#8419674)

A winnar is you! You technical monkey!

Re:Outsource it! (1)

pcraven (191172) | more than 10 years ago | (#8419646)

All your base belong to us!

Re:Outsource it! (5, Insightful)

Daetrin (576516) | more than 10 years ago | (#8419695)

Actually game developers are probably insulated more than many other industries from the dangers of outsourcing.

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-sourced part of it they would probably end up with a crappy game that got delayed at least once, and if they outsourced the entire team they would end up with a game that would sell well in India, but might or might not sell well in the US or anywhere else, which isn't something most companies want to risk.

There is a saying for this in real life... (5, Insightful)

Ga_101 (755815) | more than 10 years ago | (#8419481)

Too many cooks spoil the broth.

I FORGOT TO CHECK POST ANONYMOUSLY (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8419506)

OH SHIT!!!!

Re:There is a saying for this in real life... (1)

StuWho (748218) | more than 10 years ago | (#8419627)

Many's a mickle makes a muckle

Re:There is a saying for this in real life... (1)

Ensign Nemo (19284) | more than 10 years ago | (#8419692)

Damn, I'm way too tired. I read that as "Too many cocks spoil the broth." Dude, any cock would spoil the broth. Ewwwwww.

Good (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8419483)

I'm glad they haven't enough programmers. Playing games is like watching television. Kill your play station.

Game development sucks ASS (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8419495)

Let's talk about the anatomy [goat.cx] of trolling [tubgirl.com] instead, mmkay?

Kama Whoring with ad free versions (5, Informative)

Frogbert (589961) | more than 10 years ago | (#8419498)

Page 1 [acmqueue.com] Page 2 [acmqueue.com] Page 3 [acmqueue.com] Page 4 [acmqueue.com] Page 5 [acmqueue.com] Page 6 [acmqueue.com] Page 7 [acmqueue.com]

Re:Kama Whoring with ad free versions (1)

randyest (589159) | more than 10 years ago | (#8419756)

At least you admit it. But hey, does anyone else find it slimy that these "printer-friendly" links you provided only include part of the article? I thought the idea of "printer friendly" was to bring up a complete article, sans ads and extraneous graphics, so you can print. Once. To get it all.

How friendly is it to make me click seven pages one at a time, printing each, and having each one spill onto a fraction of the next when printed (depending on font size and marging, I suppose) so that I have to waste 10-11 sheets of paper and far too many clicks to get a 7-page article?

I'll tell you: it's not friendly at all. It's really annoying, and even though my proxy strips the ads off of every page anyway, I will not be bothered to click "next" 6 times after reading just a few paragraphs. It's just so obviously whoring that I can't play along as if the article is anything other than a blatant ad-impression generator.

Is it just my imagination (5, Funny)

Anonymous Coward | more than 10 years ago | (#8419511)

Or is the author of this article really called Joe Blow?

Nice pen name

Re:Is it just my imagination (1)

LinuxInDallas (73952) | more than 10 years ago | (#8419562)

His name is Johnathon Blow. Joe is of course short for Joseph. So yes, it was all in your (apparently oversized) imagination.

A Blow job (2, Funny)

StuWho (748218) | more than 10 years ago | (#8419638)

This classic work is surely a Blow job...

He's wrong (3, Insightful)

Anonymous Coward | more than 10 years ago | (#8419529)

The hard part is not the engineering. The hard part is the game design, story line, and content creation.
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 (5, Insightful)

tc (93768) | more than 10 years ago | (#8419564)

The balance depends on the kind of game. The engineering is getting pretty tough, because games are becoming more complicated.

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 (5, Insightful)

Mr. Piddle (567882) | more than 10 years ago | (#8419689)

"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."

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 (1)

AuMatar (183847) | more than 10 years ago | (#8419736)

ANd thats why Carmack designs shitty games. Technically sound and graphically beautiful, but boring as hell.

Your god, Carmack, is wrong. (5, Insightful)

Mulletproof (513805) | more than 10 years ago | (#8419776)

Sorry, Carmack is full of BS. Story makes or breaks a game in more than a few cases. Take Halo. Without the excellent story and plot devices, Halo would have been nothing but another faceless FPS. A pretty one, but hardly the best seller it was for the XBox. Story drove that game. Story seperates Baldurs Gate 2, a masterpiece, from the gorgeous but hollow Neverwinter Nights. NWN has BG2 dead to rights on every point except one, and it's that point alone that elevates BG2 to legendary status.

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:He's wrong (5, Informative)

gl4ss (559668) | more than 10 years ago | (#8419630)

the hard part is that too usually the designers don't seem to have been playing any games at all, ever! the biggest errors usually are all just about game design(and being designed to be something more than what the execution is able to grasp).

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

"not being able to see the forest because the trees are blocking the view"

Re:He's wrong (0)

Anonymous Coward | more than 10 years ago | (#8419664)

Sadly it appears to me that (despite their genuinely good intentions) game designers are no more likely to come up with an enjoyable, compelling game design than anyone else. They seem to spend most of their time avoiding "faults" that have been noted in other games.

I seriously suspect a bunch of kids would be better at coming up with a good game design than a professional game designer.

Re:He's wrong (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8419713)

The real hard part is maintaining a focus on the game as a whole the entire time. With games running several years of development, the original design document is drastically different than the game you end up pressing on a CD.

It becomes EXTREMELY hard to balance the schedules and problems (there are always problems) from every field (programming, design, tools, art, sound) while keeping the focus of the game on what you originally planned. So much slips, and falls through the cracks. Ask most game developers, and we can prattle on for hours about all the cool ideas we originally had for the game, but ended up tossing out or having to dumb down, or really just skipped because of time or technology constraints (we'll put it in the sequel).

Like the parent said, the actual guts of making the game (coding AI or collision, modelling and texturing the world, animating characters, blah blah blah) is basically easy, especially when you hire smart people who've done it before.

My personal opinion being that the biggest hurdle is interdependancy. Artists can't make the best art without complete tools. Tools programmers can't make feature rich tools without knowing every capability of the engine. The designers can't code interesting scenarios or gameplay without a final scripting language. The programmers are usually all spread thin writing essential low-level stuff, by the time they get to polishing the stuff everyone's waiting on, the project is halfway over.

A wise coworker of mine once told me, "The secret to game development is this: Every game actually gets made 6-8 months before release. Everything before then is either thrown out, or redone." And for the most part, he's been right. :)

-another Anonymous lurking game developer

A dream far away from here... (5, Interesting)

KamuZ (127113) | more than 10 years ago | (#8419534)

Yeah, games were easy to make ten years aog, i coded a few but it was a "code" challenge, now it's different, most of the time someone built a nice engine and everyone make content for it, that's why many studios just focus on design, don't get me wrong, design it's important but programmers don't qualify often for game industry unless you want to built something new, something that is not a goal for many companies.

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.. (5, Interesting)

Xzzy (111297) | more than 10 years ago | (#8419540)

One thing I've noticed with a lot of open source game-directed projects is that they feed off each other as needed.

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.. (2, Interesting)

foofoodog (552812) | more than 10 years ago | (#8419592)

I guess it is hard to code a game engine but I get the impression that most of the maps and some of the total conversion mods are done by small teams and some end up being much better overall than the original.

Re:OSS seems to help with this.. (4, Interesting)

sirsnork (530512) | more than 10 years ago | (#8419643)

So game developers (the companies) are moaning that there isn't enough knowledge in the industry of all the ways to use every concept, fragment of code or method, and yet the easiest way to get people more knowledgable would be to open source all of the older games so others can learn from your past experiences.

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.. (0)

Anonymous Coward | more than 10 years ago | (#8419656)

Every technology you need to make the next jaw droping game is available in OSS. It's the craftmanship which most amature attempts fail on, but that's changing with the advent of open content.

-ddn

Re:OSS seems to help with this.. (4, Interesting)

Mr. Piddle (567882) | more than 10 years ago | (#8419708)

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.

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.

Flash to the rescue (5, Interesting)

hehman (448117) | more than 10 years ago | (#8419541)

Flash is a bad word for some folks here, but it really excels as a platform for simple, addictive, and fun games that can be easily spread to the world.

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,

Re:Flash to the rescue (1)

Mr. Piddle (567882) | more than 10 years ago | (#8419721)

It's arguably easier to write, say, King's Quest now than it would have been 20 years ago,

Yes, but King's Quest didn't require a 1GHz CPU and 100MB of RAM to run smoothly. Between Flash-based ads and those crappy chain e-mails from friends, my CPU is really getting tired.

Re:Flash to the rescue (1)

sineltor (312152) | more than 10 years ago | (#8419802)

True.

Its also unarguably harder to write UT2004 in flash than it is in C/C++

Some things may be nice and elegant but at 1280x1024 boring 2d vector graphics lag in flash. For commercial games (which is what the article was referring to) this just isn't an option.

Sure, it's complex if you're copying complexity (5, Insightful)

MooseByte (751829) | more than 10 years ago | (#8419546)


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 (5, Interesting)

urantia007 (707091) | more than 10 years ago | (#8419550)

what needs to happen, is we need a complete game enviroment to creat games, not just a game engine, but a complete piece of software that doesn't need any programming at all. think of using maya to do all your 3d models and animations and worlds for the game, and instead of exporting these out to an engine you keep it all under one roof, give the models properties like colision, key bindings to play this animation when this key is pressed in this direction etc. Of course programming should be en extensible part of it to add funtionality that might not be in it. so essentially a 3d applicaiton with a game engine at it's heart containing everything you would need to make a game. This could be done right now with directX9. The single man band could be back if this happened.

Re:what the industry needs (1)

BigZaphod (12942) | more than 10 years ago | (#8419641)

While I don't have all these features implemented or anything, this is kind of what I'm going for in my JiggleScript [jigglescript.com] project (which is very early development, of course). Check it out if you're into this sort of thing. :-)

Re:what the industry needs (3, Informative)

Pvt_Waldo (459439) | more than 10 years ago | (#8419658)

You're part way there if you go with Valve's Half-Life. Full SDK that allows you to create maps, models, etc. and a ton of public domain tools for sprites and textures. Also there are some neat extensions such as the Spirit of Half-Life [valve-erc.com] mod which gives you a ton of nifty extensions.

The main place you have to code to create the game is if you choose to extend the game entities for maps, do new weapons, etc. But since Valve gives you the source for the code that does their standard weapons, it's not unreasonable to take their code and extend it.

Re:what the industry needs (1)

Mr. Piddle (567882) | more than 10 years ago | (#8419731)

a complete piece of software that doesn't need any programming at all

Between Blender and Gimp, I think this is in our future.

Re:what the industry needs (1, Informative)

Anonymous Coward | more than 10 years ago | (#8419787)

Lemme see, you want 3D modelling, animation control and editing, object interactivity and dynamics, an API for gaming logic and a simple but effective scripting language to tie it together. You didn't ask, but I'm guessing you'll also want some audio tools to go.
I'll ignore the crack about DX9, because I know you really wanted a cross-platform tool that'll work with Linux, Mac, Windows, BSD and a bunch of others.

So here you go sir, here's your tool

http://www.blender3d.com/About/?sub=Features

Now did you want fries with that?

Re:what the industry needs (1)

gl4ss (559668) | more than 10 years ago | (#8419815)

all the 'biggest' games seem to be built with such 'engines' anyways(quake/unreal style engines with their own scripting languages that can be used to make the engine run quite a different type of a 'game').

the problem is of course that in order to have the latest whizbang on them you need to have somebody bringing the engine up-to-date or else the game will for most parts look like it's old.

Can see where he's coming from... (4, Insightful)

Phil John (576633) | more than 10 years ago | (#8419558)

...have any of you seen the demo video of the upcoming Half-life 2 (or even *gasp* downloaded a leaked beta), I was watching in amazement wondering how games had come so far in such a little time.

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:Can see where he's coming from... (1)

c_oflynn (649487) | more than 10 years ago | (#8419805)

Don't worry - by the time it comes out it will probably be equivilent to every other game...

Design Patterns? (4, Informative)

BenjyD (316700) | more than 10 years ago | (#8419584)

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

Come on, Design Patterns [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... (4, Insightful)

TwoBit (515585) | more than 10 years ago | (#8419727)

First of all, any change whatsoever in header files trigger rebuilds, not just public interfaces. Secondly, core headers in theory would perhaps be fixed early on, but in practice that's just plain impossible. I can spend a lot of time here trying to explain how that comes about, but it's not worth the effort unless this message got a decent score. Suffice it to say that it's simply impossible to see into the future and know exactly how any header file really needs to be when it's finished.

Re:Design Patterns? (0)

Anonymous Coward | more than 10 years ago | (#8419739)

Shouldn't the public interfaces to external classes for a module be fixed pretty early on, if not at design time?

I don't think you understand software development very well. It's not a linear process: design...build...ship. On anything but the smallest project, it's impossible to completely specify the interfaces early on. As code is written, new requirements will inevitably emerge, necessitating interface changes. Also, note that in C++, private variables are part of the class definition that resides in the header file. So even a change to a non-public part of a class could kick of a wave of (unnecessary) recompiles.

Re:Design Patterns? (1)

BenjyD (316700) | more than 10 years ago | (#8419780)

So even a change to a non-public part of a class could kick of a wave of (unnecessary) recompiles.

That's why you use interface classes and derive implementation classes from them. Change the implementation class and nothing that calls it needs to be recompiled - all they see is the interface class. For most things apart from really tight loops, which will probably be hidden inside the rendering classes anyway, virtual function calls aren't too much overhead.

Re:Design Patterns? (1)

CdnZero (318885) | more than 10 years ago | (#8419748)

Oh but it isn't quite that easy or obvious. Remember that using OOP and/or Design Patterns both impose performance penalties.

Modern games attempt to wring the greatest number of fps using even assembler at times to increase code performance. You are right that for all but the 3D, shoot em up, multiplayer madness a lot would change with better OOP/Patterns. But like most blanket statments, it won't help everyone.

Re:Design Patterns? (1)

AuMatar (183847) | more than 10 years ago | (#8419773)

If you've ever developed a code base with a couple hundred thousand or million lines of code, you'd know that it never works out quite cleanly. You end up needing to add parameters to functions, or change their types, or add new functions to meet problems in the middle.

What thhey should have is a build system that allows them to compile only part of the code at a time, and link it against the previous compilation of the rest of the codebase. This is what I have at work- the entire codebase takes several hours to compile, but a single module can be compileld at a time, inn anywhere from 1-5 minutes, with another 2 or so to link.

Re:Design Patterns? (1)

edwdig (47888) | more than 10 years ago | (#8419789)

The comment was on compile time when a major header is changed. Things like if someone at Microsoft needs to make a change to windows.h, that's going to cause everyone to have to do a lot of recompiling. You can't avoid that.

Re:Design Patterns? (1)

AuMatar (183847) | more than 10 years ago | (#8419832)

Hey, I basically agreed with that. Although you can avoid things like windows.h, which is a huge clusterfuck. Make multiple header files, each dealing with a specific area of the code, instead of one giant mega-file.

Re:Design Patterns? (2, Informative)

VultureMN (116540) | more than 10 years ago | (#8419857)

For C++, you gotta recompile even if the interface doesn't change. Since a lot of compile-time linking is done (as opposed to all-run-time linking in Java) any changes to classes require recompilation/relinking. Or else all the offsets are wrong and KABLAMMOSegmentation Fault

new technology, designers, engineers... (5, Funny)

nuckin futs (574289) | more than 10 years ago | (#8419590)

and the most popular game on the PC is still solitaire!
:-P

Re:new technology, designers, engineers... (0)

Anonymous Coward | more than 10 years ago | (#8419769)

MINESWEEPER FOREVER!!!

Full Sail! (5, Informative)

Zoko Siman (585929) | more than 10 years ago | (#8419602)

Here in florida we have a college, Full Sail [fullsail.edu] , it specializez in entertainment industry stuff. Such as: game design and devolpment. It's good to know we have a place that specializes in making the people that are required if world of gaming is to be continued.

Re:Full Sail! (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8419651)

Full Sail seems to have a pretty nasty reputation. I'd have said people would be better off with a normal degree and some mod experience.

Of course, I can't get a games job, so feel free to ignore me...

Re:Full Sail! (0)

Anonymous Coward | more than 10 years ago | (#8419846)

Ditto: Full Sail is a profit driven diploma farm.

Harder than you think? (2, Funny)

Anonymous Coward | more than 10 years ago | (#8419608)

Obviously. New games these days are frickin' huge and increasingly sophisticated, and they have to be to compete with the OLD games. It comes as no surprise that they are harder to create.

Re:Harder than you think? (1)

TwoBit (515585) | more than 10 years ago | (#8419742)

The above message is scored as "funny" and while it may seem funny, it's entirely true. Why else do laundry detergent makers put "new and improved" stickers on their boxes every few months?

Lua (5, Interesting)

truth_revealed (593493) | more than 10 years ago | (#8419621)

Lua [lua.org] is the embedded interpreted language of choice for game designers. Lua's great for writing the game AI (you don't have to wait for a half hour C++ build). Lua's under 200K, threadsafe, has good OO abstractions, integrates with C very easily, and most important of all - it has a commercial friendly license [lua.org] .

Re:Lua (1)

MaestroSartori (146297) | more than 10 years ago | (#8419693)

Yes, Lua makes things like this, and separating game flow and logic from the guts of the game engine, much easier to sketch out.

It is also a huge pain in the ass to debug heavily-scripted games. We've reached the stage in the game I'm working on just now that AI coding is being moved back into C from Lua just so it can be more easily debugged...

Re:Lua (0)

Anonymous Coward | more than 10 years ago | (#8419766)

It is also a huge pain in the ass to debug heavily-scripted games.

I'd have to agree with you. I see Lua as more of a very high level prototyping tool. If your scripts become too complex it's usually a sign that much of the functionality belongs in the C++ core - and then it can be wrapped and called from Lua again :-)

Re:Lua (1)

truth_revealed (593493) | more than 10 years ago | (#8419709)

A Lua session in the Game Developers Conference in San Jose March 22-26, 2004... Lua in the Gaming Industry [cmpevents.com]

Another sad thing (5, Interesting)

Monkelectric (546685) | more than 10 years ago | (#8419684)

Game development has become so complex that there really is no hope for a small team or a startup to make a decent game.

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 (3, Informative)

Perianwyr Stormcrow (157913) | more than 10 years ago | (#8419821)

Even if you make the game in such a manner as not to be "professional", you may still have a winner of a game. Stuff written in Flash is very easy to do yet brings out remarkable results.

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

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

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

Article, addless in full (1, Informative)

Anonymous Coward | more than 10 years ago | (#8419685)

Ten or twenty years ago it was all fun and games. Now it's blood, sweat, and code. Project Size and Complexity The hardest part of making a game has always been the engineering. In times past, game engineering was mainly about low-level optimization--writing code that would run quickly on the target computer, leveraging clever little tricks whenever possible. But in the past ten years, games have ballooned in complexity. Now the primary technical challenge is simply getting the code to work to produce an end result that bears some semblance to the desired functionality. To the extent that we optimize, we are usually concerned with high-level algorithmic choices. There's such a wide variety of algorithms to know about, so much experience required to implement them in a useful way, and so much work overall that just needs to be done, that we have a perpetual shortage of qualified people in the industry. Making a game today is a very different experience than it was even in 1994. Certainly, it's more difficult. In order to talk about specifics, I've classified the difficulties into two categories: problems due to overall project size and complexity and problems due to highly domain-specific requirements. Though this will help me introduce the situation in stages, the distinction between the two categories is a bit artificial; we will come full-circle at the end, seeing that there are fundamental domain-specific reasons (problems due to highly domain-specific requirements) why we should expect that games are among the most complicated kinds of software we should expect to see (problems due to overall project size), and why we should not expect this to change for the foreseeable future. PROJECT SIZE AND COMPLEXITY To illustrate the growth of games over the past decade, I've chosen four examples of games and drawn graphs of them. Each node in a graph represents a major area of functionality, and the arcs represent knowledge couplings between modules. Two nodes with an arc between them need to communicate heavily, so design decisions made in one node will propagate through its neighbors. Figure 1 depicts a 2D game from the early 1990s, perhaps a side-scrolling action game for a home console, like Super Metroid. Other genres of game would have slightly different diagrams, for example, a turn-based strategy game like Civilization would gain a node for computer-opponent AI (artificial intelligence), but would lose the node for fast graphics. Certainly Super Metroid itself also has computer opponents, but their behavior is simple enough that it doesn't warrant an extra node; instead the enemy control code is lumped in with "main/misc." By 1996, 3D games had become a large portion of the game industry's output. Figure 2 shows an early 3D game, for example, Mechwarrior 2. Contrast this with figure 3, a modern single-player game. The largest endeavor we currently attempt is the 3D massively multiplayer game (MMG), illustrated in figure 4. Everquest is the canonical first example of a 3D MMG, though a more up-to-date example would be The Matrix Online (expected release in 2004). Contrasting figure 4 to figure 1 should give you a general sense of how the situation has changed. The arcs in these figures assume that code has been ideally factored, but since this is never the case, real-life situations will be more tangled. Keep in mind that each node in these graphs is itself a complex system of many algorithms working together, and that each of these nodes represents somewhere between six thousand and 40 thousand lines of source code. There's another category of game, the non-massively multiplayer client/server game, which tends to house a smaller number of players at once (perhaps 50) and does not maintain a persistent world. The diagram for one of those would be somewhere between figure 3 and figure 4. Tools Tools. To tackle such complexity, it helps to have excellent development tools. Sadly, we do not have excellent development tools. For programming on PCs, we use a compiler development environment like Microsoft Visual Studio, which is basically a wrapper around their C++ compiler; most games now are written primarily in C++. Clearly, we are not the target market Microsoft has in mind. Visual Studio seems to be aimed heavily at developers of Visual Basic and C# applications, and to the extent it caters to C++, it's meant for applications that make heavy use of COM objects and create many windows with variegated UI elements. We do very little of that stuff in modern games. We would much rather have that manpower spent to make the system compile programs quickly, or generate efficient code, or produce reasonable error messages for code that uses C++ templates. Even so, Visual C++ is the best compiler we have on PCs--with no competitive alternatives--so we're just sort of along for the ride. On consoles, the console maker as well as one or two third-party companies will provide some development tools (compiler, debugger, profiler, etc.). Console life cycles, however, are about five years long, and there isn't much motivation for the tool-maker to improve their products toward the end of that cycle. Typically, a console developer will be using an environment with only one to four years of maturity--not an enviable situation. To build game content like 3D meshes and animations, we use programs like Maya or 3D Studio MAX. However, these programs were originally created for people who make non-realtime animations (like the graphics rendering for feature films), so they present a poor fit. Lately, as games have become a bigger business, the makers of these tools have begun to pay more attention to us, to the point that they put "games" at the top of the list of their products' relevance. But these tools are so deeply rooted in the "wrong area," and so big and slow to change, that they still represent something very different from what we really need. For example, most game studios would benefit from the ability to build large continuous 3D world meshes, with multiple artists working on the same mesh at once--or methods of editing triangular meshes to ensure that cracks and holes do not appear. This would be much more interesting to us than much of the functionality these vendors develop and tout, such as sophisticated cloth simulation (useful to us only for pre-rendered cinematics, which are becoming increasingly rare in games). Thus we need to augment these content packages with our own plugins and post-processing tools, which will in general be poorly integrated and feature-starved, and may present robustness problems. Sometimes, for building the geometry of the world, we just write our own domain-specific editors from scratch (Worldcraft and UnrealEd are examples of this). Historically, the situation with regard to asset management tools has also been poor. A modern game studio needs a fast and robust system for networked revision control of source code, 3D models, animations, sound effects, and all the other various data files involved in a game. Lately, some companies have risen to provide asset control specifically for game projects. These tools are still far from ideal, but we have reason to hope that they will improve. Workflow and Multiplatform Development Workflow. We also have a lot of workflow problems that are not so directly tied to specific tool software. On the programming side, our compile/edit/debug cycles are usually far too long. Many games take half an hour or longer to compile when starting from scratch, or when a major C++ header file is changed. Even smaller changes, causing a minimal amount of recompilation and relinking, can take as long as two minutes. In general, C++ seems to encourage long build times. Once the build time has grown too long, a team may end up putting a significant amount of work into refactoring their source code to make it build more quickly. Often this happens too late, as the spaghetti of file dependencies has become so severe that fully refactoring it would be akin to restructuring the project from scratch. In fact, the best way to avoid long build times is to architect the entire code base to minimize dependencies (sometimes giving up runtime efficiency in the process!). This does not happen too often because many studios do not take these workflow issues as seriously as they ought to as the effect of the problem is somewhat intangible, and there are always so many clear and present issues to deal with--or they don't have sufficient discipline to deal with such a subtle issue over periods of time measured in years. Another way to attack the build problem is to use a third-party tool to distribute compiles across many machines (one such product is Incredibuild). These tools can help significantly but they are not cure-all solutions. Once the game is compiled, we must run it and test our changes. However, startup times can be very long, since games often need to load large amounts of data. Startup time can typically be three minutes for a debug build with large data files for which load-time optimization has not been done. Add this to the compile-and-link time, and you can easily have a five-minute delay between making the smallest possible code change and seeing the new version of the game running. Testing the actual change will take longer as the programmer needs to set up the proper conditions within the game world to exercise that code path. Visual C++ provides an "edit and continue" feature wherein one may splice code changes into a running program and avoid these delays. However, this feature doesn't work reliably enough to eliminate the problem (though when it does work, it is very welcome). This feature is not usually present in the compiler environments for console systems. Another way to avoid this turnaround time is to write a significant amount of your code in a higher-level extension language that can be dynamically reloaded by the game engine without restarting. (For more on this, see Andrew M. Phelps and David M. Parks' "Fun and Games with Multi-Language Development" on page 46 of this issue.) There's an analogous issue for the content development parts of the team with regard to how long it takes them to see the effect of changing a texture or model. Fortunately this problem is easier to solve; as loading these assets is handled entirely by our game engines, we are empowered to fix the situation. Currently, some game engines written by experienced developers provide automatic reload of content resources at runtime, which is becoming a more widespread trend. Jamie Fristrom1,2 has recently written some columns for Gamasutra3 describing these workflow issues from a manager's point of view. Multiplatform Development. Many games are developed to run on multiple systems. During development we often have to build the game for all build types (Debug, Release) for all target platforms (PC, Playstation 2, Xbox) before committing our changes to source control. Whenever this is not done, Murphy's Law nearly guarantees that small differences in header files or system behavior will cause a compile-time or runtime error, disrupting the work of the rest of the programming team--a bad situation. So before a programmer can check in a batch of changes, they may need to perform between two and five full recompiles (which, as we mentioned earlier, sometimes take half an hour each!). The programmer can easily be waiting for hours, so there's a strong motivation to check in code changes as infrequently as possible. But they can't wait too long, or the code will drift too far out of sync from the official version, causing headaches when it comes time to merge. As in large business projects, bigger game teams tend to have a "build master," a person whose job is to watch over the build, ensuring that disruptions are remedied as quickly as possible. Sometimes pleasing the build master can be a difficult task. Yet despite the presence of a build master, builds still seem to be broken too often. The result of all this is that, too often, a game programmer can't just sit down and get work done; there are significant barriers to push through. Third-Party Components. There are many nodes in figures 3 and 4 (see my discussion of highly domain-specific requirements in this article below). We ought to be able to leverage third-party products for some of those boxes in order to reduce our workload. Licensable third-party modules exist for some of those nodes. Depending on the nature of the task, however, some of these products have been more successful than others at meeting industry needs. Available products cover these areas: audio, low-level (products have been very successful); rendering, low-level (very successful); rendering, scene management (mixed success); collision detection and physics (only somewhat successful, but it's very hard to write these systems on your own, so there's a significant win for third-party tools here); networking, low-level (slightly successful, could be better but nobody has come to market with the right products); skeletal animation and morph targets (very successful); persistent object storage (mixed success); and scripting languages (mixed success). Most notably, no useful products for AI functionality exist, though there have been a few misguided attempts. Because games are complicated and require deep technical knowledge (again, see my discussion of highly domain-specific requirements below.), it can be difficult just to use these third-party components; often the programmer must have a lot of experience in the problem domain in order to understand how to interface with the product successfully. Even if this is the case, the programmer still may face great difficulties in integrating the third-party module with the rest of the game. Most of these modules were themselves technically challenging to create, so they tend to be less than perfect. Often the API (application program interface) is difficult to deal with because it embodies some conceptual model that is a poor fit for the way your game needs to work. Thick glue layers are usually necessary between the main game code and the third-party API. Application program interfaces for rendering or physics often want data organized in very specific ways, a situation that propagates through the rest of the program and imposes difficult constraints (because a lot of data needs to be passed back and forth, we can't just convert the data between formats at function call time as that would be too slow). And since games are so CPU-intensive, it will often happen that the third-party component presents a significant performance bottleneck for some input scenarios--and the programmer must fix these situations or work around them. Often when third-party code fails, it's because the problem it solves is insufficiently large; for the amount of work the development team spends to make the code succeed, they might as well have written the module from scratch--something you certainly don't want to find out after failing with the licensed code. The decision to license third-party code should always be preceded by a careful cost/benefit analysis as there's no guarantee that the product will actually hasten your development. Full-Figure Option.Instead of licensing components, we can license an entire game engine from a company that has successfully built a solid one (see my discussion of highly domain-specific requirements in this article). It's more difficult to build a licensable engine than it is just to make a game, so there are not many of these to reasonably choose from. Some recent examples are the Quake 3 engine and the Unreal engine. The cost of such a license tends to be high, perhaps $300 thousand to $600 thousand per retail SKU (stock keeping unit). If you're trying to make a game that is not doing anything new technologically, such a license can be a safe decision. But if you're trying to be technologically expansive, you will probably run into the poor-fit problems mentioned earlier, but on a larger scale this time--you might find yourself spending $500 thousand for code that you end up largely rewriting, disabling, or working around. (Even so, it's possible for this to be money well spent because having the engine gives you a kick-start that's sometimes better than starting with nothing.) Both of the aforementioned engines come from the genre of first-person shooters (FPSs), which is the area where the finest-honed game technology has flourished. For games that are very different from an FPS, you may have a difficult time finding a serviceable engine. There are no market-proven engines for MMGs. I've discussed a host of tool-related problems that cause difficulty in developing games today. These issues will be slow to change. With better tools and workflow, we will be able to make better games, raising the level of game complexity and functionality that we can handle. However, games will not actually become easier to make because the difficulty of creating a game will always expand until it exceeds our implementation abilities. The next section on the challenges of highly domain-specific requirements will discuss why this is so. Highly Domain-Specific Requirements Currently there are three levels of programming in games: script code, gameplay code, and engine code. Script and gameplay code control the overall content, rules, and high-level behavior of the game. For the remainder of this article I will treat them as one concept and just refer to "gameplay code." Sitting below gameplay code is the engine, which provides all the basic mechanisms for simulation and I/O. Engine code is much more difficult to write than gameplay code, first because it requires advanced knowledge, and also because it must be held to more stringent quality and performance standards. Engine Code. Certainly, to write good engine code, you need to have a good grasp of software engineering. But also, there's a lot of domain-specific knowledge required. This can be roughly broken into two categories, mathematical knowledge and algorithmic knowledge. Mathematical knowledge. A programmer just isn't going to be competent in a modern game without a decent grasp of basic linear algebra,4 as well as geometry in 2D and 3D. We often use 4D representations for basic operations (4D homogeneous coordinates for general linear transformations, and the quaternions to represent rotations5) so the ability to reason about higher dimensions is extremely useful. Basic calculus is necessary for all kinds of simulation and rendering tasks. For many rendering tasks, signal-processing mathematics is very important--both linear signal processing6 as well as the murkier study of spherical harmonics.7 For any kind of sophisticated simulation, you'll want experience with numerical analysis and differential forms. For networking, information theory and the statistics behind compression and cryptography are necessary to build a robust system. Algorithmic knowledge.A good engine programmer should have working familiarity with a great many algorithms--so many that attempting to list them here would be silly. The most necessary algorithms perform tasks like spatial partitioning, clustering, and intersection and clipping of geometric primitives. Most algorithms will be mainly focused on one task area, like rendering or physics, but these algorithms are often very deep and take a while to master. For years we have been mining academic research to find and modify appropriate algorithms. However, a game engine must meet soft realtime requirements, and most academic work in the relevant subject areas is geared toward batch computation. (Most of the past research in graphics has applied to offline cinematic rendering. Most physics algorithms are unstable and can fail outright, which is solved in a batch setting by tweaking the initial conditions and trying again. These algorithms do not adapt successfully to a soft realtime setting.) As games are now starting to be taken seriously by the academic community, this is beginning to change, but most academic research is still pointed in directions that don't do us much good. So, creating a technically ambitious game engine will often require a substantial amount of original research. Engine programmers don't necessarily need a deep understanding of all the aforementioned departments of mathematics and algorithms. But because they're working in such a tightly coupled system, even if a concept doesn't arise directly within the module they're working on, it may significantly affect their work by propagating through a neighbor. So engine programmers will need light-to-medium knowledge of most of these subjects in order to get work done, and should be adaptable enough to learn the others as need arises. Crosscutting Concerns. To successfully build a game engine, it's not enough to understand a lot of math and algorithms. When you put many algorithms together into a tightly coupled system, constraints imposed by the various algorithms will clash. It takes a certain experience and wisdom to choose or discover algorithms that can be combined into a harmonious whole. When game engines fail, it's often because they don't achieve that harmony. Each of the nodes in figures 3 and 4 represents a complex system full of crosscutting concerns. Also, many of those nodes represent cuts across the majority of the system's conceptual space. Currently we do not have programming paradigms that help us address this fundamental structural problem. (Some new fruits of language research, like aspect-oriented programming, are journeying into that area, but none of them are currently practical for production use.) Depth of Simulation, Profiling, and Risk Depth of Simulation. Game code is inherently about simulating some kind of world. In early games, the simulations were simple and primitive. For a while we focused mainly on graphics, which is a simulation of how light behaves in the game world. But now we are entering a time when the portions of the simulation governing physics and AI can be more important to the end user's quality of experience than the graphics. Since generalized AI is such an unsolved problem, nobody knows what it will look like in the future. Physics, though, we have some grasp of. Working on physics has educated us about some issues that can be generalized as pertaining to all manner of simulated time-evolving complex systems. Simulating a complex system generally involves integrating quantities over time using numerical methods. At a low level, therefore, quantities must be specified in an integrable way. Functions containing arbitrary discontinuities are very difficult to numerically integrate, but these are also the kinds of functions that computers make by default. (If/then statements create discontinuities unless we make explicit effort that they do otherwise; thus we must be careful with if/then statements when working on low-level simulation!) To help keep things integrable, significant world events, including AI decisions, need to occur at a level higher than the basic integrator; that is, they aren't allowed to just kick in without warning and change the state of the world. Once we have done all this, we need to worry about stiffness--the fact that merely by adjusting constants, you can cause the simulation to become unstable. To the best of our current methods, good integration techniques can only provide an area of stability within the simulation space; you must take care not to step outside that area. We then need to worry about tunneling, which happens when we integrate across a timestep that's too long, causing us to miss a significant world event. The term "tunneling" comes from collision detection, where we move entities essentially by teleporting them small distances through space; if we move an entity too quickly, it may pass through a solid object like a wall, unless we take extra steps to detect that situation. These extra steps comprise an approximation to "what really should have happened," which may result in consistency problems. Interesting simulations inherently involve subtle interactions between many different entities, an n2 problem that doesn't really want to be solved in real time. To work around this issue, we need to be good at culling negligible interactions to pare down the size of the problem. But such culling tends to involve black-art heuristics and can go wrong in strange and subtle ways. Profiling.We're always trying to push the CPU as far as we can, so profiling is very important. Unfortunately, there are no good profilers for games. Games exhibit heavily modal behavior based on dynamic conditions (at one moment, sending triangles to the graphics hardware may be a performance bottleneck; the next moment, detecting collisions between game entities may be the problem.)8 To improve game performance, we need to identify these individual modes of behavior. Unfortunately, commercial profiling products inherently average the program's activity over time, which melts all these spikes into an indistinct mush, hiding the problems. Usually, we build our own simple profiling systems into our games. Though useful, it's not like having a mature profiling tool. Vendors of graphics hardware, like ATI and NVIDIA, make some graphics-specific profiling tools, as do the makers of some game consoles. Those tools are also helpful but generally insufficient to get a bird's eye view of the system. Risk.Computer games have always evolved toward increased technical complexity to give the players things they have never experienced before. As a result, each wave of games is attempting several technical feats that are mysterious and unproven. Thus game developers carry a lot of technical risk (you can't accurately schedule the unknown or predict how it will interact with the rest of the system) as well as game design risk (how will this never-implemented feature feel to the end user? Is it going to be worth all this trouble we are taking to implement it?). CONCLUSION Games are hard. This article has tried to present a broad summary of the reasons why; though many relevant factors have been omitted in order to keep the explanations short. Rather than being discouraging, the challenge involved in making a game is a major part of the reason so many smart people are drawn to the field. The constant development of new methods, in combination with ever-faster computers to run them on, makes this a very interesting time.

Whoops! (2, Funny)

adamvjackson (607836) | more than 10 years ago | (#8419688)

Anyone else read the headline as "Anatomy of Game Developers" ?

I always knew they were put together differently!!

Especially those Running with Sissors guys!!

Meh (4, Interesting)

KalvinB (205500) | more than 10 years ago | (#8419704)

There's still a market for the simpler games. Cell phone games are big. The Game Boy Advance is big and anyone can code for it. Distribution is another matter but there's nothing stopping developers from creating a product to get their feet wet. Worst case you make it a pay per download or give it away free as an ad for your PC games.

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

Only reveals the limits of closed source (1, Funny)

GEEK CRUSHER 5000 (755251) | more than 10 years ago | (#8419718)

Clearly the OSS community can do better than this "Final Fantasy" or "Quake" pap, just look at Tux Racer, and Nethack, and FreeCiv, and the BSD games package!

Or perhaps none are willing to do the hours.... (5, Informative)

Anonymous Coward | more than 10 years ago | (#8419723)

I worked in the games biz for 3 years in QA and production, and finally with a hiring team for engineers in our company. Let me tell you, coders in the games industry are payed jack, and work like mad. Most times, the average work week is anywhere from 80-95 hours for the coding team. I personally got out of the industry because of this. I don't think there are a lack of talented people to do it, just there are not enough people willing to put 80 hours a week in to a game for circa 40-50k, w/no OT.

Oh come off it... (5, Interesting)

spray_john (466650) | more than 10 years ago | (#8419729)

I'm tired of this, I really am. When will guys like this admit that everyone else works for a living too? No, games are not always very simple. Thanks buddy, we know.

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.

HL2 delay tactic (4, Funny)

d_i_r_t_y (156112) | more than 10 years ago | (#8419760)

is this article written by the half-life2 people to attempt to justify another 6 month wait? i wanna play it now damnit!

You could try the Guildhall (2, Informative)

Anonymous Coward | more than 10 years ago | (#8419770)

There is a school in Dallas called the Guildhall [smu.edu] . They focus on Game Design, Software Development and Art Creation.

Old Interactive Basic Game, one line of code (4, Interesting)

RichMan (8097) | more than 10 years ago | (#8419796)

Here is an interactive game in one line of basic code (ok 4 statements, but you could write it in one basic numbered statement). Just showing what could be done with minimal code.

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

Oh no! (1)

xihr (556141) | more than 10 years ago | (#8419798)

You mean game programmers actually have to behave like professional programmers and learn about algorithms and data structures and computer science instead of doing a constant stream of half-assed hacks? God forbid!

FaIlz0rs (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8419813)

from withbin. are tied up in reciprocating Already dead. It is From a technical obligated to care hand...don't

Outsource (0)

crawdaddy (344241) | more than 10 years ago | (#8419824)

Top reason against (for?) outsourcing: "All your base are belong to us."

On a side note, this is my second Zero-Wing joke in one afternoon...I'm starting to feel very dirty. Maybe I should try something different:

In Soviet Russia, the programs develop YOU!
(that works on +funny AND +interesting levels!)

Tasogare (0, Redundant)

Luke-Jr (574047) | more than 10 years ago | (#8419827)

The goals of my project Tasogare [sf.net] (which will probably begin development sometime in the next year when higher-priority projects are complete) would for the most part allow the designers themselves to create the games since it would have most of the code all implemented in a way that isn't specific to any single game.

P.S. If any other game developers want to help out, let me know. This project is too large for just a few people.

The complexities of modern software development (5, Interesting)

Anonymous Coward | more than 10 years ago | (#8419843)

The author needs to get a grip. Hardly anything he has written is specific to game development. Sounds like a programmer struggling with the realities of any complex software development project.

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>