I said this yesterday. OUTSOURCING IS NOT AN OPTION IN VIDEO GAME DEVELOPMENT.
The latency between a feature request and it's implementation is too long if you outsource. Right now, a designer will come to my desk, and ask me to implement a feature to test it out. This is called iterating. Usually, that feature will take me an hour or so. The designer will have the feature to then play with, and decide if it feels better or worse then it did before.
Without this process, you get crap. All of the best games iterate. It's why Blizzard games take 3-4 years to come out.
If you outsource your game development, iteration is going to take substantially longer then it does now. Every feature request will take a day instead of a couple of hours. Games that take two years to develop will instead take ten.
There's a perfect example of what happens when you outsource video games here.
No, that doesn't work in the game industry. In the game industry requirements change WAY too quickly to outsource jobs successfully.
There have been attempts though, if you don't believe me.
The problem is that when a designer comes to me because he wants to iterate something to see how it works, he needs the answer in an hour or two--not tomorrow. If every change I made for a designer took a day, the games you get now in 2-3 years would be coming out in 10. The project requirements are just not well defined in games like they are in other areas of the software industry. Games that don't iterate (because they stick to a predefined set of requirements) generally suck ass.
I'm not sure exactly why you think a gradiated fill would be any more expensive then a plain one.
The difference in computation is so insignificant that it's irrelevant.
If you don't believe me, try using Macromedia Flash (or some other vector-painting tool) to fill a bunch of areas with gradients, then do the same thing with solid fills. You'll see that they both break down in viewing at roughly the same time.
If the code is well optimized, there is no reason why a gradient fill would be more expensive then a plain fill.
And if you were to have a receipt that said that you bought the software at $100.00 that was a created by scanning and photoshopping your $50.00 receipt
Actually, no. There are a few places that differ a bit (user experience), but in general, the code just works. The trick is where your toolkit lies. Too close to the underlying APIs, and you're right--the software is for one platform, and simply ported to the other. Too far from the APIs, and you wind up doing everything twice.
Plus, it's open source. If the code worked even partially in a Windows environment, I'd probably donate a few hours a week to making sure that it really behaved on Win32.
God, I totally agree. I would use Evo in a heartbeat if it were available on Windows. (And no, I cannot switch, I develop products for x86/Windows).
To the other poster who suggests that it would not be possible, desirable, or easy to support cross platforms... That's total bunk. I used to develop commercial apps that ran on Windows, Linux, Mac/OS9 and OSX. It *does* require a bit more work, but in practice, it's actually not much more work than supporting one OS.
Please stop treating your customers like idiots and give us information; information that we can use.
Please look up what the semi-colon is used for; it should be used in place of a period for emphasis.
Apologies for my grammar correction, but is seriously irks me when someone decides to send *an open letter* to a company and doesn't check for grammar, punctuation, and spelling mistakes. Or does OpenOffice not support these features?:-p
MS has announced they are discontinuing DX past the current version to launch DX under a new brand name & direction.
And let me be the first (only?) to say that the new direction is seriously kick-ass. Basically, all of the things that programmers generally mess up on are being integrated into the API and done automatically (or not, depending on what options you set).
The next version of DirectX (I believe called DirectNext) is going to really help push the capabilities of today and tomorrow's graphics cards.
And before I start hearing it, I do not work for MS. I write graphics for games for a living.
Sorta. There are numerous games out already that are based on Java. Pretty much all of Popcap uses Java. Java is also used as a scripting language for several games (sorry, no links), as an alternative to Python, Lisp, C++, Lua or any other interpretive language (or home-brewed language).
However, it will be a very long time (if ever) before developers switch over to Java as their language of choice. Why? Because it is only the last generation or two of games that have started to use C++.
Game developers are constantly trying to push the edges of what can be done within current hardware limitations. The problem with languages that do a lot for us is that... They do a lot for us. Which is nice a lot of times. But always seems to happen at the most inconvenient time (like when we're doing matrix operations, or animating units).
The GPU is *great* at them. Anything that can be expressed as a massively parallel simulation or effect is a cake-walk for the GPU.
As the author mentions, the bottleneck right now is getting data back from the GPU. However, the more successive steps you can do in a row on the GPU, the better off you are. Even with the new PCI express, this will remain true. The more successive steps you can do without having to retrieve the data, the faster your processing will be.
There are lots of cool demos over at NVIDIA's website that exploit the cool things that can be done with the parallelism of the GPU.
I've been toying with writing a 'Go' simulator on the GPU. Just haven't gotten around to it yet.
There's actually quite a bit of research about this topic. For instance, as another poster suggested, we think we are looking for other water-based organisms, because of the requirements of planetary stability and the particular importance of water from a biochemical standpoint. (I unfortunately do not have enough education in Biochem to go into the specifics).
Because of this requirement, SETI tends to focus its search around the watering hole. As other posters have suggested, we're not particularly looking for a signal with a message yet, just a signal that cannot be explained by natural phenomena, and that is not earth based.
Now, as to the other questions I've been seeing about 'math' and whether it is a useful way to detect an alien civilization.
There are numerous values in math that are constants, regardless of your perception or how you describe them. For instance, the ratio of the diameter of a circle to its circumference is always PI. There is also e, which any advanced civilization would have come upon, or at least any civilization which was sending signals using EMag (because these numbers are fundamental to such a system).
The difficulty with these particular numbers is that they are not integers, so encoding them would be difficult to do in a recognizable way. However, integers would be fairly easy to encode, even if the civilization were using a different base for counting then we were. There would be no mistaking of the first n primes or the first n digits of the fibonacci sequence.
It's not like the gaming industry has been terribly innovative in itself either.
Yes, I can see where you're coming from. There definitely haven't been any innovative games created by professionals. Definitely not Commander Keen, The Sims, Doom, Quake, Battlefield 1942, Deus Ex, GTA3, PopCap games, Everquest... Nope, none at all.
There is no true difference between an open source and a closed source creation of a game.
Did you read the article? He points out some very important differences. Let me add another: code control. I don't want people whom I don't know poking around in code that they don't necessarily understand. I don't want people who don't understand data structures trying to add 'features' to my code. Games push the limits of your CPU and GPU all the time. You don't want to do that because of inefficiencies in the code. You want to do that because you're adding effects that people have never seen before. Or you want to make your units more intelligent then other players.
What strikes me as funny about your argument is that most of the innovation that has gone into games in the last 10 years is stuff that players generally don't even notice. Better pathfinding. Increased polygons count through more efficient storage. More textures used better. Better AI. Random map generation.
But players don't notice these things.
They just notice how this unit is similar to this other unit in this other game.
a) Hi. Read the article. What you're not understanding is that I'm asserting that he is wrong.
b) That's totally wrong. Consider the size of a windows message in another OS. For instance... Windows. Messages are 32-bytes. They are sent infrequently. Sending pixel updates would require 32 bytes PER PIXEL. Sent frequently.
Yes, but even though Open/GL supports sending info over a network, what happens when you have view-dependent data.
For instance, it would be efficient to send vertices, matrices, and large amounts of other data across the network (maybe). But sending texture data is going to suck.
You can assume that he would require all clients to have all textures used within the application. But what about (for instance) the gimp?
One problem is his treatment of remote windows... He suggests sending them over as video streams.
If networking bandwidth is a problem now with the X format (which is basically just sending clicks and so forth), why does he think the response is going to be any better when sending *a huge ton of pixel data*?
Even if you assume that you only have to transmit differences, there are still cases where the difference will be several megs. (For example, a fullscreen clear in 1600x1200x32).
Re:Wake me up when they put the ORIGINALs on DVD
on
Star Wars on DVD
·
· Score: 4, Funny
Dear 80's Star Wars fan in my target market,
Actually, I'm willing to be that you will purchase this version when it comes out. You'll open up the shiny plastic and you'll curse my name for not releasing the "pure" movies. It is possible that you will resist this boxed set, but fortunately for me you have friends and relatives who remember how much you love Star Wars, and *certainly* one or more of them will purchase this collection for you. Either way, your money will already be mine, and I won't really care. I'll be laughing all the way to the bank in one of my 30 new Ferraris.
However, I will let you in on a little secret. Ever since DVD came around as a format, I've been saying that I didn't feel DVD was an appropriate format for the Star Wars franchise. I didn't think the betamax sales had fallen off enough to cannibalize my own market share. However, I've clearly changed views on that, and it is therefore likely that at *some* point in the future, I will release the super-duper-ultra-elite-Star-Wars-Final-absolutely -no-kidding-this-time Edition. Which will actually just be the original theater version.
And doesn't really offer any solid evidence besides.
The author's points are actually pretty weak, too.
He complains that people who say that Windows is easier to install and maintain are simply not comparing apples-to-apples. That seems unlikely, given that Windows is easier to install and maintain than Linux. That's a very broad category, and to be honest, I'd have to agree with them. That is NOT a fault of Linux itself, it is a fault of poor vendor support for the underdog OS.
Then, he tries to go on to state that there is plenty of software available for Linux. That doesn't address the counterargument. The original assertion is that there are specific apps (let me spell that, s-p-e-c-f-i-c) that are unavailable on Linux that the person is unwilling to lose. For instance, I cannot play Age of Mythology on Linux. I cannot play World of Warcraft on Linux. I cannot use MS word on linux. And before my detractors attempt to do so, I have to state that you *cannot* trivialize someone's choice of application, because they have time invested in training on how to use *that* application that they may not be willing to give up.
His third point... Was that really a point? It seemed like a half-hearted swing at the opposition.
I'm not saying that Linux *shouldn't* be the dominant operating system, I'm simply saying that it *isn't* and there are valid reasons why that is true. My firm belief is that if Linux wants to win the desktop war, you have to do two things: 1) Hit the competition where it hurts (in the wallet), and 2) Stop trying to convert the old. Its not gonna work. CONVERT THEIR CHILDREN.
I'm not sure whether to laugh or to scold you... Some people clearly thought you were trying to be funny, although I would suspect that since you posted anonymously, you were actually being serious.
At any rate, John Carmack is a pretty decent coder, but I'm not sure who this Jon Carmack person is.
Slashdot Mirror
I said this yesterday. OUTSOURCING IS NOT AN OPTION IN VIDEO GAME DEVELOPMENT.
The latency between a feature request and it's implementation is too long if you outsource. Right now, a designer will come to my desk, and ask me to implement a feature to test it out. This is called iterating. Usually, that feature will take me an hour or so. The designer will have the feature to then play with, and decide if it feels better or worse then it did before.
Without this process, you get crap. All of the best games iterate. It's why Blizzard games take 3-4 years to come out.
If you outsource your game development, iteration is going to take substantially longer then it does now. Every feature request will take a day instead of a couple of hours. Games that take two years to develop will instead take ten.
There's a perfect example of what happens when you outsource video games here.
Yes, that's exactly what I took out of it as well. I've missed the slashdot slant lately. Glad to see it alive and kicking.
No, that doesn't work in the game industry. In the game industry requirements change WAY too quickly to outsource jobs successfully.
There have been attempts though, if you don't believe me.
The problem is that when a designer comes to me because he wants to iterate something to see how it works, he needs the answer in an hour or two--not tomorrow. If every change I made for a designer took a day, the games you get now in 2-3 years would be coming out in 10. The project requirements are just not well defined in games like they are in other areas of the software industry. Games that don't iterate (because they stick to a predefined set of requirements) generally suck ass.
I'm not sure exactly why you think a gradiated fill would be any more expensive then a plain one.
The difference in computation is so insignificant that it's irrelevant.
If you don't believe me, try using Macromedia Flash (or some other vector-painting tool) to fill a bunch of areas with gradients, then do the same thing with solid fills. You'll see that they both break down in viewing at roughly the same time.
If the code is well optimized, there is no reason why a gradient fill would be more expensive then a plain fill.
Here (In case it gets slashdotted, it is a hand flexing in a very peculiar manner)
I'd recognize that motion anywhere.
They say less then 1% of that like it's not a lot of money... That's somewhere in the neighborhood of 2 BILLION dollars a year.
Then that would be fraud.
Actually, no. There are a few places that differ a bit (user experience), but in general, the code just works. The trick is where your toolkit lies. Too close to the underlying APIs, and you're right--the software is for one platform, and simply ported to the other. Too far from the APIs, and you wind up doing everything twice.
Plus, it's open source. If the code worked even partially in a Windows environment, I'd probably donate a few hours a week to making sure that it really behaved on Win32.
God, I totally agree. I would use Evo in a heartbeat if it were available on Windows. (And no, I cannot switch, I develop products for x86/Windows).
To the other poster who suggests that it would not be possible, desirable, or easy to support cross platforms... That's total bunk. I used to develop commercial apps that ran on Windows, Linux, Mac/OS9 and OSX. It *does* require a bit more work, but in practice, it's actually not much more work than supporting one OS.
Please look up what the semi-colon is used for; it should be used in place of a period for emphasis.
Apologies for my grammar correction, but is seriously irks me when someone decides to send *an open letter* to a company and doesn't check for grammar, punctuation, and spelling mistakes. Or does OpenOffice not support these features?
I played this a ways back (about 6 months ago) and the art was *terrible.*
So terrible--in fact--that I never looked back.
I believe you are looking for this:
Hommestar funny 404
Bwahahahahah. Great Futurama reference. Wish I had mod points today.
And let me be the first (only?) to say that the new direction is seriously kick-ass. Basically, all of the things that programmers generally mess up on are being integrated into the API and done automatically (or not, depending on what options you set).
The next version of DirectX (I believe called DirectNext) is going to really help push the capabilities of today and tomorrow's graphics cards.
And before I start hearing it, I do not work for MS. I write graphics for games for a living.
Sorta. There are numerous games out already that are based on Java. Pretty much all of Popcap uses Java. Java is also used as a scripting language for several games (sorry, no links), as an alternative to Python, Lisp, C++, Lua or any other interpretive language (or home-brewed language).
However, it will be a very long time (if ever) before developers switch over to Java as their language of choice. Why? Because it is only the last generation or two of games that have started to use C++.
Game developers are constantly trying to push the edges of what can be done within current hardware limitations. The problem with languages that do a lot for us is that... They do a lot for us. Which is nice a lot of times. But always seems to happen at the most inconvenient time (like when we're doing matrix operations, or animating units).
The GPU is *great* at them. Anything that can be expressed as a massively parallel simulation or effect is a cake-walk for the GPU.
As the author mentions, the bottleneck right now is getting data back from the GPU. However, the more successive steps you can do in a row on the GPU, the better off you are. Even with the new PCI express, this will remain true. The more successive steps you can do without having to retrieve the data, the faster your processing will be.
There are lots of cool demos over at NVIDIA's website that exploit the cool things that can be done with the parallelism of the GPU.
I've been toying with writing a 'Go' simulator on the GPU. Just haven't gotten around to it yet.
There's actually quite a bit of research about this topic. For instance, as another poster suggested, we think we are looking for other water-based organisms, because of the requirements of planetary stability and the particular importance of water from a biochemical standpoint. (I unfortunately do not have enough education in Biochem to go into the specifics).
Because of this requirement, SETI tends to focus its search around the watering hole. As other posters have suggested, we're not particularly looking for a signal with a message yet, just a signal that cannot be explained by natural phenomena, and that is not earth based.
Now, as to the other questions I've been seeing about 'math' and whether it is a useful way to detect an alien civilization.
There are numerous values in math that are constants, regardless of your perception or how you describe them. For instance, the ratio of the diameter of a circle to its circumference is always PI. There is also e, which any advanced civilization would have come upon, or at least any civilization which was sending signals using EMag (because these numbers are fundamental to such a system).
The difficulty with these particular numbers is that they are not integers, so encoding them would be difficult to do in a recognizable way. However, integers would be fairly easy to encode, even if the civilization were using a different base for counting then we were. There would be no mistaking of the first n primes or the first n digits of the fibonacci sequence.
Yes, I can see where you're coming from. There definitely haven't been any innovative games created by professionals. Definitely not Commander Keen, The Sims, Doom, Quake, Battlefield 1942, Deus Ex, GTA3, PopCap games, Everquest... Nope, none at all.
Did you read the article? He points out some very important differences. Let me add another: code control. I don't want people whom I don't know poking around in code that they don't necessarily understand. I don't want people who don't understand data structures trying to add 'features' to my code. Games push the limits of your CPU and GPU all the time. You don't want to do that because of inefficiencies in the code. You want to do that because you're adding effects that people have never seen before. Or you want to make your units more intelligent then other players.
What strikes me as funny about your argument is that most of the innovation that has gone into games in the last 10 years is stuff that players generally don't even notice. Better pathfinding. Increased polygons count through more efficient storage. More textures used better. Better AI. Random map generation.
But players don't notice these things.
They just notice how this unit is similar to this other unit in this other game.
As I mentioned, there are cases where the entire window has been dirtied.
Do the math. 1600x1200x32 ~= 7.6M. Even if you compress that using png, you're going to be looking at around 2M worth of data.
That's not an acceptable amount of information to be sending across the network.
a) Hi. Read the article. What you're not understanding is that I'm asserting that he is wrong.
b) That's totally wrong. Consider the size of a windows message in another OS. For instance... Windows. Messages are 32-bytes. They are sent infrequently. Sending pixel updates would require 32 bytes PER PIXEL. Sent frequently.
Yes, but even though Open/GL supports sending info over a network, what happens when you have view-dependent data.
For instance, it would be efficient to send vertices, matrices, and large amounts of other data across the network (maybe). But sending texture data is going to suck.
You can assume that he would require all clients to have all textures used within the application. But what about (for instance) the gimp?
One problem is his treatment of remote windows... He suggests sending them over as video streams.
If networking bandwidth is a problem now with the X format (which is basically just sending clicks and so forth), why does he think the response is going to be any better when sending *a huge ton of pixel data*?
Even if you assume that you only have to transmit differences, there are still cases where the difference will be several megs. (For example, a fullscreen clear in 1600x1200x32).
Dear 80's Star Wars fan in my target market,
y -no-kidding-this-time Edition. Which will actually just be the original theater version.
Actually, I'm willing to be that you will purchase this version when it comes out. You'll open up the shiny plastic and you'll curse my name for not releasing the "pure" movies. It is possible that you will resist this boxed set, but fortunately for me you have friends and relatives who remember how much you love Star Wars, and *certainly* one or more of them will purchase this collection for you. Either way, your money will already be mine, and I won't really care. I'll be laughing all the way to the bank in one of my 30 new Ferraris.
However, I will let you in on a little secret. Ever since DVD came around as a format, I've been saying that I didn't feel DVD was an appropriate format for the Star Wars franchise. I didn't think the betamax sales had fallen off enough to cannibalize my own market share. However, I've clearly changed views on that, and it is therefore likely that at *some* point in the future, I will release the super-duper-ultra-elite-Star-Wars-Final-absolutel
I hope this tidbit holds you over.
The master of your wallet,
George Lucas
And doesn't really offer any solid evidence besides.
The author's points are actually pretty weak, too.
He complains that people who say that Windows is easier to install and maintain are simply not comparing apples-to-apples. That seems unlikely, given that Windows is easier to install and maintain than Linux. That's a very broad category, and to be honest, I'd have to agree with them. That is NOT a fault of Linux itself, it is a fault of poor vendor support for the underdog OS.
Then, he tries to go on to state that there is plenty of software available for Linux. That doesn't address the counterargument. The original assertion is that there are specific apps (let me spell that, s-p-e-c-f-i-c) that are unavailable on Linux that the person is unwilling to lose. For instance, I cannot play Age of Mythology on Linux. I cannot play World of Warcraft on Linux. I cannot use MS word on linux. And before my detractors attempt to do so, I have to state that you *cannot* trivialize someone's choice of application, because they have time invested in training on how to use *that* application that they may not be willing to give up.
His third point... Was that really a point? It seemed like a half-hearted swing at the opposition.
I'm not saying that Linux *shouldn't* be the dominant operating system, I'm simply saying that it *isn't* and there are valid reasons why that is true. My firm belief is that if Linux wants to win the desktop war, you have to do two things: 1) Hit the competition where it hurts (in the wallet), and 2) Stop trying to convert the old. Its not gonna work. CONVERT THEIR CHILDREN.
I'm not sure whether to laugh or to scold you... Some people clearly thought you were trying to be funny, although I would suspect that since you posted anonymously, you were actually being serious.
At any rate, John Carmack is a pretty decent coder, but I'm not sure who this Jon Carmack person is.