I am a PC advocate. I am also a gamer. This said, there are things which are being overlooked in these posts:
Consoles are uniform. While PS2 is different from DC, the DC is always a DC; PS2 is always a PS2. Uniform hardware is what makes SOLID programming (lower bug count) possible, and has been done ALL ALONG on consoles - why would that change? The point? Why have a storage device, when it can be stored on a remote server? Who needs patches when you make the game right the first time? Of course there will be bugs, and there will likely be more of them with more complex games, but that brings another point: Why make a game that is not suited for a console and try to put it there? Granted, companies will want to just for the buck, but a great console game is designed around the input device(s).
Storage devices actually encourage hacks, as without them, how are you going to change the game?
Speaking to that last issue, keyboards (a must in my book anyway) also encourage hacking, as keyboard input means you can use it to hack the storage device.
On account of the inevitable bandwidth increase, games can mostly be on the central server, and hence most patches can be server side or implemented "real-time" before the game actually begins, also relieving the need for a local storage device.
A point on MMPGs: they need not ALL be complex RPG-format or 3D 1st person games. MMPG is Massivley Multi-Player Game, not Massively Multiplayer ROLE-playing game...
To future console game designers (myself probably included): Design games around the console and it's inputs; do not under any circumstances try to cram a PC game into a console and it's limited input resources.
Note to all: there are MANY types of console input devices currently available and many more planned - don't count the console dead on that account.
Conclusion: It can be done; it can be done right. IMO ('H' conspicuously missing): Yes on console MMPG, Yes on keyboards, No on storage devices.
...is the input rates. 3D games that make use of motion (just about all do as far as I am aware) rely on framerate as a basis for input time slices - i.e. faster framerate = faster input response cycle.
Play a racing game at 30 fps and you will be all over the road because you only have (for example - I've not coded the stuff yet so I don't know the actual stats) 30 times in a second that the computer accepts input.
Consider: you're heading for the rail on the left - you yank the wheel to the right; assume input ranges from 0 to 100 with 0 = hard left, 50 = center, 100 = hard right
At 30fps you have input at 50, then in LESS than 1/30th of a second you are at 100. NEXT FRAME the system acknowledges a hard right, possibly reeling you out of control.
At 60fps, VISUAL does not appear any different, but input is 50, 75, 100 and the game registers the 75, and you maintain control.
This is WAY simplified, but hopefully you can extrapolate the point.
I would appreciate if you'd excuse any amateur-ness to the post as it is my first on/.
Slashdot Mirror
I am a PC advocate. I am also a gamer. This said, there are things which are being overlooked in these posts:
Consoles are uniform. While PS2 is different from DC, the DC is always a DC; PS2 is always a PS2. Uniform hardware is what makes SOLID programming (lower bug count) possible, and has been done ALL ALONG on consoles - why would that change? The point? Why have a storage device, when it can be stored on a remote server? Who needs patches when you make the game right the first time? Of course there will be bugs, and there will likely be more of them with more complex games, but that brings another point: Why make a game that is not suited for a console and try to put it there? Granted, companies will want to just for the buck, but a great console game is designed around the input device(s).
Storage devices actually encourage hacks, as without them, how are you going to change the game?
Speaking to that last issue, keyboards (a must in my book anyway) also encourage hacking, as keyboard input means you can use it to hack the storage device.
On account of the inevitable bandwidth increase, games can mostly be on the central server, and hence most patches can be server side or implemented "real-time" before the game actually begins, also relieving the need for a local storage device.
A point on MMPGs: they need not ALL be complex RPG-format or 3D 1st person games. MMPG is Massivley Multi-Player Game, not Massively Multiplayer ROLE-playing game...
To future console game designers (myself probably included): Design games around the console and it's inputs; do not under any circumstances try to cram a PC game into a console and it's limited input resources.
Note to all: there are MANY types of console input devices currently available and many more planned - don't count the console dead on that account.
Conclusion: It can be done; it can be done right. IMO ('H' conspicuously missing): Yes on console MMPG, Yes on keyboards, No on storage devices.
...is the input rates. 3D games that make use of motion (just about all do as far as I am aware) rely on framerate as a basis for input time slices - i.e. faster framerate = faster input response cycle.
/.
Play a racing game at 30 fps and you will be all over the road because you only have (for example - I've not coded the stuff yet so I don't know the actual stats) 30 times in a second that the computer accepts input.
Consider: you're heading for the rail on the left - you yank the wheel to the right; assume input ranges from 0 to 100 with 0 = hard left, 50 = center, 100 = hard right
At 30fps you have input at 50, then in LESS than 1/30th of a second you are at 100. NEXT FRAME the system acknowledges a hard right, possibly reeling you out of control.
At 60fps, VISUAL does not appear any different, but input is 50, 75, 100 and the game registers the 75, and you maintain control.
This is WAY simplified, but hopefully you can extrapolate the point.
I would appreciate if you'd excuse any amateur-ness to the post as it is my first on