The legal system has always made sense in respect to these issues. The only reason why the RIAA got as far as they did as quickly as they did is that they had the element of surprise. (In a military sense.) They were able to use that surprise of legal threat to do quite a bit of damage before the legal war machine spun up to full defensive power. Now that things are spun up, the system is slowly beginning to repel the RIAA attacks.
I'm sure if you stubbed out the parts requiring the special hardware and replaced them with software implementations you could probably get it to work, but that would require some effort in essentially updating the OS.
=OR= we could get someone to develop an FPGA version of the MULTICS system. The machine was big, but today's FPGAs should be able to encapsulate all the hardware services originally available to the system. Certainly there's enough room for the CPU, a controller for a 2MB stick of RAM (though it might need to be larger to support 36-bit words if the chosen RAM is only byte addressable), and an interface to a Flash drive or hard disk. Tack some terminal hardware on the PCB and you're golden.
Never underestimate the modern potential for recreating old hardware.:)
it would be incredibly easy to decompile the bytecode back to Java source.
#1 Who cares? Only young'uns with little experience with how the industry works actually care about someone "stealing" their (incredibly boilerplate, easy to duplicate, hard to integrate into my own project) source code. Did you know that it's easy to "decompile" your HTML, Javascript, Actionscript, PERL, Python, Ruby, Shell scripts, and even Assembler too?
Oh noes! Do not want!
#2 The "Java" that runs on the phone isn't Java at all. Java is used as a development language, and is actually compiled down to Google's Dalvik VM instead. Thus while it will still be decompilable (there's no such thing as code that can't be decompiled) it might be made more difficult by the non-standard bytecode.
One of the current problems with mobile Java development is that Java has fragmented... Java virtual machines have fragmented
Whoa, he-llo? That's a rather interesting (and bold!) statement to be making there. I don't know if Google has noticed, but J2ME phones all run the same code and the same APIs. Issues between phones almost always come down to working around JVM implementation bugs. Which isn't that huge of a deal when you consider that "porting" then becomes a straightforward matter of applying a minor patch between "versions". (Often you can just inline the workarounds and have a single version that works everywhere.)
Meanwhile, Google has created a JVM that's not actually a JVM, that's incompatible with the J2ME/MIDP standard, and then has the gall to claim they're the solution to a more or less non-existent problem? That's ballsy even for Google.:-/
"First of all, it wants to put Google search on a phone. It wants to do this because it is obvious to the folks at Google that people need to do Web searches from their phone, so they can, uh, get directions to the restaurant? Of course, they can simply use the phone itself to call the restaurant and ask!"
Sounds like the parody I did of Dvorak a while back:
"Starbucks needs drive-up windows because they are planning to bring that same environment to your vehicle! That's right, Starbucks wants to give you that same coffee-saturated, easy listening, comfortable seating feeling you get in their stores, but in your car. [...] Starbucks is going to make cars."
The purpose of the article is Flash Games in specific. So your examples are neither here nor there. Personally, I'm amazed that no one has mentioned Newgrounds Rumble, one of the best brawlers of all time! It was one of the highest rated games over on Newgrounds, and hung around for AGES. More recently, it was ported to WiiCade so that you could play against your friends on the WiiMote controller. (Which is a lot more fun than trying to share a keyboard, let me tell you.)
Actually, I should probably expand on that a bit more. One of the nice things about the Wii is that you can have multiplayer flash games. Games like Wiimote Wars 2 and Slipstream are simply amazing when you get the chance to play against your friends and family members. Much, much, much better than playing single-player games. Which is good, because there isn't much in the way of online-multiplayer flash games.
Of course (DISCLAIMER!), I both have a family to play these games with and I have connections to WiiCade. So feel free to take what I'm saying with a grain of salt.
As you may have figured out, that's not the real Miguel. This is his doppelgänger who tries to be funny. "What about mono?" is obviously a gag based on how hard Miguel tries to push Mono as being a one-true-OSS-replacement-for-Java-that-is-potentially-encumbered-but-you're-supposed-to-trust-Miguel-that-it's-not.
I dunno. I chuckled. Mods, make your own decision.
And personal backups of your own media so that you don't have to buy a new copy when your friend/pet/child/"significant other" scratches it.
While I agree on the Wii discs, the truth of the matter is that it is probably illegal to backup DS chips. According to the decision of Atari v. JS&A, backups are only authorized when they're necessary to protect against "mechanical or electrical failure" of the cartridge. Given that DS media is similarly sturdy, a US court would be likely to rule in the same manner.
However, the question that remains is: Do these chips have other legal uses? In the case of DS games, that somewhat depends on whether or not these chips are the ones used by homebrewers. If they are, then you have a significant legal use right there. (This was a defense that JS&A attempted, but was unsuccessful as console homebrew communities did not really exist back in the '80s.) If homebrewers use a different set of chips, then I'm afraid that our HK friends have no real legal leg to stand on here in the US, either.
Shoot'em ups, actually. The vast majority of new Dreamcast titles were ports from the arcade hardware that was based on the Dreamcast's specs. (i.e. The NAOMI board.) Since it's easy money, companies that use the NAOMI board in their games almost always port them to the Dreamcast home system. With shoot'em ups still extremely popular in Japan's arcades, that means that some rockin' shmups make it to the market over there.
If you know where to look, you can easily purchase an import copy and use it on a US Dreamcast via a freely downloadable boot disk. My only warning is that these games ARE direct arcade ports. So if you're looking for a good value out of the $70 you're going to spend on an import, don't expect to find it unless you're a hardcore shmup fan. 5 levels that can be completed in about 15 minutes is only worth it if you're the type to play it again and again trying to best yourself.
In other words, when was the last time you saw an Atari 5200 game hit the market?
The much anticipated Adventure IIfinally hit the market just a few months ago. Though I'll grant you that new games for the 5200 are nowhere near as common as the Atari 2600 releases. The 2600 is just more popular, I'm afraid.:P
WTF are you talking about? Wear leveling is usually paired with ECC to prevent exactly the types of issues you're talking about. The technology is almost exactly the same as ECC hard drive technology. Detect a bad sector, mark it as bad, remap the sector, rewrite data to new sector. Rinse and repeat.
Naive storage devices like you describe haven't been common for quite a few years now.
'Hybrid we consider to be a Band-Aid approach to solid state,' said Marc Diana
Now there's a misleading quote if I ever heard one. Magnetic drives currently allow for storage of 250GB and up for a cost of $0.50/GB or less. In comparison, Flash Drives are are still measured in dollars per GB. The hybrid drive allows a bit of a tradeoff. A fast storage cache combined with massive space in exchange for a slight increase in price. Thus it's possible to have 1TB or more of storage, but with the performance characteristics of Flash memory under most circumstances.
What if the OS decides to write stuff to certain sectors all the time?
Most flash controllers remap the sectors on the fly to ensure that the memory is not worn down prematurely. So if you rewrite the same logical sector 5 times over, a chance exists that you'll get 5 different physical sectors.
Getting a no-compromise web experience on devices requires significant memory (>=64MB) as well as significant CPU horsepower. High end devices today are just approaching these requirements and will be commonplace soon For example, the iPhone has 128MB of DRAM and somewhere between a 400 to 600 MHz processor. It is somewhere between 10x-100x slower on scripting benchmarks than a new MacBook Pro and somewhere between 3-5x slower than an old T40 laptop on the same wifi network. But rapid improvements in mobile processors will close this gap within a few years.
I find this to be a rather shocking statement. The author is claiming that a handheld that meets the minimum requirements for a modern web browser on a desktop OS is not quite sufficient to run an embedded version? If that's really the consensus of the Mozilla developers, then my opinion is that they need to reevaluate how their approaching phone handsets. It is not a desktop platform, nor will you get the best experience by treating a handset as a desktop platform. As Apple and Opera have been showing with their embedded browsers, the interface should be designed around the phone rather than forcing the phone to be designed around the interface.
...skip cut scenes using a non-gameplay key. There's nothing more annoying than missing an important cut-scene because you accidentally hit the Fire button. Especially when the cut scenes intrude on the game suddenly and unexpectedly.
There is one of the items I disagree with:
8. Never use insipid, indefensible enemy attacks. "It's impossible to get out of the way every third attack!" I shout at the on-screen boss in despair. Ah, the indefensible enemy blitzkrieg. This technique was more prevalent in the age of quarter-munchers where arcade makers needed to extend profits at the expense of cheap gameplay, but any remnants of this move should be completely abolished from interactive entertainment.
One man's "impossible" is another man's "challenge". Just because it's impossible for you doesn't mean that it's truly impossible. Go check out some Youtube videos of people playing a Bullet-hell shmup on one life. Inspiring feats, to say the least. Yet I know that I need infinite lives to pass these games because I'm simply not that good. Therefore, #8 should really say, "Know thy audience." That way you'll make sure you put the right level of difficulty in the right game.
You're making the assumption that the ISS should have been built in the first place. Allow me to reassure you, it should not have. The original plan for Space Station Freedom was as a LEO rendezvous point for lunar-bound astronauts. The shuttle was the first stage, the station was the second stage, and a lunar-transfer vehicle would have been the third stage. (Actually, the shuttle was originally only supposed to be transportation. The heavy lifting was supposed to be done by the Saturn V. Instead, Nixon demanded that the Shuttle do both. But I digress.)
When Congress saw the price tag, however, they balked. They told NASA that they needed additional international funding if they the support of congress. So NASA talked with a few other countries (including the now democratic Russia) about getting the funding they needed. Russia told NASA that they would only get money and support if the station was located in an orbit that was easier for Russian spacecraft to reach. Of course, that same orbit made the station worthless (fuel-wise) as a lunar-staging point.
There's more to the story after that, but suffice it to say that the station shouldn't exist. It was a political boondoggle that never truly met anyone's needs. It mostly just hangs there showing the flag. Once the space shuttle is retired, there will be no way of properly maintaining the ISS. If new vehicles aren't developed to reboost the ISS regularly (e.g. robotic boosters) the ISS will simply fall into the atmosphere and burn up.
Now before you decide to interject with, "But we've already payed hundreds of millions to built it! It must be useful for something!" allow me to point you to this link:
If I have a single sphere in my scene, it will render incredibly quickly whether I render it at 320x200 or 1600x1200. The former requires 64,000 rays while the latter requires 1,920,000 rays. However, the scale is completely linear meaning that I pay the exact same amount for each ray added to the rendering of a frame.
Geometry has a much greater impact on the scene as the cost of each ray goes up with the increase in geometric complexity. Spacial divisions like bounding boxes can be used to lower the cost, making it slightly more dependent on the density and visible bounds of the scene rather than the world as a whole.
The good news is that ray tracing is a highly parallel operation. Which means that rendering time can be nearly scaled linearly by adding more processors to the mix. (I say "nearly" because the standard issues of managing and feeding a multiple processors still applies as long as they share the same memory and bus.)
Normally you don't use BSP trees. BSP is designed to solve Z-Ordering issues. Something which ray tracing was actually invented to solve. Thus the space division tends to happen on a broader level involving more dynamic spacial trees and bounding boxes, which are used to locate the likely candidates for ray intersections.
Of course, I don't know how the Intel technology works in detail, but the types of data structures used are usually a bit different from traditional polygon engines. Especially when your ray engine supports more sophisticated geometries like spheres, boxes, cylinders, and ellipsoids.
It's the number of objects in this case. As the AC said, that could mean triangles. Or it could mean spheres, cubes, cylinders, ellipsoids, and other mathematically describable geometries. What shapes are supported depends on the actual rendering engine itself. Some computations are stupidly simple for raytracers (e.g. perfect spheres) while others are slightly more computationally intensive (e.g. ellipsoids). Thus depending on the tradeoffs of the engine, 'n' could represent the total number of polygons in the meshes, the number of geometric objects in the scene, or a combination thereof.
They would instead be limited by the other kinds of data structures and algorithms you need to make raytracing in realtime feasible.
Of course. Such is the nature of the beast. The key is that it will be a different set of limitations. The key features (e.g. high detail, large number of objects, simplified lighting) are present in nearly every real-time raytracing engine I've seen. Which means that these features are something programmers will most likely be able to count on.:-)
Simply means games will appear more eye-candy than they currently are. Gameplay will not change.
Untrue! Ray Tracing is a lot more flexible method of rendering than previous engines have allowed. Many engines have claimed features like "destructible levels and terrain", but the engines were never fast enough to give both the eye candy demanded by the market and an engine capable of such free-form interaction. Ray Tracing could change all that. Programmers could no longer be limited by BSP trees, visibility trees, polygon count, and other requirements imposed on traditional engines.
Graphics-wise, ray tracing could open new doors as well. For example, 3D adventure games haven't really taken off because it's harder to insert clues in the areas. A painting on a wall, for example, will tend to be slightly too blurry to see a clue embedded in it in a true 3D environment. Ray tracing allows for more precise rendering that would make the painting crystal clear from all perspectives and distances. Which means that the game designer could actually make it visible that the subject of the painting is pointing at a hidden door without making it so obvious that it destroys the enjoyment of the puzzle.
What I'm getting at is that graphics improvements have been one of the factors that have allowed game creators to explore new game genres in the past. While the 3D-age has often focused on rendering quality to the point of forgetting the purpose of graphical improvements, that's not to say that a major switch in technologies couldn't bring new gaming experiences with it.
Reading the (now Slashdotted) article, it sounds like this design came directly out of research done into antimatter catalyzed micro-fission. ACMF is a well-proven technology that uses minuscule amounts of antimatter to kickstart or enhance a fission reaction. Because the technology was fairly straightforward and had good returns for antimatter quantities that are reasonable to produce, NASA was funding research into an engine called ICAN.
I remember that there was some talk of actually launching a small probe based on the concept, but apparently the plan was scrapped. (Probably to help fund manned space travel.) Whatever antimatter confinement technologies they were working on may have led to the development of this new magnetic confinement fission technology. Or it could just be a coincidence.
Either way, nuclear technology of this sort is fairly well developed and is not a pipe dream. At least not from an engineering standpoint. Getting the risk adverse US Government and NASA to actually build one of the many known-quantity engines we have on hand is a completely different ball of wax. They're still trying to get us reliable LEO access (Thank God for Griffin is all I can say), so I doubt we'll be seeing any advanced engines in practice until the CEV/Orion project enters its third phase.
Slashdot Mirror
The legal system has always made sense in respect to these issues. The only reason why the RIAA got as far as they did as quickly as they did is that they had the element of surprise. (In a military sense.) They were able to use that surprise of legal threat to do quite a bit of damage before the legal war machine spun up to full defensive power. Now that things are spun up, the system is slowly beginning to repel the RIAA attacks.
=OR= we could get someone to develop an FPGA version of the MULTICS system. The machine was big, but today's FPGAs should be able to encapsulate all the hardware services originally available to the system. Certainly there's enough room for the CPU, a controller for a 2MB stick of RAM (though it might need to be larger to support 36-bit words if the chosen RAM is only byte addressable), and an interface to a Flash drive or hard disk. Tack some terminal hardware on the PCB and you're golden.
Never underestimate the modern potential for recreating old hardware.
#1 Who cares? Only young'uns with little experience with how the industry works actually care about someone "stealing" their (incredibly boilerplate, easy to duplicate, hard to integrate into my own project) source code. Did you know that it's easy to "decompile" your HTML, Javascript, Actionscript, PERL, Python, Ruby, Shell scripts, and even Assembler too?
Oh noes! Do not want!
#2 The "Java" that runs on the phone isn't Java at all. Java is used as a development language, and is actually compiled down to Google's Dalvik VM instead. Thus while it will still be decompilable (there's no such thing as code that can't be decompiled) it might be made more difficult by the non-standard bytecode.
Whoa, he-llo? That's a rather interesting (and bold!) statement to be making there. I don't know if Google has noticed, but J2ME phones all run the same code and the same APIs. Issues between phones almost always come down to working around JVM implementation bugs. Which isn't that huge of a deal when you consider that "porting" then becomes a straightforward matter of applying a minor patch between "versions". (Often you can just inline the workarounds and have a single version that works everywhere.)
Meanwhile, Google has created a JVM that's not actually a JVM, that's incompatible with the J2ME/MIDP standard, and then has the gall to claim they're the solution to a more or less non-existent problem? That's ballsy even for Google.
It's scary how much this:
"First of all, it wants to put Google search on a phone. It wants to do this because it is obvious to the folks at Google that people need to do Web searches from their phone, so they can, uh, get directions to the restaurant? Of course, they can simply use the phone itself to call the restaurant and ask!"
Sounds like the parody I did of Dvorak a while back:
"Starbucks needs drive-up windows because they are planning to bring that same environment to your vehicle! That's right, Starbucks wants to give you that same coffee-saturated, easy listening, comfortable seating feeling you get in their stores, but in your car. [...] Starbucks is going to make cars."
The purpose of the article is Flash Games in specific. So your examples are neither here nor there. Personally, I'm amazed that no one has mentioned Newgrounds Rumble, one of the best brawlers of all time! It was one of the highest rated games over on Newgrounds, and hung around for AGES. More recently, it was ported to WiiCade so that you could play against your friends on the WiiMote controller. (Which is a lot more fun than trying to share a keyboard, let me tell you.)
Actually, I should probably expand on that a bit more. One of the nice things about the Wii is that you can have multiplayer flash games. Games like Wiimote Wars 2 and Slipstream are simply amazing when you get the chance to play against your friends and family members. Much, much, much better than playing single-player games. Which is good, because there isn't much in the way of online-multiplayer flash games.
Of course (DISCLAIMER!), I both have a family to play these games with and I have connections to WiiCade. So feel free to take what I'm saying with a grain of salt.
As you may have figured out, that's not the real Miguel. This is his doppelgänger who tries to be funny. "What about mono?" is obviously a gag based on how hard Miguel tries to push Mono as being a one-true-OSS-replacement-for-Java-that-is-potentially-encumbered-but-you're-supposed-to-trust-Miguel-that-it's-not.
I dunno. I chuckled. Mods, make your own decision.
While I agree on the Wii discs, the truth of the matter is that it is probably illegal to backup DS chips. According to the decision of Atari v. JS&A, backups are only authorized when they're necessary to protect against "mechanical or electrical failure" of the cartridge. Given that DS media is similarly sturdy, a US court would be likely to rule in the same manner.
However, the question that remains is: Do these chips have other legal uses? In the case of DS games, that somewhat depends on whether or not these chips are the ones used by homebrewers. If they are, then you have a significant legal use right there. (This was a defense that JS&A attempted, but was unsuccessful as console homebrew communities did not really exist back in the '80s.) If homebrewers use a different set of chips, then I'm afraid that our HK friends have no real legal leg to stand on here in the US, either.
Shoot'em ups, actually. The vast majority of new Dreamcast titles were ports from the arcade hardware that was based on the Dreamcast's specs. (i.e. The NAOMI board.) Since it's easy money, companies that use the NAOMI board in their games almost always port them to the Dreamcast home system. With shoot'em ups still extremely popular in Japan's arcades, that means that some rockin' shmups make it to the market over there.
If you know where to look, you can easily purchase an import copy and use it on a US Dreamcast via a freely downloadable boot disk. My only warning is that these games ARE direct arcade ports. So if you're looking for a good value out of the $70 you're going to spend on an import, don't expect to find it unless you're a hardcore shmup fan. 5 levels that can be completed in about 15 minutes is only worth it if you're the type to play it again and again trying to best yourself.
The much anticipated Adventure II finally hit the market just a few months ago. Though I'll grant you that new games for the 5200 are nowhere near as common as the Atari 2600 releases. The 2600 is just more popular, I'm afraid.
I call dibs on Lexa Doig!
WTF are you talking about? Wear leveling is usually paired with ECC to prevent exactly the types of issues you're talking about. The technology is almost exactly the same as ECC hard drive technology. Detect a bad sector, mark it as bad, remap the sector, rewrite data to new sector. Rinse and repeat.
Naive storage devices like you describe haven't been common for quite a few years now.
The term is "Wear Leveling", and it's built into standards like SD Cards. Doing a quick Google search produces white papers like this one:
http://www.stec-inc.com/downloads/AN-0702_STEC_SMALL_CARDS_WEAR_LEVELING_LIFETIME_CALCULATOR.pdf
Now there's a misleading quote if I ever heard one. Magnetic drives currently allow for storage of 250GB and up for a cost of $0.50/GB or less. In comparison, Flash Drives are are still measured in dollars per GB. The hybrid drive allows a bit of a tradeoff. A fast storage cache combined with massive space in exchange for a slight increase in price. Thus it's possible to have 1TB or more of storage, but with the performance characteristics of Flash memory under most circumstances.
Most flash controllers remap the sectors on the fly to ensure that the memory is not worn down prematurely. So if you rewrite the same logical sector 5 times over, a chance exists that you'll get 5 different physical sectors.
I find this to be a rather shocking statement. The author is claiming that a handheld that meets the minimum requirements for a modern web browser on a desktop OS is not quite sufficient to run an embedded version? If that's really the consensus of the Mozilla developers, then my opinion is that they need to reevaluate how their approaching phone handsets. It is not a desktop platform, nor will you get the best experience by treating a handset as a desktop platform. As Apple and Opera have been showing with their embedded browsers, the interface should be designed around the phone rather than forcing the phone to be designed around the interface.
There is one of the items I disagree with:
One man's "impossible" is another man's "challenge". Just because it's impossible for you doesn't mean that it's truly impossible. Go check out some Youtube videos of people playing a Bullet-hell shmup on one life. Inspiring feats, to say the least. Yet I know that I need infinite lives to pass these games because I'm simply not that good. Therefore, #8 should really say, "Know thy audience." That way you'll make sure you put the right level of difficulty in the right game.
DeBeers are evil and should be wiped off the face of the Earth. Not to be confused with DaBears. They just lose to the Packers all the time.
You're making the assumption that the ISS should have been built in the first place. Allow me to reassure you, it should not have. The original plan for Space Station Freedom was as a LEO rendezvous point for lunar-bound astronauts. The shuttle was the first stage, the station was the second stage, and a lunar-transfer vehicle would have been the third stage. (Actually, the shuttle was originally only supposed to be transportation. The heavy lifting was supposed to be done by the Saturn V. Instead, Nixon demanded that the Shuttle do both. But I digress.)
When Congress saw the price tag, however, they balked. They told NASA that they needed additional international funding if they the support of congress. So NASA talked with a few other countries (including the now democratic Russia) about getting the funding they needed. Russia told NASA that they would only get money and support if the station was located in an orbit that was easier for Russian spacecraft to reach. Of course, that same orbit made the station worthless (fuel-wise) as a lunar-staging point.
There's more to the story after that, but suffice it to say that the station shouldn't exist. It was a political boondoggle that never truly met anyone's needs. It mostly just hangs there showing the flag. Once the space shuttle is retired, there will be no way of properly maintaining the ISS. If new vehicles aren't developed to reboost the ISS regularly (e.g. robotic boosters) the ISS will simply fall into the atmosphere and burn up.
Now before you decide to interject with, "But we've already payed hundreds of millions to built it! It must be useful for something!" allow me to point you to this link:
http://en.wikipedia.org/wiki/Sunk_cost
If I have a single sphere in my scene, it will render incredibly quickly whether I render it at 320x200 or 1600x1200. The former requires 64,000 rays while the latter requires 1,920,000 rays. However, the scale is completely linear meaning that I pay the exact same amount for each ray added to the rendering of a frame.
Geometry has a much greater impact on the scene as the cost of each ray goes up with the increase in geometric complexity. Spacial divisions like bounding boxes can be used to lower the cost, making it slightly more dependent on the density and visible bounds of the scene rather than the world as a whole.
The good news is that ray tracing is a highly parallel operation. Which means that rendering time can be nearly scaled linearly by adding more processors to the mix. (I say "nearly" because the standard issues of managing and feeding a multiple processors still applies as long as they share the same memory and bus.)
Normally you don't use BSP trees. BSP is designed to solve Z-Ordering issues. Something which ray tracing was actually invented to solve. Thus the space division tends to happen on a broader level involving more dynamic spacial trees and bounding boxes, which are used to locate the likely candidates for ray intersections.
Of course, I don't know how the Intel technology works in detail, but the types of data structures used are usually a bit different from traditional polygon engines. Especially when your ray engine supports more sophisticated geometries like spheres, boxes, cylinders, and ellipsoids.
It's the number of objects in this case. As the AC said, that could mean triangles. Or it could mean spheres, cubes, cylinders, ellipsoids, and other mathematically describable geometries. What shapes are supported depends on the actual rendering engine itself. Some computations are stupidly simple for raytracers (e.g. perfect spheres) while others are slightly more computationally intensive (e.g. ellipsoids). Thus depending on the tradeoffs of the engine, 'n' could represent the total number of polygons in the meshes, the number of geometric objects in the scene, or a combination thereof.
Of course. Such is the nature of the beast. The key is that it will be a different set of limitations. The key features (e.g. high detail, large number of objects, simplified lighting) are present in nearly every real-time raytracing engine I've seen. Which means that these features are something programmers will most likely be able to count on.
Untrue! Ray Tracing is a lot more flexible method of rendering than previous engines have allowed. Many engines have claimed features like "destructible levels and terrain", but the engines were never fast enough to give both the eye candy demanded by the market and an engine capable of such free-form interaction. Ray Tracing could change all that. Programmers could no longer be limited by BSP trees, visibility trees, polygon count, and other requirements imposed on traditional engines.
Graphics-wise, ray tracing could open new doors as well. For example, 3D adventure games haven't really taken off because it's harder to insert clues in the areas. A painting on a wall, for example, will tend to be slightly too blurry to see a clue embedded in it in a true 3D environment. Ray tracing allows for more precise rendering that would make the painting crystal clear from all perspectives and distances. Which means that the game designer could actually make it visible that the subject of the painting is pointing at a hidden door without making it so obvious that it destroys the enjoyment of the puzzle.
What I'm getting at is that graphics improvements have been one of the factors that have allowed game creators to explore new game genres in the past. While the 3D-age has often focused on rendering quality to the point of forgetting the purpose of graphical improvements, that's not to say that a major switch in technologies couldn't bring new gaming experiences with it.
Reading the (now Slashdotted) article, it sounds like this design came directly out of research done into antimatter catalyzed micro-fission. ACMF is a well-proven technology that uses minuscule amounts of antimatter to kickstart or enhance a fission reaction. Because the technology was fairly straightforward and had good returns for antimatter quantities that are reasonable to produce, NASA was funding research into an engine called ICAN.
I remember that there was some talk of actually launching a small probe based on the concept, but apparently the plan was scrapped. (Probably to help fund manned space travel.) Whatever antimatter confinement technologies they were working on may have led to the development of this new magnetic confinement fission technology. Or it could just be a coincidence.
Either way, nuclear technology of this sort is fairly well developed and is not a pipe dream. At least not from an engineering standpoint. Getting the risk adverse US Government and NASA to actually build one of the many known-quantity engines we have on hand is a completely different ball of wax. They're still trying to get us reliable LEO access (Thank God for Griffin is all I can say), so I doubt we'll be seeing any advanced engines in practice until the CEV/Orion project enters its third phase.