Slashdot Mirror
Carmack's QuakeCon Keynote Detailed
TheRaindog writes "In addition to announcing the Quake III source code's impending release, John Carmack's QuakeCon 2005 keynote also covered the programmer's thoughts on Microsoft and Sony's next-gen consoles, physics acceleration in games, and what he'd like to see from new graphics hardware."
Carmack doesn't deisgn games, he makes engines. Doom and Quake are tech demos for whatever his latest engine is. If you buy an id game expecting it to be anything else, you're doomed to disappointment. Even Id doesn't claim its anything else.
I still have more fans than freaks. WTF is wrong with you people?
I found his views on dual core processers fascinating. Until now I had always believed they could give major boosts in performance in games as soon as the developers made their games multi-threaded. Maybe I should put off buying that dual-core cpu for a bit longer.
It's worth pointing out that he doesn't design games because he's a renderer/technology programmer. Id (id? iD?) Software will have designers responsible for designing the gameplay and so on.
JC isn't really responsible for the shortcomings of the games *as games*, except in as much as the ability of the engines he makes for them limits & influences gameplay decisions by those designers...
Game dev and music blog
All kidding aside, it's amazing how "recreational activities" end up pushing the limits and levels of technology to a point that it can eventually be used for more "serious" purposes. Examples?
Pr0n had a lot to do with pushing the massive webserver throughput / broadband increases we've seen in the past several years.
Gaming is directly responsible for the graphics technology that can later be used in training simulations for going to Mars.
Of course, if NASA uses the Quake engine for training for trips to Mars, they may also need to equip the astronauts with railguns...
- Add to unprocessed que
- Grep for coded expressions
- add symbol to character action queue
Thread 2: Charactor Thread- read action queue
- publish action
- recieve reaction
- update state
Thread 3-100: AI Threads- Read viewable universe state
- Process against goals
- publish action
- recieve reaction
- update state
Please don't read this too literally, it only a slashdot post, but this is meta-outline of how I'd start thinking about the game universe in a multi cpu system. Of course it would run like shit on a single CPU (all those context switches (ugh)), but it would really utilize a multicore system.Scared of flying, pointy things snce 1979!
Although Mr.Carmack says physics in game engines isn't easily scalable for level of detail, there is ongoing research about this producing good results. I remember a video from last years SIGGRAPH that had hundreds of plastic chairs falling from the sky, and bouncing realistically. The important part was it employed a level-of-detail hierarchy for interacting parts (i.e. an object doesn't have much physical detail if you don't touch it), but it will be some time before we can see such techniques in real time games.
I think you're misunderstanding his point. When he talks about level-of-detail, this has more to do with game design than with algorithms. What he's claiming is that detailed physics has much more of an effect on actual gameplay than detailed rending does, and that it's harder to write a game which graceful downgrades the player's physical interaction with the world. But a graceful downgrading is necessary for people who don't have a fancy physics-accelerating card.
For example, you can take an older game and change its appearance by giving it higher resolution textures, more detailed meshes for the AI models etc., without having to redesign the actual gameplay. (e.g., the SHTUP and Rebirth mods for System Shock 2).
These steps are independent of each other and independent of the rest of the game. They can simply be dropped in, or not. The point is that if it's that straightforward to take a game forward in technology, it's even easier to go in reverse. So the player can choose low texture detail, etc., and the game may look worse, but it will still play the same.
The game physics on the other hand has historically been more closely connected to the way the player interacts with the world.. so it has a big effect on level design. If Half-Life 2 had a 'simple physics' option that would somehow revert the game physics to something equivalent to the physics in the original Half-Life (ignoring aside the difficulty in implementing such an option) then some areas would have to be substantially redesigned so that they would remain playable for people using the simple physics.
This is of course what he means by peripheral elements "such as flowing water" being accelerated. But I have two criticisms of this.
1) Yes, physics acceleration may affect mainly peripheral elements of the game. But in some ways, the same could be said about improved textures, filtering, etc. If it's done well, it can significantly improve the overall experience. If it's done poorly, the player will hardly notice.
2) As long as it's an upgrade of the basic design, it will probably be okay to let it affect critical elements as well. E.g.: due to the engine upgrade in the port of Half-Life to the Source engine, movable crates and such have a more realistic response than in the original implementation. It's not a big improvement, since the levels were really designed with that in mind. But it doesn't hurt.
For me, the real question is whether improved physics would really make a game more enjoyable. I think this depends more on graphics than on anything else. As objects are made to look more realistic, it becomes more satisfying for them to have real-seeming interactions.
If graphics get much better, accelerated physics will be important. But if for some reason graphics tend to stabilize (due to the end of Moore's Law, long load times caused by slow disk access, or whatever), then the usefulness of improving game physics is more questionable.