Toops posted:

Look I don't wanna crosswords with you, a greed to diss a greed, kay?

ManofManyAliases posted:

Amazon bought the whole 3.4 (or 3.5 ... whichever it was) tree free and clear. It's not Crytek's anymore.

CrazyTolradi posted:

In regards to the whole idea that SC is about emergent gameplay, emergent gameplay is only as good as the gameplay mechanics that are in place that allow it. Star Citizen 3.0 is like putting a bunch of kids in a room that only has gameboards with all the pieces missing and toys that are either broken or just not complete.

G0RF posted:

Also, it only just fully hit me today the irony of CIG’s plight with respect to Squadron’s relationship to Crytek and Coutts. CIG must have made explicit declarations to Coutts about Squadron as a discreet standalone game, considering that Squadron alone was used as collateral for the loan. Yet to Crytek and elsewhere, Squadron is part of Star Citizen.

Ubik_Lives posted:

Is the Coutts loan still outstanding? Would we know if they have paid it off? I thought that was a pay-day loan to get them to the convention period, and the UK gaming tax credit was part of the collateral, which they were supposed to get in the fall.

If that loan is still around, and CIG have taken the tax credit without paying the loan off, Coutts must have a pretty itchy trigger finger about now.

boviscopophobic posted:

The charge is not satisfied according to Companies House, and F42 UK also altered their accounting period to conveniently add an additional 6 month delay before they have to release any financial statements including the loan.

boviscopophobic posted:

Ubik_Lives posted:

Deep down I knew the answer before I'd even asked the question, but yet, as with all things related to Star Citizen, I can't understand how they can keep failing at everything they do.

kilus aof posted:

I think the key problem here is they tried to make all these crazy designs without any upper management thought on how feasible they were, how they interacted with each other, how much of a network load it would make, the load on a client computer, development time, suitability in the confines of their technology choices and the technology choices themselves. With all of that being excused by 'fidelity', 'no cheating', 'never been done before' and 'no publishers'. And the biggest rationale was the thought if any design didn't work out they could just go for a simpler design. Which is the critical problem with Star Citizen, they have no simpler designs.

A simpler design isn't the consequence of a complex design failure, it's its own design with a host of required considerations. So when their designs fail they have nothing. It's back to the drawing board with multiple years wasted on designs which yielded nothing. And that's is why you get the emphasis on "emergent gameplay" because nothing works and it will years minimum before a system that works is implemented.

CrazyTolradi posted:

In regards to the whole idea that SC is about emergent gameplay, emergent gameplay is only as good as the gameplay mechanics that are in place that allow it. Star Citizen 3.0 is like putting a bunch of kids in a room that only has gameboards with all the pieces missing and toys that are either broken or just not complete.

CrazyTolradi posted:

In regards to the whole idea that SC is about emergent gameplay, emergent gameplay is only as good as the gameplay mechanics that are in place that allow it. Star Citizen 3.0 is like putting a bunch of kids in a room that only has gameboards with all the pieces missing and toys that are either broken or just not complete.

Bootcha posted:

WANT

Gimmie your favorite physics moments in SC, in video/gifphy formats.

Toops posted:

Nice post, and I'll just add this: Even if your feature design is simple, such as

code:

{"air": 1.0}

Instead of

code:

 {"nitrogen": 0.7809, "oxygen": 0.2095, "argon": 0.0093, "carbonDioxide": 0.0004}

that in itself doesn't automatically make the code simple. See folks, the hard part of programming isn't writing code that does a thing, it's the code that glues them all together, sends messages between all the different systems, and generally makes them work in concert to form a cohesive system, so that every function knows what to do, when to do it, and has the information it needs when they get called on.

It doesn't take programming experience to know that SC's code is a colossal goat-gently caress in this regard. You can feel it. Your intuition knows something is wrong down in the guts. Overall low framerates, massive game locks on the order of seconds, ridiculous collision/clipping issues, unresponsive UI, unresponsive actions (ahem doors, ramps), poor maintenance of state (doors and ramps again), etc. The engine is choking and sputtering like an old lawnmower that sat out in the yard naked all winter, because the information is poorly manicured, and the inter-system messaging is hosed.

