Star Citizen Development Instances and Combat[KOR subbed]

[VoA]

Star Citizen Development Instances and Combat[KOR subbed] - is a good video that CIG will hopefully see.  It is different than @Lutin earlier video but similar.  His concept of pseudo space is interesting.  Enjoy

 

[Fizzlefuse]

very interresting.

[Daishi]

Yah I'm not a fan of their 100 man instances. Really sucks the fun out of fleet battles. That's like 2-4 full crewed Javelins fighting each other..... and nobody could come to back them up till a javelin exploded to make room for them.

 

And if you are fighting in a stacked instance how would you gain access to another stacked instance layer when there is room? Fly out and back in again?

 

The instance mechanic just sucks.

 

[Ragnor]

Yah I'm not a fan of their 100 man instances. Really sucks the fun out of fleet battles. That's like 2-4 full crewed Javelins fighting each other..... and nobody could come to back them up till a javelin exploded to make room for them.

 

And if you are fighting in a stacked instance how would you gain access to another stacked instance layer when there is room? Fly out and back in again?

 

The instance mechanic just sucks.

 

Always thought CIG meant 100-ship instances, but I could be wrong. Basically what's happening inside the ship isn't really visible, so the number of people on board a ship shouldn't be a factor, all those people inside the ship are in a seperate instance for the internal view of the ship I believe. 

[Morgenroete]

I also thought once they're in the 64-bit system they'll be able to enlarge the size of instances?

[VoA]

I also thought once they're in the 64-bit system they'll be able to enlarge the size of instances?

Correct - the 64-bit system will enlarge the instances.  64-bit determines precision the further away from the center source.  Another thing that CIG is developing (and has already to a certain degree).... is rendering less fidelity the further the ship (or object) is away from you.  Fidelity (or the detailed models of SC)... is the biggest factor when determining how many ships can fit in an instance.  That is why CR always mentioned that earlier on in development they'll only be able to have 1/2 dozen to a dozen ships in an instance....... but said their goal will eventually be around 50-100 ships in an instance.

[Daishi]

What I really don't get is 10 minute timers.

 

You go and have a big fleet battle and then the winner comes along and get like three ships salvaged.

 

I call bullshit on a 10 minute despawn timer.

[Morgenroete]

I think the 10 minute limit is if the destroyed object is inactive after 10 minutes. So if we're bumping the object around it'll be an "active" object and not applicable to the 10 minute limit. Anyhow, that time limit is also arbitrary right now

[Morgenroete]

@VoA Hey, I don't think it's how instance work as described in this video. What this video described is more like WoW and other traditional mmo. And I believe when CIG said they'll "divide" the instance ( because more player joined the instance) they mean they'll physically divided a instance into several smaller instance, but not making a carbon copy. 

 

@Luetin09 video

 

And @Weyoun described it nicely

 

here is how one of the devs explained things in RSI chat roll:

 

[Weyoun]

Correct - the 64-bit system will enlarge the instances.  64-bit determines precision the further away from the center source.  Another thing that CIG is developing (and has already to a certain degree).... is rendering less fidelity the further the ship (or object) is away from you.  Fidelity (or the detailed models of SC)... is the biggest factor when determining how many ships can fit in an instance.  That is why CR always mentioned that earlier on in development they'll only be able to have 1/2 dozen to a dozen ships in an instance....... but said their goal will eventually be around 50-100 ships in an instance.

The further away from the source (0) losing precision does not have to do with the bit-ness, but is an artifact of floating point numbers. If they used integer math they wouldn't have that problem. However, floating point math is very common and thus most computers are optimized for it and do float math much faster. They can take short cuts because you can 'round' and still get a good enough answer for most purposes. Quick example... in floating point you can NOT represent the number .1, thus is you take 1 and divide it by ten you get the answer 0.100000001490116119384765625 which is 'good enough'. The farther you get from zero the worse this problem becomes.

 

