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