Good thing about GPU: there is tons of different techniques which allow to offload GPU. Game client need to cache lot of information in RAM (building you seen, radar information from other planets, etc), because network bandwidth is expensive. But GPU don't need to store or process any unused data, it's only need to store limited data required for current frame. As long as we know there will be "window in window", so you need more powerful GPU if you want to keep open many. So I doubt that GPU is real problem if Uber done rendering well. Only real problem I see for PA it's network bandwidth, currently game can use up to 3mbps just for team units, and I wonder how many bandwidth spectator of 3v3v3 have. E.g if we have 16 players game and each need 3mbps that's mean server should have 50mbps upload. There is tons of ways how to optimize GPU usage, and very few for client-server networking. PS: Can somebody check spectator bandwidth in large (3v3v3) battle?
The servers are limited in bandwidth currently. Don't ask me why, but I can't play the game correctly because of that.
I understand that. I even know why: Uber rent their cloud VPS at SoftLayer (and there was some from Amazon EC2 before): http://www.softlayer.com/cloudlayer/bui ... -own-cloud They probably have lower prices because they rent many servers, but it's can't be much cheaper. Bandwidth it's reason why I think that GPU isn't main problem of 40-players games. We probably need to rent servers with more than 100mbps uplink play something like that. Good news is 1gbps are fairly cheap now. :lol: PS: But anyway there is many people who stream large battles as spectators, and some of them doesn't have much lags.
Paying ~200$/month for hosting a single game at a time ? Yeah, no. I don't care what's the cost of servers of Uber. They went to a server/client solution, they have provided enough servers for everyone that run smoothly.
Bit of a negative attitude you've got. :cry: Without a client-server architecture a 40 player game wouldn't even be possible anyway. You know yourself pretty well how horrible Supcom run with many players...
If you need to rent yourself a server for a 40 players game, it doesn't exists much more than in supcom
Lol @ PA Lan party. "Okay, we've got these 4 desktop computers twist-tied together, their processors running in parallel and several external SSDs for extra RAM, we should be able to run a Scale-2 Moon and *maybe* a star to go with it."
I don't talking about servers for everyone, I talking for some epic server, not especially 40-players, just epic. Obviously than Uber won't pay for my own crazy ideas.
I seriously don't think so because there are many many people who able to run game servers for free. They already paying for hardware anyway, so they don't care about cost.
And why does the client needs to store ALL planets? There are enough games with procedurally generated content and non of them require the client (when using a server-client setup) to store everthing.. thats the best part of procedurally generated content.. one number to generate whole universes.. Second the client does not store anything about units it has intell on.. the server just gives a signal you saw an enemy/friendly unit.. And the last past, you only store stuff in your GPU memory you look at atm... Do you think a game like World of Warcraft has everything loaded into your GPU memory? Oh and I believe Neutrino mentioned that we fight in one solar system at once while the solar system can be part of a bigger galaxy. So your client only needs info about one solar system..
Because planet generation it's CPU-intensive process and planets have complex geometry. E.g if you go to planet view one moment it's should open instantly, it's why it's should be stored in RAM. It's also need to be stored because from one point of view you should able to see other planets from long distance. Planet generation it's just not something might be done on demand on most of CPUs. Unfortunately it's not RTS games with multiple point of view support... E.g they split map in chunks and player usually not able to fly on top of map and see everything.
sxx is partially right. It is true that PA needs a lot more raw optimization than other games because you are technically capable of viewing about 49-50% of the all the geometry on the entire map at once. However, because of this, the game can be heavily optimized by only rendering the polygons you can see. If you are zoomed out, and a moon is only ~100 pixels, you should only have to render a maximum of 100 polygons to get those 100 pixels, instead of the entire moon. In addition, Uber HAS stated that instead of sending over all the geometry data of a planet, they are instead just sending over the planet's specifications and having the client generate it onto RAM.
Unfortunately it's not so easy when we talk about rendering which looks cool. For example my avatar on this forum is only 90 x 90 currently, but it's contain lot of details. As static image it's just points on it, but in dynamic you'll see lot of moving air units. Traditional LOD system is working fine for first person games like Skyrim when developers build simplified LODs for game and these LODs never change. But we talking about RTS where planet view should contain all details you see on planet, in dynamic. I doubt it's will be ever possible to do that with 100 polygons.
I'm not talking about LoD models, I'm talking about selective polygon rendering. I'm not sure if that is even possible, or worth the trouble, in terms of programming, but for this kind of scale, it would be worth it. You only need to render the polygons near the center of pixels, because at that range, intricate details don't matter. Once zoomed out all the way, you only really need to render whatever polygon is at the center of a pixel, and then make that pixel the same color as the polygon. So let's say you're looking at a supermassive trinary star system with 30 planetoids and 4 different asteroid belts, as well as a comet field. At maximum zoom, a planet might be only 20x20 pixels... So you only really have to render 400 polygons, the ones that are in the centers of pixels.
It's called tesselation, when you use less poly-count models based on camera distance. But I don't think it's might give performance boost for PA because game don't have models with complex geometry, it's just need to draw low low-poly objects. * I now move in some rendering specifics which I'm not very good at, so if somebody can correct me - please do that. * As long as I know this is one of hardest problems in 3D graphics: detect what player can see and what's not, what's important and what's not. Usually details on long distance just "removed" from frame to offload GPU and all limitations are masked using post processing and LODs. In rendering it's fairly easy to determine your field of view based on camera position and angle, so game doesn't need to process geometry you don't see, but game still can't check what you see on screen: mess of black pixels or air battle.
Aren't you doing a raytrace for each pixel with z-buffering? Isn't it possible to tack on a true/false visibility switcher with that? Also, last time I checked, Tessellation is either repeating a set of interlocking shapes to form a pattern, or dynamically subdividing and modifying a polygon to create detailed geometry from a heightmap.
