I really can't see Spore reaching the 'moms and girlfriends' market the way The Sims did. The Sims does indeed represent a virtual dollhouse, but Spore is something else all together. Outside of 'gamers', Spore is only likely to interest the kind of people who are really interested in things like micro-biology, evolution, space exploration, etc. That doesn't doom it to failure, but I don't see it having the mass market success of The Sims.
Spore seems like even less of a 'game' than Black and White.
I hope you don't get modded down to much by people who are caught up in the hype. Hell, we are looking at an article which is basically about how Spore will change the world as we know it. I think that's slightly out of control, in the end most of us will just move on to something else after a week or so (like we did after B&W). I'm certain it will be a technical masterpiece (as with B&W again), but that alone will never be enough.
You misunderstood me, I know it wouldn't be an issue for software that uses DirectX; all the old stuff will have to work on Vista anyway. The difficulty would be in the device drivers, the operating system, and the implementation of DirectX.
In Vista, GPU resources are virtualised by the operating system; it's similar to the transition between real and protected mode operating systems on x86. It's kind of like asking for DirectX 9 on Windows 3.1. You could argue that it's just a different driver model, like 98->XP, but I would imagine that adding virtualisation would make the transition much more difficult than that.
Good thoughts. I think it's much more likely to go the Xbox route than the Windows route. The problem with building a new version of Windows (or dos) is that it has to do everything the current version does (and dos too, mostly).
It's not as if those games are going to make a big impact in the market. I would also be very suprised if this device ends up being a direct competitor for the DS.
They never assumed you would have to fit your whole framebuffer in EDRAM at once, that's why they have predicated tiling. I'm not going to go beyond what info is publicly available, but you clearly have no idea what you're talking about.
The article is about RSX<->Cell bandwidth, not SPU local stores. It's a non-issue for reasons explained in many other posts already. Even the title is wrong since it's not an issue with the Cell, but with the host system.
The big Wii demo at Nintendos E3 conference was tennis; not trying to look any more like real tennis, but definitely trying to play more like it. If a fancy looking tennis game with a gamepad makes you want to play real tennis, what about one where you actually have to swing the controller around like a raquet?
Playing sports games for me has never been a replacement for playing the actual sports; it's not a simulation of athletics, it's a simulation of the mental side of the sport. Wii tennis though (and baseball, etc), really makes me wonder why I would stand in my living room making serve and forehand motions with a controller rather than going out and playing for real.
$2 might be ok for a couple really great programmes, but right now I can watch a hell of a lot more than 15 episodes of programming for the $30 I spend per month on cable. Even just watching the daily show and colbert report would cost too much with that model. The other issue I would have is that it would force me to make a value judgement for everything I watch, including programmes I've never seen before.
An alternative is a two-tiered system with and without advertising, sort of like TV vs. DVD.
If you are talking about programming, it's all tools. A game engine is just as much a tool as photoshop, it just fits in a different spot in the pipeline.
I like to keep the actual software the player uses (the engine) absolutely as compact as possible, which means I spend a lot of time writing software that gets used in production only. For example: our tool chain supports all kinds of image formats for asset creation, but the data actually used by the engine is always in platform specific formats, and the engine never needs to support anything else.
It's pretty much common sense to do as much as possible offline, so I think you should avoid drawing an arbitrary line between 'tools' and 'game', and just enjoy doing any work that contributes to the end product.
Just the idea of the controller might have sparked people's imagination to a damaging degree. I think a lot of people imagined the thing having full six degrees of freedom absolute positioning; a controller that knows exactly where it is in the room and how it's oriented.
Excuse me for recycling a topic from the 'blogosphere', but take for example the sword control in ubisoft's red steel demonstration. The expectation was that when using the controller as a sword, the moves you made with the controller would translate directly into movements of the sword in the game. The reality is that it basically detects simple gestures such as slashes, and the sword in the game performs predefined moves accordingly. This is not to assume that the former method would be any more fun, it's just that the latter is not going to meet expectations of interactivity.
From a technical point of view, I think the 6-dof absolute positioning is out of the question (though I would love to be proven wrong). It seems like there are probably two systems involved: accelerometers, and a pointing device. The accelerometers probably measure 6-dof of acceleration, and are could be very similar to what's going to be in the PS3 controller. They will useful for detecting discreet movements, like the sword slashes, but will not give you absolute positioning. The pointing device uses a sensor bar which you place next to the TV, and there is a window on the front of the Wii controller which is most likely used for this system. My theory about how it works (could be wrong, common knowledge, or in patents, etc. I have no idea) is that the sensor bar is basically just a marker, and the controller has a camera type device on the front of it which can locate the sensor bar relative to the controller. This would give you a pretty accurate absolute orientation, but probably only with line of sight between the front of the controller and the sensor bar. As soon as line of sight is broken, you'd just have a PS3 controller.
I think there is a lot of gameplay potential in the controller, and the average consumer probably doesn't care about how it works, especially if the games are fun. However, many of the people who have been conjecturing, and building up this mass of hype around the system might feel a bit let down when they don't end up with a magical virtual reality wand to play lightsaber with.
I'm not an expert on this, but aren't the bugs in the design, not from the manufacturing process? It's just like writing software, they find design errors and declare them shippable if they are minor enough. Switching the manufacturing process shouldn't change the errata at all.
Same goes for the timing, sure they might be able to run the new version at a higher clock rate, but they won't. Since it's the exact same design, the timing will be the same when run at the same rate.
Data must be encrypted from disc to display precisely because everything in between can't be trusted. All the software has to do is pass that data along intact, so I don't see why open source would make a difference.
Now, educate me on how exactly you design the game 'properly' so that some external hardware device cannot mimic human keyboard commands?
Maybe make a game that actually requires brain activity to succeed? We're not talking about a chess playing super computer here, or some cutting edge artificial intelligence. This game is exploitable by simple keyboard macros, which shows that it is far too simplistic. It rewards repetitive behaviour, and as a result, suffers from this sort of exploitation.
Xbox kits (green ones) are _way_ cheaper than that, or at least have been for the last couple years. I'm not sure about PS2 as we haven't bought any in ages, but PSP kits are also a lot less than your figure. If you want to show some proof, fine, but I'm not going to bother if you won't.
D is the only language that got my hopes up at all, but there are a few minor worries I have about it. I don't much like losing multiple inheritance, but it's not a dealbreaker. I'm not really sure how the heap works, and if you can ditch the garbage collector, or at least manage the heap manually. It seems not to have the option of static casts for certain types. I definitely like the idea of the language, and if anyone has any experiences with it, it would be nice to hear from you.
Unfortunately, at this point for a language to be practical for games it would need to both interface with existing C calling conventions, compile to C as an intermediate language.
I would love to find a replacement for C++, and if there is something that will meet my requirements, please let me know.
First of all, lets ignore the actual existence of the language tools, if there is even anything on the horizon, I'd like to know. In order to replace C++, I need something with that will be as efficient and predictable. I need some way to exploit all features of the machine, for example: If the machine has a reciprocal-square root instruction, I can make an function inline float rsqrt(float) in C++, and use inline asm to emit the instruction. The compiler will then slot that instruction right into the calling code and optimise it extremely well (no branches, no extra loads, etc). I'm not saying that exact method is ideal, but the bottom line is if the machine has a certain reciprocal-square root performance, I'd need to be able to at least approach it. The only reason this works in C++ is because you usually have an assembler that can generate any instruction the target machine can execute, and the C++ compiler gives you a window to it.
Memory management is the other big issue. I need to have more control over memory than just a global garbage collected heap and a stack. The option of using a garbage collector on a block of memory is not unwelcome, but I need to have more control for some things. In C++ I can specify the address of an object, so for example, if the machine has scratchpad memory, I use that memory and still have reasonably maintainable code.
C++ is not perfect by any means, but right now you can develop a game for all of the major platforms using it, and usually with it alone (with inline asm, and for the main processor at least). I await it's successor in this field, but I don't think it's out there just yet.
PS. I would just be happy if we had more modern multipass compilers for C++ that would unify declaration and definition.
You know it's possible to make exact digital copies of those backups, right? As far as copies for personal use, you get a lot more than you did in the days of vinyl or cassette. With those you couldn't even make a single accurate copy.
Slashdot Mirror
I really can't see Spore reaching the 'moms and girlfriends' market the way The Sims did. The Sims does indeed represent a virtual dollhouse, but Spore is something else all together. Outside of 'gamers', Spore is only likely to interest the kind of people who are really interested in things like micro-biology, evolution, space exploration, etc. That doesn't doom it to failure, but I don't see it having the mass market success of The Sims.
Spore seems like even less of a 'game' than Black and White.
I hope you don't get modded down to much by people who are caught up in the hype. Hell, we are looking at an article which is basically about how Spore will change the world as we know it. I think that's slightly out of control, in the end most of us will just move on to something else after a week or so (like we did after B&W). I'm certain it will be a technical masterpiece (as with B&W again), but that alone will never be enough.
You misunderstood me, I know it wouldn't be an issue for software that uses DirectX; all the old stuff will have to work on Vista anyway. The difficulty would be in the device drivers, the operating system, and the implementation of DirectX.
In Vista, GPU resources are virtualised by the operating system; it's similar to the transition between real and protected mode operating systems on x86. It's kind of like asking for DirectX 9 on Windows 3.1. You could argue that it's just a different driver model, like 98->XP, but I would imagine that adding virtualisation would make the transition much more difficult than that.
It's pretty ugly, but it is possible to hint some compilers about such things using OpenMP, etc.
Good thoughts. I think it's much more likely to go the Xbox route than the Windows route. The problem with building a new version of Windows (or dos) is that it has to do everything the current version does (and dos too, mostly).
It's not as if those games are going to make a big impact in the market. I would also be very suprised if this device ends up being a direct competitor for the DS.
They never assumed you would have to fit your whole framebuffer in EDRAM at once, that's why they have predicated tiling. I'm not going to go beyond what info is publicly available, but you clearly have no idea what you're talking about.
Predicated Tiling
The article is about RSX<->Cell bandwidth, not SPU local stores. It's a non-issue for reasons explained in many other posts already. Even the title is wrong since it's not an issue with the Cell, but with the host system.
The big Wii demo at Nintendos E3 conference was tennis; not trying to look any more like real tennis, but definitely trying to play more like it. If a fancy looking tennis game with a gamepad makes you want to play real tennis, what about one where you actually have to swing the controller around like a raquet?
Playing sports games for me has never been a replacement for playing the actual sports; it's not a simulation of athletics, it's a simulation of the mental side of the sport. Wii tennis though (and baseball, etc), really makes me wonder why I would stand in my living room making serve and forehand motions with a controller rather than going out and playing for real.
$2 might be ok for a couple really great programmes, but right now I can watch a hell of a lot more than 15 episodes of programming for the $30 I spend per month on cable. Even just watching the daily show and colbert report would cost too much with that model. The other issue I would have is that it would force me to make a value judgement for everything I watch, including programmes I've never seen before.
An alternative is a two-tiered system with and without advertising, sort of like TV vs. DVD.
If you are talking about programming, it's all tools. A game engine is just as much a tool as photoshop, it just fits in a different spot in the pipeline.
I like to keep the actual software the player uses (the engine) absolutely as compact as possible, which means I spend a lot of time writing software that gets used in production only. For example: our tool chain supports all kinds of image formats for asset creation, but the data actually used by the engine is always in platform specific formats, and the engine never needs to support anything else.
It's pretty much common sense to do as much as possible offline, so I think you should avoid drawing an arbitrary line between 'tools' and 'game', and just enjoy doing any work that contributes to the end product.
This isn't really an Apple vs. Microsoft issue, but still interesting.
... which is awesome.
Just the idea of the controller might have sparked people's imagination to a damaging degree. I think a lot of people imagined the thing having full six degrees of freedom absolute positioning; a controller that knows exactly where it is in the room and how it's oriented.
Excuse me for recycling a topic from the 'blogosphere', but take for example the sword control in ubisoft's red steel demonstration. The expectation was that when using the controller as a sword, the moves you made with the controller would translate directly into movements of the sword in the game. The reality is that it basically detects simple gestures such as slashes, and the sword in the game performs predefined moves accordingly. This is not to assume that the former method would be any more fun, it's just that the latter is not going to meet expectations of interactivity.
From a technical point of view, I think the 6-dof absolute positioning is out of the question (though I would love to be proven wrong). It seems like there are probably two systems involved: accelerometers, and a pointing device. The accelerometers probably measure 6-dof of acceleration, and are could be very similar to what's going to be in the PS3 controller. They will useful for detecting discreet movements, like the sword slashes, but will not give you absolute positioning. The pointing device uses a sensor bar which you place next to the TV, and there is a window on the front of the Wii controller which is most likely used for this system. My theory about how it works (could be wrong, common knowledge, or in patents, etc. I have no idea) is that the sensor bar is basically just a marker, and the controller has a camera type device on the front of it which can locate the sensor bar relative to the controller. This would give you a pretty accurate absolute orientation, but probably only with line of sight between the front of the controller and the sensor bar. As soon as line of sight is broken, you'd just have a PS3 controller.
I think there is a lot of gameplay potential in the controller, and the average consumer probably doesn't care about how it works, especially if the games are fun. However, many of the people who have been conjecturing, and building up this mass of hype around the system might feel a bit let down when they don't end up with a magical virtual reality wand to play lightsaber with.
You are good.
You can run cmd.exe in rxvt or something if you don't like the default windows terminal. I would assume the same is true for this.
I'm not an expert on this, but aren't the bugs in the design, not from the manufacturing process? It's just like writing software, they find design errors and declare them shippable if they are minor enough. Switching the manufacturing process shouldn't change the errata at all.
Same goes for the timing, sure they might be able to run the new version at a higher clock rate, but they won't. Since it's the exact same design, the timing will be the same when run at the same rate.
It gets decrypted in software? I guess I need to read about it a bit, but that doesn't seem very secure.
Data must be encrypted from disc to display precisely because everything in between can't be trusted. All the software has to do is pass that data along intact, so I don't see why open source would make a difference.
Now, educate me on how exactly you design the game 'properly' so that some external hardware device cannot mimic human keyboard commands?
Maybe make a game that actually requires brain activity to succeed? We're not talking about a chess playing super computer here, or some cutting edge artificial intelligence. This game is exploitable by simple keyboard macros, which shows that it is far too simplistic. It rewards repetitive behaviour, and as a result, suffers from this sort of exploitation.
Xbox kits (green ones) are _way_ cheaper than that, or at least have been for the last couple years. I'm not sure about PS2 as we haven't bought any in ages, but PSP kits are also a lot less than your figure. If you want to show some proof, fine, but I'm not going to bother if you won't.
D is the only language that got my hopes up at all, but there are a few minor worries I have about it. I don't much like losing multiple inheritance, but it's not a dealbreaker. I'm not really sure how the heap works, and if you can ditch the garbage collector, or at least manage the heap manually. It seems not to have the option of static casts for certain types. I definitely like the idea of the language, and if anyone has any experiences with it, it would be nice to hear from you.
Unfortunately, at this point for a language to be practical for games it would need to both interface with existing C calling conventions, compile to C as an intermediate language.
I would love to find a replacement for C++, and if there is something that will meet my requirements, please let me know.
First of all, lets ignore the actual existence of the language tools, if there is even anything on the horizon, I'd like to know. In order to replace C++, I need something with that will be as efficient and predictable. I need some way to exploit all features of the machine, for example: If the machine has a reciprocal-square root instruction, I can make an function inline float rsqrt(float) in C++, and use inline asm to emit the instruction. The compiler will then slot that instruction right into the calling code and optimise it extremely well (no branches, no extra loads, etc). I'm not saying that exact method is ideal, but the bottom line is if the machine has a certain reciprocal-square root performance, I'd need to be able to at least approach it. The only reason this works in C++ is because you usually have an assembler that can generate any instruction the target machine can execute, and the C++ compiler gives you a window to it.
Memory management is the other big issue. I need to have more control over memory than just a global garbage collected heap and a stack. The option of using a garbage collector on a block of memory is not unwelcome, but I need to have more control for some things. In C++ I can specify the address of an object, so for example, if the machine has scratchpad memory, I use that memory and still have reasonably maintainable code.
C++ is not perfect by any means, but right now you can develop a game for all of the major platforms using it, and usually with it alone (with inline asm, and for the main processor at least). I await it's successor in this field, but I don't think it's out there just yet.
PS. I would just be happy if we had more modern multipass compilers for C++ that would unify declaration and definition.
You know it's possible to make exact digital copies of those backups, right? As far as copies for personal use, you get a lot more than you did in the days of vinyl or cassette. With those you couldn't even make a single accurate copy.