Assuming the '138' patent is short for US patent # 6,200,138, I just checked and it was filled in 1998(!).
Between late 1994 and early 1995, I pitched a game idea to Disney (while I was an employee at WDI VR Studio) called "Wild Taxi," which was further developed for consideration as a new VR ride/game for DisneyQuest. That idea was fundamentally the same as Crazy Taxi, which I don't personally recall seeing as an arcade or console game for a few more years circa 1997 or 1998. I could have missed it, so please chime in if you know it existed prior to 1995 and I'll stand corrected.
I also believe it is now public knowledge that Disney and Sega were in various negotiations around the time of the Wild Taxi idea. Those talks didn't last long as far as I can tell, but at the time, I have every reason to believe the Wild Taxi ride idea was disclosed to Sega in a presentation of potential ride ideas.
For example, I recall seeing the storyboards Disney artists composed for these presentations. And I witnessed at least one such meeting between Disney and Sega, though I was not physically "in" the meeting (being a grunt, I sat outside an open meeting room). I also recall being told that Sega liked the ideas.
BTW, as far as I know, the reason Disney [DisneyQuest] didn't ultimately build this ride was technical, having to do with compelxity and throughput issues in an LBE environment for multiple participants. But that's a side issue.
I do not know if Sega had done prior work on "Crazy Taxi" before these meetings, but I have every reason to believe it was new idea at the time.
I also wouldn't know if Disney and Sega have come to some sort of prior agreement over this IP, which may in fact have transferred the various IP rights to Sega without much or any public comment. I can only speculate on the terms under which the ideas were disclosed.
I never sought credit for my contribution, nor do I seek any now. However, my personal opinion is that Disney should now disclose the "Wild Taxi" ride designs as they may potentially invalidate Sega's patent. If, indeed, Sega got the idea from our group at Disney, then this patent may be without merit and, IMO, would be incredibly obnoxious.
These are all my opinions and recollections and I do not claim to present any legal facts as such.
I've coded for Second Life in the past, so I don't want to dis There, but that Will Harvey quote honestly baffles me. Even the extended quote in the article seems out of touch. If you use SL, you'll see a scripting language that doesn't seem to have any of those problems (and no, I didn't work on that part).
The real problem with user scripting is that once you have the equivalent of magic in the world, you can really piss people off. And that's hard to sandbox or detect algorithmically. For example, it's difficult to tell the difference between user code that helps a friend levitate and one that keeps a victim pinned in place.
The real problem with user content in general is similar: you want to somehow reward and retain beneficial content and discourage the retention of crap. Let people build all the crap they want, but please take it down at the end of the day, okay?
Second Life has some interesting approches, including taxation and community rating. But, frankly, the crappy content problem is not solved in the real world either.
I'm just glad for anything that turns non-designers into even modest designers--in any world. For me, it was legos and computer graphics that got me thinking about aesthetics. The more ways, the better.
On perception, studies from the visual simulation field showed that 60HZ is plenty. In fact, having a solid 60HZ is inordinately better than a variable framerate, even if it was often higher. Motion seems smoother, temporal artifacts go away, and our brains can better predict motion, which leads to more of a feeling of "presence."
I wholly support locking the framerate, but I'd prefer if rendering locked to my actual monitor refresh rate, not only 60HZ. That's a bit too monolithic, especially when the problem of special jumps only working at 105fps or whatever is a problem of _simulation_ framerate, not rendering.
On simulation, 60HZ is not the gold standard. Physical simulations are often run higher for various reasons. Positions can be interpolated when graphics and simulation are not integer multiples. Not a problem. But locking the two makes some design issues simpler. Id may have some better way to do all this with a locked 60HZ. I don't know how dynamic their world will be.
On benchmarking, my attitude is this whols FPS benchmark crap was always a mistake. The only useful benchmarks for any video card IMO are how many sustained verts, triangles and pixels per second they can do under a variety of conditions. FPS can be tricked up in so many ways it's not at all useful as a benchmark.
Well, I know a fair number of S.F. writers who use various methods. One of my friends does her first drafts with pencil and paper. Another uses every feature of word, including having special styles for the little dividers between scenes.
Personally, I didn't find it hard to turn off the features of Word I don't want: grammar, clippy, auto-everything (except the em-dash --we need a key for that). All gone. I do use stylesheets, but more for outlining. Outlining in Word helps me quite a bit. Font selection? That's a bit silly. Pick one font and run with it. Courier 12 is the standard in my genre. Most publishers have clear guidelines that state as much.
But the single biggest problem with word processors is a feature no one will ever disable -- the ability to edit as you type. This is why my friend uses pencil and paper and why some writers use VI or manual typewriters. Wordprocessors make it too easy to stop the flow of writing and waste time editing. Editing is important, but for many it's a distraction and should be left to the end.
My own process tries to cope with editing as I go. At this point, I can start a day's writing without editing everything that came before (a process that sometimes left 10 minutes to write new stuff). But it's not easy. And it's often the case that if I were to just cut whole sections and rewrite them instead of editing a word here and there, they might come out better in the end.
I don't know what all the fuss is about. For at least five years now, I've projected images into thin air. Of course, I have a little help from my "photon reversal mechanism" hanging on the wall -- but the photons all float in mid air right to my eye. Amazing stuff. Good contrast ratio too. In my case, it cost $40 for a 250 thread king size sheet and four stiff pieces of wood.
Answered my own question with a little more searching. Apparently, Valve knows about this and reports it's due to the filesystem reusing old blocks, not their code.
I found this link today claiming steam is possibly collecting info on kazaa usage.
Steam gets tricky by siN
For those of you metalheads who are also online gamers, it has come to the attention of the gaming community that Steam by VALVe software, the program that is used for the mod Counterstrike, has been (and still is) gathering huge amounts of information off of personal computers that have Steam installed.
To quote:
"1) Browse to steam dir
2) Search for gcache.gcf
3) Open the 400+ meg file in a hex editor
4) Search for 'kazaa' and 'mp3'
----
5) Ponder
6) Curse and uninstall steam"
The question is why is Steam looking at Kazaa user names, mp3 contents, HTM records, and more? Those suspect of these activities are pointing fingers that these actions might somehow be linked to the RIAA and it's attempt to browse through users files and folders in a vain attempt to see what people are downloading. Just a heads up.
I don't have steam installed yet, so I can't verify personally. But maybe someone here can, and hopefully reply if they find the kazaa and mp3 strings in said steam files. True of false?
The article and some of the comments here are all over the map. So to avoid redundancy, I'll point out a few common sense things and a few places where research since the 60s has already addressed these issues.
1. A fixed frame-rate is better than even high but variable frame-rate. A solid 30hz can actually be better than 30-120 fluctuating. A ton of research has gone into how to make the graphics pipeline effectively lock to a fixed rate and there's a good reason: variable frame-rates make people sick; fixed-framerates make things feel smooth and continuous. The article's point about motion blur seems an attempt to reconcile this point, albeit incorrectly. The key is smooth predictable motion. Note: this is harder than just locking to the vsync -- do it wrong and you randomly drop frames, which is exactly what you're trying to avoid.
2. No matter how high your instantaneous framerate, you will _never_ get more FPS than your monitor refresh rate, no matter what the little FPS number in the corner says. For me and my LCD, that's 60HZ. The rest is wasted energy. In fact, it's best if the fixed framerate is locked to the monitor refresh rate in some low multiple (1:1, 1:2, etc..) or it will effectively be a variable framerate (see: temporal aliasing, every nth frame seems to skip ahead or behind in time).
3. I can also tell you from looking at the source code to various demos that FPS is often measured by draw-time, not total time from frame-to-frame! If your game says it's getting 93fps but you don't see any horizontal tearing (partial updates racing the raster scan) on a 72hz monitor, the game is not measuring the total frame time. It is, in effect, lying to you.
4. I don't care what the peak framerate or even the average is. The only benchmark that matters is the _lowest_ framerate, because if that's too low, once you get sick, you'll stay sick for a while. Personally, I can't stand games that optimize for empty rooms. Add too many characters or lots of action and it turnes into a real-life vomitorium. Graphics developers need to tune for the worst case, not the benchmarks. And the best case, due to locked framerates, will seem no better. Programmers can find some other way to feel macho.
5. There are many ways to reduce latency and increase the fidelity of physical simulations. For one thing, rendering can be made asnychronous from input and simulation. User motion inputs can also be added late in the pipeline (right before draw) with the proper architecture. Imagine how much better a physical simulation can be if we're not busy rendering frames no one will ever see? And given the variability of graphics and CPU performance on PCs, this seems to be critical to getting good gameplay across the spectrum of machines.
I wouldn't wait on the internet to reconfigure itself to solve latency. Yes, there are proxy solutions, even at the ISP level that address latency, but as you correctly say: it's a design issue and many games just tack MP on at the end.
The biggest problem with the animation-time-sync approach is when the other player gets the jump on you halfway into a quick motion before you can react. From your point of view, your animation would play normally. So it's an issue, but not the one you're apparently concerned about.
What's the length of the animation compared to the latency? Eating even five whole frames of a two-second animation isn't going to make a game suck. Time synchronization is always critical.
So yes, many of the solutions lie at a higher level of design. But that's like saying the government budget problems are due to us spending more than we take in. It's harder to be specific, other than to just wish latency (or waste) away.
When it comes down to it, there's going to be latency until FTL communication is invented. So we'd better learn to deal with it.
I realize it may be heretical to say this, but lag isn't the heart of the problem IMO -- it's a convenient whipping boy, but for most games, lag can generally be overcome with predictability of motion, rollback, and good spatial reasoning to keep the circuits optimized.
The thing with twitch games is that there's almost no predictability for when a player will trigger a move, but there's full predictability of motion once the moves are triggered. A well-designed animation system should be able to take advantage of that to make up for late triggers. For example, a non-networked game may be designed to know the outcome of any given pair of player moves as soon as the button is pressed. Design it instead to resolve the move-pair based on late input and you're halfway there. The main artifact of latency, then, is that moves may seem to start late (as late as the late-ncy), but their ends and their results are still synchronized and well-behaved.
As has been pointed out elsewhere, there's a lot of good research on how to combine both. However, the key issues in choosing a method are:
Animated characters move in non-physical ways. A character can turn its head left to right in one or two frames. A human can't (without injury) and that puts a hard limit on mocap's usefulness there (except, see below).
Assuming you want realistic human motions, using a realistic human as model is essential. This can be a living human or a high-quality biomechanical software model driven by an animator or an algorithm. The latter is more interesting, since it allows more than just recombinations of recorded motions.
The main thing missing in motion capture, IMO, is real-time feedback. I worked on a system that used only 12 6DOF body sensors (magnetic, long time ago), but allowed you to drive an animated character in real-time. The effects were really good, IMO, in that the actor could adapt the way a puppeteer learns the motions of her puppet.
Avi Ruben was probably a fool for not divesting or disclosing his interest in a pseudo-competitor, but why isn't anyone screaming about Senator Chuck Hagel's ownership of Diebold?
here's a version of the story. But where are the mainstream media accounts of this in relation to Hagel's unprecedented win in Nebraska using election machines his own company sold! And then he apparently failed to disclose this for years.
Frankly, if voting is going to be electronic and this insecure, I'd prefer to vote via the web. Better yet, I'll go vote via Taco Bell.
Excellent comments. I mostly agree (and I just wrote a novel on the subject, so I've done a bit of research). A couple of points:
1. Given a sufficient nest egg (currently, in the range of $2M), you can generate a perpetually comfortable income -- the trick is to live off the interest and have enough for inflation or economic shifts which are fairly predictable over the long haul.
2. Regardless of whether the world can agree on voluntary population controls (i.e., birth control, not carousel), the have-nots will not be able to outlive their nest egg and society will be in no position to grant a perpetual safety net, whether it wants to or not.
3. Growing old in the future may not come with the current implication of growing stale. If technology can keep a person at age 25 mentally, then I don't think your assumption holds. I think that the "staleness" factor has much more to do with becoming rigid and settled in one's life than it does with age -- people will be having mid-life crises every decade or so to keep things fresh. And I don't think this stiffles innovation. However, if people can retire and live off interest, that does tend to take talented people out of the work pool.
4. I don't think competition from the pseudo-young vs. the real young is the core issue. The job of the real young will be to learn, accumulate their own nest egg (forget inheritance), and graduate into "retired" society. As long as society doesn't try to shun the young, I think it would be a change for the better.
And, not a nit on your post, but the original article seems to miss one important bit of math. With the acceleration in life-expectancy, there won't be some magic pill to herald the start of immortality. By adding one year of life expectancy every decade now, five years per decade in the next 50 years, when we finally reach the point where we add one decade of life expectancy per decade (and the trend continues), then we're reached statistical immortality without ever inventing such a pill. Just stay ahead of the curve and you'll never die.
If the company converts your real dollars into virtual ones for some delayed return to cash, it is acting like a bank or casino, especially if the value out is not a fixed percentage of the value in.
With transactions and brokering, the idea is that the middle-man doesn't hold your money for any longer than is necessary to complete the transaction and the money is protected in the interim. In other words, the money goes straight from dollar account A (in some bank) to dollar account B (in some bank). And the middle-man extracts a fee for that service. If you hold the money, then you are in essense a bank and new rules apply.
If the value out is a random (but statistically known over many transactions) function of the value in, you are most likely a casino. Both of these statements seem to apply to the economic model implied in the article. If you buy virtual dollars and get real dollars back later, then these models apply.
And even in pure transactional systems, the currency flow can be gamed and value can be "extracted" from the economy, thereby diminishing the "fun" for those left holding a smaller bag of virtual cash. It's done all the time with currency markets, except there, no single company owns or can keep secret the key information that makes those markets work.
I'm all for virtual economies with cash in, or even using ebay or similar to trade items, but let's keep the concepts separate.
I think it comes down to this: slot machines can pay out real money because they can statistically reassure their owners that they'll pay somewhere between 80% and 100% of what they take in. Banks can operate because they can almost always take your money and make more from it than they pay you in interest.
But most games have no such reassurances. Games of skill can be mastered and "gamed" in such a way that the owner of the MMOG will ultimately lose money. It's a no-win proposition in the long run and it just begs for government regulation in something that's supposed to done for fun.
Many on-line games have concepts of in-world currency and even track the "exchange rate" to dollars. They let you buy more virtual dollars. But to pay out real dollars is not in the company's interest. Better that they give something they can afford, like free access, free virtual items, or even real items that bear their free advertising. Remember the older arcades that awarded tickets for cheapo items instead of cash? Same idea
Finally, I find it most curious that the author is so bent on gold as a standard, since I thought the whole point of gold was to avoid virtualized currencies like paper money! What's more virtual than MMOG dollars? Or does he simply gain from having virtual economies backed by gold?
I may be missing something, but I thought that even these "sufficiently advanced" encryption algorithms can be more easily broken if the attacker knows both the cyphertext (the encrypted disk) and part of the cleartext. Knowing both, you can recover the key much more easily than a brute-force attack. And in the case of a fully-encrypred hard disk, there should be lots of structure (partition tables, headers, etc..) that is well known. If the key isn't even algorithmic (same key for everything), this makes the cracking inordinately easier. So "weeks on a supercomputer" may actually be hours in a lab.
There's a missing component for making usable/tilable aerial images -- you'd want position/orientation tracking of the camera.
If you want to do a EarthViewer-like flyover of your house, you'll need that and a little extra horsepower to orthorectify the images and do some stitching -- not quite as simple as it sounds. Mounting two GPS units some distance apart could give you enough position/heading info (or three if your balloon tilts, which is likely).
But you could always use this _with_ EarthViewer, not instead. Even the consumer version has the ability to add your own image overlays on the Earth and share them via internet downloads. (full disclosure: I used to work at Keyhole).
Try to distinguish between me saying it's not art (which I'm not) versus me saying it's not a "new art form" (which I am). Pissing in a bucket for an audience is not a new art form either. It's still performance art and it's been done.
"Proving" is not important unless the artist is claiming that using a game engine is what makes his or her art unique. I don't know about you, but I've seen Machinima enthusiasts make that claim precisely.
Alas, I don't think I've missed the real point about the possibilities. I've been working on creating virtual movie studios in one form or another for ten years. I'm the sort of programmer that writes 3D engines you may use for your movies. What I object to is the hype, not the intent; the claims of it being new or revolutionary. It's not ready for prime time yet, but someday it will. And believe me, I'll be there.
And, finally, I might point out that an artist who ignores the qualities of his or her tools and canvas is going to have a serious handicap. Sure, paint on canvas has known limitations and you can "work around them." But it's the finer qualities of the paint on the canvas, the way paints mix, their physical shape, brush strokes, that an artist uses to help make a masterpiece. That's part of what distingushes art from basic creative self-expression.
Agreed. It would be quite elitist photography. But for Machinima to be art, at least some people other than the creators need to be able to experience the original content. No problem with releasing AVI files for the masses who can't afford the game engine or player--we have books about art, after all. But we don't mistake the books for the art itself. And someone other than the artist generally writes the book and we trust _they've_ seen the art.
But my preference in this case would be to have a game-less player that could be distributed with the content. If the game studios have to charge for that, that's their right. But theoretically (not advisedly), they could write their game licenses such that Machinima creators would have to pay for AVI showings to non-paying customers.
This guy is posting to several boards now, hyping this up. I don't have a problem with claiming machinima is cool, but words like "new art form" and "the first real-time 3D movies" are definitely over the top.
If you define "machinima" as using real-time 3D to make movies, it's been done since 1994 (at least) and even done professionally. There was a project at Disney that used 3D graphics hardware to play movies in real-time, with characters, dialog, and everything. It was even interactive if you wanted (or automatic, if you did nothing). You could watch on a monitor if you didn't like the VR gear that went along with the official ride. But it was not a game and the "engine," called the "player," was custom-built. Disney had other examples of movies rendered using real-time, like the Cyberspace Mountain ride. The 3D hardware was essentially a big decompressor and video-mixer, giving better compression ratios using polygons than any block encoder ever did.
A third example, from the game community itself, is Dungeon Keeper II, which used its own 3D engine to animate the ends of the levels with some semblance of story. I don't even expect it was the first or the best, but it was the first I remember.
Now, if you want to define "Machinima" as using Game Engines and their free (sometimes open source) editors as the "tools," then we're in the realm of reason. As an art form, it is essentially defined by the styles and restrictions the game engines impose, just as any art form is shaped by the tools it uses. But lose the game engine and it's just a relatively poor (compared to pixar) animated movie.
But then to ship the resulting movies as AVI files? That's the biggest cop out I've ever seen in any art form. If no one was allowed to see a great painting except as a photograph, we'd call it photography, not painting.
Ultimately, for machinima to be a real art-form, it needs to deliver the goods in the form they're created. Otherwise, who cares whether you used Maya or Quake to make your animation and who can even prove it was rendered in real-time and not frame-by-frame?
Having had same thing happen to me (in a book, libeling me, etc...) "rape" is the perfect word for the feeling. No one is saying it's the same as physical rape -- the legal punishments are totally different, for one thing. But the _feeling_ was that I was totally powerless, ruined, damaged, ashamed, unworthy of self respect and contunially subject to someone who could to run over my life with a steamroller; like someone had bent me over and rammed me against my will, and they kept on doing it, over and over. That's really how it feels.
I didn't feel old when I woke up this morning, but now I do. I played almost every infcom game from starcross up to the point where they tried to go graphical and started sucking. I still think the environments they painted with words are richer than most games today.
Basically, if they're paying the bill, you have a responsibility to deliver what they want (if possible). And if you can't or won't, you have a responsibility to tell them.
'What they want' is the question. They may want opinions, or they may simply want hands typing. It's okay to ask. And if you don't like the answer, then you can decide how important 'being right' is to you. Keep in mind that 'Right' is often relative. And sometimes it takes people time to come around, longer if they've been forced into a corner.
I've been lucky that most of my clients have wanted my opinions and experience along with actual code. They haven't always listened and it has often been frustrating. But even though I may know certain aspects of 3D optimization (in my case) better than them, they know their business and their overall needs better than me. In many cases, I was probably right about 'what we should do' and they were undoubtedly more right about 'what they could afford to do.' It's their company, afterall.
Sorry if that isn't as specific as possible, but the thing I've learned after 10 years is that every case is different and flexibility is key.
Slashdot Mirror
Assuming the '138' patent is short for US patent # 6,200,138, I just checked and it was filled in 1998(!).
Between late 1994 and early 1995, I pitched a game idea to Disney (while I was an employee at WDI VR Studio) called "Wild Taxi," which was further developed for consideration as a new VR ride/game for DisneyQuest. That idea was fundamentally the same as Crazy Taxi, which I don't personally recall seeing as an arcade or console game for a few more years circa 1997 or 1998. I could have missed it, so please chime in if you know it existed prior to 1995 and I'll stand corrected.
I also believe it is now public knowledge that Disney and Sega were in various negotiations around the time of the Wild Taxi idea. Those talks didn't last long as far as I can tell, but at the time, I have every reason to believe the Wild Taxi ride idea was disclosed to Sega in a presentation of potential ride ideas.
For example, I recall seeing the storyboards Disney artists composed for these presentations. And I witnessed at least one such meeting between Disney and Sega, though I was not physically "in" the meeting (being a grunt, I sat outside an open meeting room). I also recall being told that Sega liked the ideas.
BTW, as far as I know, the reason Disney [DisneyQuest] didn't ultimately build this ride was technical, having to do with compelxity and throughput issues in an LBE environment for multiple participants. But that's a side issue.
I do not know if Sega had done prior work on "Crazy Taxi" before these meetings, but I have every reason to believe it was new idea at the time.
I also wouldn't know if Disney and Sega have come to some sort of prior agreement over this IP, which may in fact have transferred the various IP rights to Sega without much or any public comment. I can only speculate on the terms under which the ideas were disclosed.
I never sought credit for my contribution, nor do I seek any now. However, my personal opinion is that Disney should now disclose the "Wild Taxi" ride designs as they may potentially invalidate Sega's patent. If, indeed, Sega got the idea from our group at Disney, then this patent may be without merit and, IMO, would be incredibly obnoxious.
These are all my opinions and recollections and I do not claim to present any legal facts as such.
I've coded for Second Life in the past, so I don't want to dis There, but that Will Harvey quote honestly baffles me. Even the extended quote in the article seems out of touch. If you use SL, you'll see a scripting language that doesn't seem to have any of those problems (and no, I didn't work on that part).
The real problem with user scripting is that once you have the equivalent of magic in the world, you can really piss people off. And that's hard to sandbox or detect algorithmically. For example, it's difficult to tell the difference between user code that helps a friend levitate and one that keeps a victim pinned in place.
The real problem with user content in general is similar: you want to somehow reward and retain beneficial content and discourage the retention of crap. Let people build all the crap they want, but please take it down at the end of the day, okay?
Second Life has some interesting approches, including taxation and community rating. But, frankly, the crappy content problem is not solved in the real world either.
I'm just glad for anything that turns non-designers into even modest designers--in any world. For me, it was legos and computer graphics that got me thinking about aesthetics. The more ways, the better.
On perception, studies from the visual simulation field showed that 60HZ is plenty. In fact, having a solid 60HZ is inordinately better than a variable framerate, even if it was often higher. Motion seems smoother, temporal artifacts go away, and our brains can better predict motion, which leads to more of a feeling of "presence."
I wholly support locking the framerate, but I'd prefer if rendering locked to my actual monitor refresh rate, not only 60HZ. That's a bit too monolithic, especially when the problem of special jumps only working at 105fps or whatever is a problem of _simulation_ framerate, not rendering.
On simulation, 60HZ is not the gold standard. Physical simulations are often run higher for various reasons. Positions can be interpolated when graphics and simulation are not integer multiples. Not a problem. But locking the two makes some design issues simpler. Id may have some better way to do all this with a locked 60HZ. I don't know how dynamic their world will be.
On benchmarking, my attitude is this whols FPS benchmark crap was always a mistake. The only useful benchmarks for any video card IMO are how many sustained verts, triangles and pixels per second they can do under a variety of conditions. FPS can be tricked up in so many ways it's not at all useful as a benchmark.
Well, I know a fair number of S.F. writers who use various methods. One of my friends does her first drafts with pencil and paper. Another uses every feature of word, including having special styles for the little dividers between scenes.
Personally, I didn't find it hard to turn off the features of Word I don't want: grammar, clippy, auto-everything (except the em-dash --we need a key for that). All gone. I do use stylesheets, but more for outlining. Outlining in Word helps me quite a bit. Font selection? That's a bit silly. Pick one font and run with it. Courier 12 is the standard in my genre. Most publishers have clear guidelines that state as much.
But the single biggest problem with word processors is a feature no one will ever disable -- the ability to edit as you type. This is why my friend uses pencil and paper and why some writers use VI or manual typewriters. Wordprocessors make it too easy to stop the flow of writing and waste time editing. Editing is important, but for many it's a distraction and should be left to the end.
My own process tries to cope with editing as I go. At this point, I can start a day's writing without editing everything that came before (a process that sometimes left 10 minutes to write new stuff). But it's not easy. And it's often the case that if I were to just cut whole sections and rewrite them instead of editing a word here and there, they might come out better in the end.
But that could just be me.
I don't know what all the fuss is about. For at least five years now, I've projected images into thin air. Of course, I have a little help from my "photon reversal mechanism" hanging on the wall -- but the photons all float in mid air right to my eye. Amazing stuff. Good contrast ratio too. In my case, it cost $40 for a 250 thread king size sheet and four stiff pieces of wood.
Answered my own question with a little more searching. Apparently, Valve knows about this and reports it's due to the filesystem reusing old blocks, not their code.
I don't have steam installed yet, so I can't verify personally. But maybe someone here can, and hopefully reply if they find the kazaa and mp3 strings in said steam files. True of false?
The article and some of the comments here are all over the map. So to avoid redundancy, I'll point out a few common sense things and a few places where research since the 60s has already addressed these issues.
1. A fixed frame-rate is better than even high but variable frame-rate. A solid 30hz can actually be better than 30-120 fluctuating. A ton of research has gone into how to make the graphics pipeline effectively lock to a fixed rate and there's a good reason: variable frame-rates make people sick; fixed-framerates make things feel smooth and continuous. The article's point about motion blur seems an attempt to reconcile this point, albeit incorrectly. The key is smooth predictable motion. Note: this is harder than just locking to the vsync -- do it wrong and you randomly drop frames, which is exactly what you're trying to avoid.
2. No matter how high your instantaneous framerate, you will _never_ get more FPS than your monitor refresh rate, no matter what the little FPS number in the corner says. For me and my LCD, that's 60HZ. The rest is wasted energy. In fact, it's best if the fixed framerate is locked to the monitor refresh rate in some low multiple (1:1, 1:2, etc..) or it will effectively be a variable framerate (see: temporal aliasing, every nth frame seems to skip ahead or behind in time).
3. I can also tell you from looking at the source code to various demos that FPS is often measured by draw-time, not total time from frame-to-frame! If your game says it's getting 93fps but you don't see any horizontal tearing (partial updates racing the raster scan) on a 72hz monitor, the game is not measuring the total frame time. It is, in effect, lying to you.
4. I don't care what the peak framerate or even the average is. The only benchmark that matters is the _lowest_ framerate, because if that's too low, once you get sick, you'll stay sick for a while.
Personally, I can't stand games that optimize for empty rooms. Add too many characters or lots of action and it turnes into a real-life vomitorium. Graphics developers need to tune for the worst case, not the benchmarks. And the best case, due to locked framerates, will seem no better. Programmers can find some other way to feel macho.
5. There are many ways to reduce latency and increase the fidelity of physical simulations. For one thing, rendering can be made asnychronous from input and simulation. User motion inputs can also be added late in the pipeline (right before draw) with the proper architecture. Imagine how much better a physical simulation can be if we're not busy rendering frames no one will ever see? And given the variability of graphics and CPU performance on PCs, this seems to be critical to getting good gameplay across the spectrum of machines.
I wouldn't wait on the internet to reconfigure itself to solve latency. Yes, there are proxy solutions, even at the ISP level that address latency, but as you correctly say: it's a design issue and many games just tack MP on at the end.
The biggest problem with the animation-time-sync approach is when the other player gets the jump on you halfway into a quick motion before you can react. From your point of view, your animation would play normally. So it's an issue, but not the one you're apparently concerned about.
What's the length of the animation compared to the latency? Eating even five whole frames of a two-second animation isn't going to make a game suck. Time synchronization is always critical.
So yes, many of the solutions lie at a higher level of design. But that's like saying the government budget problems are due to us spending more than we take in. It's harder to be specific, other than to just wish latency (or waste) away.
When it comes down to it, there's going to be latency until FTL communication is invented. So we'd better learn to deal with it.
I realize it may be heretical to say this, but lag isn't the heart of the problem IMO -- it's a convenient whipping boy, but for most games, lag can generally be overcome with predictability of motion, rollback, and good spatial reasoning to keep the circuits optimized.
The thing with twitch games is that there's almost no predictability for when a player will trigger a move, but there's full predictability of motion once the moves are triggered. A well-designed animation system should be able to take advantage of that to make up for late triggers. For example, a non-networked game may be designed to know the outcome of any given pair of player moves as soon as the button is pressed. Design it instead to resolve the move-pair based on late input and you're halfway there. The main artifact of latency, then, is that moves may seem to start late (as late as the late-ncy), but their ends and their results are still synchronized and well-behaved.
Just some thoughts.
As has been pointed out elsewhere, there's a lot of good research on how to combine both. However, the key issues in choosing a method are:
Animated characters move in non-physical ways. A character can turn its head left to right in one or two frames. A human can't (without injury) and that puts a hard limit on mocap's usefulness there (except, see below).
Assuming you want realistic human motions, using a realistic human as model is essential. This can be a living human or a high-quality biomechanical software model driven by an animator or an algorithm. The latter is more interesting, since it allows more than just recombinations of recorded motions.
The main thing missing in motion capture, IMO, is real-time feedback. I worked on a system that used only 12 6DOF body sensors (magnetic, long time ago), but allowed you to drive an animated character in real-time. The effects were really good, IMO, in that the actor could adapt the way a puppeteer learns the motions of her puppet.
As the AC states, it is ES&S, not Diebold. My mistake. However, the machines were still the ones used in his election, according to those reports.
Avi Ruben was probably a fool for not divesting or disclosing his interest in a pseudo-competitor, but why isn't anyone screaming about Senator Chuck Hagel's ownership of Diebold? here's a version of the story. But where are the mainstream media accounts of this in relation to Hagel's unprecedented win in Nebraska using election machines his own company sold! And then he apparently failed to disclose this for years.
Frankly, if voting is going to be electronic and this insecure, I'd prefer to vote via the web. Better yet, I'll go vote via Taco Bell.
I had the same thing happen to me, only it was after playing Tron Lightcycles. I found myself making instant 90 degree turns all the time.
Excellent comments. I mostly agree (and I just wrote a novel on the subject, so I've done a bit of research). A couple of points:
1. Given a sufficient nest egg (currently, in the range of $2M), you can generate a perpetually comfortable income -- the trick is to live off the interest and have enough for inflation or economic shifts which are fairly predictable over the long haul.
2. Regardless of whether the world can agree on voluntary population controls (i.e., birth control, not carousel), the have-nots will not be able to outlive their nest egg and society will be in no position to grant a perpetual safety net, whether it wants to or not.
3. Growing old in the future may not come with the current implication of growing stale. If technology can keep a person at age 25 mentally, then I don't think your assumption holds. I think that the "staleness" factor has much more to do with becoming rigid and settled in one's life than it does with age -- people will be having mid-life crises every decade or so to keep things fresh. And I don't think this stiffles innovation. However, if people can retire and live off interest, that does tend to take talented people out of the work pool.
4. I don't think competition from the pseudo-young vs. the real young is the core issue. The job of the real young will be to learn, accumulate their own nest egg (forget inheritance), and graduate into "retired" society. As long as society doesn't try to shun the young, I think it would be a change for the better.
And, not a nit on your post, but the original article seems to miss one important bit of math. With the acceleration in life-expectancy, there won't be some magic pill to herald the start of immortality. By adding one year of life expectancy every decade now, five years per decade in the next 50 years, when we finally reach the point where we add one decade of life expectancy per decade (and the trend continues), then we're reached statistical immortality without ever inventing such a pill. Just stay ahead of the curve and you'll never die.
If the company converts your real dollars into virtual ones for some delayed return to cash, it is acting like a bank or casino, especially if the value out is not a fixed percentage of the value in.
With transactions and brokering, the idea is that the middle-man doesn't hold your money for any longer than is necessary to complete the transaction and the money is protected in the interim. In other words, the money goes straight from dollar account A (in some bank) to dollar account B (in some bank). And the middle-man extracts a fee for that service. If you hold the money, then you are in essense a bank and new rules apply.
If the value out is a random (but statistically known over many transactions) function of the value in, you are most likely a casino. Both of these statements seem to apply to the economic model implied in the article. If you buy virtual dollars and get real dollars back later, then these models apply.
And even in pure transactional systems, the currency flow can be gamed and value can be "extracted" from the economy, thereby diminishing the "fun" for those left holding a smaller bag of virtual cash. It's done all the time with currency markets, except there, no single company owns or can keep secret the key information that makes those markets work.
I'm all for virtual economies with cash in, or even using ebay or similar to trade items, but let's keep the concepts separate.
I think it comes down to this: slot machines can pay out real money because they can statistically reassure their owners that they'll pay somewhere between 80% and 100% of what they take in. Banks can operate because they can almost always take your money and make more from it than they pay you in interest.
But most games have no such reassurances. Games of skill can be mastered and "gamed" in such a way that the owner of the MMOG will ultimately lose money. It's a no-win proposition in the long run and it just begs for government regulation in something that's supposed to done for fun.
Many on-line games have concepts of in-world currency and even track the "exchange rate" to dollars. They let you buy more virtual dollars. But to pay out real dollars is not in the company's interest. Better that they give something they can afford, like free access, free virtual items, or even real items that bear their free advertising. Remember the older arcades that awarded tickets for cheapo items instead of cash? Same idea
Finally, I find it most curious that the author is so bent on gold as a standard, since I thought the whole point of gold was to avoid virtualized currencies like paper money! What's more virtual than MMOG dollars? Or does he simply gain from having virtual economies backed by gold?
I may be missing something, but I thought that even these "sufficiently advanced" encryption algorithms can be more easily broken if the attacker knows both the cyphertext (the encrypted disk) and part of the cleartext. Knowing both, you can recover the key much more easily than a brute-force attack. And in the case of a fully-encrypred hard disk, there should be lots of structure (partition tables, headers, etc..) that is well known. If the key isn't even algorithmic (same key for everything), this makes the cracking inordinately easier. So "weeks on a supercomputer" may actually be hours in a lab.
There's a missing component for making usable/tilable aerial images -- you'd want position/orientation tracking of the camera.
If you want to do a EarthViewer-like flyover of your house, you'll need that and a little extra horsepower to orthorectify the images and do some stitching -- not quite as simple as it sounds. Mounting two GPS units some distance apart could give you enough position/heading info (or three if your balloon tilts, which is likely).
But you could always use this _with_ EarthViewer, not instead. Even the consumer version has the ability to add your own image overlays on the Earth and share them via internet downloads. (full disclosure: I used to work at Keyhole).
Try to distinguish between me saying it's not art (which I'm not) versus me saying it's not a "new art form" (which I am). Pissing in a bucket for an audience is not a new art form either. It's still performance art and it's been done.
"Proving" is not important unless the artist is claiming that using a game engine is what makes his or her art unique. I don't know about you, but I've seen Machinima enthusiasts make that claim precisely.
Alas, I don't think I've missed the real point about the possibilities. I've been working on creating virtual movie studios in one form or another for ten years. I'm the sort of programmer that writes 3D engines you may use for your movies. What I object to is the hype, not the intent; the claims of it being new or revolutionary. It's not ready for prime time yet, but someday it will. And believe me, I'll be there.
And, finally, I might point out that an artist who ignores the qualities of his or her tools and canvas is going to have a serious handicap. Sure, paint on canvas has known limitations and you can "work around them." But it's the finer qualities of the paint on the canvas, the way paints mix, their physical shape, brush strokes, that an artist uses to help make a masterpiece. That's part of what distingushes art from basic creative self-expression.
Agreed. It would be quite elitist photography. But for Machinima to be art, at least some people other than the creators need to be able to experience the original content. No problem with releasing AVI files for the masses who can't afford the game engine or player--we have books about art, after all. But we don't mistake the books for the art itself. And someone other than the artist generally writes the book and we trust _they've_ seen the art.
But my preference in this case would be to have a game-less player that could be distributed with the content. If the game studios have to charge for that, that's their right. But theoretically (not advisedly), they could write their game licenses such that Machinima creators would have to pay for AVI showings to non-paying customers.
This guy is posting to several boards now, hyping this up. I don't have a problem with claiming machinima is cool, but words like "new art form" and "the first real-time 3D movies" are definitely over the top.
If you define "machinima" as using real-time 3D to make movies, it's been done since 1994 (at least) and even done professionally. There was a project at Disney that used 3D graphics hardware to play movies in real-time, with characters, dialog, and everything. It was even interactive if you wanted (or automatic, if you did nothing). You could watch on a monitor if you didn't like the VR gear that went along with the official ride. But it was not a game and the "engine," called the "player," was custom-built. Disney had other examples of movies rendered using real-time, like the Cyberspace Mountain ride. The 3D hardware was essentially a big decompressor and video-mixer, giving better compression ratios using polygons than any block encoder ever did.
A third example, from the game community itself, is Dungeon Keeper II, which used its own 3D engine to animate the ends of the levels with some semblance of story. I don't even expect it was the first or the best, but it was the first I remember.
Now, if you want to define "Machinima" as using Game Engines and their free (sometimes open source) editors as the "tools," then we're in the realm of reason. As an art form, it is essentially defined by the styles and restrictions the game engines impose, just as any art form is shaped by the tools it uses. But lose the game engine and it's just a relatively poor (compared to pixar) animated movie.
But then to ship the resulting movies as AVI files? That's the biggest cop out I've ever seen in any art form. If no one was allowed to see a great painting except as a photograph, we'd call it photography, not painting.
Ultimately, for machinima to be a real art-form, it needs to deliver the goods in the form they're created. Otherwise, who cares whether you used Maya or Quake to make your animation and who can even prove it was rendered in real-time and not frame-by-frame?
Having had same thing happen to me (in a book, libeling me, etc...) "rape" is the perfect word for the feeling. No one is saying it's the same as physical rape -- the legal punishments are totally different, for one thing. But the _feeling_ was that I was totally powerless, ruined, damaged, ashamed, unworthy of self respect and contunially subject to someone who could to run over my life with a steamroller; like someone had bent me over and rammed me against my will, and they kept on doing it, over and over. That's really how it feels.
I didn't feel old when I woke up this morning, but now I do. I played almost every infcom game from starcross up to the point where they tried to go graphical and started sucking. I still think the environments they painted with words are richer than most games today.
Basically, if they're paying the bill, you have a responsibility to deliver what they want (if possible). And if you can't or won't, you have a responsibility to tell them.
'What they want' is the question. They may want opinions, or they may simply want hands typing. It's okay to ask. And if you don't like the answer, then you can decide how important 'being right' is to you. Keep in mind that 'Right' is often relative. And sometimes it takes people time to come around, longer if they've been forced into a corner.
I've been lucky that most of my clients have wanted my opinions and experience along with actual code. They haven't always listened and it has often been frustrating. But even though I may know certain aspects of 3D optimization (in my case) better than them, they know their business and their overall needs better than me. In many cases, I was probably right about 'what we should do' and they were undoubtedly more right about 'what they could afford to do.' It's their company, afterall.
Sorry if that isn't as specific as possible, but the thing I've learned after 10 years is that every case is different and flexibility is key.