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.'"
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
Funny how more people have ideas for games than actually know how to write them...
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
No, really...
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
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.
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.
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.
...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.
I am NaN
Many games take half an hour or longer to compile when starting from scratch, or when a major C++ header file is changed.
Come on, Design Patterns is only $50. Surely they can afford a copy or two? Shouldn't the public interfaces to external classes for a module be fixed pretty early on, if not at design time?
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.
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.
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.
This classic work is surely a Blow job...
"If you think nobody cares if you're alive, try missing a couple of car payments." Earl Wilson
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
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
Anyone else read the headline as "Anatomy of Game Developers" ?
I always knew they were put together differently!!
Especially those Running with Sissors guys!!
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
Work Safe Porn
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!
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.
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.
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.
is this article written by the half-life2 people to attempt to justify another 6 month wait? i wanna play it now damnit!
There is a school in Dallas called the Guildhall. They focus on Game Design, Software Development and Art Creation.
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
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
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!
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.)
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
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!)
The goals of my project Tasogare (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.
Luke-Jr
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.
One of the design patterns is the 'pimpl', where most of the private members are hidden within a pointer to a separate internal class that is declared but undefined to the external world. You can then make whatever changes you want to the private members in the internal class without changing the header file and triggering those unnecessary rebuilds as long as the public interface hasn't changed. (It also keeps the size of the object constant, for places where that may be important.)
The downside is that now you have to reference all those private members through this extra pointer, which is annoying. That's why it's really only highly recommended for very widely used classes.
All of them are still pretty playable. Most flash games just last one lunch break.
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
For what it's worth, Yes, I am a professional Game Programmer.
From a programming standpoint, 20 hours of high quality game play is just as difficult as 60 hours. The bulk of the work for an additional 40 hours is done by artists and level designers creating the additional content.
And a shorter game does not aid its 'beat-ability'. It just aids its re-playability. Most 60 hour games can be beaten in 20 hours or less, typically, you just skip the side quests.
And doing a 20 hour game, but making more of them reeks of what EA does with expansion packs. Its a very shallow marketing ploy.
I would rather play one long well made game, then 1 short well made game and 4 short crappy games tossed off with the aim of turning out a profit.
END COMMUNICATION
BS. Programmers are like actors in movies. Sure they're vitally important but without the huge support group making scores, costumes, scripts, sound effects, CGI, directing, producing, and just shooting the damn thing you wont end up with much of a movie.
Just like with any modern game you'll need a soundtrack, sound effects, level design, textures, models, animations, voice-overs and a good story.
Honestly one good texture artist is worth their weight in gold. Far more than any coder but the lead at any rate.
The game development community used to take algorithms from other fields. Now they've gone beyond academia in graphics, physics simulation, and AI. Games are a tough, competitive market, and the stuff has to work, or you get trashed in reviews. That makes for real progress.
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.
Reminds me of the ads I used to see when Unix was first catching on. Entry-level pay jobs requiring 5 or 10 years of Unix experience, obviously written by HR people with no clue.
I guess Kernighan, Ritchie, Thompson, Bourne, and Plauger weren't tempted into leaving Bell Labs by the pay scale. B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
If putting together a 3D engine on a real time schedule means 50-75 core components but 5 different IDEs and 3 or 4 compilers not all the parties have to vest themselves with alike design interests. As a matter of fact to stimulate creativity and competition it should be emphasized complexity is encouraged in game development but tolerated only to a point and cut there when it gets crazy.
The point is making money from well written, well executed code and delivering it to the clients!
Every year or so I buy a game that consists of 90% 3D fluff. I just spent an hour at Dave and Busters and really enjoyed the "old" 2D interfaces because they nether helped nor hindered good games. By good game I mean something designed with regards to gameplay and not another over-done FPS maze game or cookie-cutter strategy game.
The game industry looks like the equivalant of the comic book industry in the eary 90s, lots of eye-candy, gimmick covers, etc and little substance. Seems its a technological arms race to build games that run on the newest hardware and that gameplay is the last thing on the 'to do' list.
you could write it that way.
And it rendered on, until the end of its days.
I believe there's something being worked on, over on the Blender site. Sort of a high-level communications protocal between 3D apps (tools).
I see with broadband being 30%, artist, designers, sound, and all the others working in an OSS fashion in the same country bringing games about.
Throw in OSS built libraries of code, sound, textures, and reference material. Welcome to the future of gaming.
Maybe they should open-source game development.
Then in just 8 more years we'll get OSSSSSEverQwest-0.0.97beta and it'll have real 2-d sprite graphics and stuff...
There was a time when video games were a one man process. You can read about one such programmer at the website that I maintain, The World Of Owen Rubin. Owen wrote a number of classic coin-operated arcade games while working at Atari and Sente.
"You're getting brutal, Sark. Brutal and needlessly sadistic."
"Thank you, Master Control"
-Sark and the MCP
Funny thing that pimpl when you see, say the Eclipse SWT exposing an HWND or an HDC through a public member function that the docs strenuously warn you is for internal use only, aw shucks, it really is a Windows HDC, but don't you all starting calling it because I warned ya and yer app is gonna be non-portable.
I am just waiting for Tablizer to jump in here and tells us that he has been warning us all along about this kind of thing, that objects don't probably divide up the world into natural classes and categories. Or perhaps we should all start using Dylan which has a funky way of binding functions to objects.
But if encapsulation is all about "need to know", in spycraft, you sometimes have to conduct transactions across public interfaces and resort to stuff like dead drops. Heck, even the CIA needs a front gate. There was this dimestore satire titled "Oh Henry", popular long ago when Henry Kissinger was in the news, that had his alter ego as a nebbish superspy. They had this deal where the road in Langley, Virginia leading up to you-know-where had this billboards saying "This is NOT the road to the CIA" and "Where did you ever get the idea that the CIA was over here?", lampooning the idea of keeping such undocumented by published interfaces private.
I think you're making it a little bit too easy on yourself. I've been in software development for, well, let's say a while now, starting with end-user applications over web-based and non-web based network applications to game development. Development of a 'profesional' game easily rivals large e-commerce applications as far as complexity is concerned. .NET and whatnot, specifications of proprietary file formats, encryption and security, are just some of the subjects a single software engineer may have to work on in a single large scale game project.
The reason?
Far more diverse challenges from different areas of software development come to play. Network engineering, including bandwidth, server stability and scalability issues, performance of processing large amounts of data in an unimaginable amount of different ways, compression algorithms, design and architecture of APIs, use of often many different (often poorly documented) 3rd party APIs at a time, efficient use of dedicated video, audio and other hardware, strong knowledge of human audiovisual perception, asset management, database design, knowledge of several different programming languages, scripting, SQL, SOAP, development of tools and applications using MFC,
In addition to that, any software engineer working in one or more of graphics, animation, audio, tools, to name a few, will need to have good knowledge of how the modelling, animation, audio and texture artists go about creating assets, in order to be able to make asset integration into the systems they develop, work as smoothly as possible.
Add about a teaspoon of multi-platform development (let's say, PC, XBOX, PS2, GameCube, sometimes Mac, for example).
Combine that with tight deadlines (the game industry isn't infamous for crunchtime for no reason), publisher's big wigs constantly looking over your shoulder and asking 'is it ready yet?', and dealing with (and this is the result of some people not knowing what they're doing as you stated) poorly specified requirements, and with the fact that hardware and technology in game related fields is advancing faster than anywhere else.
Stir frequently, and you have a recipe for the software development time of your life.
To summarize, in my opinion, a software engineer working on large scale interactive entertainment projects has to be far more flexible, have a higher level of self-motivation to take on problems and acquire the necessary skills and knowledge to do so, and be more team oriented and communicative than developers in other fields of software engineering.
We are not a bunch of kids hacking in hundreds of thousands of lines of spaghetti code without any consideration of software design and architecture principles, to release a game to make a quick buck. Those times are long gone.
*Gasp!!* Destructable, interactive environments! Its a revelation! A miracle of modern programming!! All hail HL2!!
..end sarcasm..
..begin rant..
..end rant..
..sorta..
Listen here whippersnapper, destructable environments are nothing new. Why, I remember, way back in... musta been ninteen hunderd and nintety four - when I played a game called XCOM. It displayed soldiers and aliens in an isometric format, and just about everything could be blown up. In fact, that was probably the thing that most contributed to how much fun that game was...
I take you back in time, for this conversation when I was viewing the game for the first time:
"They've got the door to the barn covered."
"OK, well, lets just make our own door, with this handy grenade..."
"What?"
"Yeah, kaboom, instant door."
Look, I know destructible, interactive environments in 3D games are new. (And no, the horrid piece of software called "Tresspasser" cannot be called a game, and thus does not count.) And I applaud game developers to finally getting around to it. But it isn't something that hasn't been done before. Added complexity, yes. A new age of 3D gaming? Perhaps. But I'd say a bigger advance was present in the first Half Life game - an AI that put up a decent challenge and displayed some level of realistic enemy behavior in a FPS.
All that said, good luck to the HL2 guys. I really do hope they succeed. I look forward to the day when playing first person shooters involves some level of problem solving, rather than testing reflexes with the mouse and keyboard.
// harborpirate
// Slashbots off the starboard bow!
But even with the best of intentions, best of Law of Demeter and making objects self contained, and the separation of controls into view and model, there is always an object over here that needs a value defined over there, and I just can't see how you can design systems without designing interfaces, coding to those interfaces, seeing how it works, and extending those interfaces until you feel ready to bury those interfaces in cement to make them available to a developer public.
This is closer to reality than you might think. You have OGRE for graphics. OpenDE for physics. Once there is middleware that makes it a little bit easier for the two to interoperate, we'll see more titles using them. I'm currently working on an open source driving simulator that makes use of both. These open source engines are cross platform so they have been used in commercial titles as well as for open source projects.
An interesting discussion is whether or not the middleware should be BSD, LGPL, GPL licensed or something else. The article brings up an interesting point though. In our case we could sure use a few more good C++ gurus. There is no shortage of good ideas. Check out our site and forums here if you have some time to kill and you like tough problems.
What if Digg added local news and a Slashdot inspired comment karma system? ---
http://houndwire.com
The game I am working on right now is a week before Beta. I work for a medium sized publisher of console games. Take that as warning of my bias.
I would add several reasons to why game development is hard. All the technical issues Mr. Blow mentions, can be fixed given enough time. But there is never enough time.
To keep funding $10M+ game projects, a corporation needs to release a steady stream of games during major buying periods. This means, unless you're the likes of id or Valve, development cycles are 18 months, rarely negotiable. If you are late you will start loosing consumer awarness and marketing budgets. You also need to schedule time to do several demo disks and generate assets for the media. A senior programmer said that our primary target is management, and only later the gamer.
Second, unlike many software markets, you constantly feel your competition at your heels. The graphics, realism, complexity is an arms race. This makes games better and it also makes developers stay at work extra longer past midnight to implement that extra rocket launcher effect to stand out from the competition.
Then the market judges you on purely subjective measures. You can't lock yourself into a market like MS Office or Windows would. It doesn't even matter if you are technically the most advanced. As a game developer you are fighting for gamers attention. This is why you see games that are mostly sequels and based on established IP.
Then again these challanges are the reason I'm a game developer. Mr.Blow does point out a good deal of inneficient practices in the industry.
This should be seen as a call to arms for middle ware vendors and ISVs. Whenever there is a problem there is a buisness plan!
This article is very well-written, but it only serves as evidence that the game industry still ignores standard engineering practices. 30 minutes is nothing in terms of build time, especially with a C++ project. And there are some very simple ways to reduce build time that they could be practicing right from the start instead of refactoring halfway through. I'm surprised they didn't establish such practices after their first experience with such horrific development delays.
I will agree that the cost of game developmetn is skyrocketing. The cost of developing an engine alone is more than many game houses can handle and things are not improving. It can't be too long before more third party suppliers spring up who do nothing but build game engines and design tools. In a way it's kind of silly that game houses still have to build most of their stuff from scratch.
Because the game industry has come this far, it is hard to make a game that isnt similar to another game. And if you make an original game, would it still be fun to play?
Day of the Tentacle... oh. By far the most funny game i've ever played. What happended to these? Most of the adventure games in the 'point-and-click' genre are educational, so i wish someone will think back and see the potential of these games once again.
this is probably the most boring sig in the world
-- Would it be acceptable to just put my name on my sig?
Do you guys think this is feasible, and if so, how should I go about doing this? I'm probably not the most qualified person to head this up, but I do have passion for it, so if I could find more qualified folks, and find the right sort of grants, I think it may be feasible.
Do you think any game companies would be interested in supporting such a venture, one so that we could train people they could hire, and two so they could use our products to speed their development cycles?
News to game companies:
Calling API's isn't brain surgery.
The 'eletist' attitude those that call themselves 'game programmers' is infuriating. They think there doind something special, and that there above every other type of programmer is hurting the game industry.
I love when I'm talkoing to people in the game industry.
first it's 30 minutes of moaning there 12 hour work day.
then its talking about there 2 hour lunch, there games of quakes, and shooting nerf darts at each other. then they complain about deadlines, the fact that they have to fly an inconvient flight to some electronics game convention, and the fact that there manager is bugging them to do there work in the schedule that the programmer said it would be done.
I bet you would worker fewer hours if you spent more time at work...working.
Naturally there are exceptions. People who do the actual engineering, low level stuff, usually have less of an attitude about there work. maybe there just confident in there work.
The Kruger Dunning explains most post on
...but as you point out, yes in fps games it is something novel.
That's what I was trying to get at with my point. And oh yes, xcom rule(s|d) (until I lost my copy a few moves ago).
From looking at the hl2 video it does indeed require some lateral thinking and proper problem solving (something that has been sorely missing from 99.9% of the titles released in the last 5 years).
Some say Romero and Carmack revolutionised gaming with the likes of wolfenstein 3d and doom but i think they actually set it back 10 years and only now is the damage they did being undone.
I am NaN
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.
Check out this game... www.kingdomofloathing.com
It's made with PHP, crappy black and white stickman graphics, and a warped sense of humour.
Probably took a while to make but certainly didn't need a blockbuster budget.
This game is easily as much fun as half the crap filling the shelves of stores today.
All games absolutely must have a story... for the right definition of "story".
Most people interpret "story" to mean "plot", but the two are not the same. A story, broadly speaking, is "setup, conflict, development, resolution", but writing a plot line, with set characters and dialog is only one way to get a "story".
Tetris has a "story". The set up is the rules. The conflict is that the game is throwing blocks at you, but you don't want blocks on the field. The development is the game play, and in Tetris's case, the eventual resolution is typically that you fail, but you get some kind of score. (There are varients that play to a finite point which you can "win", but when most people think Tetris they think of the varient where you play until you fill the screen.)
Games with no "story" exist, but are typically rare. You can recognize them because they will typically look like "tech demos", or you'll think of them as "incomplete", even if they have all the technological pieces in place. Imagine an RPG engine that works perfectly, but you're confined to one town and absolutely everybody is friendly and all you can do is talk to them, except this one fight with a rat on the edge of town. The engine is (for the sake of argument), perfectly done, but there's no story.
You can similarly imagine a side-scrolling shooter where the game just goes on and on, but no bosses, no increasing difficulty, just monotonous onslaughts of homogenous enemies. I remember playing these on the C64... briefly. For better or for worse, the now-standard "boss" system does at least provide a story. Even the "level" system provides story; the exact same game as the classic 2D space shooter Galaxian, but without level delinations, would be a lot less compelling.
Lots of things must have a story like this, but not necessarily a "plot line" and "characters". A presentation should always tell a story: "Our project was this (setup), our problems with it were this (setup), we handled it this way (development), and this was the result (resolution)." (I strongly disagree with people who say to put the result first; you lose the interest of the crowd and they'll have a superficial understanding of the result. If you result is at all complex and you really want your crowd to understand the result, you must take them through the whole story before they can appreciate this.)
Doom has a story, but the "plotline" it has is entirely incidental. Doom's story is on a per-level basis: "[Rules of the Doom game] (setup), there are monsters blocking my path (conflict), the combat (development), I got to the end of the level and prevailed (resolution)." There is an over-arching story in the boss battle but it's quite diffuse compared to the level-by-level story, as evidenced by the fact you can basically pick it up and play any level you want without playing the ones before it.
All games must have stories. Plot lines are one way, but not the only want and generally not even a good way, for this to occur. Generally the engine itself must provide the story, or the user will feel they are just watching a movie.
(Think about this and apply it to games you've played before dismissing this; this is really a surprisingly interesting field. It seems that the general story pattern of setup, conflict, development, resolution is buried deep in our psyches since it is so important in so many artistic or creative endeavors, from games to literature to presentations to music to a whole lot of other things. Heck, even software tutorials should have a story. People who understand this and apply it have a distinct advantage over those who don't.)
It can't be too long before more third party suppliers spring up who do nothing but build game engines and design tools.
There already are quite a few 3rd party engines from tools only companies. I'm not sure why Mr. Blow only mentioned the Quake and Unreal engines. There are other engines like
NetImmerse (or I guess it's called "Gamebryo" now), and, well, there are more links here. Go see for yourself.
I think The Unreal and Quake engines are actually some of the most expensive you can buy. From what I understand, you pay a premium for these engines because there's marketing value in being able to associate yourself with greatness by advertising "Built on the Unreal Engine". Whereas "Built on the LithTech engine" isn't going to impress anyone. So you pay a lot for those engines, when in fact, it's sort of akin to movies that advertise "From the producer of 'some good movie'". It's just not a very good predictor of whether it will or will not be a good movie.
There are a few game firms using tools such as SDL and pygame, but not enough, not even open gl. But look at a tool like blender, though the latest version doesn't have a realtime engine yet, they still have older versions with the realtime engine and the standalone player works well with the lastest machines, so using blender 2.25 for free one can develop game logic with "logic bricks" or you can code python, but you never have to use c++, and you can create 3d games for all the major platforms without having to use c++. But for c++ users, there's libSDL, which gives you a cross platform games library with opengl extensions as well. Pygame gives you access to the same library, but with python. However you can use distutils under windows to generate a windows exe which you can use the python installer builder to create a regular windows installer, as well as mac os x and linux and *bsd. Java is another tool that doesn't get mentioned. Its becoming a very important tool for wireless phone and pda game development. SDL is the number one game aid that gets overlooked, also the market for "microgames", some of the most popular games of all time have still been seemingly simple, but hiding complexity, like tetris.
It's easy to be jaded by the spoon, having known it all your life. But that doesn't make you clever, sophisticated, or witty.
Karma Whore.
Yeesh. Somebody buy this guy an Enter key.
-A. Coward
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.
Did I miss something, or did Borland, Intel and RMS all just stop making compilers? These are all competitive alternatives if I'm not mistaken.
/<en
That is soooo true. I loved BG2. I have NWN installed on my PC at the moment, and got most of the way through to what I assume is the end of the first chapter. I haven't played it in several weeks now, though, and have bought two new games in the interim. BG2 didn't have the same snazzy 3D rendering engine, but it had two things so many games lack: playability and storyline. And for that, I played it for hours and hours, twice through, and may yet play it again to see a different selection of the sub-plots.
Of course, BG2 and NWN are both RPGs, where storyline matters a lot more. One of those new things was Quake III Gold, which I finally got around to buying now my system is up to playing the games. Plot: zero. Playability: a good 8/10, IMHO. Sometimes story just doesn't matter.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
And how do you know that they aren't already using these "very simple" ways to reduce build time? Don't you think that they might in fact be very interested in reducing build times?
As for third party suppliers springing up who do nothing but build game engines, such things exist and if you want your game to look just like everybody else's game, then I suggest you buy from one of these companies. Another reason game houses often build things from scratch is that they want/need to wring every bit of performance out of crappy machines like the PS2 that they can, and generic systems written to work for everybody just can't do that.
"that we have a perpetual shortage of qualified people in the industry."
This is funny. A few years ago, after working on successful but boring software projects for the past ten years, I decided that I wanted to work in the game industry. I have no debt, and was willing to take a pay cut. I live in San Diego, home of a number of game companies, EA, Sony, etc. I figured it wouldn't be too difficult to get myself at least an entry level position with 10-years experience, just to learn the ropes. Nobody seemed willing to hire someone that didn't have several previously delivered games under their belt, despite a number of other successful consumer products and happy customers. I had sent resumes to all the companies in the area, as well as working briefly with a "game headhunter" which didn't work out as well. After roughly six months of trying, I gave up, and went back to working on my boring jobs. I'm guessing that the writer of the above quote isn't all that tied into the needs of the industry.
WWJD -- What Would Jimi Do?
(Smash amp, burn guitar, take home the groupies)
I don't know how to break it to you, but you are living in a dimension of pure fantasy.
The "very comprehensive design document" system is very similar to the waterfall methogology of the software developement. And if you have any clue, you know how well that worked out.
Until game design is understood much better than it is now, iterative design will be the only way to go.
Idiot.
The problem isnt that there arent enough programmers, it's simply that you need the best ... with artists you can make do with less talented one, since they can simply spend more time on their assignments while you hire more of them to do the work of the single better artist. With programming this doesnt work.
"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.
"
Hmmm, maybe we can develop a time waster called Slashdot.
I'm a n00b with Blender. After about three tries that failed right at the start I've been making good progress on a humanoid character; a high-poly one(I'm doing a game with pre-rendered sprites), but nonetheless a pretty good one.
There are plenty of tuts that point you in the right direction, but mine basically involved starting with a torso outline, then extruding/rescaling and repeating until the outline of the full torso's made. Once you have the outline, you chop off half of the character so that you only need to deal with one side, and then start adding detail and the additional appendages. With subdivision surfaces and decent anatomy knowledge you can get a fantastic-looking result with only a few hours' work.
Strangely enough, I've had more difficulty in making spaceships than on this character.
Blow was problably called into to rescue fucked up projects. And Carmack is good, but he's not worthy of such worship. If you've read Blow's columns (which I doubt) you'd know that he's pretty sharp.
retard fan boy.
Someone with a clue (in fact, more than one). And I thought slashdot was totally filled with retarded fanboy wannabees.
It is possible to compete without being competitve...
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.
Ok, I'm new in the industry - approaching 6 months - so my opinion probably doesn't count much.
To me, this guy is a whining little bitch. What the hell is a "Gaming Development Consultant" anyway? Just look at how overly-complex those spaghetti diagrams are!
The company that I work at is apparently rather advanced in our development methodology and stuff compared to other companies. Quite simply, everything we do in our process of development just makes sense to me - I don't know how anyone couldn't do it the way we do it.
1/2 an hour to do a build? So? I only have to do a clean build maybe once a week at the most (and that's usually because VC starts playing silly buggers with dependencies and stuff), unless I'm working on a core component of the engine - like the string or array classes - but they shouldn't need to be touched once their written. Yes, you have to build and test your code on all the target platforms before comitting - but come on - you don't have to do a clean build for that! You can compile for PC and Xbox on your workstation while a build server or your tool does the PS2 one.
Modularising your code is key, develop re-usable components. This is what's preached in software engineering and it applies just as much to games. Profiling is not hard either - build profiling functionality into your code and use that in combination with external tools like the PS2 PA.
Yeah, games are hard because they're always on the cutting edge and evolving, but use some common sense when laying down your initial engine and component designs and it should all be pretty easy to manage as long as everyone knows what the score is. Communication is vital.
That there's not enough programmers and too many designers/artists is bullshit too, well, only if you're using a pre-built engine. Games are content-centric now... you need way more artists and designers than coders these days. Having a good workflow for them is essential in order for them to be productive. This entails writing plugins for apps like 3dsmax and photoshop to convert to the interal formats, and to have a quick and easy way to get the content into the game and tweak it. This is another area where the company I work at excels in.
If you can't stand the heat, get out of the kitchen. Those who can, do. Those who can't, teach. Enough of this crap, I'm going outside for a walk.
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.
I acutally know guys who program and do all the art for thier games. http://www.wolfire.com is run by a friend of mine and it has an amazing quality of games now adays. lugaru is top quality fighting and design. 6 months of programing by 1 guy produced that in his spare time at the highschool level.
Never could figure out why my girl liked my bitch tits, then I found out she was a lesbian.
(from the second page)
What about Intel's excellent compiler? Or AMD's? Or GCC?
I think someone needs to think outside the box here. Surely if you're good enough to write a game like UT2003 (or something) you could deal with emacs* and use a great compiler. Oh well. Whatever, I don't play games (often) anyway.
* Saying "dealing with emacs" is like complaining that your girlfriend loves you too much. In other words (slashdotters may not relate to the gf example
My other car is first.
Designers in abundance, salesmen all around but what I need is a coder and a C to sail them on.
But this C is tiny and difficult to sail so I'll hand them all an upgrade to C++ and let them wail.
This shrieking is ill met, I stop and look profound as I have a solution it's C pound.
My coders all have left me with this ugly stinking mess I should have not given them more and more but merely better less.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
Live For Speed is a game developed independently, and it's proving to be reasonably successful so far.
I got my undergrad from UCF in Digital Media, just down the street from FullSail - heard some questionable things as well about the place. They do have kickin' facilities, though.
I'm a grad student now at the Entertainment Technology Center at Carnegie Mellon University. The program has people going into many industries, but the majority are into video games. We have graduates at Rockstar, EA, Maxis, Angel Studios, and a number of other companies. One guy was back from his co-op at Maxis and had to excuse himself from a party because Will Wright had called him on his cell. We took a trip to EA (among other companies like Pixar, Disney, etc) last month, where the Vice President and CTO each gave presentations to our group of 30 or so.
Unlike many vocational programs, we don't actually have any courses on video game programming directly, though we do offer official courses in Maya, Building Virtual Worlds, and Game Design. The game design course mainly focuses on board, dice, and card games.
Retro gaming is a popular side hobby, with one student teaching a course in Game Development for the 8-bit NES and the X-Arcade company at residence in our building. (We've got two MAME Arcade setups in the hall)
It's not uncommon to see students parked in front of the gaming setups we have on each floor (with all the major consoles) doing "research", only to go back and discuss what they learned for a few hours with their project team.
The program is pretty demanding and tough to get in, but it's a fun place. Gaming is not an easy industry, there's a lot of late hours, especially in "crunch" mode before a game ships, but it's pretty rewarding.
There != Their != They're.
There = Not here.
Their = Belonging to them
They're = "They are"
It found its way into Irrational's Freedom Force and will probably make a reappearance into the upcoming sequel.
Admittedly, that's just one game.
Try Panda 3D (Sourceforge Page)- it's an open source game engine originally written at Disney's VR studio for DisneyQuest and Toontown Online. We're now co-developing it with the Disney team at the Entertainment Technology Center at CMU, and use it for a lot of internal projects.
The core is written in C++, but game programming is done in Python, which initializes the engine. Exporters exist for Max & Maya. Since your stuff runs in Python, it's simple to add extra functionality. Last semester we used it for the Building Virtual Worlds Class, and were able to add things like networking, computer vision, MIDI IO, and simple show control pretty trivially. One group now is using it to do realtime interactive stuff on a dome with 5 cameras stitched together in realtime.
This semester, the project is adding in-engine video playback using Helix and integrating with the Eclipse IDE. It serves our needs pretty well.
What's needed is a list of Game Patterns.
Rick DeBay
The games industry is going to die because there *is* an upper bound on complexity, as you have said.
I've said it before and I was modded as troll. But, if one faces reality, he/she would see that games development becomes much harder every year. Only really exceptional developers will be able to make a product that stands out. The smaller ones will die or will be absorbed by bigger ones.
In fact, there are several problems already.
One of the problems is the tools themselves. Although I am not a games programmer, the article's considerations are real, and they are present for bussiness systems, also. The usage of a language that solves some of the previous language problems (Java instead of C++, for example) only solves some tiny fraction of the problems.
Another problem is the content. There are just no new ideas. I have practically stopped playing FPS games after Half Life, because everything seems so inferior to it. I was playing the Contract Jack demo the other day, and it seemed so boring!!! I just had to shoot and shoot and shoot enemies, and that's it.
Personally, I have given up playing modern games. I am back to playing old games that I have missed. I recently finished Legend Of Zelda: A Link to the Past (on emulation, of course), and I found it highly endertaining. It was easy to grasp, easy on the eye, with very clever puzzles, many things to do and explore, in short, a fantastic game. I started Chrono Trigger yesterday. And in the last year, I have played many other games that are of high entertainment value (for example the remake of Kings Quest 2 by Tierra).
There are lots of good games out there that one can play that are not very demanding and they are highly entertaining. And thanks to the Internet, they are available.
Finally, I really pity console owners. The PC offers much greater entertainment that it is not possible with a console. I was a console player, but now I am hooked to games that actually require thought...that is the best genre, really.
Do you know Counter-Strike? Its a mod. Do you know DoD? Its a mod. Actually some very interesting games comes as a devirative work of other game. That safe a lot of work, whatever can be shared, dont need to be recreated (the engine, textures, sounds, menus, etc...) and you have instantly a lot of users.
So you make a tiny mod for Half-Life, and you have a 1 millon potentian userbase. Cool or not?
Making mods shortcut the problem of very very long development process.
posdata:
Recently a quake guru (FrikaC) has make a Tetris clone in only 2 hours of work. You can download a stand-alone version here:
http://telejano.berlios.de/option/qtetris1.zip
-Woof woof woof!
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!
My main experience, from programming on computer game projects ranging in size from 10 to 80 people, is that design is a weak discipline. Planning is often non-existant (in a way that simply does not happen when writing a graphics engine or sound library or building from concept art into in-game models) and suffers from the whims of anyone with a say (all levels of management and often extending into the entire team) that feels they can add input in a way that does not happen when approaching other fields.
Features are often not thought through and the interaction between the many aspects of a game not even considered.
Designers can be placed in two camps. Those who, given a half completed project, based on a vague specification, can tell you what's wrong with it, what they like about it and hint and what to do next and those that can sit with a blank sheet of paper and find a feature set that will interact in a way that will enhance the game rather than act to it's detriment.
I'm sure that type II designers exist. I don't think I've ever met any of them.
I've worked on too many projects with Just-In-Time design that's burnt out the art team (who are the first to suffer when design strays) and even the programming team.
Blue sky design is often seen as an opportunity to come up with a crazy set of "cool" features that out-do every game ever made in every aspect. This rapidly cools into less and less of a next-gen game as time is wasted on prototyping the impossible (often going beyond prototyping and getting half way into a finished game before it's realised that it _is_ impossible) where, in the first place, the design team should have sat down and just talked through ten minutes of gameplay to see if it would be possible/contain positively interacting features/actually be fun.
Of course, rigidity in design can also be a huge problem if taken to extremes. What is generally needed is a well thought out, flexible design that does not suffer the whims of all and sundry. This, unfortunately, is rarely the case.
Mike
(working on a Sunday due to the whims and impractical designs of industry luminaries)
Another problem is the half finished game engines out there, some of them are nice and have set up nice goals but are far from finished. No, most of us happy amateurs do NOT have a gazillion in cash to get a Gamebryo or UT engine license.
For a hobby project, i've been evaluating client(3D) and server software for months (sourceforge stuff) and decided to write the server software myself (DB/sockets, positioning, commands, items and all that) and hope to find someone(or more) who has the client side skills.
Otoh; i dont have a deadline..
You are not qualified to be a game programmer. Sucks, but true. There really is no point in having "entry level" positions other than to develope more qualified programmers, but that would be too farsighted a goal for the biz...
Getting into the industry is like getting into Hollywood. You can't just say "I'm qualified, give me the job." You need to: bullshit, lie, give blowjobs, beg to work for free, start your own biz, etc.
Too many wannabees...
Heck, the bosses in the last few NES Mega Man cames were all entries submitted into a design a boss contest.
Actually, it was just two of them in Mega Man 5, submitted in a Nintendo Power contest.
So which is it -- "nothing" or "horrific"?
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005
You do make a viable point. A game that strays far from conventional ideas is better served by being short. However, it should not be short in terms of the amount of time it takes to beat the game. It should be short in terms of how long it takes to play a complete game / round / level.
What will cut down the costs of making an innovative game is in cutting down the 'turn around time', or time it takes to create and play test new levels or ideas.
Super Monkey Ball and Chu Chu Rocket managed to do this perfectly. You can play a complete game or level very quickly. Mario 64 did well at this also (it does not take too long to get that first star).
RPG's like Final Fantasy and Adventures like Half Life dont lend themselves very well to this. They work on a completely different time scale from a players point of view. Quick level transitions break up the narrative, which is the primary appeal of the game.
As such, they do not innovate with new styles of gameplay. They innovate by expanding the gameplay options of their predecessors (Better enemy AI, in game physics, more open storylines, new weapons or vehicles, new levels).
You cannot make a followup or immitator and expect to beat your predecesor title if you deliver less core gameplay then the predecessor. That only works for expansion packs.
END COMMUNICATION
Oh, and game headhunters suck IMHO. I wasted 3 years with them. Unless you are a programming god in a field they need, they are not going to pay the 5% (or whatever) to the headhunter. They will hire one of the several dozen wannabees offering them free blowjobs.
Spell cheek you've failed me four the last thyme!