As more Citizens try to join Port Olisar, the instances fill up and there's no space for additional players. Will there be more slots in the instances around Crusader in the future?asked by Torian

So I'm assuming that whether we're talking about the actual instance itself, in terms of now the fact that we have 24 players and whether there's space for the ships or whether we're going to get above 24 players.So the answer is, yes, long-term we're absolutely going to have more than 24 players in any single instance, we will also open up some of the other spokes on Port Olisar, and there are actually 64 sleeping habitations in Port Olisar and basically arranged between 4 groups of 16 and 4 spokes and we're going to do connections between the spokes and add things like some shops and stuff on Port Olisar and by the way, Port Olisar is sort of a template of a sort of way-space-station that you'd kind of stop off, trade or repair your ship and stuff like that in the longer-term Persistent Universe.So we'll be fleshing out that, giving more functionality, giving more life and we'll make it more functional and have more players and in the mean-time we are working on backend stuff to be able to have more players happening in any one instance and also have players seamlessly go between instances – so the idea I've mentioned before on 10 for the Chairman is to sort of have a mesh of servers in the cloud that are dealing with one continuous space, say, the Stanton system where Crusader is based and then the different servers manage a certain group of players and if someone, say, travels from Port Olisar to Port Kareah and we've got more than the limit that one server can happen, say, right now 24 we would kind of have servers looking after the area around Port Kareah and servers looking after the area around Port Olisar and a server looking after the area around Covalex and as you move between these, you'd be handed off to the server that would be authoritative in that area but that server would still tell the other servers what your position is and what your state was.So any one server has a snapshot of all the entities or all the players in the system, but just only simulating the ones they are responsibility for. And that's a technique that we'll be able to increase the player count of the server, the other thing is increasing the efficiency of the code on the server and how it can utilize multiple cores, cause I think I've pointed out before, currently we run 8 dedicated game servers on one actual physical server in the cloud.A physical server has 32 logical cores, so it's about 16 actual physical CPU cores, and each one of our game servers – DGS instances – runs 4 logical cores, so two physical cores, and so if you just decided now we're not going to run 8 instances on this physical server, we're just going to run instance, there are then, you'd be 8*24 so that's a fairly decent number, right? Almost 200 players, and that's without even scaling, better optimizations and performance and stuff.Right, so, we are working on it, it's all stuff that's happening – it's kind of a bit of a trade-off because you can kind of see that what we're releasing you, like 2.2 and 2.3, sometimes performance goes down, sometimes performance goes up, and a lot of the problem is that we sort of add some new features and we don't really see the impact of the load until it's actually out on the PTU or even out Live. Because we don't, within our internal test environment, even with 30-odd testers, it's not enough to stress it in the same manner as thousands of testers doing PTU or hundreds of thousands when it goes fully live.So we're constantly working on that. We're working on optimizing code but we're actually in the middle of a massive backend rewrite – completely changing the way the serialization works to a much more efficient, logical way. Which is the item port- the item 2.0 system we've talked about, which we've recently got going. It is a fundamental part of that, because we're restructuring some of the way that entities are set up – so we're changing it completely from the way it was done in the old CryEngine to be a very component-based setup, much more logical, and we're only really serializing data that we need to serialize rather than big globs of data and it's not nearly as, I guess, fixed as the old system was. Because the old system was really built for small, 16 player or 8 player, multiplayer games – deathmatch, FPS shooter-style whereas we've got something that we need to be up for long times, hours or days of time have the server up and have hundreds of people on it.So our ability to scale has been much bigger, it's something we've been working on for quite a long time, and we're still working on it, we're getting close to having some fruits of it being born in the near future. So this is very much analogous to us using, when we did the zone system and moving to 64-bit math instead of 32-bit math. All those things sort of paid off – what allowed us to be able to do Crusader and the local physical grids and all the cool stuff that you've seen from 2.0 onwards and a lot of this other backend stuff we're working on is going to make the experience much better, much smoother for you and have a higher framerate on the server – one of the reasons why people see desync issues now, and maybe some precision issues is the actual server when it's under load is running at actually quite a low framerate, even compared to clients.You could be on a client running at 40 or 50 frames, yet the server is only running at 10 or 15 frames. Now the server running at 10 or 15 frames is simulating physics only at 10 or 15 frames, which means there are big steps between each frame, whereas on your local machine, you've got much smaller steps, so what can happen is, on the server, you could be here – which is something that happened in the EVA situation – and the next frame of what the server thinks you're doing is, like you're player is half-way in the wall of the ship – he's moving outside. But on your local client, you haven't – because you have all the fidelity whereas on the server, it goes, "oh look, he's half way in the world, so I'll give him a big impulse to try get him out" whereas the server isn't in the same position which basically catapults your EVA person – could potentially kill him from the damage and that was one of the things that was creating, say, the deaths that you would see in an EVA-transition going in and out.And partly that was because the server on the physics step was running at a much slower framerate than the client so we're working on things to make all that better, it's a work-in-progress, it will take a little while to get going but once it does, it will be better and there will be a lot more people in the instances and we'll be moving smoothly. So these are all things that the network team is working on – I wish we had more members of the network team, we have essentially about 4 engineers that work on the game server network side and then we have another 3 that working in the backend services side. But if any of you out there are network engineers and wanna work on a really ambitious game, let us know, because we've had open positions for this for quite a while.We're always looking for good people because the things that we need is networkers, there's a big need for us on the engineering side, AI is a big need and physics – if there's any physics geniuses out there but if you talk to anyone in the game business, those are all the areas that are it's genuinely hard to find people. We're moving along and it's going to be pretty cool when it's all said and done, cause it's basically building a system, I've talked about it before, that the next generation of how you build these online cloud-driven systems, so we can distribute it across many servers and process more than you would in traditional single-server setups.So anyway, probably a long answer for whether or not there will be spaces for more additional pilot players, but there you go.