ATTENTION: PTU 2.4 AVAILABLE for ALL BACKERS!!
- Thread starter AstroSam
- Start date
supitza
Vault Dweller
Noice! I'll probably hit public before I get home from work, though.
Is that it? Knew they coouldnt replicate ship numbers like Eve but thought it would be more than that? How will they ever do operation Pitch Fork with only 64 ships? Will be a very quick battle!
No, lateron there will be more; I'm writing of the currrent status. Until 2.3, one instance was limited to 32 users...well, no. 24. They planned to extend it to 32. But the next step/goal is to reach the maximum of 64 users in one instance. And thats why I'm curious: 64 users within the mini PU. Even with 24 in my opinion the mini PU was way too overcrowded ...
Not enough from my perspective, its just a rabble with nothing organised by anyone in the PU currently. When you actually have a goal to do stuff and then others decide to jack you up, 64 still doesnt cut it.
CR explained his plans in Episode 77 of 10ftC:
Right, I touched a little bit of the it at the top of this 10 for the Chairman. I'm talking about the fact that we are working on getting more and more people into an individual instance - or really what it's more about is getting more people into an individual game server. So, Right now if you play Crusader in 2.2 there will be 24 players in one game server instance. Now, we actually have 8 of those, I believe... Yep, 32 core servers we are running on and we have 8 game server instances on this 32 core server each using 4 cores.
Now, the real goal would be not to have 8 on that, it would be rather to have one game server running on that one 32 core machine. Then, if we have 8 game server now and you have 8 times 24 you are getting a much larger number of people. You would be almost at 200 people at that point; and that would be one server. And that is without us doing more and more optimizations. So that's were we sort of moving towards.
Then on the client side, even hough the server can maybe deal with more entities, because it doesn't have to render, it doesn't have to move all the memory around, it just has to sort of deal with the background simulation and updating stuff. The clients may not be able to [handle all the entities the server can], but then the client would sort of make sure, what's around you, what you can see is what it is drawing and updating and been told by the server.
On top of that we are planning to have sort of seamless server transitions and basically mash the servers together. So, instead of: "I'm in Stanton system and I'm on one server, or I'm on a second server or a third server of the Stanton system." That is not the way how Stanton is gonna work.
It's gonna be very dynamic. We will actually have [something like this]: Say, we start with one server and people fly around. It could be anywhere in Stanton. Like is what you can do right now in Crusader. But then, as you go beyond the cap: say, just for simplicity sake, lets just say, say we can run 50 people on a server.
You know, 30 people, 40 people, they are all running around in Stanton, no problem doing their stuff. AI doing their stuff. But now a bunch of people come in and we move from 30 people to 60 people. Well, that is more than we can fit on one server. So, at that point, we will always have probably one server taking-over-ready - keeping one as a buffer.
Now, we got more [players] than we can fit on one server, so we sort of migrate players to whichever server is appropriate. It might be just arbitrary where you go. Well, there is a group of players over here, so [the first] server will take care of them. And there is a group of players over here and [the second] server will take care of them.
Both servers have full global view of the whole star system and the server also talk to each other as well as the clients. A server is essentially responsible for simulating the entities it is "authoritative" of. But it will also tell the other server if the other server needs to know, what the entity on the server did.
That's where it is educative. It's like: "[First server] I'm updating those people, but there is one guy who is over here, that's coming towards [the second server] and one guy is coming towards [the first server from the second server]". And then: "[First Server] This is were [my] guy is." The [second] server knows and has a sort of copy of it in his memory space and vice versa. So you can sort of basically resolve overlaps between sort of server controlled areas.
That's kind of the idea. As more and more people come in, you spin up more and more servers and they all mesh them together. You can ultimately have hundreds if not thousands of people all simulating essentially in the same instance. Then your real limitation is more about the client and what the client can render and see on its side.
That's kind of the plan which is sort of a more dynamic and [is] actually more advanced and I think [an] ultimately better solution that what we have talked before. Which was much more instances on top of each other and you can only ever see 30 or 50 other people or what ever it would be. I think it's gonna be good.
There will probably be some cases where there are still too many people. I can see in a landing area, where there's a thousand people hanging around in a landing area. We just won't be able to have thousand people. Or, hundreds or 500 people getting together and say lets go to the courtyard.
Well, on a client you just can't render 500 people. Just won't happen. What we will probably do is, besides having aggressive Level of Details, at some point we just cull out people beyond a certain area. They will all be sort of tagged and known there. As you move around as a client people will come in and out of your visibility - basically your sphere of visibility. I think it will be pretty seamless. On top of that, you know, getting down to your friends which is one key parts of this question. We will know, who are sort of your acquaintances, who is your person of interest, who you play with, who is on your friend list, stuff like that. If you are making decisions of who you can see: Like as in at some point there are to many people and the client saying: "I can't just render that many people. I have to choose some entities and people to not see."
It would not be the people you as a player has sort of tagged as your friends or the ons you are interested in. They would get preference in terms of the algorithm that determines who you see and who is culled out.
I think it's gonna be pretty cool. You should be able to kind of hang out and work with your friends. I think the only issue we are gonna get - which will happen - because we have some massive organisations. There is no way possible have one of those massive thousands people in a space battle set-ups. But I do think we will probably get like quite a few hundred into it. That would be pretty cool.
I'm sure you guys will break - figure out a way to break it. You know, that's what it is. I think it's gonna be a pretty cool experience. I'm actually quite excited by the tech that we are working on for this. It's not gonna happen overnight. It can take a lot of time, because we are building something that's really - we are right on the cutting edge of this kind of stuff.
I mean there is a few other projects that are doing similar stuff: sort of using the cloud architecture to sort of dynamically scale and process much more bigger, denser worlds than you could do on a single server or a single client - which is what we are doing. But I think it is the future and it's going to be pretty cool.
Basically, the instances are limited to variables like a visibility radius as well as static borders like patches in the verse. Server KIs will decide constantly, which player is to be put/shift in which instance i.e. from patch "asteroid field xyz" to "station/planet 123 orbit". Plus the closed instances within capital ships.
Right, I touched a little bit of the it at the top of this 10 for the Chairman. I'm talking about the fact that we are working on getting more and more people into an individual instance - or really what it's more about is getting more people into an individual game server. So, Right now if you play Crusader in 2.2 there will be 24 players in one game server instance. Now, we actually have 8 of those, I believe... Yep, 32 core servers we are running on and we have 8 game server instances on this 32 core server each using 4 cores.
Now, the real goal would be not to have 8 on that, it would be rather to have one game server running on that one 32 core machine. Then, if we have 8 game server now and you have 8 times 24 you are getting a much larger number of people. You would be almost at 200 people at that point; and that would be one server. And that is without us doing more and more optimizations. So that's were we sort of moving towards.
Then on the client side, even hough the server can maybe deal with more entities, because it doesn't have to render, it doesn't have to move all the memory around, it just has to sort of deal with the background simulation and updating stuff. The clients may not be able to [handle all the entities the server can], but then the client would sort of make sure, what's around you, what you can see is what it is drawing and updating and been told by the server.
On top of that we are planning to have sort of seamless server transitions and basically mash the servers together. So, instead of: "I'm in Stanton system and I'm on one server, or I'm on a second server or a third server of the Stanton system." That is not the way how Stanton is gonna work.
It's gonna be very dynamic. We will actually have [something like this]: Say, we start with one server and people fly around. It could be anywhere in Stanton. Like is what you can do right now in Crusader. But then, as you go beyond the cap: say, just for simplicity sake, lets just say, say we can run 50 people on a server.
You know, 30 people, 40 people, they are all running around in Stanton, no problem doing their stuff. AI doing their stuff. But now a bunch of people come in and we move from 30 people to 60 people. Well, that is more than we can fit on one server. So, at that point, we will always have probably one server taking-over-ready - keeping one as a buffer.
Now, we got more [players] than we can fit on one server, so we sort of migrate players to whichever server is appropriate. It might be just arbitrary where you go. Well, there is a group of players over here, so [the first] server will take care of them. And there is a group of players over here and [the second] server will take care of them.
Both servers have full global view of the whole star system and the server also talk to each other as well as the clients. A server is essentially responsible for simulating the entities it is "authoritative" of. But it will also tell the other server if the other server needs to know, what the entity on the server did.
That's where it is educative. It's like: "[First server] I'm updating those people, but there is one guy who is over here, that's coming towards [the second server] and one guy is coming towards [the first server from the second server]". And then: "[First Server] This is were [my] guy is." The [second] server knows and has a sort of copy of it in his memory space and vice versa. So you can sort of basically resolve overlaps between sort of server controlled areas.
That's kind of the idea. As more and more people come in, you spin up more and more servers and they all mesh them together. You can ultimately have hundreds if not thousands of people all simulating essentially in the same instance. Then your real limitation is more about the client and what the client can render and see on its side.
That's kind of the plan which is sort of a more dynamic and [is] actually more advanced and I think [an] ultimately better solution that what we have talked before. Which was much more instances on top of each other and you can only ever see 30 or 50 other people or what ever it would be. I think it's gonna be good.
There will probably be some cases where there are still too many people. I can see in a landing area, where there's a thousand people hanging around in a landing area. We just won't be able to have thousand people. Or, hundreds or 500 people getting together and say lets go to the courtyard.
Well, on a client you just can't render 500 people. Just won't happen. What we will probably do is, besides having aggressive Level of Details, at some point we just cull out people beyond a certain area. They will all be sort of tagged and known there. As you move around as a client people will come in and out of your visibility - basically your sphere of visibility. I think it will be pretty seamless. On top of that, you know, getting down to your friends which is one key parts of this question. We will know, who are sort of your acquaintances, who is your person of interest, who you play with, who is on your friend list, stuff like that. If you are making decisions of who you can see: Like as in at some point there are to many people and the client saying: "I can't just render that many people. I have to choose some entities and people to not see."
It would not be the people you as a player has sort of tagged as your friends or the ons you are interested in. They would get preference in terms of the algorithm that determines who you see and who is culled out.
I think it's gonna be pretty cool. You should be able to kind of hang out and work with your friends. I think the only issue we are gonna get - which will happen - because we have some massive organisations. There is no way possible have one of those massive thousands people in a space battle set-ups. But I do think we will probably get like quite a few hundred into it. That would be pretty cool.
I'm sure you guys will break - figure out a way to break it. You know, that's what it is. I think it's gonna be a pretty cool experience. I'm actually quite excited by the tech that we are working on for this. It's not gonna happen overnight. It can take a lot of time, because we are building something that's really - we are right on the cutting edge of this kind of stuff.
I mean there is a few other projects that are doing similar stuff: sort of using the cloud architecture to sort of dynamically scale and process much more bigger, denser worlds than you could do on a single server or a single client - which is what we are doing. But I think it is the future and it's going to be pretty cool.
Basically, the instances are limited to variables like a visibility radius as well as static borders like patches in the verse. Server KIs will decide constantly, which player is to be put/shift in which instance i.e. from patch "asteroid field xyz" to "station/planet 123 orbit". Plus the closed instances within capital ships.
supitza
Vault Dweller
Reading through that like, I find this:
"And that cargo space also means there’s plenty of internal room to expand, allowing the placement of medical systems, weapons racks and more. Ultimately, though, the Reliant is no transport: it’s a sleek and maneuverable utility ship more than capable of holding its own in combat!"
WHOA! If the Reliant can be a mini-ambulance, I'LL TAKE IT!
DemCoconuts
Commander
What the hell you doing out there still? I've been home since Monday. Sheesh. :P
I'm a dick. I have cold beer for you. Just come home.
I just went to update and can no longer access the PTU, something is going down. Possibly a live release?
Thank you for all your hard work and patience in helping to get 2.4.0 Live.
2.4.0 is LIVE.
Enjoy.
2.4.0 is LIVE.
Enjoy.
Word the Fuck up! Woohoo. Now if I could only get rid of all these house guests. Damn real life.
DemCoconuts
Commander
Tell me about it! The only thing productive that I did since you left is... well...
I drank some beer.
Meh, I can home Monday and had to work all week, Didn't get to drink until last night. Shitty.