Average Manatee
Arcane
- Joined
- Jan 7, 2012
- Messages
- 14,418
No worries. I think fish that swim away from you are fully accomplishable.
-
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Decline PS4 wins the console war against XboxONE, yet it is a hollow victory as Consolesdämmerung is upon us
- Thread starter Dexter
- Start date
No worries. I think fish that swim away from you are fully accomplishable.
Cowboy Moment
Arcane
- Joined
- Feb 8, 2011
- Messages
- 4,407
Nono bro, those will run on the GPU. They only need the cloud for more complex AI behaviour like ducking behind cover.
Xi
Arcane
. Cloud: Player -> Cloud -> Processing -> Back to player
Dexter
Arcane
- Joined
- Mar 31, 2011
- Messages
- 15,655
I did write this someplace else in regards to Microsofts claims that they want to do some "rendering" e.g. in their examples lighting and physics in "the cloud", now this doesn't 100% fit with AI since simple bots are possible, but it might still elucidate why this would be an abysmally stupid idea for anything more complex.
You seem to have a basic misunderstanding of how normal Multiplayer games work and what in this instance is being referred to as “cloud”.
To simplify this somewhat let’s take Counter Strike and a bunch of players playing on a server.
There’s a Client and a Server and there are two basic steps that happen at the same time.
The Client does something (like fire his gun) or move around or changes state from standing to crouch or similar. The Client now sends this data as basic updated x/y/z coordinates and values to the Server.
At the same time the Server has received the last batch of updates from all connected Clients the same way and proceeds to send it out to everyone. This also includes if it has registered a weapon hit and how much damage has been done. The latency is effectively only your Ping time to the Server.
Most of the net code is also held rather simple (player character positions and states, hit/no hit and in some rare instances also bullet trajectories and speed or impact points for decals. You will not see many games that try and transfer physics, debris, particles or anything like that to players (even if the final representation is computed Client-side and you see these things), since depending on how many players are involved the amount of data and bandwidth required goes up exponentially. At best you will also see some position coordinates of a certain event having happened there and all the computations for debris and particle stuff usually happens Client-side and doesn’t look exactly the same for every player (which leads to synch issues between players, but they are usually minor and don’t impact gameplay).
What would happen in this “cloud” situation as proposed by Microsoft is different though.
First you have a level being rendered locally on your machine/console and let’s say you would want to offload something like physics or lighting to said Server.
What happens here is that first the Client has to send specific data connected to a certain event (in considerably larger amounts than simple positions or state changes) to the Server, for instance meshes for the involved objects (if you want to dent a barrel with an axe it needs the meshes for at least these two objects and the collision point and angle), it would also require material details or similar and possibly lighting data and other stuff like various maps used on the object. This is all being sent to the Server, the Server then has to process all that data, compute the event that just happened and send the results back to the Client and the Client basically has no other choice than to wait till the Server is done with whatever it is doing and sends its results in a similar data-intensive way (like a malformed mesh of said object(s) and whatever map changes might be required etc.) so it can update the rendering on your local machine.
At 60 Frames per second the entire process (both back and forth) would require a latency of 16.6ms at maximum in the totality of this process, even at 30 FPS this is still a stretch with 33.3ms and to be quite frank not really possible.
The process would potentially be even more complicated than “OnLive”, since in that case you are only sending control commands from your controller directly to the server instead of any game data and it does all the computing based on those commands Server-side, then a lossy/fast encoding process takes place and it sends back the picture to you.
At most Microsoft will offer "pretend tasks/jobs" outsourced to their servers like in the already oft-mentioned Sim City or even Diablo III to make it seem like what they are referring to as the "cloud" is needed, but offering resource, bandwidth and latency-intensive tasks for rendering over it isn't really feasible.
Said gimmick in the case of a game that for instance did elaborate on what they are trying to do with Forza and their "Drivatar" is simply a file locally or being allowed to be uploaded to their servers with your username and a few states they determined by some sort of algorithm of your driving behaviour saved therein (it could be even more simple with a few values on a scale for aggressiveness, speed and whatnot and I might be giving them too much credit) which is called upon and transferred to someone elses machine to be used by the game. There is no "distributed processing" happening there.
Actually: http://research.microsoft.com/en-us/projects/drivatar/forza.aspx
Some simple Multiplayer bots like: http://www.fileplanet.com/182178/180000/fileinfo/Counter-Strike-1.6---Z-Bot
Are largely defined by a few simple values and variations thereof that could run on the server without any input from you in a similar way:
Anything that would analyze and need to react to what you are doing + plan moves based on that instead of just executing a few presets and work through a nav-file is more complicated.
abija
Prophet
- Joined
- May 21, 2011
- Messages
- 2,930
Oh cut the bullshit, plenty of games already provide bots in multiplayer games which is exactly the same fucking thing and they aren't worse than what mainstream games feature in terms of AI. Not to mention how good would be for slower games (turn based for example) to have the AI running on a server farm.
The question isn't if it's possible to implement it but if M$ is willing to provide enough processing power for it, which I doubt.
Xi
Arcane
You are incorrect.
Something like shadows are a realistic option, since shadows that lag behind by half a second isn't that big a deal - especially if those shadows are of a static objects only. Car physics is not, but it can be used for something like post-crash analysis. Not everything has to happen in real time for it to be realistic option for a game.
Average Manatee
Arcane
- Joined
- Jan 7, 2012
- Messages
- 14,418
If it doesn't need to be rendered real time on the server it doesn't need to be rendered real time on the client either.
deuxhero
Arcane
So that would limit it to what... uber complicated salvage system?
Ah, but calculation time might be shorter. The server could have calculated the shadows (if it's a persistent world) long before you actually got to see them. It's just about extra options being given. You feel none are realistic, and that's fine - you wouldn't offload anything to the cloud. I'm sure some developers will have interesting ideas of what to do if they are given cloud compute capabilities.
On static objects? Yeah I'd say so.
That's just one option.
Dexter
Arcane
- Joined
- Mar 31, 2011
- Messages
- 15,655
Static/unchanging objects and things like shadows or lighting that aren't dynamic and would save GPU-cycles can be pre-baked and it was largely done 7+ years ago, read up on static shadow maps and light maps e.g.:
If there are „latency-insensitive" or static/scripted things that don't react to player input they might as well pre-compute them and include the results either on the game disc or via download.
Highly dynamic and unscripted events, for instance computations of how barrels or particles would behave if the player shoots them would be rather latency-sensitive though and this wouldn't be feasible because of considerable lag.
Most games and applications other than a few Indies have largely gone over to use real-time lighting and shadowing system, for instance using radiosity within Frostbite 2 and other engines with the possibilities of light reflection from various materials etc.
Again, it's a stupid system to mix and doesn't make much sense other than as pretense for Always-Online DRM systems and gimmicks.
Even doing the entire rendering server-side and sending the player just the video-stream makes more sense in an application perspective, but people should already know that this doesn't work properly and there are considerable problems after the failure and bankruptcy of "OnLive" and the lack of focus Sony is putting on "Gaikai".
Least of which to dismiss is the operating and upgrading cost involved that customers usually bankroll themselves by buying new graphics cards and consoles to play new games or the ownership/subscription based context of these services.
If there are „latency-insensitive" or static/scripted things that don't react to player input they might as well pre-compute them and include the results either on the game disc or via download.
Highly dynamic and unscripted events, for instance computations of how barrels or particles would behave if the player shoots them would be rather latency-sensitive though and this wouldn't be feasible because of considerable lag.
Most games and applications other than a few Indies have largely gone over to use real-time lighting and shadowing system, for instance using radiosity within Frostbite 2 and other engines with the possibilities of light reflection from various materials etc.
Again, it's a stupid system to mix and doesn't make much sense other than as pretense for Always-Online DRM systems and gimmicks.
Even doing the entire rendering server-side and sending the player just the video-stream makes more sense in an application perspective, but people should already know that this doesn't work properly and there are considerable problems after the failure and bankruptcy of "OnLive" and the lack of focus Sony is putting on "Gaikai".
Least of which to dismiss is the operating and upgrading cost involved that customers usually bankroll themselves by buying new graphics cards and consoles to play new games or the ownership/subscription based context of these services.
You can't pre-bake them if the object can be dynamic, but is currently in a static state. For instance player A leaves a broom standing up against a wall. Since that broom is not being dynamically handled any more the change in lighting because of day/night or because a person switches on a light in the room, the server can be used to calculate those shadows. Player B can then pick up the broom and that dynamic shadow will then be handled locally. It's just an example of where it could be used, whether it's actually a good test case or not is not really up to me.
Gord
Arcane
- Joined
- Feb 16, 2011
- Messages
- 7,049
The biggest point against large-scale cloud calculations is imho still the costs of the huge amount of computing power they have to keep ready.
Considering the amount of sold consoles (expected sales at least should be tens of millions), even if you only provide again half the computational power of one console in the cloud, power costs alone would be huge (like dedicated large power plants huge). And there are hardware and maintenance costs on top of this.
So using the cloud to (potentially) provide significant computational power to mass markets like console players? I highly doubt it's even remotely viable right now.
Considering the amount of sold consoles (expected sales at least should be tens of millions), even if you only provide again half the computational power of one console in the cloud, power costs alone would be huge (like dedicated large power plants huge). And there are hardware and maintenance costs on top of this.
So using the cloud to (potentially) provide significant computational power to mass markets like console players? I highly doubt it's even remotely viable right now.
- Joined
- Jan 28, 2011
- Messages
- 97,793
Nobody will use the fucking cloud. Too complex, too risky, and all for marginal benefit. IDtenT is delusional or more likely trolling
I love how you can predict the next decade so accurately.
Dexter
Arcane
- Joined
- Mar 31, 2011
- Messages
- 15,655
This doesn't work with global illumination and it would still be extremely stupid to send all the required data for something like that (position of the light source/mesh of object between light and projection including distance and whatnot, mesh and material properties of where the shadow is projected on) to a "server" instead of using idle time or spare resources to do just that locally...
I'm not sure why it is so hard for some people to understand that "the cloud" is largely a marketing term that they want people to swallow and impose their restrictive DRM measures with it and doesn't really produce (m)any benefits.
There was a free ecosystem on the PC with Online Multiplayer for nearing two decades where they could have explored this and not a single game made use of any similar feature aside from normal server hosting via Dedicated servers or MMOs.
The last time a game banked itself on "the cloud" this happened: http://www.eurogamer.net/articles/2...e-for-20-min-force-shutdown-timer-for-offline
The last time they tried to sell a system with "the cloud" this (rightfully) happened since there was no market for this retardation: http://www.theverge.com/2012/8/19/3253029/onlive-bankruptcy-filing
I'm not sure why it's so hard for people to understand that more developer options are always a positive. This is why I absolutely despise the GPL. If I'm going to code something it's either going to be proprietary or BSD.
http://www.shacknews.com/article/79851/skulls-of-the-shogun-dev-says-microsoft-exclusivity-hurt
"They came across as though they were institutionally incompetent," Pfeifer said. "I think they're not really set up to be a decent publisher. I do feel slightly bad saying that, because there were people there who worked hard on our behalf, but at the same time there are systemic problems with the way that division is setup and run."
Nice to know MS still likes to fuck indies in the ass.
"They came across as though they were institutionally incompetent," Pfeifer said. "I think they're not really set up to be a decent publisher. I do feel slightly bad saying that, because there were people there who worked hard on our behalf, but at the same time there are systemic problems with the way that division is setup and run."
Nice to know MS still likes to fuck indies in the ass.
As an Amazon Associate, rpgcodex.net earns from qualifying purchases.