hey, who remembers when I said the same thing weeks ago?
"
They're likely culling things based upon the view frustrum of the camera"
Well, read this
developer FUD
A game developer and programmer of considerable experience and years in the industry has offered a commentary on the current state of the SC engine. He has given permission for it to be posted here. No it isn't Derek Smart - this is a European dev of some calibre.
Background - it was a surprise to a few folks in the industry that CIG took the decision to promote a free fly given the poor state of the builds on the PTU. A conversation took place around many of the deep technical issues that CIG's team have been unable to address, and a layman's commentary was requested around some specific 'glitches' that are present in the current build. So here it is in full.
Star Citizen Free Fly build, a developer's commentary:
DISCLAIMER
Most of these are going to be pure, wild, stabs in the dark - what I would start with if I had to debug them. But keep in mind that I have no idea what their codebase is like (besides clearly not ideal), so plenty of them are probably far off the mark.
Glitch type: random teleportation
I don't know what the is going on here. This is so amazingly broken, it could very well be caused by quite literally anything. So, this is going to be wild speculation: Animations often have movement associated with them. A good example of this is a walk animation cycle - animators can put in the forward momentum, so it's perfectly synced to the animation, and can be easily sped up or slowed down while still looking right. It's possible that there's a tiny bit of movement during the "fidelitiously drink from glass" animation. Or perhaps the glass is a physical entity with collision detection. And either way, it added movement to the commando, which caused the commando to clip inside some other collision object (such as the nearby bar), which then caused it to freak out and deposit them elsewhere. The second jump? Who knows. That's pure magic. It's probably a separate, but related, issue to the first jump, where rapidly changing environments in a way that was never supposed to happen caused another system to explode. It seems to have teleported the commando far away, perhaps to another side of the moon, since they're rotated horizontally.
Gitch type: clipping into stuff erases ships
https://clips.twitch.tv/BovineUglyBurritoBigBrother Another physics oddity. Since this is going to come up a lot, we need to go over the basics of physics in game development. Physics is a bunch of really complex math, and one of its primary tasks is resolving and providing response to collisions. When two objects overlap, the collision must be resolved by calculating how much each object is penetrating (har har) each other and in what direction. A response can then be provided in the form of deciding how to move those objects apart so that they are no longer colliding, and then applying force to them. This prevents objects from clipping through each other, and gives them that nice, warm and fuzzy physical-y feeling that you get when you throw a heavy ball at a tower of boxes and the boxes realistically tumble and fall in response to the ball's weight.
That's how it's supposed to work. In the 'verse, it is clearly not working as it is supposed to. What happens here is that the physics are failing at that resolve and response step. The objects are penetrating each other, but the physics engine can't figure out how to correctly resolve it. What usually happens in such a case is that one or both of the objects goes flying away at an extremely high velocity - we've all seen this happen in games like Skyrim. A cheap way of 'fixing' that problem (without actually fixing what is causing the underlying problem) is to simply detect when an object is suddenly given a super huge velocity, and deleting it. Poof, problem solved. Sort of. In this case, the chariot blinks out of existence, leaving the hapless commando trapped in limbo, because it was never designed to know what to do when the chariot he was piloting no longer exists and he did not have time to perform a fidelity immersion animation to return to a not-piloting-chariot state. This looks like what is happening here.
Glitch type: bind culling on objects that are visible for player
https://thumbs.gfycat.com/SomeSilkyBaiji-max-14mb.gif Haha. Bad math. They're likely culling things based upon the view frustrum of the camera, but forgetting to keep it in sync when switching between camera views and environments. Lots of things can affect the camera's state like that, especially cramped environments - and I'm sure that they're forgetting to keep the version of the camera's position/rotation/view matrix updated properly before culling with it.
Glitch type: animation glitches
https://media.giphy.com/media/uiKYLa...xmhn/giphy.gif Holy stimperor that's disturbing. And what happens when animation states go bad. The commando was presumably supposed to use a immersion mocap to exit the chariot, but instead, somehow got into the "nah, let's just walk forwards lol" state due to extremely good programming. But, his legs were all ready to be part of that fidelity animation... But then were told to do a bog-standard walk animation instead, so they did the best they could and split the difference. Basically, the code that handles animation was trying to go in two directions at once, like the creepy guy with each eye pointing in a different direction. The result was Fidelity™ to make the stimperor proud.
Glitch type: weapon fire curves when strafing
So they're adding the chariot's velocity to the projectile's velocity as it's fired. Makes it easier to lead shots when you're aiming, in the worst, brokenest possible way that immediately falls over when anyone who has touched a flight sim tries to play it. Revisit trig, this is stuff that is both simple enough that it should have been covered in a college course and stuff that has been solved so many times over that you could have found a complete solution in ten seconds of searching. I award you no points.
Glitch type: going too fast into planet breaks collision detection
https://giant.gfycat.com/JitteryImpe...gurbuzzard.mp4 He's clipping through the planet's ground before the collision detection has a chance to stop him. Their coordinate system was obviously not intended to function underground (sorry, anyone looking forward to hot subterrainian mining action), and promptly had a panic attack, breaking everything simultaniously. Only God knows what happened in the final few moments of that commando's short, painful life.
Glitch type: Tposing multiple characters in 1 spot
https://clips.twitch.tv/EmpathicAver...tmullinsLitFam A t-pose happens when the animation data for the commando becomes corrupted, and it reverts to its default state. Some of the fidelity immersion animations that were supposed to happen likely get corrupted when they try to resolve collision with another commando occupying the same space, as described previously. Apparently they just turn off collision detection with the offending object in that case, since you can't very well delete a commando like you can a ship.
Glitch type: rubber banding on NPC
Rubber banding can happen in most any multiplayer game that uses network prediction - that is, predicting that if a commando is running to the left, he'll probably continue running to the left until the network tells him otherwise - and the networking starts slowing down so those new packets saying "hey wait, I'm actually going right now" don't come through until several seconds later, leading to the commando rubber banding back to its correct, not-based-off-of-old-predictions position. This is usually caused by a bad connection that's suddenly dropping a lot of packets or getting a far higher ping than usual. It can also be caused by terribly written netcode.
Glitch type: latency issues/manipulation
A combination of all of the above, plus the wonderful fact that their clients are fully trusted and you can freely hack the poor thing to smithereens, as has been discussed many times before. Zany hijinks ensue in the more lethal than COD e-sports sensation!
BONUS COMMENTARY:
As much as they like to claim that they're the Best Damn Space Simulator Ever, they're not. Like, at all. Nothing about the game is a simulation, it's a bunch of parlor tricks hacked together to create the illusion of a coherent world, which, as we've seen, is not doing a great job of hiding the fundamental, structural cracks behind the cheap curtains. It's not inherently a bad thing because almost every game is made just like this - cheap as much as humanly possible in order to give the best possible experience to the players, most of which will never be the wiser anyway.
AI is a great example of this because it's blatantly obvious that they have not designed the game to be an NPC simulation first, game second - which they need to in order for it to work as they claim for the reasons described above. Whatever AI they put in immediately gets released-state Radiant AI-esque handcrafted stuff pasted on top of it. Just look at how many iterations a single mission giver has been through. No amount of jackets is going to magically tip the switch and turn glorified handcrafted pathfinding waypoint lists into something that shatters the Turing test and ushers us into a brave new world of I, Robot existential crisis.
