The Star Citizen Thread v5

[Tippis]

He was describing the bandwidth requirements for an instance with 1000 players.

Assuming a client-server setup, then the positional and heading data for each ship would take up 288 bits sent by each client to the server 3 times a second. So client upload bandwith requirements would be 864 bits every second. Of course, in reality there'd be a good bit more information sent but Hanz was simply looking at position and heading.

The server, however, would have to update 1000 clients with the information from 1000 ships....so its datasize would be 1000 times greater sending to 1000 clients so its vandwidth requirements rould be a million times more.

But even then....chicken feed for a data centre.

So I am not sure why he thinks each clients would require a 300 meg link just for positional and heading data when it appears only the central server might require that type of bandwidth

Again, that part is because he's envisioning a P2P scenario.

But it's not (just) a matter of bandwidth. It's a matter of actual data processing of an O(n²) problem in a real-time environment. The positional data is just an example of how even the tiniest thing will rapidly run away to the point where even something as simple and basic as sheer bandwidth becomes worrisome.

On the client end, the actual bandwidth requirement may not be all that bad, even with all the extra gunk CIG wants to throw in there, but even there, you have to actually do something with all that data, and that gets messy very quickly. You have to cycle through it, apply everything on every object and… oh no! New packet, let's start over! Or not? Did you go through everything? Do you wait until you can complete the last cycle, and just skip updates in-between? Oh, and this cycle, the roundtrip and timing was different so now you completed in time… I guess we just idle a while and wait for the next pa…what? Two packages at once? Damn you TCP/IP! Do we apply both? I sure hope there's nothing in there that is cumulative because then we always have to filter that out first to maintain a proper “state history”…

On the server end, you can conceivably parallelise some of that processing to deal with the exponential increase — no such luck on the client side. And again, the numbers start to look awful just with the most minute basics of data at an abysmally low tick-rate that wouldn't really qualify as real-time.

 

[thorn-]

But yeah this 1000 clients and "users won't need to download all that" - as the guy states your problem is it's a space game. If you turn around and look at a battle of 999 other commandos in space you can see all 999 other commandos. There's no horizon/fog/atmosphere/buildings/geography to limit your view.

