Please create an account to participate in the Slashdot moderation system


Forgot your password?
Programming Entertainment Games IT Technology

Anatomy of Game Development 385

CowboyRobot writes "ACM Queue has an article titled Game Development: Harder Than You Think that looks at the complexities of creating a modern game, in comparison with the relative simplicity of doing so ten years ago. My understanding of the industry is that they have too many designers and not enough programmers. From the article: 'Now the primary technical challenge is simply getting the code to work to produce an end result that bears some semblance to the desired functionality... There's such a wide variety of algorithms to know about, so much experience required to implement them in a useful way, and so much work overall that just needs to be done, that we have a perpetual shortage of qualified people in the industry.'"
This discussion has been archived. No new comments can be posted.

Anatomy of Game Development

Comments Filter:
  • by hyphz ( 179185 ) * on Saturday February 28, 2004 @08:03PM (#8419454)

    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.
  • by SisyphusShrugged ( 728028 ) <me&igerard,com> on Saturday February 28, 2004 @08:05PM (#8419465) Homepage
    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! []
  • by KamuZ ( 127113 ) on Saturday February 28, 2004 @08:18PM (#8419534) Homepage
    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.
  • by Xzzy ( 111297 ) <> on Saturday February 28, 2004 @08:19PM (#8419540) Homepage
    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 to the rescue (Score:5, Interesting)

    by hehman ( 448117 ) on Saturday February 28, 2004 @08:20PM (#8419541) Homepage Journal
    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,
  • by urantia007 ( 707091 ) on Saturday February 28, 2004 @08:21PM (#8419550)
    what needs to happen, is we need a complete game enviroment to creat games, not just a game engine, but a complete piece of software that doesn't need any programming at all. think of using maya to do all your 3d models and animations and worlds for the game, and instead of exporting these out to an engine you keep it all under one roof, give the models properties like colision, key bindings to play this animation when this key is pressed in this direction etc. Of course programming should be en extensible part of it to add funtionality that might not be in it. so essentially a 3d applicaiton with a game engine at it's heart containing everything you would need to make a game. This could be done right now with directX9. The single man band could be back if this happened.
  • by foofoodog ( 552812 ) on Saturday February 28, 2004 @08:28PM (#8419592)
    I guess it is hard to code a game engine but I get the impression that most of the maps and some of the total conversion mods are done by small teams and some end up being much better overall than the original.
  • by Anthony Boyd ( 242971 ) on Saturday February 28, 2004 @08:30PM (#8419600) Homepage
    I have attempted to work as good as I can, see what you think of my game, it is a bit difficult to wear the hats of Programmer, Designer, Developer, Musician, and Artist!

    Well, I just downloaded your game. One of the things I like about this is that I take your comments at a higher value seeing that you're actually "down in it" building games on your own. I think your kind of game could really appeal to a lot of people.

    First of all, as the article describes, the industry is really stretched by new 3D worlds that require huge investments of time, staff, and money. Getting back to the lone developer model of gaming, or even a 2 or 3 person development team, could be one solution. Also, if you visit Usenet groups like, you'll find a lot of people who miss isometric games with smaller, tighter storylines. I personally would love to buy a few games like Baldur's Gate 1 & 2, but which had only maybe 20 hours of gameplay, instead of 60. Those games would be more "complete-able" by 30-something and 40-something parents (like me), and more "build-able" by developers like you. And we seem to be a bigger part of the market nowadays anyway.

    Garage Games [] is also catering to this market, at least in part. Smaller games, simple in scope, faster development & deployment, but great gameplay. I would encourage you to do more of this. I think the only difficulty is getting the word out, especially if you hope to charge money for the game. I don't know how you'd draw in traffic, except to say that Google's AdWords might be useful.

  • Lua (Score:5, Interesting)

    by truth_revealed ( 593493 ) on Saturday February 28, 2004 @08:36PM (#8419621)
    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 [].
  • by sirsnork ( 530512 ) on Saturday February 28, 2004 @08:41PM (#8419643)
    So game developers (the companies) are moaning that there isn't enough knowledge in the industry of all the ways to use every concept, fragment of code or method, and yet the easiest way to get people more knowledgable would be to open source all of the older games so others can learn from your past experiences.

    Older games may not teach a developer all the latest techniques but it would sure as hell let you be able to compare 3 or 4 similar implementations of a function and pick the best or even merge parts of 2 together to make it better still, I know some companies di this but there are more that don't.
  • Re:Full Sail! (Score:1, Interesting)

    by Anonymous Coward on Saturday February 28, 2004 @08:42PM (#8419651)
    Full Sail seems to have a pretty nasty reputation. I'd have said people would be better off with a normal degree and some mod experience.

    Of course, I can't get a games job, so feel free to ignore me...
  • Another sad thing (Score:5, Interesting)

    by Monkelectric ( 546685 ) <> on Saturday February 28, 2004 @08:50PM (#8419684)
    Game development has become so complex that there really is no hope for a small team or a startup to make a decent game.

    I remember when I was 13 writing ASM code code aspiring to write something like Monkey Island -- that was a very attainable goal. I had a friend who was a very good artist, he would whip up a some cells in autodesk animator, I had written a little converter, and we could walk our little guy around the screen against a background. Now truth be told I had NO idea how a game engine worked at 13 years old, but we did end up writing a few neat demos and bbs loaders (I was a weird kid).

    Now the level of art work and technical knowledge required to make something that looks half professional is off the scale. I have a great game idea that I don't think I'll ever be able to realize. Thats the loss I mourn... kids wont ever have the fun I had trying to make a game, and we might never be exposed to some new ideas these kids might have.

  • Meh (Score:5, Interesting)

    by KalvinB ( 205500 ) on Saturday February 28, 2004 @08:55PM (#8419704) Homepage
    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.

  • by Mr. Piddle ( 567882 ) on Saturday February 28, 2004 @08:55PM (#8419708)
    No it won't be the next jaw dropping engine that will command everyone's respect but that's not really the point, the point is as long as you have enough basic intelligence to learn an API and can manage to glue several of them together the open source world is plenty willing to fill in the gaps of your knowledge.

    This is one area where Java is way underrated. Just between the 2D and Midi APIs, there is a lot of gaming potential there. I haven't looked at Java3D, so I'm not sure about mega-real-time-worlds, but perhaps it could work there, too.

  • Re:He's wrong (Score:1, Interesting)

    by Anonymous Coward on Saturday February 28, 2004 @08:56PM (#8419713)
    The real hard part is maintaining a focus on the game as a whole the entire time. With games running several years of development, the original design document is drastically different than the game you end up pressing on a CD.

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

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

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

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

    -another Anonymous lurking game developer
  • Oh come off it... (Score:5, Interesting)

    by spray_john ( 466650 ) on Saturday February 28, 2004 @09:00PM (#8419729)
    I'm tired of this, I really am. When will guys like this admit that everyone else works for a living too? No, games are not always very simple. Thanks buddy, we know.

    All this "Life is so hard! My industry is so cruel!" is just attention grabbing to get readers to an otherwise rather dry review article on the elements of commercial game production.

    In other news, games are unimportant. All but a very few games are played by practically no one, and those that do play it throw it away after a couple-dozen hours. Where did this conception that making games was so exciting and dramatic come from? Just because so many other areas of software development are even more mind-numbing doesn't make gamedev automatically interesting!

    Design me a new spoon. Design me a spoon that will be sold across the world, used by millions on a daily basis for years of their life. Design me a brilliant spoon, and I will be impressed.
  • by RichMan ( 8097 ) on Saturday February 28, 2004 @09:13PM (#8419796)
    Here is an interactive game in one line of basic code (ok 4 statements, but you could write it in one basic numbered statement). Just showing what could be done with minimal code.

    You control an object at the top of the screen it will move left if you don't push shift, right if you do. Blocks "###" are printed at the bottom of the screen and scroll up. If you crash into a block it is game over. Quite complex for 1 line. I would walk into stores displaying computers without games that attracted the kids, type this in and have fun.

    I had versions for PET, VIC20, C64, APPLE II, TRS80 machines

    Adjust for my bad memory and learning of many other languages since then.

    0 poke 32788+a,65; a = a + peek(515)*2-1; print tab(36*rnd()),"###"; if (peek(32788+a) == 32) goto 0;

    clear the screen, scroll to the bottom and run

    Break down
    A) poke - puts player "A" set by ascii 65 at the middle of the top line of the screen plus the offset a
    B) adjust the offset a of the players position dependent on the state of the shift key
    C) print - puts a block in a random position on the next line. If this is the bottom of the screen, we get a scroll and everything moves up and the players object is cleared off the top
    D) check the new position of the player to see if it is clear

    Majic numbers
    32788 address of the middle of the top line of the screen
    65 character for players object
    36 + width of block is 1 less than the width of the screen, in this case 36+3 40
    515 shift key status updated by system interrupt

  • by Anonymous Coward on Saturday February 28, 2004 @09:25PM (#8419843)
    The author needs to get a grip. Hardly anything he has written is specific to game development. Sounds like a programmer struggling with the realities of any complex software development project.

    Let look at a few examples:
    Games have ballooned in complexity-
    I think it is safe to say that nearly all software has grown in complexity. For traditional client-centric applications, we have seen interfaces grow more complicated and sophisticated. Unlike software designed in 1996 nearly all applications are now internet aware. Even your wordprocessor has the ability to communicate via the internet, to interact with email and offer colaboration functionality.
    Very little software is designed to operate in the vacuum of a stand-alone workstation anymore. Apparently this is also true of games. Wow, brilliant insight.

    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 all code is hard. Identifying bottlenecks in code which involves a great deal of user interaction is very complicated. Hardly specific to game programming.

    Reality check time. All the article says is in 2004 that users expect a far more sophisticated product than have been required in 1996. Engineering complex products is difficult. Welcome to the software industry.

  • Re:Shocking... (Score:5, Interesting)

    by frankthechicken ( 607647 ) on Saturday February 28, 2004 @09:41PM (#8419896) Journal
    I completely agree, there is also a hell of a lot of difference between having a great game 'idea' and having a great game 'idea' that is practical and fun.

    There are countless examples of games that are great in theory, but poor in practice(I'm looking at you Black & White). Yet relatively few that have no business in being so great(And here I'm looking directly at a certain Tetris), and somehow pull of all those intangibles such as playability.

    Even taking a great idea that 'will' be purely playable and making it so, is a great skill that only few can accomplish.

    It amazes me how certain designers can almost routinely pull off the impossible.
  • by H4x0r Jim Duggan ( 757476 ) on Saturday February 28, 2004 @09:54PM (#8419946) Homepage Journal
    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.

    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.) software is the way the world *should* work
  • Re:Design Patterns? (Score:5, Interesting)

    by Naysayer ( 71120 ) on Saturday February 28, 2004 @09:56PM (#8419955)
    (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).
  • by protohiro1 ( 590732 ) on Saturday February 28, 2004 @09:57PM (#8419966) Homepage Journal
    This is a pretty good idea. There've been products like that for flight/combat simulation for years. What you are talking about is almost a flash for 3d games. The hard part coding-wise is done for you. All you need is scripters and artists (and a good story and design). That could really open up game design to a lot more people.
  • by LordZardoz ( 155141 ) on Saturday February 28, 2004 @10:05PM (#8420022)
    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.

  • by Ungrounded Lightning ( 62228 ) on Saturday February 28, 2004 @10:15PM (#8420092) Journal
    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-)
  • by Naysayer ( 71120 ) on Saturday February 28, 2004 @10:28PM (#8420162)
    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!
  • Re:He's wrong (Score:3, Interesting)

    by Daetrin ( 576516 ) on Saturday February 28, 2004 @10:31PM (#8420179)
    mho 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).

    I agree, that can be a very good thing, but only if you take what the outsider says with a grain of salt. The last game i worked on they decided in the last month or two that it was really lacking, so they brought in someone from another area of the company who hadn't dealt with the game before.

    He had a LOT of suggestions. Some of the suggestions were really good, and some of them sucked. However since he had been brought in to make suggestions we were under orders from on high to try to implement all of his ideas.

    Overall the game probably improved because of his input, but it would have been even better if we'd ignored half of what he said. He was especially worried about the dificulty of the game. He insisted that we add all kinds of changes to make the game easier and implement them at all difficulty levels. He was afraid that if we didn't some reviewer would start playing the game at the most difficult setting and think it was too hard and give it a bad review. The only thing he would let us change was the HP/damage ratios, so we bumped those up a lot for the most difficult level and hoped that would compensate. (Some of the reviews still complained about how easy the game was, so at best it was only a partial success)

    In one level there were turrets that were supposed to track the player which he didn't think were good enough. He suggested we should make changes A, B, C, and D, all of which were fairly reasonable. I worked on it and told him that we had A, B and C, and something that was similar to D, but not exactly what he wanted. (He wanted circles of light to follow the targeting lasers around whever they struck an object, and all the consoles are limited in how many lights they can calculate at one time. The best i could come up with in the time available was to have sparks shooting out of wherever the lasers hit.) His response was that if we couldn't have all four, we should just yank the turrets out. We did so, despite how much improved the new turrets were over the old ones, and it made that level way too simple afterwards, but we didn't have the time to rework it.

    It would have helped if we'd started the whole process of getting outside input earlier so that we weren't quite as rushed, but it wouldn't have fixed the whole problem. It can be difficult to try and fairly judge the suggestions of someone on something you've been working on for months and they've been playing for a few days or weeks, but it's better than accepting what they say on blind faith. _Everyone_ has some good ideas, some ideas that are good in theory but suck in practice, and some ideas that just suck. This ratio improves for professional developers (or so we like to think) but no one is ever compeltly free of dumb ideas.

  • by Jerf ( 17166 ) on Saturday February 28, 2004 @11:34PM (#8420442) Journal
    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.)
  • by asapien ( 582847 ) on Saturday February 28, 2004 @11:40PM (#8420468) Homepage
    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.
  • by TRACK-YOUR-POSITION ( 553878 ) on Sunday February 29, 2004 @01:29AM (#8420968)
    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. But whether we're talking about the forementioned Lone Wolf or a Huge Company, level design and art are still expensive, no? 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. I'd rather play the one short boldly innovative game, let the other 4 rot on the shelf, then play the one huge game that's exactly like last year's one huge game but with better graphics because management refused to take any risks with their multi-million dollar project. The reason for short games isn't because short is better, but because innovation is proportional to risk-taking which is inversely proportional to cost which MIGHT be proportional to length?
  • My thoughts... (Score:5, Interesting)

    by Shaheen ( 313 ) on Sunday February 29, 2004 @01:48AM (#8421040) Homepage
    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...
  • by Sj0 ( 472011 ) on Sunday February 29, 2004 @02:17AM (#8421158) Journal
    Sir, I salute you. I'm an indie as well, and it's the single most thankless, grueling job I've ever had. Considering that I work in Customer Service, that's saying something.

    Good luck... ...and thanks, on behalf of every bastard who feels that you owe them a perfect video game because they downloaded the demo off your site. :)
  • by Sj0 ( 472011 ) on Sunday February 29, 2004 @02:42AM (#8421254) Journal
    you should learn to play nice with others and work in a team. aparently the team model is a superior one then the lone wolf one. I am realizing this in my engineering studies.

    You sound like an engineering student all right. For the future, real engineers actually analyze problems and give workable solutions. Managers give catchphrases like "you should learn to play nice with others" without apparantly any knowlege of the situation beyond a couple paragraphs of type.

    OK smart guy, do the entire indie development community around the world a favour and break this little conundrum: How do you get together a team of dedicated independants who are willing to work hard on a project for years on end? If you can figure this out, please let us know, because I've seen thousands of projects fall by the wayside not due to some internal dispute, but because most independants have lives, and simply can't afford to dedicate that kind of resources to a project for the periods of time needed to finish a production run. Most who do are newbies who will spend a couple hours working on this project before quitting, a week at most. People with experience work alone or with people who they happen to know in real life, or they fail. It's a simple fact of life, one which I've experienced myself in a couple projects I joined with in the past. Eventually all of them folded, because nobody could keep working while critical team members took months off the project to deal with real life matters.

    Sure, sometimes a team manages to keep together, as the recent release of "Diver Down", a great indie RPG, shows. The problem is that it often has far less to do with team management and more to do with the fact that people have real lives to deal with, and simply put, shit happens.

    The best advantage of the lone wolf model for indie developers is that a single dedicated person can make the game of his dreams, and keep on making it while teams fumble around and lose members like mad. Take me. I've been working on my lifes work, a great RPG, for three years. In that time, the entire community of developers I tend to hang out in has been completely transformed several times, great sites have risen and fallen, great projects have come and gone never to be heard from again, but I'm still chipping away at this, dedicating every waking moment to dreaming up refinements to my original designs, preparing to code great enhancements, or actually going into the engine and adding things. I guarantee you that the odds of me finding another developer as dedicated as myself to this particular project are about the same as me digging up a UFO in my back yard. I'm sure the parent is the same way. Take a look at how long abaddon has been in development. No team will keep working that long. Only a man with a vision can, and so he does. Regardless however, many indie games done with this model achieve steady progress throughout their development, slowly but surely, as a single person fights to complete it through force of sheer will.

    It's a beautiful thing.
  • Re:He's wrong (Score:2, Interesting)

    by Prehensile Interacti ( 742615 ) on Sunday February 29, 2004 @04:18AM (#8421473)
    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.

    Fortunately video games is a large market. Outside of sports, ID is pretty much the market leader in story free games. To compete in that area, you need to be better than ID. Fortunately games players are all different (as the disagreement in this thread shows).

    Games with strong stories are playing in a different area of the market to the Quake's etc that ID puts out. A lot of people value a quality story in their games (e.g. Final Fantasy, or Zelda), and those games sell well to those people.

    In my experience, it is the 'hardcore gamer' who grew up with 8 bit machines, and the arcades, who values awsome game mechanics. A more casual gamer, does value the story that is told through the game. Quake is certainly not everyone's 'cup of tea'.

    I personally hope for a time, when the vast majority of all people's leisure time is spent interacting with one another, and I hope that games of the future will be where that is provided. The people who aren't playing games at the moment, are largely sitting on the couch watching TV, rotting their brains. I believe that to appeal to that mentality of consumer we need to start having more games, which do place the emphasis firmly on story, and less on whether you can jump at just the right pixel to make it through.

  • Re:Shocking... (Score:2, Interesting)

    by Anonymous Coward on Sunday February 29, 2004 @05:00AM (#8421556)
    It isn't codifying it formally that's difficult, but modern games are some of the most difficult to get correct because they place a lot of unusual demands for the functionality.

    A game has to be robust, user-friendly, look good, work smoothly, give the player lots of degrees of freedom (which makes testing both important and hard) etc.
  • by master_p ( 608214 ) on Sunday February 29, 2004 @06:22AM (#8421717)
    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.

  • by Anonymous Coward on Sunday February 29, 2004 @07:13AM (#8421830)
    I've done both C++ with Direct3D (using some game engines on top of that) and I've done some sim/visualisation work using Java3D.

    Java would be great for games (and is already great for mobile phone games) except for one thing.... pure and simple, no matter how you sugar-coat it or no matter how many different angles you look at it, it's just TOO SLOW.

    Sure, there's been great progress in terms of JIT-compilation, getting it to run faster, etc. I also know about all the benchmarks where they compare Java routines to their C++ equivalents and get near-identical speeds.

    In a production environment, with everything going on, it's still simply too slow. Java3Ds framerates are terrible compared to what you can achieve using C++. That's with hardware accelerated OpenGL.

    What Java needs on the desktop is simple: A REAL COMPILER. Something that supports most of the Java runtime functions but actually compiles the code into a static .EXE, just like your normal everyday C++ compiler. GCC can do this, but it dosen't support anywhere near as much of the API as we'd like (well, I might be wrong on this because it was a long time ago that I checked).

    For phones, Java is great and binary portability makes sense. For the desktop though, I really wonder and don't see the use of binary portability, especially in a gaming sense (unless you are executing distributed objects over multiple platforms, maybe in some kind of MMORPG game....)
  • by Tei ( 520358 ) on Sunday February 29, 2004 @07:29AM (#8421852) Journal
    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.

    Recently a quake guru (FrikaC) has make a Tetris clone in only 2 hours of work. You can download a stand-alone version here:
  • Re:He's wrong (Score:1, Interesting)

    by Anonymous Coward on Sunday February 29, 2004 @07:32AM (#8421858)
    I remember playing a flight sim called Strike Commander. This sim had the unusual twist of having a story. That made it extremely playable (meaning that the last time I played this acient DOS game was last month). Every genre would benefit from a story. Funny you should mention puzzle games. Anyone remember playing alone in the dark? Part puzzle game, part action, part scary, all story.

    Maybe it's because sports games lack a story, that I usually don't give a damn about them...
  • Re:He's wrong (Score:1, Interesting)

    by Anonymous Coward on Sunday February 29, 2004 @07:34AM (#8421866)
    You also have to remember that doom and quake are just technology demos. id is in the buisness of selling game engines, not games.
  • by Kent Recal ( 714863 ) on Sunday February 29, 2004 @08:18AM (#8421937)
    Well, probably ion has improved a lot since last time I used it.
    I switched back to a more "traditional" wm two months ago because too many apps were causing trouble (basically everything except browser and [resize-patched] xterm) and real annoyances like un-movable galeon "find-dialogs" overlapping the page I'm searching through and such..

    I found it a pain to run the gimp in anything other than a floatws because resizing frames often left artefacts on the image and generally I found no way to line up all these popup windows in a sane way...

    Admittedly a seasoned gimper might actually find a way to get something out of ion - with a lot of kludges and work involved, tho.

    I didn't mean to bash ion as a whole, anyone looking for a "different wm" should definately give it a try. Was just a bit irritated to see it mentioned in context with the gimp (one of the apps that really challenge ion)...
  • Making Game (Score:5, Interesting)

    by essreenim ( 647659 ) on Sunday February 29, 2004 @08:47AM (#8422003)
    Yeah, I totally agree. The games business is really a trade. I'm a qualified Software Engineer but I know that means nothing in the games business. The amount of exposure you get to games creation as a whoole in college for me is minimal. I work for a games company, and I have been exposed to the madness of build fever etc. Its organised chaos. The article is excellent and its actually very nice for me to read as I would have to concider myself as a pawn on the chessboard of the games creation business. The best thing is it's honest. Games creation for modern MMG's is a miraculous thing. Notice the graphs that this guy - an expert - has put together. Along way from UML aren't they??. And in their heart, the really top-level engineers / designers will all admit that they could not put a logical coherant uml spec for an mmg at the initial stage, that will end up looking anything like the final one. What was best, was he pointed out the problems with the business. In particular, I liked this quote:

    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!

  • by Anonymous Coward on Sunday February 29, 2004 @11:06AM (#8422392)
    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.

    (working on a Sunday due to the whims and impractical designs of industry luminaries)

Order and simplification are the first steps toward mastery of a subject -- the actual enemy is the unknown. -- Thomas Mann