Slashdot Mirror
Anatomy of Game Development
CowboyRobot writes "ACM Queue has an article titled Game Development: Harder Than You Think that looks at the complexities of creating a modern game, in comparison with the relative simplicity of doing so ten years ago.
My understanding of the industry is that they have too many designers and not enough programmers. From the article: 'Now the primary technical challenge is simply getting the code to work to produce an end result that bears some semblance to the desired functionality... There's such a wide variety of algorithms to know about, so much experience required to implement them in a useful way, and so much work overall that just needs to be done, that we have a perpetual shortage of qualified people in the industry.'"
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.
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.
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
Post apocalyptic gaming goodness
Too many cooks spoil the broth.
Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 Page 7
Or is the author of this article really called Joe Blow?
Nice pen name
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.
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.
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.
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,
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 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.
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.
and the most popular game on the PC is still solitaire!
:-P
Here in florida we have a college, Full Sail, it specializez in entertainment industry stuff. Such as: game design and devolpment. It's good to know we have a place that specializes in making the people that are required if world of gaming is to be continued.
Lua 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.
Outsourced games.. ewww.
You come across Wumpus!
What you do?
> Shoot Wumpus
Wumpus die.
the hard part is that too usually the designers don't seem to have been playing any games at all, ever! the biggest errors usually are all just about game design(and being designed to be something more than what the execution is able to grasp).
imho what they should do is that they should bring in an outsider(always a different one!) in once a month to take a look at what they got going on and tell them bluntly if it doesn't make any sense or is stupid, frustrating or otherwise sucking(inside testers are too involved, and can't see if something 'just sucks' because they've seen it from the ground up or are afraid to say that it sucks). it often looks that the developers have gotten 'blind' from being too close to the project(and as such the end product ends up having some stupid shit that could have easily been fixed, like lacking keyboard configuration, having frustrating controls, bad camera view and so on).
"not being able to see the forest because the trees are blocking the view"
world was created 5 seconds before this post as it is.
I 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.
Religion is a gateway psychosis. -- Dave Foley
"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.
Vote in November. You won't regret it.
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
This Space Intentionally Left Blank
I worked in the games biz for 3 years in QA and production, and finally with a hiring team for engineers in our company. Let me tell you, coders in the games industry are payed jack, and work like mad. Most times, the average work week is anywhere from 80-95 hours for the coding team. I personally got out of the industry because of this. I don't think there are a lack of talented people to do it, just there are not enough people willing to put 80 hours a week in to a game for circa 40-50k, w/no OT.
I'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.
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.
You need a FREE iPod Nano
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.
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.
As the author of this article I will throw a couple of cents in.
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.
Although I'm a programmer, I've spent time learning GIMP, blender, Sodopi (and a load of applications from other skill domains) - when no one is regulating your use of software, you're free to teach yourself what ever you want.
...free software is the way the world *should* work
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.)
Please help publicise swpat.org - the software patents wiki
(I wrote the article).
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).
(I wrote the article).
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."
Yeah. This is a problem, but it's actually one that the industry is aware of.
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!
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.
Besides this, many people have ideas that have already been thought of but weren't done because they just aren't feasible to do or don't add to the fun in any way.
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.
"But I trust in the people's capacity for reflection, rage and rebellion." -Oscar Olivera
I work in the industry. You can read some of my earlier slashdot posts to see where exactly I work.
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...
You should never take life too seriously - You'll never get out of it alive.
It is hard to compare games by time it takes to play them. I spend large amounts of money on great (to me at least) arcade games and I really only like arcade games. How many hours of gameplay do you consider Galaga to have for example? 2 minutes? 1000 hours? Does it matter if it is a great game? The replay value in great arcade games is priceless. I have found in the majority (not all) of 3D games of the last few years, they have almost zero replay value. Why pay for a game you are only going to play once or twice? I am sure I will get more replay value from Metal Slug 3 or R Type Final than the majority of other recent releases - garaunteed!
Every year or so I buy a game that consists of 90% 3D fluff
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.
Most game companies, despite having been in business for years, still underestimate the difficulty of the task...
Isn't that pretty much the state of the whole software industry?
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!