If you're interacting with a system in SC, chances are 1 of 2 things are true:
1. That system doesn't have the info it needs and locks up waiting for someone to kindly send it along
2. The opposite; That system gets loving HADOKEN'd with a poo poo-heap of data, most of it totally superfluous, and has to dig through it with a fine-toothed comb to pull out a couple params

In my experience writing game code, this is much harder to get right than most other types of applications, for two reasons, which form a deadly binity:
1. Game code is inherently stateful
2. That state needs to be analyzed, compared with player input, altered, and bundled up into a frame that the video card won't choke on, as fast as loving possible.

You can't wait. If you do, you block the main update loop and boom, the game locks up, chugs, and the hapless player thinks "the gently caress is this poo poo?" Every compute cycle is precious.

A good SC example is when a ship spawns on the pad I'm standing on. Literal megabytes of unfathomably complex data structures describing every nuance of every component of the overdesigned fidelity chariot blast into your game client like the loving Kool-Aid Man, sending waves of panic and abject terror through every corner of your operating system.

Now, let's think about what happens here. This is massively over-simplified, and I added some details to help explain how this data is used, but when some rear end in a top hat spawns an Idris, the server will send you a hulking data structure that looks something like this:

code:

{
  entityType: ship,
  name: Idris,
  model: models\ships\idris\chassis\idrisChassisModel.dat,
  position: {x: 2910, y: 99, z: 194729},
  positionType: world,
  components: [
    {
      entityType: mainEngine,
      name: idrisMainEngine01,
      model: models\ships\idris\engines\idrisMainEngineModel.dat,
      position: {x: -20, y: 0, z: -500},
      positionType: rel
    },
    {
      entityType: rcsThruster,
      name: idrisMainEngine,
      model: models\ships\idris\engines\idrisMainEngineModel.dat,
      position: {x: 20, y: 0, z: -500},
      positionType: rel
    },
    {
      entityType: outerDoor,
      name: idrisOuterDoor001,
      model: models\ships\doors\idris\idrisOuterDoorModel.dat,
      position: {x: -150, y: 20, z: 200},
      positionType: rel
    },
    {
      entityType: outerDoor,
      name: idrisOuterDoor002,
      model: models\ships\idris\doors\idrisOuterDoorModel.dat,
      position: {x: 150, y: 20, z: 200},
      positionType: rel
    },
    {
      entityType: ramp,
      name: idrisMainRamp,
      model: models\ships\idris\ramps\idrisMainRamp.dat,
      position: {x: 150, y: 20, z: 200},
      positionType: rel
    },
... etc

Every one of those "components" are separate entities with their own 3d model. Each one has to be unraveled and loaded into objects (unmarshalled), their 3d model information retrieved from disk and loaded into ram/videoram, assembled according to their relative position, and plonked down into the game world at so-and-so position. As you can imagine, the more poo poo you have to unravel and load, the longer it takes. This is what pisses me off so much about Chris Roberts and his "FIDELETY" obsession. There is a very clear point where there's just too much information to process and your game locks up, the servers poo poo themselves, and the whole thing collapses under its own weight.

So what do you do? Well, you can make the ships simpler, which ain't gonna happen in a million hand-waving lifetimes, or you can defer the processing in order to unblock the main update loop. But that adds complexity, and now you have a state problem. Is the ship there or isn't it? Do I load each entity in its own thread? Well, how do I know when the ship is "assembled?" Surely some will load faster than others which means each ship component will "pop in" when it's good and god drat ready. And do you really think that'll fly in The Chris Robert Fidelity Funhouse? OK, so do I wait for every component's model to load in memory before it's allowed to visually spawn? Well if so, now every component has to report its state to some main-brain statekeeper who stands there with a clipboard checking boxes, then says yep, everyone is present and accounted for, let's glue all these 3d models together and start rendering it. What if we need to add a Hairy Roberts Drinkblaster 8000 to the bridge? How many lines of code will that touch?

This is why SC is getting worse, not better. They barely know what each system will do, and they' haven't even considered how they will communicate. Chris and his ramshackle crew of "game designers" are jamming panicky, poorly-conceived features down the devs' throats, who are forced to plop brittle, rushed //TODO: Fix This code into this witch's steaming poo poo cauldron. And man, I don't need to tell you, it's boiling over.

And so Star Citizen the computer program is just getting worse, and worse, and slower, and buggier, and choppier, and crashier as the bloated, abominable kludge slowly grinds to a halt and eats itself like Pizza the Hut.

This all happened because CIG did it full-on gently caress backwards. Your game designers need to have a really solid idea of not only what the systems are, but how the systems logically interact in order to build a gamified, cohesive logical flow that results in a fluid, contiguous causal map that resembles a game. You need to strip your features of all fluff, avoid details like the plague, keeping them simple, stark, and easy to understand. You need to build and assemble them as quickly as possible so you can prove your concept, and adjust the design when your assumptions don't all come true. Then you iterate, redesign, re-write, and hopefully, if you kept things simple, this isn't a massive undertaking. Code has to be designed to be flexible, but only flexible in the right ways. Too much flexibility kills your code because it's easier/cleaner to write something concrete. Death by a thousand ifs. And it really, really helps when you can do this without having to waste time on premature minutiae, trillions of polygons, sizzle-reel polish, drink machines, jacket layering, loving ARGON, etc.

Now the final coup-de-grace, which brings it home to my original point: Even if you do all this right and keep it simple, things that look simple on paper often blow up when you start coding. Simple components (in this case, "game systems") can fall apart at the seams when they have to start playing with others. But CIG doesn't have this problem, because they've never done anything simple. They still don't even know what their game systems are supposed to do, let alone how to code them individually, let alone how to assemble them into a working game, let alone how to make that game fun.

In closing, Star Citizen is not good, it's not bad. It's nothing. A huge. loving. Nothingburger.

Toops posted:

Thoatse posted:

https://i.imgur.com/9iZkoPG.gifv

Toops posted:

Now the final coup-de-grace, which brings it home to my original point: Even if you do all this right and keep it simple, things that look simple on paper often blow up when you start coding. Simple components (in this case, "game systems") can fall apart at the seams when they have to start playing with others. But CIG doesn't have this problem, because they've never done anything simple. They still don't even know what their game systems are supposed to do, let alone how to code them individually, let alone how to assemble them into a working game, let alone how to make that game fun.

In closing, Star Citizen is not good, it's not bad. It's nothing. A huge. loving. Nothingburger.

Toops posted:

A good SC example is when a ship spawns on the pad I'm standing on. Literal megabytes of unfathomably complex data structures describing every nuance of every component of the overdesigned fidelity chariot blast into your game client like the loving Kool-Aid Man, sending waves of panic and abject terror through every corner of your operating system.

Streetroller posted:

Man I gotta be honest.
I don't even think I can take the hate of this poo poo.

It's not that it surprises me or that I can't handle it on a personal level, but it's that those sick individuals are a surrounded by the disabled in their real lives.

This is how they really think? It's disgusting to think about because I've met angels and saints compared to me with disabilities -- and I've seen those people get taken advantage of by assholes like that.

I dropped literal tears for those people. Not trolling, it makes me want to vomit.

Toops posted:

code:

 {"nitrogen": 0.7809, "oxygen": 0.2095, "orgone": 0.0093, "carbonDioxide": 0.0004}

Brazilianpeanutwar posted:

Brian may's let himself go.....

Mangoose posted:

Can you even imagine how bad these people must feel about themselves already when comments like theirs don't even make a blip on their emotional radar? Imagining their vast depression is MY snuggie.

Or they could just be idiots, I guess. Hateful, lovely sociopaths, but in that case we can always take comfort in the fact that they're getting scammed out of all their money by a loving thumb

Streetroller posted:

Man I gotta be honest.
I don't even think I can take the hate of this poo poo.

It's not that it surprises me or that I can't handle it on a personal level, but it's that those sick individuals are a surrounded by the disabled in their real lives.

This is how they really think? It's disgusting to think about because I've met angels and saints compared to me with disabilities -- and I've seen those people get taken advantage of by assholes like that.

I dropped literal tears for those people. Not trolling, it makes me want to vomit.

Toops posted:

Nice post, and I'll just add this: Even if your feature design is simple, such as

code:

{"air": 1.0}

Instead of

code:

 {"nitrogen": 0.7809, "oxygen": 0.2095, "argon": 0.0093, "carbonDioxide": 0.0004}

that in itself doesn't automatically make the code simple. See folks, the hard part of programming isn't writing code that does a thing, it's the code that glues them all together, sends messages between all the different systems, and generally makes them work in concert to form a cohesive system, so that every function knows what to do, when to do it, and has the information it needs when they get called on.

It doesn't take programming experience to know that SC's code is a colossal goat-gently caress in this regard. You can feel it. Your intuition knows something is wrong down in the guts. Overall low framerates, massive game locks on the order of seconds, ridiculous collision/clipping issues, unresponsive UI, unresponsive actions (ahem doors, ramps), poor maintenance of state (doors and ramps again), etc. The engine is choking and sputtering like an old lawnmower that sat out in the yard naked all winter, because the information is poorly manicured, and the inter-system messaging is hosed.

If you're interacting with a system in SC, chances are 1 of 2 things are true:
1. That system doesn't have the info it needs and locks up waiting for someone to kindly send it along
2. The opposite; That system gets loving HADOKEN'd with a poo poo-heap of data, most of it totally superfluous, and has to dig through it with a fine-toothed comb to pull out a couple params

In my experience writing game code, this is much harder to get right than most other types of applications, for two reasons, which form a deadly binity:
1. Game code is inherently stateful
2. That state needs to be analyzed, compared with player input, altered, and bundled up into a frame that the video card won't choke on, as fast as loving possible.

You can't wait. If you do, you block the main update loop and boom, the game locks up, chugs, and the hapless player thinks "the gently caress is this poo poo?" Every compute cycle is precious.

A good SC example is when a ship spawns on the pad I'm standing on. Literal megabytes of unfathomably complex data structures describing every nuance of every component of the overdesigned fidelity chariot blast into your game client like the loving Kool-Aid Man, sending waves of panic and abject terror through every corner of your operating system.

Now, let's think about what happens here. This is massively over-simplified, and I added some details to help explain how this data is used, but when some rear end in a top hat spawns an Idris, the server will send you a hulking data structure that looks something like this:

code:

{
  entityType: ship,
  name: Idris,
  model: models\ships\idris\chassis\idrisChassisModel.dat,
  position: {x: 2910, y: 99, z: 194729},
  positionType: world,
  components: [
    {
      entityType: mainEngine,
      name: idrisMainEngine01,
      model: models\ships\idris\engines\idrisMainEngineModel.dat,
      position: {x: -20, y: 0, z: -500},
      positionType: rel
    },
    {
      entityType: rcsThruster,
      name: idrisMainEngine,
      model: models\ships\idris\engines\idrisMainEngineModel.dat,
      position: {x: 20, y: 0, z: -500},
      positionType: rel
    },
    {
      entityType: outerDoor,
      name: idrisOuterDoor001,
      model: models\ships\doors\idris\idrisOuterDoorModel.dat,
      position: {x: -150, y: 20, z: 200},
      positionType: rel
    },
    {
      entityType: outerDoor,
      name: idrisOuterDoor002,
      model: models\ships\idris\doors\idrisOuterDoorModel.dat,
      position: {x: 150, y: 20, z: 200},
      positionType: rel
    },
    {
      entityType: ramp,
      name: idrisMainRamp,
      model: models\ships\idris\ramps\idrisMainRamp.dat,
      position: {x: 150, y: 20, z: 200},
      positionType: rel
    },
... etc

Every one of those "components" are separate entities with their own 3d model. Each one has to be unraveled and loaded into objects (unmarshalled), their 3d model information retrieved from disk and loaded into ram/videoram, assembled according to their relative position, and plonked down into the game world at so-and-so position. As you can imagine, the more poo poo you have to unravel and load, the longer it takes. This is what pisses me off so much about Chris Roberts and his "FIDELETY" obsession. There is a very clear point where there's just too much information to process and your game locks up, the servers poo poo themselves, and the whole thing collapses under its own weight.

So what do you do? Well, you can make the ships simpler, which ain't gonna happen in a million hand-waving lifetimes, or you can defer the processing in order to unblock the main update loop. But that adds complexity, and now you have a state problem. Is the ship there or isn't it? Do I load each entity in its own thread? Well, how do I know when the ship is "assembled?" Surely some will load faster than others which means each ship component will "pop in" when it's good and god drat ready. And do you really think that'll fly in The Chris Robert Fidelity Funhouse? OK, so do I wait for every component's model to load in memory before it's allowed to visually spawn? Well if so, now every component has to report its state to some main-brain statekeeper who stands there with a clipboard checking boxes, then says yep, everyone is present and accounted for, let's glue all these 3d models together and start rendering it. What if we need to add a Hairy Roberts Drinkblaster 8000 to the bridge? How many lines of code will that touch?

This is why SC is getting worse, not better. They barely know what each system will do, and they' haven't even considered how they will communicate. Chris and his ramshackle crew of "game designers" are jamming panicky, poorly-conceived features down the devs' throats, who are forced to plop brittle, rushed //TODO: Fix This code into this witch's steaming poo poo cauldron. And man, I don't need to tell you, it's boiling over.

And so Star Citizen the computer program is just getting worse, and worse, and slower, and buggier, and choppier, and crashier as the bloated, abominable kludge slowly grinds to a halt and eats itself like Pizza the Hut.

This all happened because CIG did it full-on gently caress backwards. Your game designers need to have a really solid idea of not only what the systems are, but how the systems logically interact in order to build a gamified, cohesive logical flow that results in a fluid, contiguous causal map that resembles a game. You need to strip your features of all fluff, avoid details like the plague, keeping them simple, stark, and easy to understand. You need to build and assemble them as quickly as possible so you can prove your concept, and adjust the design when your assumptions don't all come true. Then you iterate, redesign, re-write, and hopefully, if you kept things simple, this isn't a massive undertaking. Code has to be designed to be flexible, but only flexible in the right ways. Too much flexibility kills your code because it's easier/cleaner to write something concrete. Death by a thousand ifs. And it really, really helps when you can do this without having to waste time on premature minutiae, trillions of polygons, sizzle-reel polish, drink machines, jacket layering, loving ARGON, etc.

Now the final coup-de-grace, which brings it home to my original point: Even if you do all this right and keep it simple, things that look simple on paper often blow up when you start coding. Simple components (in this case, "game systems") can fall apart at the seams when they have to start playing with others. But CIG doesn't have this problem, because they've never done anything simple. They still don't even know what their game systems are supposed to do, let alone how to code them individually, let alone how to assemble them into a working game, let alone how to make that game fun.

In closing, Star Citizen is not good, it's not bad. It's nothing. A huge. loving. Nothingburger.

Streetroller posted:

Got depressed, went bar hopping... Picked a fight with a local.

I got footage.
https://www.youtube.com/watch?v=llVGO-os2s4

Streetroller posted:

Got depressed, went bar hopping... Picked a fight with a local.

I got footage.
https://www.youtube.com/watch?v=llVGO-os2s4

SomethingJones posted:

lol

Either he knew that you were a totally cool guy or that you had some secret controls to dispense electricity at him

Hav posted:

For fork's sake.



I suck at matting.