The Levels of Detail you mention about drawing things at a lower resolution the farther away they are is an old gaming trick used to get the most preform from graphics cards but has very little influence over the physics/instancing system. Star citizen uses rigid-body physics which is a trick to get better performance in physics calculations on large objects by pretending they are not a collection of small bits, but rather one larger object, where a force that acts upon it, acts on the whole. Instead of figuring out deformation, twists, torsion, propagation of forces at the speed of sound through material etc. Instead the physics says, there is x Parts with y momentum and z position that got w forces applied to it, if certain conditions are met, the rigid bodies are modified through scripts. Now star citizen might use ships made up of multiple smaller rigid bodies that are joined up into larger ones. And in some instances when appropriate do calculation on parts instead of the larger whole. (example, thrusters could exert vector forces onto a simple model of the entire ship, while if shot by a gun the engine would trace the round through various sub components and see how that worked out)

 

This is abstracted with hit points, and scripted changes to the models that happen at certain thresholds as various bits and pieces are blown away.  The physics Logic (client & server) then tells the graphics logic to draw the ships, which is then done using the LoD's you mentioned, along with the users particular graphics setting.

 

When I was dabbling in starcraft 2 map dev I remember their physics engine ticks ~60 times per frame so at 30 fps you are looking at like 1800 physics calculations per second per entity. You have physical 'agents' that are invisible that are you actual units that the physics happens to. these then  pass info every so often to 'actors' which are the onscreen representation you see actually rendered with colors and glowing and all that other fancy looking stuff. But the game will always prioritize physics over graphics, which is why you get you units 'hoping' around the screen for some people, but buttery smooth for others, without having an inconsistent game state between the two.  The game only lags for the one person if their gfx suck, but if their CPU sucks and they can't keep up with physics the game slows down for all.

 

This is also why when we play Fractured Space the game has been laggy as all heck, even if we all play on minimal gfx settings.

 

for an example of accurate soft body physics in vehicles see: http://www.beamng.com/great physics, but not so good gfx.

 

Also keep in mind distance is relative. Just because someone is far from you doesn't mean the servers/instances can 'down grade' them to speed things up, as they are close to themselves, and any one near them. If they used simplified physics for the other guys ship for you, but accurate for him  and those around him you would end up with inconsistent game states, being in two different places at the same time.

 

The bigest thing effecting instances is actually network bandwidth. More specifically, #of datapoints changed multiplied by the number of connected players.

 

Lets say each player connected has their ship position, movement vector, shield status, weapons status, damage state, a missile fired, some chaff to avoid enemy missiles, and an average of 3 laser shots fired that are being tracked.

 

10 entity * 1 connected player = 10 sets of data to send out.

100 entities * 10 connected players = 1,000 sets of data to send out

1000 entities * 100 connected players = 100,000 sets of data to send out

 

to go from 1 person to 100 you increase the players by 10^2 but increase the data by 10^5 and this is if its all client-server only. If you are doing peer-to-peer calculations (which they have mentioned attempting to want to do) you don't need nearly as much processing on the server to track all the physics, the server can 'spot check' random samplings of data, and peers can cross check each others work to root out cheating.. but then everyone has to send all that data not just server->client but from each client to each other also so add a few more zeros onto the amount of data you must pipe through some poor Australians internet pipe.

 

So the 'orbital' instances mentioned in luetins video make it easy, as you can throw 100 random people and 1000 npcs into one instance and put another one side by side with another random 100 players and 1000 npcs, and it will feel vast and full. if people know each other or have org ties/relations they are pulled into the same one.

 

In the proposed battle instances they can break it up into sections, and the large ships can have separate instances for their internals, while the exterior overlaps through multiple exterior instances. each instance handles physics for its own area, and transmitting datasets to connected players, and also adjacent instances. Those other instances would then pass relevant data to their own connected players. Since the instances would share a rack in the same server room, or be connected with high bandwidth back hauls to other server farms they would be transmitting in our above example 1000 entities * 5-8 adjacent instances = 5000-8000 datasets over much larger pipes.

 

TL;DR

Floating point math is evil & The server isn't saying draw this polygon here, and this one there, and a wisp of smoke going this way. It's simply saying play explody animation #5

 

Also people have told me the info from chat roll was just a dev spit balling ideas and that it should not be read as what they intended to do, but later after that wingman confirmed larger ships and space station would span across multiple instances. And that instances are not limited by # of ships, but by number of connected players.

[Wu Jen]

The further away from the source (0) losing precision does not have to do with the bit-ness, but is an artifact of floating point numbers. If they used integer math they wouldn't have that problem. However, floating point math is very common and thus most computers are optimized for it and do float math much faster. They can take short cuts because you can 'round' and still get a good enough answer for most purposes. Quick example... in floating point you can NOT represent the number .1, thus is you take 1 and divide it by ten you get the answer 0.100000001490116119384765625 which is 'good enough'. The farther you get from zero the worse this problem becomes.

 

The Levels of Detail you mention about drawing things at a lower resolution the farther away they are is an old gaming trick used to get the most preform from graphics cards but has very little influence over the physics/instancing system. Star citizen uses rigid-body physics which is a trick to get better performance in physics calculations on large objects by pretending they are not a collection of small bits, but rather one larger object, where a force that acts upon it, acts on the whole. Instead of figuring out deformation, twists, torsion, propagation of forces at the speed of sound through material etc. Instead the physics says, there is x Parts with y momentum and z position that got w forces applied to it, if certain conditions are met, the rigid bodies are modified through scripts. Now star citizen might use ships made up of multiple smaller rigid bodies that are joined up into larger ones. And in some instances when appropriate do calculation on parts instead of the larger whole. (example, thrusters could exert vector forces onto a simple model of the entire ship, while if shot by a gun the engine would trace the round through various sub components and see how that worked out)

 

This is abstracted with hit points, and scripted changes to the models that happen at certain thresholds as various bits and pieces are blown away.  The physics Logic (client & server) then tells the graphics logic to draw the ships, which is then done using the LoD's you mentioned, along with the users particular graphics setting.

 

When I was dabbling in starcraft 2 map dev I remember their physics engine ticks ~60 times per frame so at 30 fps you are looking at like 1800 physics calculations per second per entity. You have physical 'agents' that are invisible that are you actual units that the physics happens to. these then  pass info every so often to 'actors' which are the onscreen representation you see actually rendered with colors and glowing and all that other fancy looking stuff. But the game will always prioritize physics over graphics, which is why you get you units 'hoping' around the screen for some people, but buttery smooth for others, without having an inconsistent game state between the two.  The game only lags for the one person if their gfx suck, but if their CPU sucks and they can't keep up with physics the game slows down for all.

 

This is also why when we play Fractured Space the game has been laggy as all heck, even if we all play on minimal gfx settings.

 

for an example of accurate soft body physics in vehicles see: http://www.beamng.com/great physics, but not so good gfx.

 

Also keep in mind distance is relative. Just because someone is far from you doesn't mean the servers/instances can 'down grade' them to speed things up, as they are close to themselves, and any one near them. If they used simplified physics for the other guys ship for you, but accurate for him  and those around him you would end up with inconsistent game states, being in two different places at the same time.

 

The bigest thing effecting instances is actually network bandwidth. More specifically, #of datapoints changed multiplied by the number of connected players.

 

Lets say each player connected has their ship position, movement vector, shield status, weapons status, damage state, a missile fired, some chaff to avoid enemy missiles, and an average of 3 laser shots fired that are being tracked.

 

10 entity * 1 connected player = 10 sets of data to send out.

100 entities * 10 connected players = 1,000 sets of data to send out

1000 entities * 100 connected players = 100,000 sets of data to send out

 

to go from 1 person to 100 you increase the players by 10^2 but increase the data by 10^5 and this is if its all client-server only. If you are doing peer-to-peer calculations (which they have mentioned attempting to want to do) you don't need nearly as much processing on the server to track all the physics, the server can 'spot check' random samplings of data, and peers can cross check each others work to root out cheating.. but then everyone has to send all that data not just server->client but from each client to each other also so add a few more zeros onto the amount of data you must pipe through some poor Australians internet pipe.

 

So the 'orbital' instances mentioned in luetins video make it easy, as you can throw 100 random people and 1000 npcs into one instance and put another one side by side with another random 100 players and 1000 npcs, and it will feel vast and full. if people know each other or have org ties/relations they are pulled into the same one.

 

In the proposed battle instances they can break it up into sections, and the large ships can have separate instances for their internals, while the exterior overlaps through multiple exterior instances. each instance handles physics for its own area, and transmitting datasets to connected players, and also adjacent instances. Those other instances would then pass relevant data to their own connected players. Since the instances would share a rack in the same server room, or be connected with high bandwidth back hauls to other server farms they would be transmitting in our above example 1000 entities * 5-8 adjacent instances = 5000-8000 datasets over much larger pipes.

 

TL;DR

Floating point math is evil & The server isn't saying draw this polygon here, and this one there, and a wisp of smoke going this way. It's simply saying play explody animation #5

 

Also people have told me the info from chat roll was just a dev spit balling ideas and that it should not be read as what they intended to do, but later after that wingman confirmed larger ships and space station would span across multiple instances. And that instances are not limited by # of ships, but by number of connected players.

You hurt my head but I'm going to go with a 'Your correct' response.

 

The thought of instances moving hurts my head even more.

[Morgenroete]

The further away from the source (0) losing precision does not have to do with the bit-ness, but is an artifact of floating point numbers. If they used integer math they wouldn't have that problem. However, floating point math is very common and thus most computers are optimized for it and do float math much faster. They can take short cuts because you can 'round' and still get a good enough answer for most purposes. Quick example... in floating point you can NOT represent the number .1, thus is you take 1 and divide it by ten you get the answer 0.100000001490116119384765625 which is 'good enough'. The farther you get from zero the worse this problem becomes.

 

The Levels of Detail you mention about drawing things at a lower resolution the farther away they are is an old gaming trick used to get the most preform from graphics cards but has very little influence over the physics/instancing system. Star citizen uses rigid-body physics which is a trick to get better performance in physics calculations on large objects by pretending they are not a collection of small bits, but rather one larger object, where a force that acts upon it, acts on the whole. Instead of figuring out deformation, twists, torsion, propagation of forces at the speed of sound through material etc. Instead the physics says, there is x Parts with y momentum and z position that got w forces applied to it, if certain conditions are met, the rigid bodies are modified through scripts. Now star citizen might use ships made up of multiple smaller rigid bodies that are joined up into larger ones. And in some instances when appropriate do calculation on parts instead of the larger whole. (example, thrusters could exert vector forces onto a simple model of the entire ship, while if shot by a gun the engine would trace the round through various sub components and see how that worked out)

 

This is abstracted with hit points, and scripted changes to the models that happen at certain thresholds as various bits and pieces are blown away.  The physics Logic (client & server) then tells the graphics logic to draw the ships, which is then done using the LoD's you mentioned, along with the users particular graphics setting.

 

When I was dabbling in starcraft 2 map dev I remember their physics engine ticks ~60 times per frame so at 30 fps you are looking at like 1800 physics calculations per second per entity. You have physical 'agents' that are invisible that are you actual units that the physics happens to. these then  pass info every so often to 'actors' which are the onscreen representation you see actually rendered with colors and glowing and all that other fancy looking stuff. But the game will always prioritize physics over graphics, which is why you get you units 'hoping' around the screen for some people, but buttery smooth for others, without having an inconsistent game state between the two.  The game only lags for the one person if their gfx suck, but if their CPU sucks and they can't keep up with physics the game slows down for all.

 

This is also why when we play Fractured Space the game has been laggy as all heck, even if we all play on minimal gfx settings.

 

for an example of accurate soft body physics in vehicles see: http://www.beamng.com/great physics, but not so good gfx.

 

Also keep in mind distance is relative. Just because someone is far from you doesn't mean the servers/instances can 'down grade' them to speed things up, as they are close to themselves, and any one near them. If they used simplified physics for the other guys ship for you, but accurate for him  and those around him you would end up with inconsistent game states, being in two different places at the same time.

 

The bigest thing effecting instances is actually network bandwidth. More specifically, #of datapoints changed multiplied by the number of connected players.

 

Lets say each player connected has their ship position, movement vector, shield status, weapons status, damage state, a missile fired, some chaff to avoid enemy missiles, and an average of 3 laser shots fired that are being tracked.

 

10 entity * 1 connected player = 10 sets of data to send out.

100 entities * 10 connected players = 1,000 sets of data to send out

1000 entities * 100 connected players = 100,000 sets of data to send out

 

to go from 1 person to 100 you increase the players by 10^2 but increase the data by 10^5 and this is if its all client-server only. If you are doing peer-to-peer calculations (which they have mentioned attempting to want to do) you don't need nearly as much processing on the server to track all the physics, the server can 'spot check' random samplings of data, and peers can cross check each others work to root out cheating.. but then everyone has to send all that data not just server->client but from each client to each other also so add a few more zeros onto the amount of data you must pipe through some poor Australians internet pipe.

 

So the 'orbital' instances mentioned in luetins video make it easy, as you can throw 100 random people and 1000 npcs into one instance and put another one side by side with another random 100 players and 1000 npcs, and it will feel vast and full. if people know each other or have org ties/relations they are pulled into the same one.

 

In the proposed battle instances they can break it up into sections, and the large ships can have separate instances for their internals, while the exterior overlaps through multiple exterior instances. each instance handles physics for its own area, and transmitting datasets to connected players, and also adjacent instances. Those other instances would then pass relevant data to their own connected players. Since the instances would share a rack in the same server room, or be connected with high bandwidth back hauls to other server farms they would be transmitting in our above example 1000 entities * 5-8 adjacent instances = 5000-8000 datasets over much larger pipes.

 

TL;DR

Floating point math is evil & The server isn't saying draw this polygon here, and this one there, and a wisp of smoke going this way. It's simply saying play explody animation #5

 

Also people have told me the info from chat roll was just a dev spit balling ideas and that it should not be read as what they intended to do, but later after that wingman confirmed larger ships and space station would span across multiple instances. And that instances are not limited by # of ships, but by number of connected players.

