CUDA

Proud user of CUDA nvidia 670m (GEFORCE)

the basic problem with peer to peer is, that it doesn't scale. In a small setting (eg LAN) it might work better (if all players have pcs of the same quality), but even there the slowest pc will determine the maximum size of your game.
With the client server model the amount of work per player client is more or less constant, independent if you are playing a 1vs1 or a 20vs20 and the size of the server determines the size of the game. (in the LAN setting the network bandwidth shouldn't be a problem anyhow.)

This is for the time being a general observation and independent from the actual hardware requirements for clients/server/network, which will have to be seen.

As a side note, peer to peer in that context is just a waste of resources, since you duplicate the server workload and invest additional hope and synchronization to keep the parallel sims in line and stop them from drifting into parallel single player games.

That doesn't solve the issue.

It's less powerful in that it doesn't need a GPU. For huge games you are going to want a lot of CPU. Computing the sim on every PC is not going to be possible in large games, period end of story. A 32-bit client probably can't even fit the entire game state.

I'm not trying to optimize network bandwidth, I'm trying to optimize awesome.

Not true because you can only reconstruct the state by running through the entire simulation up to that point.

Because I want to make a game that can scale, which synchronous cannot. Frankly that isn't really debatable. Feel free to write your own game and prove me wrong on that one... I already tried it with SupCom and it was a HUGE problem.

Now that's what we want

QOTD.

I'm not sure to understand that point. If each client run the sim locally, there is nothing to reconstruct ? How a peer to peer solution is incompatible with your design (scrubbing in the replay, ....) ? (just to be clear : this is a honest question, I'm trying to understand, not debate about your choices

It's more about how the sim is running than how the players connect (after all, a local replay doesn't connect to anything), am I wrong ?

But now, you get me worried about something.
In starcraft 2 you can scrub in it because, I guess, nothing is simulated and the number of units is very small so it's fast to recompute the sim (I'm only guessing here, correct me if I'm wrong). The replays are very small (200ko) as they are probably just commands (again, only guessing).

If it's possible to scrub in the replay with PA and that it has something to do with how the sim is send from server to client, what probable size of replays are we talking about ?

Don't get me wrong, while I have some (I think valid) concerns about a client/server solution, it's really more interrogations about it.
I'm just trying to understand why you choose another route than every other RTS that ever existed. (even FPS are going back to P2P these days).

I know your are aiming for a scale probably never done before, and it's probably the reason why, I guess I have to see what scale we are really talking about to believe it (ie. I've never played a 81x81 map in supcom, I don't believe that RTS can scale very well if they also need to be competitive).

The way simulation works in P2P is only the commands are sent. This means that a player trying to jump into a game half way has no way of actually creating a current game state, except by re-enacting the entire game. In a Client/Server model, new clients can ask the server for all the information of the current game state, allowing them to join without a needing a full re-creation. PA clients do *not* run the (full) sim, they only have the information the player can see, and all the serious calculations are done by the server.

Every other RTS is pretty small scale, even compared to Sup Com, let alone PA. If using P2P Every player needs a computer powerful enough to run the entire game, and if one player is too slow, it slows down everyone else. Using a Client/Server model lowers the computing requirements for each player, lowers the bandwidth usage (eg. it doesn't grow exponentially with the number of players) and makes it possible to reconnect (it's alot more robust).

Isn't the bandwidth usage of p2p games like SupCom linear to the number of clients involved?
One connection to each of the other clients with a certain up and downstream.
Add one client is just adding another of those connections with up and downstream.

use more rock nukes

I wasn't talking of jumping in the middle of the game (nobody in his right mind will do that in a RTS), but what will happen if the server was going down (network issue, crash,....) and one of the clients had to take over (the chances of that happening are in my opinion infinitively bigger than jumping into an existing game).

Also, I really don't see why a client couldn't ask for the whole sim to another client with peer to peer. (peer to peer doesn't limit what you are transferring, but how. Actually, client/server is limiting it, not p2p .)

Hell, with p2p, you can ask each client the data about his army only to limit the upload needed for each guy. I know it's easier said than done and probably extremely complicated to implement, but I don't see why it's not possible.
There is a mod doing that with FA actually. It's hacking around as FA is not designed to support that, but it works (minus wrecks and props).

Jumping in the middle of the game is what is needed to allow someone who disconnects to be able to re-connect. If the server goes down, a client can't take over. That is a downside, but on the other hand, I'd say with 40 players (not possible with P2P, btw), the chances of players dropping is far larger than the server. Apart from mod-related errors or network issues, FA was extremely stable and I can't see any particular reason a PA server wouldn't be.

P2P doesn't technically limit it, but neither does Client/Server (in fact, starcraft is P2P via a server, iirc). I'm not sure of the specifics, but I'm guessing syncing up a P2P full sim transfer would be hella difficult.

"His army" is not a concept that makes sense. Through scripting, players can switch sides, have areas of the map suddenly revealed, plus all sorts of other shenanegans. The only way to allow that without a server is to have all clients have the full sim state. A server lets clients get just the relevant info to them, while still having a full copy of the sim state on the server.

Someone hasn't been paying attention to the plans for the game then.

The client can't take over though for a number of reasons. First off 32-bit clients are allowed and they may not be able to even fit the game state. Secondly for a big game a server may need multiple CPU's and a lot of network bandwidth. Note that this isn't an issue for P2P because they can't even come close to getting to that game size because the game has to fit on the minspec client and it scales very badly as you add more clients.

It's not client/server vs p2p. It's client/server versus synchronous. Which one are you talking about?

Synchronous sim sucks for a ton of reasons I've already gone into.

P2P has just at ton of issues that make it suck. NAT being one of them. Unreliability of clients causes game slowdowns for everyone. Cheating. etc.

Synchronous sucks because you can't make replays robust and you can't multithread the sim. You are also stuck with running at the speed of the slowest computer.

Client/server is simply the best solution for a modern game, especially if you want to be able to scale. I can't think of a single advantage P2P would have for our game. Going sync sim would massively cripple our game. Going P2P would just cause massive issues with NAT and would seriously limit scaling.

Personally I don't think you're really understanding the vision for the game.

Big Battles thousands of units BIG explosions and of cause AWESOME Asteroids blowing up planets? Amirite? or Amirite? In all Seriousness Non-Synched servers are the best way to go here it allows the benefits of faster processing due to many many many more cores leaving the User end to just render the graphics whilst the server crunches numbers and sends you back only what you need to know thus speeding up the games increasing the size and allowing those godly 40 player battles Neutrino promised us!

I will be very sad if we don't get 40 Player blood baths! =_=

yeah, but it shouldn't be forced upon a player, think if he dosoen't have the specs for dealing with that huge of a battle

Nobody is forcing anyone to play in any size game. Play by yourself. Play in small games. Play in big games. Do whatever is fun for you.

Ha, this thread isn't even about CUDA anymore. :lol:

I'm glad that Uber is taking this path, my CPU is hardly good at crunching that many numbers. It'll be nice to have the workload taken off my poor FX-4100.

It was never about CUDA in the first place. CUDA is a dead, antiquated and closed technology which is only available on a ridiculous low number of platforms and is limited to the goodwill of a single company.

If anything, then OpenCL is the only viable choice for a parallel, GPU/APU accelerated framework / API. And even though todays average server might not have OpenCL capable devices integrated, there is a different type of server which does and which will most likely profit more from OpenCL-support than every other system. I'm talking about "low end" multimedia PCs on base of AMD APUs, half the computing power of those systems is "hidden" in the OpenCL capable GPU part of the APU.

There are also a few very expensive operations which are easy to port to OpenCL, one of them is proper path finding. Sure, you can try to do that on the CPU, but calculating a flow field for several thousand units on the CPU is a waste of time and resources and there are enough other CPU expensive tasks which could use those resources. E.g. the unit and strategic AI which relies on expensive analysis of the game state and which grows stronger with every bit of computing power available.

Those functionalities must be implemented twice though, once for OpenCL capable systems and once for systems without OpenCL. This has two consequences, for one it's twice as much code to write in some sections, but it does also mean that these functionalities must be encapsulated in such way, that the whole pathfinding process and alike can be exchanged with ease and without breaking other components.









PS:
neutrino maybe didn't make it clear enough, but a synchronized model is a bad decision for every type of large scale simulation for a simple reason. Synchronized means, that is must also be deterministic, that means that two simulators which get the same input MUST come to the exact same result.
Determinism is not easy to achieve in modern systems. It was back then, when most processors had only one core and applications had only ONE thread per task, but nowadays a single task is split onto multiple threads which run simultaneously on multiple cores.

You can compare that to a single lane vs a multi lane highway. On the single lane highway, cars will pass in the precise order they entered the highway, but on the multiple lane highway, cars may overtake each other and might change order. You could try to prevent this by complex rules to maintain the order, but those rules would slow down the traffic, and they are quite difficult to calculate.

You therefore often have to sacrifice determinism when parallelizing algorithms, but that is the only way to achieve a sufficient speedup. The result is slightly chaotic, but this is not much of a problem since many problem which make parallelization necessary often work by approximation so you maybe won't get the same result, but a result which is as close as the original one.

Finally, this means that you can't expect two simulations to run exactly alike, even if they did receive the precise same input. You can't just sync them by exchanging the inputs, but you would require to sync the WHOLE gamestate frequently as the states of the simulations will differ inevitable and the variance will increase over time.

Isnt that going a bit overboard? The game still needs be deterministic enough to ensure that the result of a replay i.e. is always the same and that players know what will happen if they do something. Just because you use multiple threads does not mean that you can do away with determinism.

We are doing away with determinism. Replays are *recordings* of gamestate.

You can't write a multithreaded sim and have it be deterministic. Well at least I can't, maybe someone smarter than me can. Nobody ever has that I'm aware of though...

Also using CUDA or OpenCL would not be deterministic either. A sync game simply wouldn't be able to use these technologies at all except for non-sim things.