Reply To: Star Citizen – General Discussions
Without trying to rant on what he said and be a bit constructive:
“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”
– Whilst improvements are nice, there is an admission here that on the lower level there is some serious underlying issues with the engine / code. Serializing data is not necessarily what I would go with but it is at least an acknowledgement of the issues with the engine and their current architecture. There are pressing issues is this regard that require priority.
“…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… 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 they admit the server has a framerate, sort of headless version of the cry engine as I’ve mentioned previously. Will give them their dues I never expected that admission as most backend server engineers scratch their heads and ask “why does a server NEED a framerate or a high framerate to get client physics working?”. It’s an admission on their part but that’s not how a game server SHOULD work. It will be a tough nut for them to crack, not impossible to fix but still require some serious dedication and engineering time. If it was done correctly at the start before implementation in planning then it wouldn’t be an issue now.
“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.”
– There is reasons why they are still open. Why did they also amend the job descriptions based on what was posted here – specifically my posts on service bus? Also why would anyone work as a network engineer or server specialist for the wages they are offering? Maybe they cannot recruit the talent at that range? They are unsure to what they exactly need therefore don’t know whom to hire?
“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.”
– Probably the most negative comment to write but worth appending his statement with “as long as they don’t have accented English” based upon my experience.
“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.”
– Another admission here, now best bet would be for them to do at least a multi-tenanted server short term on much beefier hardware with nginx or similar sitting in front acting as LB using iphash then look at getting those instances talking to each other properly (via service bus or a proper messaging system). Likely to fall upon deaf ears but worth mentioning.