Game Discussions Star Citizen Discussion Thread v12

[[VR] Merkir]

There is precisely one context five A's should ever be used. Fortunately it applies here...

AAAAARGH!

 

[VR Golgot]

How the hell they get that all communicated through a network is a very, very different story and I still (have always said it) think that's where the real issues lie.

Yeah this seems to boil down to the 'have your cake and eat it' philosophy that Chris has pursued. So neatly summed up in the 2016 Kotaku piece:

We’re trying to do something that has the fidelity that you see in The Order, or has the fidelity you see in a first-person shooter but has multiplayer online and this huge universe and I absolutely, to the very fibre of my being, know it can happen.

They never seemed to have a technical pathway in mind to how they could achieve all of those things simultaneously. As the article suggests, he seems to have mainly just fired the guys who raised objections to it instead :/

That's what I expect from the team and if the pushback is 'Well, I didn't do this when I was working at this other company', then, well, here we're trying to push it a bit more and if you can't get on board then you're probably not right for the team.

And there's certainly historical precedent there, IE the 'design by decree' thing: "You did everything exactly the way he said to do it, period, or you were fired almost immediately. No second chances. He was very explicit with what he wanted, and you either did it that way, or you were not part of his team.".

Which may have worked back in the WC days. But seems highly dependent on his initial vision being 'right'. I'm not convinced it's working so well this time...

(2016 was interesting year for insights into the project. And also the year Chris decided that what the project really needed was Server Meshing. Hmmm. )

From a physrep / visual side, I think SC's getting very close to having everything it needs to 'make it real' (or close enough) for whatever they throw at it (providing the end user has the beast of a rig required).

Yeah I don't have a problem with the attempts to represent physical reality as well as possible. It's more that at points CR seems to have faltered into thinking that representing reality as 'physically' as possible is the best way to do this

Ultimately the fakery will have to win out, because it's generally more efficient. (And lord knows a beast project of this side needs efficiency under the hood).

It just comes across as so much burnt dev time, and wasted potential, if all of those complex systems (even if achieved) are unlikely to be supportable in concert.

 

[Skizomeuh]

Just another 10 years folks! Then it will be a game you play for 20-30 years.... presumably from the afterlife.

I'll stick to my AaaS. Alpha as a Service.

 

[Winterdyne]

There is the argument that developing the complex system allows you to more easily see the approximation to use for efficiency later (sort of like using square-distance coarse collision detection rather than relying on lots of sqrts from the outset). Not always a valid argument though.

 

[Skizomeuh]

Yeah I don't have a problem with the attempts to represent physical reality as well as possible. It's more that at points CR seems to have faltered into thinking that representing reality as 'physically' as possible is the best way to do this

Ultimately the fakery will have to win out, because it's generally more efficient. (And lord knows a beast project of this side needs efficiency under the hood).

It just comes across as so much burnt dev time, and wasted potential, if all of those complex systems (even if achieved) are unlikely to be supportable in concert.

That looks to be the magic of this "fideliciously no compromises" business model: inexhaustible dreams, infinite fundings, eternal alpha, no accountability as you can blame hardware, backers not backing enough if you fail to deliver. But delivering isn't in the plan.

 

[Xink]

All this "simulation", and ships fly like an FPS engine in no clip mode. What is the point of doing all that work if the player does not see any benefits.

 

[Winterdyne]

I dunno. Elite's doing the no clip thing pretty well itself at the moment:

 

[Skizomeuh]

All this "simulation", and ships fly like an FPS engine in no clip mode. What is the point of doing all that work if the player does not see any benefits.

Same as for 1st/3rd person equity: brag about, "never done before" argument for the SCDF, tier-0/refactor loop so can stay in eternal alpha.

 

[GuruNot]

Just another 10 years folks! Then it will be a game you play for 20-30 years.... presumably from the afterlife.

I could get hit by an Electric Car in that time!

 

[Intrepid3D]

You're confusing abstractions with approximations. They're not the same thing, logically or practically in a development sense, but in general I think I agree.

What you're actually getting at is that for a great many systems the amount of approximation (getting something that looks and feels about right in a simulation even though it's a kludge) isn't enough to be practical, and we are instead seeing systems implemented at a level of complexity that just make the overall job longer.

Lets for example take ship maneuvering thrusters.

Elite approximates this by having thrusters about the ship that fire when the ship moves based on a simple 'yaw, pitch, roll' stat trio. The individual thrusters can't be damaged, can't be altered (altering the thruster grade basically tweaks the YPR values), the centre of rotation of each ship is fixed. It's a kludge, but it works, it's neat enough, and it doesn't actually need to be anything more. Ding ding, point to Elite.