Nicely said! (Pretending I know what you're saying....) 

[CyberianK]

The further away from the source (0) losing precision does not have to do with the bit-ness, but is an artifact of floating point numbers. If they used integer math they wouldn't have that problem. However, floating point math is very common and thus most computers are optimized for it and do float math much faster. They can take short cuts because you can 'round' and still get a good enough answer for most purposes. Quick example... in floating point you can NOT represent the number .1, thus is you take 1 and divide it by ten you get the answer 0.100000001490116119384765625 which is 'good enough'. The farther you get from zero the worse this problem becomes.

 

The Levels of Detail you mention about drawing things at a lower resolution the farther away they are is an old gaming trick used to get the most preform from graphics cards but has very little influence over the physics/instancing system. Star citizen uses rigid-body physics which is a trick to get better performance in physics calculations on large objects by pretending they are not a collection of small bits, but rather one larger object, where a force that acts upon it, acts on the whole. Instead of figuring out deformation, twists, torsion, propagation of forces at the speed of sound through material etc. Instead the physics says, there is x Parts with y momentum and z position that got w forces applied to it, if certain conditions are met, the rigid bodies are modified through scripts. Now star citizen might use ships made up of multiple smaller rigid bodies that are joined up into larger ones. And in some instances when appropriate do calculation on parts instead of the larger whole. (example, thrusters could exert vector forces onto a simple model of the entire ship, while if shot by a gun the engine would trace the round through various sub components and see how that worked out)

 

This is abstracted with hit points, and scripted changes to the models that happen at certain thresholds as various bits and pieces are blown away.  The physics Logic (client & server) then tells the graphics logic to draw the ships, which is then done using the LoD's you mentioned, along with the users particular graphics setting.

 

When I was dabbling in starcraft 2 map dev I remember their physics engine ticks ~60 times per frame so at 30 fps you are looking at like 1800 physics calculations per second per entity. You have physical 'agents' that are invisible that are you actual units that the physics happens to. these then  pass info every so often to 'actors' which are the onscreen representation you see actually rendered with colors and glowing and all that other fancy looking stuff. But the game will always prioritize physics over graphics, which is why you get you units 'hoping' around the screen for some people, but buttery smooth for others, without having an inconsistent game state between the two.  The game only lags for the one person if their gfx suck, but if their CPU sucks and they can't keep up with physics the game slows down for all.

 

This is also why when we play Fractured Space the game has been laggy as all heck, even if we all play on minimal gfx settings.

 

for an example of accurate soft body physics in vehicles see: http://www.beamng.com/great physics, but not so good gfx.

 

Also keep in mind distance is relative. Just because someone is far from you doesn't mean the servers/instances can 'down grade' them to speed things up, as they are close to themselves, and any one near them. If they used simplified physics for the other guys ship for you, but accurate for him  and those around him you would end up with inconsistent game states, being in two different places at the same time.

 

The bigest thing effecting instances is actually network bandwidth. More specifically, #of datapoints changed multiplied by the number of connected players.

 

Lets say each player connected has their ship position, movement vector, shield status, weapons status, damage state, a missile fired, some chaff to avoid enemy missiles, and an average of 3 laser shots fired that are being tracked.

 

10 entity * 1 connected player = 10 sets of data to send out.

100 entities * 10 connected players = 1,000 sets of data to send out

1000 entities * 100 connected players = 100,000 sets of data to send out

 

to go from 1 person to 100 you increase the players by 10^2 but increase the data by 10^5 and this is if its all client-server only. If you are doing peer-to-peer calculations (which they have mentioned attempting to want to do) you don't need nearly as much processing on the server to track all the physics, the server can 'spot check' random samplings of data, and peers can cross check each others work to root out cheating.. but then everyone has to send all that data not just server->client but from each client to each other also so add a few more zeros onto the amount of data you must pipe through some poor Australians internet pipe.

 

So the 'orbital' instances mentioned in luetins video make it easy, as you can throw 100 random people and 1000 npcs into one instance and put another one side by side with another random 100 players and 1000 npcs, and it will feel vast and full. if people know each other or have org ties/relations they are pulled into the same one.

 

In the proposed battle instances they can break it up into sections, and the large ships can have separate instances for their internals, while the exterior overlaps through multiple exterior instances. each instance handles physics for its own area, and transmitting datasets to connected players, and also adjacent instances. Those other instances would then pass relevant data to their own connected players. Since the instances would share a rack in the same server room, or be connected with high bandwidth back hauls to other server farms they would be transmitting in our above example 1000 entities * 5-8 adjacent instances = 5000-8000 datasets over much larger pipes.

 

TL;DR

Floating point math is evil & The server isn't saying draw this polygon here, and this one there, and a wisp of smoke going this way. It's simply saying play explody animation #5

 

Also people have told me the info from chat roll was just a dev spit balling ideas and that it should not be read as what they intended to do, but later after that wingman confirmed larger ships and space station would span across multiple instances. And that instances are not limited by # of ships, but by number of connected players.

I thought its not enough with 2 peoples quoting this wall of text and saying Weyoun is right so now it is 3

[TRON]

I really hope they pull it off but every game I have played that was heavily instanced ending up having terrible issues and problems that overall made the multiplayer interaction suck.

 

I really hope they have a great system but from previous games, heavy instancing in MMO's never works as intended and always bring more problems than it is worth.

[Daishi]

I'm here to help!

 

Um where is everyone?

 

...oh.... I have to wait for more of my squadron to get ambushed and die before I can help....greaaaaaat.

[Dabclipers]

This is arguably one of the more important parts of the game to get nailed down.  If you look at EVE online the stuff that really makes news and gets players excited is when massive battles take place on unprecedented scale.  I know I am not really adding anything to the conversation, my knowledge on the technical side of how the instancing is going to work is poor at best.  The system that Morgen talked about would be acceptable, but hopefully in two years the technology will have progressed far enough that gimmicks would not be required to get larger battles running.

 

Regardless, how this issue is dealt with may easily make or break the success of this game in the eyes of the player-base.

[Tisi]

one thing keeps spinning around in my head...

so let's say im on one of our cap ships doing my daily work when we are getting ambushed by some pirates...

would i be able to see the smaller ships outside fighting each other when i look out of a window when the interior is a seperate instance?

thx in advance if someone can enlighten me

[VoA]

This is arguably one of the more important parts of the game to get nailed down.

Agree. I think CIG is still working on it. We will probably see more on this from RSI after they work out modifying Cry Engine for 64 bit.