I doubt they would have the technical know-how, but yes, this is already happening through legal and political means: witness a) the continuing expansion of US copyright law to the rest of the world by any means possible, and b) the fact that a UK version of this law applying to overseas broadcasts has been in place since April 2006.
Speed is only an issue on PC. Disk space is not cheap any more on consoles when we compare time required to load into memory versus time required to generate stuff using the CPU(s). CPU speed is increasing a lot faster than disk transfer rate.
Two reasons this doesn't make it into more games are:
1. This stuff takes a lot of development time to achieve the same level of quality of modelling something in Maya or Max, or painting something in Photoshop. And in games, artwork is more readily outsourceable than programming.
2. Off-the-shelf, artist-friendly procedural tools are still geared towards offline baking of assets which become normally loaded meshes and textures at runtime. Custom procedural tools (which can leverage the procedural nature on the runtime itself) are still mostly one step above programmer art. Tons of knobs and dials to tweak that the programmers added because they were easy or cool, typically not very easy for artists to use in a directed fashion.
It's a harder problem to make NPCs react intelligently to groups of players than to single players, especially when you mix in the trend toward NPC squad intelligence. But this isn't the only reason co-op is more difficult.
Designwise, levels are difficulty-balanced for single player. Co-op requires re-balancing, or the development of some algorithmic way of balancing, neither of which are trivial.
If co-op is effectively adding more players to the single player campaign, somewhere you have to find the machine power to run extra player control models, render more characters, do more physics, etc. Not usually trivial since in the interests of making the single player as good as possible you have usually used up almost all of the memory & CPU time available. Particularly, this is why there have been almost no co-op FPS games on consoles.
You might have streaming textures, terrain, geometry, animations, etc - what do you do if the players are physically separated? Also, the enemy encounters are probably controlled by the player entering and leaving trigger volumes. All of this type of logic has to deal with multiple players.
Just a few of the reasons why producing co-op gameplay is nowhere near as easy as (comparatively) empty competitive multiplayer levels. You can also add in the fact that many games have multiplayer added after the single player has been designed and half implemented. Even for games that start with a multiplayer capable engine, the multiplayer game often tends to languish until halfway through the dev cycle.
IME Pay-as-you-go in the USA isn't real PAYG. The account still expires if you don't keep paying, even if you have a positive balance. So it's actually "pay every 3 months instead of every month". If you don't use your phone very much (I mostly just keep it for emergencies and such) then you still end up with $$$ worth of time that you won't use.
I used to have real PAYG in the UK: I spent about £30 on my phone calls & SMS over the course of 3 years. Now my cheapest option is 3 or 4 times that because my account "expires" periodically.
The reason why at least one game shop uses Lua rather than Python is that Lua was written by just a few people.
They are both under similar "free, non-copyleft" licenses, but in the case of Python, what makes the lawyers nervous is that the Python code has (and has had) many contributors, any of whom may step forward and demand their pound of flesh at some future time. The point is not that the case would be successful, but companies want to avoid going to court and exposing their inner workings.
This won't happen with Lua: it was written by a few people who can sign agreements to guard against this future possibility.
The paper states: "For forensics, we anticipate that our techniques will be most useful when arguing that a given device was not involved in a recorded event."
"... we stress that our techniques do not provide unique serial numbers for devices"
They recognise that of the millions of machines on the Internet, many will have identical clock skews within measurable limits. If this is used for activation purposes, the only application would be of a negative result - i.e. you can't install it again on a machine with a different skew from the original.
For all the technical upsides, front projection has one big down side: you can't play DDR with it!
Or any other games (e.g. EyeToy) which involve standing between projector and screen...
Agreed about Settlers of Catan. I have read that the original game as designed was in fact Seafarers, and that Settlers was cut down from it to make a nice 1-hour game that perhaps could be better marketed? I can believe that, having played both: Seafarers seems the more rounded.
It's a great game and particularly interesting for the number of strategies available and the way in which the game limits force strategy changes over time.
Story and graphics are orthogonal. To me the real caveat here is realism for realism's sake.
Realistic graphics don't make a good game, and "cinematic" doesn't have to mean "realistic" either. The best games have good gameplay, good story if required for the genre, but equally importantly, a distinctive, consistent graphical style - not necessarily (or even desirably) a realistic one.
While 128 players is a great achievement, it's not all about the network model.
The reason why most FPSs do not have such large numbers of players is less to do with the network bandwidth and more to do with a) the CPU cycles devoted to rendering and/or running collision models for N detailed player characters in complex environments, and b) the content generation: maps are specifically designed to be good for a smallish range of players, and it's usually not worth it to design 128-player maps.
This is clearly a good network engine. But the other FPSs of the world aren't failing to support 128 players because the TNL programmers are technical geniuses by comparison. They are undoubtedly good, but they're solving a different problem.
As an FPS network programmer, you use the available bandwidth to provide the best experience for the player. You stop optimising when you don't need to optimise any more. If all your maps aim to provide a good experience for 4, 8, 16 players, you don't design the engine to go up to 128 just because you think it would be neat.
Europeans only have themselves to blame for using PAL TVs.
A good portion major-manufacturer TVs in Europe are multi-standard, much more so than in the US where a multi-standard TV is considered specialist. Even the smaller European TVs can usually sync to a 60Hz signal, so for the most part it is just the territory lockout (where it can't be worked around) preventing Europeans from importing.
Slashdot Mirror
Exactly my thoughts. Did the defence not use this argument? Also, what was the length of the IP address lease? Probably less than a month...
I doubt they would have the technical know-how, but yes, this is already happening through legal and political means: witness a) the continuing expansion of US copyright law to the rest of the world by any means possible, and b) the fact that a UK version of this law applying to overseas broadcasts has been in place since April 2006.
Speed is only an issue on PC. Disk space is not cheap any more on consoles when we compare time required to load into memory versus time required to generate stuff using the CPU(s). CPU speed is increasing a lot faster than disk transfer rate.
Two reasons this doesn't make it into more games are:
1. This stuff takes a lot of development time to achieve the same level of quality of modelling something in Maya or Max, or painting something in Photoshop. And in games, artwork is more readily outsourceable than programming.
2. Off-the-shelf, artist-friendly procedural tools are still geared towards offline baking of assets which become normally loaded meshes and textures at runtime. Custom procedural tools (which can leverage the procedural nature on the runtime itself) are still mostly one step above programmer art. Tons of knobs and dials to tweak that the programmers added because they were easy or cool, typically not very easy for artists to use in a directed fashion.
It's a harder problem to make NPCs react intelligently to groups of players than to single players, especially when you mix in the trend toward NPC squad intelligence. But this isn't the only reason co-op is more difficult.
Designwise, levels are difficulty-balanced for single player. Co-op requires re-balancing, or the development of some algorithmic way of balancing, neither of which are trivial.
If co-op is effectively adding more players to the single player campaign, somewhere you have to find the machine power to run extra player control models, render more characters, do more physics, etc. Not usually trivial since in the interests of making the single player as good as possible you have usually used up almost all of the memory & CPU time available. Particularly, this is why there have been almost no co-op FPS games on consoles.
You might have streaming textures, terrain, geometry, animations, etc - what do you do if the players are physically separated? Also, the enemy encounters are probably controlled by the player entering and leaving trigger volumes. All of this type of logic has to deal with multiple players.
Just a few of the reasons why producing co-op gameplay is nowhere near as easy as (comparatively) empty competitive multiplayer levels. You can also add in the fact that many games have multiplayer added after the single player has been designed and half implemented. Even for games that start with a multiplayer capable engine, the multiplayer game often tends to languish until halfway through the dev cycle.
IME Pay-as-you-go in the USA isn't real PAYG. The account still expires if you don't keep paying, even if you have a positive balance. So it's actually "pay every 3 months instead of every month". If you don't use your phone very much (I mostly just keep it for emergencies and such) then you still end up with $$$ worth of time that you won't use. I used to have real PAYG in the UK: I spent about £30 on my phone calls & SMS over the course of 3 years. Now my cheapest option is 3 or 4 times that because my account "expires" periodically.
The reason why at least one game shop uses Lua rather than Python is that Lua was written by just a few people. They are both under similar "free, non-copyleft" licenses, but in the case of Python, what makes the lawyers nervous is that the Python code has (and has had) many contributors, any of whom may step forward and demand their pound of flesh at some future time. The point is not that the case would be successful, but companies want to avoid going to court and exposing their inner workings. This won't happen with Lua: it was written by a few people who can sign agreements to guard against this future possibility.
In fact, whatever happened to the NeGcon? It was hands down the best controller for driving games. Gran Turismo just wasn't the same after mine broke.
The paper states:
"For forensics, we anticipate that our techniques will be most useful when arguing that a given device was not involved in a recorded event."
"... we stress that our techniques do not provide unique serial numbers for devices"
They recognise that of the millions of machines on the Internet, many will have identical clock skews within measurable limits. If this is used for activation purposes, the only application would be of a negative result - i.e. you can't install it again on a machine with a different skew from the original.
Only per household, not per TV.
For all the technical upsides, front projection has one big down side: you can't play DDR with it! Or any other games (e.g. EyeToy) which involve standing between projector and screen...
Agreed about Settlers of Catan. I have read that the original game as designed was in fact Seafarers, and that Settlers was cut down from it to make a nice 1-hour game that perhaps could be better marketed? I can believe that, having played both: Seafarers seems the more rounded.
It's a great game and particularly interesting for the number of strategies available and the way in which the game limits force strategy changes over time.
Story and graphics are orthogonal. To me the real caveat here is realism for realism's sake.
Realistic graphics don't make a good game, and "cinematic" doesn't have to mean "realistic" either. The best games have good gameplay, good story if required for the genre, but equally importantly, a distinctive, consistent graphical style - not necessarily (or even desirably) a realistic one.
While 128 players is a great achievement, it's not all about the network model.
The reason why most FPSs do not have such large numbers of players is less to do with the network bandwidth and more to do with a) the CPU cycles devoted to rendering and/or running collision models for N detailed player characters in complex environments, and b) the content generation: maps are specifically designed to be good for a smallish range of players, and it's usually not worth it to design 128-player maps.
This is clearly a good network engine. But the other FPSs of the world aren't failing to support 128 players because the TNL programmers are technical geniuses by comparison. They are undoubtedly good, but they're solving a different problem.
As an FPS network programmer, you use the available bandwidth to provide the best experience for the player. You stop optimising when you don't need to optimise any more. If all your maps aim to provide a good experience for 4, 8, 16 players, you don't design the engine to go up to 128 just because you think it would be neat.
Europeans only have themselves to blame for using PAL TVs. A good portion major-manufacturer TVs in Europe are multi-standard, much more so than in the US where a multi-standard TV is considered specialist. Even the smaller European TVs can usually sync to a 60Hz signal, so for the most part it is just the territory lockout (where it can't be worked around) preventing Europeans from importing.