The problem with many game related OSS projects is that they are started by people with little industry experience. Often these projects are demos to get into the industry or get a publishing deal. Once inside the industry you have no time to give away to an OSS project. There are notable exceptions: Nebula Device, Quake1&2 engines.
I've followed several OSS game projects (Ogre3D, crystal space engine, stuff on flipcode etc.). Many of these fizzle out within a year. Most are not designed to handle a full scale production. For instance almost no OSS game project focuses on the asset management and export pipeline. This comes from the fact that linux has no workable free 3d editor yet. A workable editor is defined as something that a team of artist would like to spend a year or two working with. Blender does not fall under that category.
Also, games have a very short lifetime. If you're giving away your time (thus money) for free, you at least hope it has a lasting effect, the way a constatly evolving operating system might have.
Howerver if somebody does figure out a good buisness model of how to run an OSS game project, it wont be that difficult to match features of the XNA platform. It seems it took Microsoft 9 generations of DirectX and a seperate team working on XBox to learn how not to screw up game development tools with classic MS cruft.
That dosn't work if a developer is pushing the absolute limits of PS2 or XBOX. GC has a hard time competing unless you are shooting for some common demoninator performance target.
So you compress the hell out of your vertices and textures no matter what the platform. Thats the whole point of consoles. Cube has S3TC, XBox has DXT, PS2 is optimized for palettized textures. All platforms can use vertex compression tricks. You can try to stream more to get around lack of RAM, but all you have a measly mini-disk in the end. And then you need to compress buttons..
Beyond a some limit you need to make platform dependent art assets. It starts to become expensive to support a port for a platform with the lowest installed base. Thats a decision for each company to make, but Nintendo is loosing out by having hardware so far below its competition. This is the first generation of platforms where cross platform development is common.
Granted they make up for it masterfully with the quality of their titles and classic franchises.
Ok, this is simply wrong. I will do my best not to let it propagate.
My current work is leading the XBox port of a PS2 engine for a major upcoming title. The Game Cube port was canceled half way through our development.
The Game Cube does not, _by far_, have the best development kit. Its not as bad as for the PS2, but there is no productivity boost there at all. Quite the opposite. The Cube lacks memory and DVD space; has fewer controller buttons, big endian vs. little endian. Fitting the same game as for PS2 on the Cube is twice the work. The graphics chip and memory cache is quite capable, but thats about it. It is so lacking in installed based and hardware compared to XBox and PS2 that often it does not make financial sense to support it, unless you're Nintendo or an exclusive developer.
The PS2, I've heard from collegues, is like writing a graphics card driver from scratch. You have fine-grained low level control, but you pay for it in complexity and arcane assembly coding. Support and docs are poor.
The XBox has _the best_ development kit, support and documentation. Its better than D3D SDK on a PC. Using an NVidia GPU it can do the most complex texture blending operations. XBox signature look is shiny bump-mapped environment maps and (simple) stencil shadocws. However the PS2 has far more fill rate/bandwidth which clever artists can use to great effet with particle systems, multi-layer polys etc.
Most developers care about the installed base of a platform first, and the PS2 wins hands down.
The game I am working on right now is a week before Beta. I work for a medium sized publisher of console games. Take that as warning of my bias.
I would add several reasons to why game development is hard. All the technical issues Mr. Blow mentions, can be fixed given enough time. But there is never enough time.
To keep funding $10M+ game projects, a corporation needs to release a steady stream of games during major buying periods. This means, unless you're the likes of id or Valve, development cycles are 18 months, rarely negotiable. If you are late you will start loosing consumer awarness and marketing budgets. You also need to schedule time to do several demo disks and generate assets for the media. A senior programmer said that our primary target is management, and only later the gamer.
Second, unlike many software markets, you constantly feel your competition at your heels. The graphics, realism, complexity is an arms race. This makes games better and it also makes developers stay at work extra longer past midnight to implement that extra rocket launcher effect to stand out from the competition.
Then the market judges you on purely subjective measures. You can't lock yourself into a market like MS Office or Windows would. It doesn't even matter if you are technically the most advanced. As a game developer you are fighting for gamers attention. This is why you see games that are mostly sequels and based on established IP.
Then again these challanges are the reason I'm a game developer. Mr.Blow does point out a good deal of inneficient practices in the industry.
This should be seen as a call to arms for middle ware vendors and ISVs. Whenever there is a problem there is a buisness plan!
first off, excellent points. took some thinking, but I'm back to my original argument.
One rendering engine can gracefully handle all those features based on the artwork and shader programs it reads in.
That would be true if we have interactive engines that can render arbitrary detailed and large geometry with negligable pre-processing.
Unlike in off-line rendering world, the rendering engine will be tightly bound to geometry management part of the engine for the forseable future. You will always be able to squeeze out extra detail, or effects while trying to keep above 30fps by attacking the problem from new directions.
The rendering engine is only a small part of a full 3d engine and Carmack is merely observing that part is soon going to be as good as it can/need be.
Maybe he speaks of a very narrow geometry and material pusher part of the rendering engine. In that case OpenGL has been shown to emulate full RenderMan shaders for some time, but was not interactive or practical. I took the rendering engine to include geometry management needed for rendering (culling, shadow geometry, lod, impostors etc.) and graphic rendering algorithsm inherently dependent on it.
Real-time graphics engines will always be constrained. Better hardware allows us to lessen these constrains. I think that is what Carmack suggests; because of this we may reach some temporary plateu, shift focus to GPU programming. However this just opens up the possibility of new techniques where engine re-design again becomes necessary. I don't deny that engines will be more data driven, less hardwired and graphics programming will increasingly target the GPU. But this will not stop engine design. This is no different than arguments that using hardware acceleration limits the innovation possible with writing your own software rasterizer.
Look at the innovation done in high-end off-line CGI. You got the dominant approach (ILM & Pixar) to build your rendering up from insanely detailed geometry and shaders. Thats been around for a while. Yet the special effects on the Matrix (forgot what the studio there is) are pushing image based rendering to its limits. Two radically different _rendering_ approaches even when rendering what thought to be mostly solved.
Carmack sugests that the only the _rendering_ engine will soon become stable and future improvements will be only incremental.
This does not mean that engine programmers will be obsolete, relegated to support and optimization or that innovation slows down. Doom III and Quake engines has been optimized for tight, enclosed indoor spaces. There are lot of different possibilities not yet explored.
Just off the top of my head I can imagine game engine technology spanning a decade into the future:
- soft shadows or realtime radiosity lighting. This might be not that far off, but a lot of intersting research will be involved on top of current stencil-buffer and projected depth map based techniques.
- high dynamic range (hdr) light calculation across the entire pipeline, including effects like light bloom and hdr reflections. you start to see some of this in Splinter Cell.
- real-time, arbitrary resolution, procedurally generated texture maps and generated displacement maps (ex. RenderMan). The previous methods of doing texturing progressed from manually shaded (doom-quake3), to manually colored with normal maps for shading (doom3). The general case would be to use nothing except procedural shaders and geometry to generate all detail before approximated by texture maps.
- arbitrarily dynamic solid world geometry. Current renering engines work with a heavily pre-processsed visible shell of the world, which can be modified only in special rigid cases. It will take some effort for an engine to deform or destroy arbitrary world geometry. Imagine taking off a chunk of the wall and seing the layers of concrete underneath, then having the building collapse when supports are removed.
As the last point suggests some time into the future the latest engine might be quite exotic compared to the current ideas. I can imagine a type of voxel based representation with some image based rendering.
Innovation will never stop.
Re:A (hopefully) unbiased opinion on Perl v. Pytho
on
Python in a Nutshell
·
· Score: 4, Insightful
My own opinion, like yours, is biased by the specific problem domain I applied Python to. For me that has been sys-admin scripts and network/cgi automation scripts.
How is the ability to write a Python compiler in itself practially relevant to most users?
Lack of strong typing and no support for data hiding can be thought of as a feature by those so inclined. This is just analogous to objections against 'whitespace sensitivity'.
I more closely agree with one of the replies: that Python suffers from horrible documentation. I recommend looking at ActiveState Python for a slight improvement from the web manual.
Some _personal_ highlights using python:
- learning curve duration: 1.5 hours to start writing moderate complexity RE file parsing scripts.
- ability to write a cgi enabled http server in approx 3 lines of code
- ability to write a decent cross-platform opengl demo in approx 200 lines of code. using PyGame, PyOpenGL, Numeric etc.
Also, please just ignore the zealots, don't acknowledge them with so much disclaimer.
Can anybody tell me how the JavaScript engine interacts with the game? Do they somehow intercept all player input (key, mouse etc.) and let the script generate those inputs? Or is there some other hackery at work? Docs are brief on this.
Any chance the same ideas could be used for other games? A general game scripting environment? It would free all those everquest addicted people, or at least let them go to the bathroom once in a while.
I would imagine that the paranoid US government would see growing tide private-sector rocketry as a major annoyance. They can claim anything from military radar interference to plausible methods of chemical and warhead delivery and use that to stop many legitimate efforts at small-scale and highly innovative engineering. I've read from John Carmack's posts somwhere that Armadillo Aerospace does not publish their flight control software for worry of illegitimate use.
Does anybody know how understanding the post 9/11 government is to private sector rocketry and what hoops you have to go through to get clearance for high altitude flights?
This is already possible thanks to the great GPL licensing by Trolltech. Here is what you need to get started
- Linux kernel with frambuffer support - GPL version of Qt/Embedded - GPL version of Qtopia SDK - Lots of new apps ported and written for Qtopia
This is excellent to get your old 486s and old laptops going. You can also mix and match with uClib and some tiny linux distros. How long before we have a new linux Qtopia distro?
If you had a "scale-free" network, AFAIK you have an unlimited amount of independent computational nodes, most NP problems would be trivial to solve in polynomial time. Imagine, just spawn a new node for each possible solution to the problem. Each node can check if its solution is valid in polynomial time.
This is similiar how genetic algorithms should be executed. Each packet of genetic information in such an algorithm is a point in a very large state space you're searching for optimal solutions. Each mutation is a random jump around that state pace, and the fitness function tries to seek a local optimal point.
Except in the 'real-world' this algorithm is not executed linearly, but concurrently. Each animal is an concurrent node able to spawn an arbitrary amount of new nodes.
Your computational power then grows exponentially, not the problem. (Sounds like in mother Russia... eh, not worth it).
How to factor prime numbers really quickly: advance nano-technology to the point where your nano-pc is able to construct duplicates of themselves when you issue a fork() command.
Back when Intel just released early 75Mhz and 100Mhz Pentiums, Alpha with their advanced CMOS process was pushing 600Mhz on RISC chips.
Nobody bought it.
Their sales people couldn't convince consumers that superior technology was worth the price. They generated no excitement! They hoped that the technology could speak for itself.
I've been told by a long time Alpha engineer that long time clients would call him directly asking about new products, bypassing the sales rep. At the same time Sun sales team was attacking like wolves and stole the high end server market.
The result is that Intel now owns most of Alpha technology including the engineering teams. The last Alpha EV7 system can do up to 256 MP, and 256GB RAM, all on high speed ultra-wide packet switched interconnect bus. HP has to play down its performance to justify moving to Itanium servers.
The first Itanium has problems with more than 4 MP. Thank you Mr. Capellas.
Slashdot Mirror
The problem with many game related OSS projects is that they are started by people with little industry experience. Often these projects are demos to get into the industry or get a publishing deal. Once inside the industry you have no time to give away to an OSS project. There are notable exceptions: Nebula Device, Quake1&2 engines.
I've followed several OSS game projects (Ogre3D, crystal space engine, stuff on flipcode etc.). Many of these fizzle out within a year. Most are not designed to handle a full scale production. For instance almost no OSS game project focuses on the asset management and export pipeline. This comes from the fact that linux has no workable free 3d editor yet. A workable editor is defined as something that a team of artist would like to spend a year or two working with. Blender does not fall under that category.
Also, games have a very short lifetime. If you're giving away your time (thus money) for free, you at least hope it has a lasting effect, the way a constatly evolving operating system might have.
Howerver if somebody does figure out a good buisness model of how to run an OSS game project, it wont be that difficult to match features of the XNA platform. It seems it took Microsoft 9 generations of DirectX and a seperate team working on XBox to learn how not to screw up game development tools with classic MS cruft.
That dosn't work if a developer is pushing the absolute limits of PS2 or XBOX. GC has a hard time competing unless you are shooting for some common demoninator performance target.
So you compress the hell out of your vertices and textures no matter what the platform. Thats the whole point of consoles. Cube has S3TC, XBox has DXT, PS2 is optimized for palettized textures. All platforms can use vertex compression tricks. You can try to stream more to get around lack of RAM, but all you have a measly mini-disk in the end. And then you need to compress buttons..
Beyond a some limit you need to make platform dependent art assets. It starts to become expensive to support a port for a platform with the lowest installed base. Thats a decision for each company to make, but Nintendo is loosing out by having hardware so far below its competition. This is the first generation of platforms where cross platform development is common.
Granted they make up for it masterfully with the quality of their titles and classic franchises.
Ok, this is simply wrong. I will do my best not to let it propagate.
My current work is leading the XBox port of a PS2 engine for a major upcoming title. The Game Cube port was canceled half way through our development.
The Game Cube does not, _by far_, have the best development kit. Its not as bad as for the PS2, but there is no productivity boost there at all. Quite the opposite. The Cube lacks memory and DVD space; has fewer controller buttons, big endian vs. little endian. Fitting the same game as for PS2 on the Cube is twice the work. The graphics chip and memory cache is quite capable, but thats about it. It is so lacking in installed based and hardware compared to XBox and PS2 that often it does not make financial sense to support it, unless you're Nintendo or an exclusive developer.
The PS2, I've heard from collegues, is like writing a graphics card driver from scratch. You have fine-grained low level control, but you pay for it in complexity and arcane assembly coding. Support and docs are poor.
The XBox has _the best_ development kit, support and documentation. Its better than D3D SDK on a PC. Using an NVidia GPU it can do the most complex texture blending operations. XBox signature look is shiny bump-mapped environment maps and (simple) stencil shadocws. However the PS2 has far more fill rate/bandwidth which clever artists can use to great effet with particle systems, multi-layer polys etc.
Most developers care about the installed base of a platform first, and the PS2 wins hands down.
The game I am working on right now is a week before Beta. I work for a medium sized publisher of console games. Take that as warning of my bias.
I would add several reasons to why game development is hard. All the technical issues Mr. Blow mentions, can be fixed given enough time. But there is never enough time.
To keep funding $10M+ game projects, a corporation needs to release a steady stream of games during major buying periods. This means, unless you're the likes of id or Valve, development cycles are 18 months, rarely negotiable. If you are late you will start loosing consumer awarness and marketing budgets. You also need to schedule time to do several demo disks and generate assets for the media. A senior programmer said that our primary target is management, and only later the gamer.
Second, unlike many software markets, you constantly feel your competition at your heels. The graphics, realism, complexity is an arms race. This makes games better and it also makes developers stay at work extra longer past midnight to implement that extra rocket launcher effect to stand out from the competition.
Then the market judges you on purely subjective measures. You can't lock yourself into a market like MS Office or Windows would. It doesn't even matter if you are technically the most advanced. As a game developer you are fighting for gamers attention. This is why you see games that are mostly sequels and based on established IP.
Then again these challanges are the reason I'm a game developer. Mr.Blow does point out a good deal of inneficient practices in the industry.
This should be seen as a call to arms for middle ware vendors and ISVs. Whenever there is a problem there is a buisness plan!
first off, excellent points. took some thinking, but I'm back to my original argument.
One rendering engine can gracefully handle all those features based on the artwork and shader programs it reads in.
That would be true if we have interactive engines that can render arbitrary detailed and large geometry with negligable pre-processing. Unlike in off-line rendering world, the rendering engine will be tightly bound to geometry management part of the engine for the forseable future. You will always be able to squeeze out extra detail, or effects while trying to keep above 30fps by attacking the problem from new directions.
The rendering engine is only a small part of a full 3d engine and Carmack is merely observing that part is soon going to be as good as it can/need be.
Maybe he speaks of a very narrow geometry and material pusher part of the rendering engine. In that case OpenGL has been shown to emulate full RenderMan shaders for some time, but was not interactive or practical. I took the rendering engine to include geometry management needed for rendering (culling, shadow geometry, lod, impostors etc.) and graphic rendering algorithsm inherently dependent on it.
Real-time graphics engines will always be constrained. Better hardware allows us to lessen these constrains. I think that is what Carmack suggests; because of this we may reach some temporary plateu, shift focus to GPU programming. However this just opens up the possibility of new techniques where engine re-design again becomes necessary. I don't deny that engines will be more data driven, less hardwired and graphics programming will increasingly target the GPU. But this will not stop engine design. This is no different than arguments that using hardware acceleration limits the innovation possible with writing your own software rasterizer.
Look at the innovation done in high-end off-line CGI. You got the dominant approach (ILM & Pixar) to build your rendering up from insanely detailed geometry and shaders. Thats been around for a while. Yet the special effects on the Matrix (forgot what the studio there is) are pushing image based rendering to its limits. Two radically different _rendering_ approaches even when rendering what thought to be mostly solved.
Carmack sugests that the only the _rendering_ engine will soon become stable and future improvements will be only incremental.
This does not mean that engine programmers will be obsolete, relegated to support and optimization or that innovation slows down. Doom III and Quake engines has been optimized for tight, enclosed indoor spaces. There are lot of different possibilities not yet explored.
Just off the top of my head I can imagine game engine technology spanning a decade into the future:
- soft shadows or realtime radiosity lighting. This might be not that far off, but a lot of intersting research will be involved on top of current stencil-buffer and projected depth map based techniques.
- high dynamic range (hdr) light calculation across the entire pipeline, including effects like light bloom and hdr reflections. you start to see some of this in Splinter Cell.
- real-time, arbitrary resolution, procedurally generated texture maps and generated displacement maps (ex. RenderMan). The previous methods of doing texturing progressed from manually shaded (doom-quake3), to manually colored with normal maps for shading (doom3). The general case would be to use nothing except procedural shaders and geometry to generate all detail before approximated by texture maps.
- arbitrarily dynamic solid world geometry. Current renering engines work with a heavily pre-processsed visible shell of the world, which can be modified only in special rigid cases. It will take some effort for an engine to deform or destroy arbitrary world geometry. Imagine taking off a chunk of the wall and seing the layers of concrete underneath, then having the building collapse when supports are removed.
As the last point suggests some time into the future the latest engine might be quite exotic compared to the current ideas. I can imagine a type of voxel based representation with some image based rendering.
Innovation will never stop.
My own opinion, like yours, is biased by the specific problem domain I applied Python to. For me that has been sys-admin scripts and network/cgi automation scripts.
How is the ability to write a Python compiler in itself practially relevant to most users?
Lack of strong typing and no support for data hiding can be thought of as a feature by those so inclined. This is just analogous to objections against 'whitespace sensitivity'.
I more closely agree with one of the replies: that Python suffers from horrible documentation. I recommend looking at ActiveState Python for a slight improvement from the web manual.
Some _personal_ highlights using python:
- learning curve duration: 1.5 hours to start writing moderate complexity RE file parsing scripts.
- ability to write a cgi enabled http server in approx 3 lines of code
- ability to write a decent cross-platform opengl demo in approx 200 lines of code. using PyGame, PyOpenGL, Numeric etc.
Also, please just ignore the zealots, don't acknowledge them with so much disclaimer.
all the best,
mbaranow
Can anybody tell me how the JavaScript engine interacts with the game? Do they somehow intercept all player input (key, mouse etc.) and let the script generate those inputs? Or is there some other hackery at work? Docs are brief on this.
Any chance the same ideas could be used for other games? A general game scripting environment? It would free all those everquest addicted people, or at least let them go to the bathroom once in a while.
I would imagine that the paranoid US government would see growing tide private-sector rocketry as a major annoyance. They can claim anything from military radar interference to plausible methods of chemical and warhead delivery and use that to stop many legitimate efforts at small-scale and highly innovative engineering. I've read from John Carmack's posts somwhere that Armadillo Aerospace does not publish their flight control software for worry of illegitimate use.
Does anybody know how understanding the post 9/11 government is to private sector rocketry and what hoops you have to go through to get clearance for high altitude flights?
This is already possible thanks to the great GPL licensing by Trolltech. Here is what you need to get started
- Linux kernel with frambuffer support
- GPL version of Qt/Embedded
- GPL version of Qtopia SDK
- Lots of new apps ported and written for Qtopia
This is excellent to get your old 486s and old laptops going. You can also mix and match with uClib and some tiny linux distros. How long before we have a new linux Qtopia distro?
Just off the top of my head here:
If you had a "scale-free" network, AFAIK you have an unlimited amount of independent computational nodes, most NP problems would be trivial to solve in polynomial time. Imagine, just spawn a new node for each possible solution to the problem. Each node can check if its solution is valid in polynomial time.
This is similiar how genetic algorithms should be executed. Each packet of genetic information in such an algorithm is a point in a very large state space you're searching for optimal solutions. Each mutation is a random jump around that state pace, and the fitness function tries to seek a local optimal point.
Except in the 'real-world' this algorithm is not executed linearly, but concurrently. Each animal is an concurrent node able to spawn an arbitrary amount of new nodes.
Your computational power then grows exponentially, not the problem. (Sounds like in mother Russia... eh, not worth it).
How to factor prime numbers really quickly:
advance nano-technology to the point where your nano-pc is able to construct duplicates of themselves when you issue a fork() command.
Like I said, talking out of my ass.
Back when Intel just released early 75Mhz and 100Mhz Pentiums, Alpha with their advanced CMOS process was pushing 600Mhz on RISC chips.
Nobody bought it.
Their sales people couldn't convince consumers that superior technology was worth the price. They generated no excitement! They hoped that the technology could speak for itself.
I've been told by a long time Alpha engineer that long time clients would call him directly asking about new products, bypassing the sales rep. At the same time Sun sales team was attacking like wolves and stole the high end server market.
The result is that Intel now owns most of Alpha technology including the engineering teams. The last Alpha EV7 system can do up to 256 MP, and 256GB RAM, all on high speed ultra-wide packet switched interconnect bus. HP has to play down its performance to justify moving to Itanium servers.
The first Itanium has problems with more than 4 MP. Thank you Mr. Capellas.