Perhaps at some point they'll have to admit 1000 clients was a dream/goal, but not possible/practical with today's technology. Sort of how Frontier had to kill the offline mode, after users paid for Elite. (Which I had no problem with. Sometimes plans have to change, and I didn't want Elite : Offline in the first place.)

 

[TenakaFurey]

Part of the problem seems to be CR's obsession with *cough* fidelity. The more detail (character model positioning, bullet/projectile tracking, etc) the more data needs to be sent to the client applications. Link this with, say, a high tick rate and even if the datacentre can handle the traffic & processing you'll definitely start to get issues with user's connections. We haven't even thought about NPCs, environmental effects, and so-on.

TBH thinking about a 1000 player instance and you really do start to get very real problems with the computing power needed as the CIG model doesn't, or rather cannot, off-load a lot of the details to the local game client as Frontier does as it isn't peer-to-peer. Now, you can always add more computing horsepower but this comes at a price, and I don't know how a non-subscription business model can cover it without continuing ship sales to existing customers.

There's a reason why fps/twitch-style games don't have hundreds of people in an instance, except maybe in lobbies.

All of this is true, but my issue was with Hanz's example. I cannot see where he gets a requirement for a 300 meg pipe, although some people here have speculated that he was positing a P2P type system rather than a server-client setup, and I can see why such a system **may** require more bandwidth at each node. However, a P2P network would likely be a very bad choice for a 1000 player instance, so I would not be certain why Hanz would model that environment.

As it is, I would posit that CIG would need to design around an instance limit of no more than 200 players...and almost certainly less...alongside the possibility of hundreds, or thousands of other objects in the instance. I can see why bandwidth could be a problem as each objects data - position, heading, actions, etc - would need to be shared and even small amounts of data build up.

- - - Updated - - -

I'm no expert on game networking, but the assumption that 3 updates per second for a twich game seems low. For strategy games, fine, even perhaps excessive. If you do a google you can find a really cool article about some of the tricks they used in the old days to get age of empires to work well over modem connections with so many units, including things like predictive movement, which can still be used today. But even so, we make a hell of a lot more than 3 adjustments per second when flying out ships in the middle of combat (including firing weapons, chaff, etc). The lower the value, the less "fidelity" you get.

Maybe 3 times per second is enough. No idea what ED uses for its P2P instances.

I believe he was thinking about his own example....3 times a second simply to share the positional and heading data for 1000 ships between each other so that each can be displayed and shown accurately.
If you want to take other activities into account, such as firing, you could either go with more frequent updates, or triggered updates where the client takes a note of the action initiated, and sends an update then and there informing the server that the ship with ID X has just fired its gimballed wing cannons at a heading of X,Y,Z and that the pilot has accelerated....allowing the server to instruct all the other clients to show the appropriate weapons fire and generate a suitable engine flare.

 

[Tuub t Tute]

It's avoided simply due to the general suspicion we've had for a couple of decades...

Umm, are you saying that for 20 years, or at least 11 to split hairs, you identify as part of a group that monitored the behaviour of some guy on the internet? So for 5 or 6 years before SC even Kickstarted?

/chapeau sir, you have dedication to your cause.

 

[DLewth]

The three updates a second sounds bit high, to be honest, at least for ship-based stuff, because you only need to propagate changes. If a train leaves London at 7:40 and travels north at 60 mph, and another leaves Crewe at 8:27 and travels south at 56 mph, you don't need updates every 0.3 seconds to work out there'll be a signal failure at Milton Keynes and everyone will moan about it in the Daily Mail.

Thinking about it in an ED context then yes, I 'm probably doing that much frantic stick-waggling when in combat but most of the time I'm cruising from A to B, and you don't need to report on that until I overshoot and do the inevitable loop around the planet.

Not that this makes 1000-player instances particularly feasible because you *do* have to generate this data for every bullet & missile (and some for laser/railgun stuff) and report resulting damage, but I don't think it something you can easily back-of-envelope.

 

[Marak]

Not that this makes 1000-player instances particularly feasible because you *do* have to generate this data for every bullet & missile (and some for laser/railgun stuff) and report resulting damage, but I don't think it something you can easily back-of-envelope.

Yes - and if a minigun is shooting 10 bullets per second, data stuff is gonna get enormous fast. And if 10 ships are doing it the data load will be huge.

Tracking every bullet and what it hits/penetrates/damages (ala WoT) will be quite a challange...

 

[TenakaFurey]

Yes - and if a minigun is shooting 10 bullets per second, data stuff is gonna get enormous fast. And if 10 ships are doing it the data load will be huge.

Tracking every bullet and what it hits/penetrates/damages (ala WoT) will be quite a challange...

Which is likely why they won't do it.

Tracking every bullet might not be necessary....at least so far as assuming them to be a discreet object. It might be enough for the system to know SHIP A has opened fire - so generate an appropriate animation - and then have it clauculate hots and damage and sending that information to the clients, rather than keep track of thousands of objects. Or maybe they will.

 

[Gregstrom]

IIRC the idea of tracking every individual bullet fired in online play died with a patch to DooM. Hopefully CIG won't dig it up again.

 

[Ian Skippy]

IIRC the idea of tracking every individual bullet fired in online play died with a patch to DooM. Hopefully CIG won't dig it up again.

Wasnt CR bragging about calculating individual bullet trajectories?

 

[Vasious]

I'm no expert on game networking, but the assumption that 3 updates per second for a twich game seems low. For strategy games, fine, even perhaps excessive. If you do a google you can find a really cool article about some of the tricks they used in the old days to get age of empires to work well over modem connections with so many units, including things like predictive movement, which can still be used today. But even so, we make a hell of a lot more than 3 adjustments per second when flying out ships in the middle of combat (including firing weapons, chaff, etc). The lower the value, the less "fidelity" you get.

Maybe 3 times per second is enough. No idea what ED uses for its P2P instances.

3 updates a second would be effectively no less than333 ping ne?

Well each update comes a third of a second later PLUS the time to send to the server, the time taken for the server to do its thing, and the time for the data to come from the server.

 

[Stigbob]

Wasnt CR bragging about calculating individual bullet trajectories?

After modeling billions of individual blood corpuscles mere bullets will be easy.

 

[DLewth]

IIRC the idea of tracking every individual bullet fired in online play died with a patch to DooM. Hopefully CIG won't dig it up again.

Like they did with head-bobbing? Hmmm...

 

[thorn-]

Umm, are you saying that for 20 years, or at least 11 to split hairs, you identify as part of a group that monitored the behaviour of some guy on the internet? So for 5 or 6 years before SC even Kickstarted?

I also know who American McGee and John Romero are; does that make me part of a "group", or just not ignorant?

Derek was known in gaming circles long before SC was kickstarted... it was rather impossible participate in usenet boards without seeing him make a 3-page post several times a week (or day) discussing Battlecruiser 3000.

 

[Tuub t Tute]

I also know who American McGee and John Romero are; does that make me part of a "group", or just not ignorant?

Derek was known in gaming circles long before SC was kickstarted... it was rather impossible participate in usenet boards without seeing him make a 3-page post several times a week (or day) discussing Battlecruiser 3000.

Thanks for the confirmation. Appreciate you taking time out of your busy schedule

Wonder when CiG will release any news on SC 3.0 or sq42 ep1? Are they shutdown until the 9th? Expect that means nothing dynamic before February... Oh well, SC is a waiting game indeed.

 

[TenakaFurey]

Thanks for the confirmation. Appreciate you taking time out of your busy schedule

Wonder when CiG will release any news on SC 3.0 or sq42 ep1? Are they shutdown until the 9th? Expect that means nothing dynamic before February... Oh well, SC is a waiting game indeed.

I would not expect 3.0 to release before Q2 at the earliest. CIG have a real problem meeting deadlines provided by Chris Roberts.
SQ42 Ep1 - at best, I would expect it's release sometime in Q4, assuming it is as developed as they say. The lack any previews, the knowledge that CIG are still working on the flight model and the scrapping of the demo is a bit worrying. I am hoping for - but not expecting - some news in the next few months. If there is nothing by June or July, I'd seriously question a release in 2017.

 

[VidarSnipes]

I would not expect 3.0 to release before Q2 at the earliest. CIG have a real problem meeting deadlines provided by Chris Roberts.
SQ42 Ep1 - at best, I would expect it's release sometime in Q4, assuming it is as developed as they say. The lack any previews, the knowledge that CIG are still working on the flight model and the scrapping of the demo is a bit worrying. I am hoping for - but not expecting - some news in the next few months. If there is nothing by June or July, I'd seriously question a release in 2017.

I think that SQ42 Prelude, however long that is going to be, will happen no later than in Q2 as it doesn't require any new technology (for example netcode) I can think of, followed by 3.0 somewhere around Gamescom, and the full release of the first episode of SQ42 in 2018.

 

[thorn-]

I don't think we'll see Squadron 42 released as final any time soon. Define "soon" however you wish.

Personally, I don't care if it's Christmas 2017 or Summer 2018. S42 wasn't why I backed the game. I'd rather have the improvements that 3.0 will (should) bring, and other sorts of code fixes.

 

[TenakaFurey]

I think that SQ42 Prelude, however long that is going to be, will happen no later than in Q2 as it doesn't require any new technology (for example netcode) I can think of, followed by 3.0 somewhere around Gamescom, and the full release of the first episode of SQ42 in 2018.

If SC42 - even the prelude - were to be released in Q2, I'd expect to start seeing some serious previews for it now

But I can't say you'd be wrong. But if they weren't willing to put in "a few days more effort" for the demo and so keep the backers happy, that implies the game itself is more than a few days away. After all, a few days delay when its two years late shouldn't have been an issue.

Maybe we'll see some progress once they nail down the flight model they want. Hopefully, that'll be all they are waiting on. But the prelude is due for March (yes, 2.6 and 3.0 were both due for release in 2016), so I really wouldn't expect Epi1 until October or November. They'll probably save it for a big launch at one of their events around then and a late launch will give them some time to finish up all that "polishing" so it meets Roberts standards. Although, being honest...now that I've earmarked late 2017 for Ep1, a 2018 launch window wouldn't be impossible.

I do think CIG need to show something - anything - at CitCon or the holiday events or the Anniversary shows. They've had the excuse that it's only been three years of serious development and that they were concentrating on the engines and tools, but the time to put up and shut up is rapidly approaching. Backers need to see their faith rewarded somehow, even if it is just a playable demo

 

[frostypaw]

I'm curious what the expected feature list is for the Sq42 prelude.

Now the SC chaps must understand that while many of the PU focused backers don't care for it the single player campaign is a massive draw for a lot of other players and drawing those people into the PU is it's purpose alongside raising more funds for the PU so it needs to be good, it needs to happen but what exactly IS it?

Will it involve getting into and out of spaceships? Flight? Using different loadouts? The ~USE~ button? Someone somewhere must have a list of the features that need to be complete for any of Sq42 to be released, I assume Orlando will have it to his fingertips somewhere if he'll oblige. We can then tick off which features are complete and working and how close we are to the possibility of Sq42 releasing in any way. Releasing a Sq42 preview with Alpha-state flight models isn't a thing, or if it is it's a project-fatal thing so we can't be six months away surely?

 

[TenakaFurey]

I'm curious what the expected feature list is for the Sq42 prelude.

Now the SC chaps must understand that while many of the PU focused backers don't care for it the single player campaign is a massive draw for a lot of other players and drawing those people into the PU is it's purpose alongside raising more funds for the PU so it needs to be good, it needs to happen but what exactly IS it?

Will it involve getting into and out of spaceships? Flight? Using different loadouts? The ~USE~ button? Someone somewhere must have a list of the features that need to be complete for any of Sq42 to be released, I assume Orlando will have it to his fingertips somewhere if he'll oblige. We can then tick off which features are complete and working and how close we are to the possibility of Sq42 releasing in any way. Releasing a Sq42 preview with Alpha-state flight models isn't a thing, or if it is it's a project-fatal thing so we can't be six months away surely?

As I recall, the PRELUDE was promised for March, so an Ep1 release in the June-Nov period is far from unlikely.