Star Citizen handles this by having each individual thruster gimbal to provide thrust based on an actual centre of mass. Knocking out thrusters on one side actually stops them from working and feeds back to the maneuvering of the ship. The abstraction method provides a location for thrusters relative to centre of mass, force of the thruster, etc. etc. It's super complicated but allows for great depth of simulation. But all that setup needs to be done*, for each and every ship. And at the end of the day, in most situations, it won't behave any differently (other than the thrusters wobbling like a spastic violin player's elbow).

*: This boils down to back-calculating the thruster values from playtested YPR values for the ships.

The questions of 'Do you actually need that?' 'Is that actually fun?' 'Is it worth the time and cost?' are often perhaps answered in ways that we, as either players, or customers awaiting their product might not.

Edit: It bears repeating, I do not class Star Citizen as a game yet. Yes, I've spent money on it (quite a bit, for me, for a game/plaything). I did that knowing I was funding CR's insane fever dream - and that's the important bit. I paid to watch the madness unfold. Don't buy into it if you want a game to play, or at least, certainly don't spend anything you'd be upset about. I've not actually spent that much time on Star Citizen. I've done a few things, looked at others (now need to rebind all my controls which will take a frickin' age). It's a testbed of a developer given almost completely free rein, and it shows 'where could things in game development go' if anything more than 'where will Star Citizen / S42 itself go'.

It can be annoying if you lose a wing with a thruster on it or you have two main engines and one starts flaming out, you end up trying to fly the ship on the crab or worse going round in circles, i've had one ship barrel role uncontrollably.

That's a little too real for me.

Tho, i have not had any of that happen for a while, i think they turned it off, you do lose chunks of your ship in a fight, some times, perhaps they also decided it was a little too real.

 

[Mole HD]

All this "simulation", and ships fly like an FPS engine in no clip mode. What is the point of doing all that work if the player does not see any benefits.

That's because most folk playing SC fly the ships like an FPS in noclip mode. They play SC like a twitch shooter, fly ships like they're FPS models all circle strafing and jousting with no 6 DoF flying for the most part. I still fly ships like I did in ED though...the HOTAS helps with that, mainly for the magic word 'immersion' at the end of the day since controlling a ship with M/KB isn't natural for me with playing a few flight sims here and there.

Ci¬G designed the space ships, flight model, control inputs and key bindings around a mouse and keyboard FPS shooter...and it shows. I'm too set in my ways...even though the ships, especially the smaller fighters, fly like revolving turrets in space, I still through force of habit fly them like spaceships.

 

[Winterdyne]

It can be annoying if you lose a wing with a thruster on it or you have two main engines and one starts flaming out, you end up trying to fly the ship on the crab or worse going round in circles, i've had one ship barrel role uncontrollably.

That's a little too real for me.

Tho, i have not had any of that happen for a while, i think they turned it off, you do lose chunks of your ship in a fight, some times, perhaps they also decided it was a little too real.

Losing a nacelle on a connie was always hellish, too. Especially trying to land for repairs.

 

[Winterdyne]

That's because most folk playing SC fly the ships like an FPS in noclip mode. They play SC like a twitch shooter, fly ships like they're FPS models all circle strafing and jousting with no 6 DoF flying for the most part. I still fly ships like I did in ED though...the HOTAS helps with that, mainly for the magic word 'immersion' at the end of the day since controlling a ship with M/KB isn't natural for me with playing a few flight sims here and there.

Ci¬G designed the space sim, control inputs and key bindings around a mouse and keyboard FPS shooter...and it shows. I'm too set in my ways...even though the ships fly like revolving turrets in space, I still through force of habit fly them like spaceships.

The really good pilots fly very similarly to the FAOFF guys in Elite. 'Decoupled mode' (last time I played) was kind of easier to jump in and out of (compared to Elite) as it allowed for more free rotation, and I think that's where the circlestrafe stuff came in. But I fly a connie, so that sort of game just ain't for my ship.

 

[Agony_Aunt]

I'll stick to my AaaS. Alpha as a Service.

Cheeky!

 

[Agony_Aunt]

I dunno. Elite's doing the no clip thing pretty well itself at the moment:
View attachment 246028

Sees 32 FPS. Starts to cry.

 

[Agony_Aunt]

It can be annoying if you lose a wing with a thruster on it or you have two main engines and one starts flaming out, you end up trying to fly the ship on the crab or worse going round in circles, i've had one ship barrel role uncontrollably.

That's a little too real for me.

Tho, i have not had any of that happen for a while, i think they turned it off, you do lose chunks of your ship in a fight, some times, perhaps they also decided it was a little too real.

Shame you're not play Starfox

Also, type do a barrel roll into google

 

[Mole HD]

The really good pilots fly very similarly to the FAOFF guys in Elite. 'Decoupled mode' (last time I played) was kind of easier to jump in and out of (compared to Elite) as it allowed for more free rotation, and I think that's where the circlestrafe stuff came in. But I fly a connie, so that sort of game just ain't for my ship.

I don't have many fighters left barring my blinged out Hornet Ghost, a freebie Buccaneer loaded out in griefer mode with space shotguns and a Vanguard or 2...since the pew stuff isn't really my thing. I'm either bulk hauling or mining...Caterpillar previously or Herc C2/M2 since they appeared, mining is either in the Mole if I have a few mates around or Prospector if I'm on my tod. I really like the little ROC buggies though, standard or the new ROC Derek-Smart (DS), load them up into the MSR and vanish from everyone's radar for a few hours.

The medium to bigger ships are kinda home from home for me since I'm always in my Ratmobile Python or the T-10 Combat-cow in EDO. I don't even own a Cutter or Corvette in EDO, or a Ferdie-Clownshoe...decided I didn't need them

 

[VR Golgot]

Star Citizen handles this by having each individual thruster gimbal to provide thrust based on an actual centre of mass. Knocking out thrusters on one side actually stops them from working and feeds back to the maneuvering of the ship. The abstraction method provides a location for thrusters relative to centre of mass, force of the thruster, etc. etc. It's super complicated but allows for great depth of simulation. But all that setup needs to be done*, for each and every ship. And at the end of the day, in most situations, it won't behave any differently (other than the thrusters wobbling like a spastic violin player's elbow).

*: This boils down to back-calculating the thruster values from playtested YPR values for the ships.

The questions of 'Do you actually need that?' 'Is that actually fun?' 'Is it worth the time and cost?' are often perhaps answered in ways that we, as either players, or customers awaiting their product might not.

The ship physics seems to be a really interesting example of the 'pitching for pure fidelity, ending up in fudge' arc.

If you look at John Pritchett's design doc, which he shared on leaving, gameplay designers have so many ways to override the physics system that, as you say, it almost might as well not be there.

Caveats
The downside of this approach is that it is possible to achieve any desired performance for a ship, regardless how realistic. If a designer wants to tune an Idris to go from zero to 1 km/s in half a second, this system will generate thruster capacities that will allow the ship to achieve this performance, regardless of whether it is reasonable. If care is not taken, a ship can end up with, for example, a small-diameter mav generating several million newtons of force, while a larger-diameter main generates only a fraction of that amount. While this would be strictly realistic within the simulation, it would not be reasonable. Based on in-fiction tech limits, thrusters should maintain a general relationship between size and capacity. This limitation is not enforced by the simulation. It is entirely up to the designer to balance desired performance goals against realistic physical behaviors for each ship.


Workarounds

Though I’ve made every effort to avoid any unnecessary cheats in this simulation, cheats are unfortunately necessary in any game. My general rule is that all ship motion must be derived from forces, and that the properties of acceleration, velocity and position must all change smoothly and continuously over time. For example, I do not simply snap a ship’s velocity or position to the goal values unless they are near enough to the final value that this snap is imperceptible. I rely on the reaction control system to drive all values to their final goals over time.

The workarounds that I accept as unavoidable are as follows.

Gimbaled thrusters – The decision to support gimbaled thrusters introduces a wide range of issues. While it is possible to accurately support gimbals, doing so without proper thruster design will result in unstable ship performance. In particular, gimbaled thrusters are inappropriate for reaction control. RCS thrusters must be able to fire quickly on multiple axes, and especially in the case where a gimbaled thruster ranges over both directions of a single axis, the time needed to re-orient the thruster from one direction to the other makes them impractical for providing stabilizing thrust. Since many of our ships do use gimbaled thrusters as the only provider of reaction control thrust, it is necessary to cheat and allow a gimbaled thruster to generate its force at the target vector immediately when called upon, even while it is in the process of rotating into the goal vector. This can be clearly seen as a ship like the Hornet can begin to rotate or strafe immediately while the thrusters are clearly not yet aligned to their intended vectors. There are two potential fixes for this issue, neither of which is likely to be employed. One is to avoid gimbaled thrusters entirely. The other is to guarantee that all ships carry a set of fixed thrusters that can generate immediate thrust on every local axial direction, so that any gimbaled thrusters are secondary, providing additional force or torque only, and only after rotating into proper alignment.

Fixups – There are three kinds of fixups that are supported in this simulation.

1. Thruster Position – As I stated in the section on ship tuning, I support the assignment of thruster positions to override the physical position of a thruster as set on the ship model. However, it is expected that this fixup will be relatively small, and while it is clearly a cheat, it should not be obvious to an observer that the thruster is generating thrust from a point in the simulation that is different from its visible mount-point.

2. Thruster Attitude – Along with thruster position fixups, I also support rotational fixups. In some cases, a ship is designed so that a thruster’s vector does not coincide with one or more of the ship’s local axes. The simulation requires that each thruster is either fixed on a local axis, or can gimbal over the full range between 2 or more axes. In cases where the art does not properly support this, a fixup can be used. But even more than with positional fixups, these attitude corrections should be very small. Even a small deviation in thrust vector between the simulation and visual thrust will be obvious to most observers. Ideally, this fixup will be a temporary fix until the art can be adjusted to support the required thruster range.

3. Center of Mass – For any ship with a particular thruster setup, there is an ideal center of mass that provides for optimal operation of those thrusters. It is generally located at a balance point within the array of thrusters, supporting as much balance as possible during linear thrust actions. If the center of mass is not well balanced, a great deal of thrust will be expended trying to counter the torque that is generated by unbalanced linear thrust. Until a better system can be implemented, I currently support a fixup for the center of mass, to simplify the process of establishing the center of mass at its most desirable location. This fixup is applied at the moment of tuning, and is relative to the true center of mass at that moment. If the true center of mass changes after tuning, the fixed-up center of mass will change by the same relative amount. This allows the center of mass to change dynamically as a ship changes, even if the original position has been adjusted relative to its true position. Any center of mass fixup is meant to be temporary until the reference ship can be adjusted to naturally achieve the desired center of mass. In the future, a dynamic ballast system would make this fixup unnecessary.

The severity of many of these workarounds is left to the discretion of the designers. It is my philosophy that we must be very careful to not over-use these workarounds. Once players begin to see discrepancies between the physics simulation and the game visuals, they will lose confidence in the fidelity of the simulation and assume that everything is faked. At that point, it is difficult to justify the complexity of such a realistic simulation. If it looks and feels fake, why not just fake it?

But I imagine the physics simulation is still spinning away there under the hood, even when its outputs are just being overridden by those workarounds. Which begs the question whether it would have just been better to accept a fudge compromise from the start.

There is the argument that developing the complex system allows you to more easily see the approximation to use for efficiency later (sort of like using square-distance coarse collision detection rather than relying on lots of sqrts from the outset). Not always a valid argument though.

Yep I can totally see the argument. But I think this is where SC's business model becomes an issue. Normally you'd prototype all this stuff, see what looks likely to work, and then sell people the giant capital ship with related capabilities . SC seems to have embraced the whole 'sell the big dream to everyone in great detail, including ourselves, and then try and make it work...' approach instead.

It seems a philosophy with some foibles. Of the 'fake it til you make it' variety

I dunno. Elite's doing the no clip thing pretty well itself at the moment:

Bigger than an 890J that. Just needs a jacuzzi

 

[Intrepid3D]

That looks to be the magic of this "fideliciously no compromises" business model: inexhaustible dreams, infinite fundings, eternal alpha, no accountability as you can blame hardware, backers not backing enough if you fail to deliver. But delivering isn't in the plan.

You don't need a super high end rig to run SC.

1440P Highest Graphics settings, Smooth 60+ FPS

AMD Ryzen 5600X: $300
Gigabyte Aorus Elite B550: $160
AMD RX 6700XT: $480 (MSRP)
WD Blue SN550 NVMe: $60
32GB 3200MT/s DDR4: $160

$1160 Total
-----------

1080P Highest Graphics settings.

AMD Ryzen 3600: $200
GIGABYTE B450M DS3H V2: $70
Nvidia RTX 3060: $330 (MSRP)
WD Blue SN550 NVMe: $60
16GB 3200MT/s DDR4: $90

$750
-----------

I will add the RX 6700XT in the first build is about 25% more powerful than mine and mine runs the game at 1440P highest settings more than fine.
The RTX 3060 is about 15% slower than mine, its just that Nvidia or AMD don't currently make anything that fits in the middle for around <$400. My GPU was $480 8 months ago.

 

[Fishy]

I'll just leave that here. While some studios work on outdated AWS/Twitch integration, real innovation is taking place elsewhere.

Behold the first ever mmo/Tinder integration: