I'll start by saying thank you for the latest live stream. Even though you may think that most of us didn't understand the live stream, there are many of us who did and we appreciate the technical overview. Its always great to see the behind-the-scenes technical systems on a game like this especially when we've already backed the project. I have a few questions: 1. At one point in the live stream you mention 1 million units and something about 64 cores, what kind of performance can we expect to see on our local PCs unit count and planet size wise when we are not playing on a server? Additionally what can we expect to see on hosted VPS'? (E.g. eight core 2.4 GHz, 4 GB of RAM) 2. Given that you are expecting to see a large number of units, are you using any technology to optimise target searches? 3. I am probably dreaming here but will we be able to cluster servers e.g. use four servers instead of one big one which can in a lot of cases be cheaper? Again thank you for the overview. I know many of us are getting restless and want to see gameplay but there are some of us who still appreciate the time you take to show us these tech 'demos'. Thank you Uber. You guys are inspiring.
I'd like to say thank you for the live stream as well. I regrettably wasn't able to watch it live, but I watched it as soon as I could on YouTube. Judging by the general reaction I'm going to guess we won't get another live stream like it, but I would love to see more videos (or at least blog posts) detailing the underlying framework.
This is all answered in the stream. They said they planned to have a range of graphics settings so low to high end PCs could all play the game reasonably well. The actual final unit count isn't even remotely close to being determined. The 64 core machine joke was just a joke.
I think he was asking more about what sort of scale game we could expect to see on a home PC at a decent framerate. What they said is that you can play it at a decent framerate on most PCs from low end to high, but they did not cover what sort of size those games would be, a low end PC might only be able to handle a 2 player game on a single small planet, a high end one might only handle 8 players on 8 planets, that sort of thing. TBH though they wont know that till MUCH later in development anyway, usually you wouldn't get good figures for that sort of stuff till the last month of development. Why would you think that would be a joke? 64 core machines aren't that uncommon, and I'm sure they intend to set up one of two of them to host some MASSIVE games with tens (hundreds?) of players and planets.
Because it was a joke. He even had a sarcastic tone in his voice when he mentioned it. 64 core machines are quite uncommon. The fact that they exist doesn't make them common. Very very few people game on 64 core machines (if any). You appear to be thinking that a super server could make up for the power of a user's home PC. The only way that would be the case is if the user played remotely, but that would have some major input lag. And I'm pretty sure Uber isn't trying to be the next OnLive.
The designgoal of PA is pretty much to be able to put all the heavy load on a server. It's not like OnLive, graphics will still be handled by the clients. Gamelogic however will only happen on the server, so in that regard: yes you do play remotely. That's what server-client means.
That's not what it means at all. In a server/client video game, the logic runs on both. The server can either verify the client's data or simply dictated to the client what to do. In either case, the client still has to process everything. When dictating, to save bandwidth, the server only wants to send new or changed events instead of a constant stream of data. This means the client needs to run all the logic and just use the server as its input method since it is only getting events to process. While the client is waiting for a response from the server, it needs to start assuming your input was legit and continue to run the game. It needs to run all the logic to do this and if it didn't, movement would be really laggy and jerky. The term you're looking for may be thin client. That's when the server does basically everything and the client mostly only displays graphical updates.
To me he just sounded slightly annoyed because he's had to answer that same question a million times and every time he states that the goal is a million units (though I doubt he's as confident he can reach it as when he first stated that ), and that he wants to be able to have the game scale to have huge 30+ player games that run on big servers, and big servers do use 64+ core configurations and only the server would need the 64 cores. For PA a powerful server can make up for an average home PC, the clients will not need to be processing EVERYTHING, clients are unlikely to need to have much (if any) information about what is going on on other planets when they are focused on one, so they can just ignore the majority of what is going on when there's multiple planets. Even on one planet you really only need to process what is going on on the side you are looking at and can stagger updates for things on the other side. Only the server needs to process everything all at once, so a 64 core server could run a game with tens of players and hundreds of thousands of units that would still be playable by people with relatively average home PC hardware because they only need to handle a small section of it, and from what Jon was saying in other streams that seems to be the goal for PA. All server/client means is that clients connect to a server rather than sharing the responsibilities as in peer-to-peer architectures, the implementations can vary to cover either of the mention cases and still be considered to be server/client. As I said earlier it only needs to run the logic for the relevant area that the player is focused on, the rest can be ignored until the player changes the area they are focusing on at which point the server can start sending them more detailed information about the new area instead and ignoring the old area. This is why games use prediction and interpolation, if you tell units to move somewhere the client can start moving them the way it expects the server would and when it gets back a response from the server it can interpolate from the predicted paths to the ones from the server. With PA being an RTS game as opposed to something that needs absolute precision (like a first person shooter) there is also a hell of a lot of room for discrepancies between the server and client, if they don't make the mistake of sending raw inputs (which I'm sure they wont since they are using asynchronous simulation) then they can send actions or intents to/from the server which can greatly improve things. For instance if you tell a unit to attack another unit then it actually doesn't matter where the units are in relation to each other the server can happily carry out that attack even if the unit you wanted to attack was to the right on the client but to the left on the server, and visually you wouldn't even know there was a discrepancy between the server and the client because it will attack that unit just like you would expect. Because of this an RTS can get away with not having to keep the client and server perfectly synced which drastically reduces the need for the client to be aware of things happening on the server side of the simulation. I'm not familiar with that term, but yeah I believe that is the sort of thing Uber are aiming for with PA.
Fair point. I haven't worked on a networked app or game that needed to have the client ignore sectors/quadrants (however you want to describe it) of parts of the simulation to save client performance. So I hadn't thought of that. This is just repeating what was quoted. So... thanks for confirming I guess? Definitely, but you still want the client's view to be as close to the server's view as possible. Your example is pretty extreme and I would consider the game to be broken if that happened because in your example, because the client would see one direction safe to move in (as in no enemy that way) when it's really for the opposite direction that is the case. I doubt it. Thin clients really do barely anything. Remote desktop is a thin client.
