Mirificus posted:

Mirificus posted:

Mirificus posted:

VictorianQueerLit posted:

Yeah, also don't forget that whenever anyone would mention how good Freespace 2 was or recommend it he would lose his mind because he thought Crobbler's 4th or 5th lovely cinematic cutscene game was a masterpiece instead so he would rant at length about how lovely and awful Freespace 2 was.

Not only did he have no qualifications to work for CIG other than slapfighting on the internet he is also terminally retarded and can't recognize a good space sim.

Mirificus posted:

VictorianQueerLit posted:

I think it would be funny if discovery uncovered all of the emails Ben was sending to Chris. He already thought the guy cured his blindness and spent years throwing it in other nerd's faces that his idol had actually communicated with him.

Daztek posted:

https://i.imgur.com/NkQNzQ3.gifv

GreenElephant posted:

I've been seeing a lot of "Hey, only 20 people are working on ships, the rest are working on mechanics/etc so it ain't hurting speed at all, fools" recently and want to add my two cents on this.

Dear citizens reading this, it isn't true. In fact, the 50+ half done flyable ships are a constantly increasing millstone around CIG's neck. In addition to the hours of design, modeling, tech debt, QA, textures and effect works on the ships themselves, here are the bigger problems caused by the continual required reworks:

Code complication: Every time a coder makes even a small change in a ship mechanic, for example, changing how thruster values work or adding a new tag to a ship zone this means going through EVERY old ship and updating, testing, and merging into the latest version. This probably means hours per ship for even the smallest change and much more for larger modifications.

Backward asset compatibility: Retouching & testing every ship asset to fix something before a release usually doesn't happen as it's too time consuming, especially when older ships won't even export with the latest version of the tools because nobody has updated it to use the new 3.0 control panels or whatever – so the coder is asked to continue supporting the "old way" as well.

You end up with multiple versions of code doing the same things, item system v1, v2, etc. The code turns into unmanageable spaghetti because you can never make completely breaking changes unless you're prepared to release something with only a single ship or two being functional.

Unfortunately, releasing an update that doesn't include most ships (or having a year with no updates...) while baseline technology is still being figured out would make a big impact on funding, so can't do that.

Programmers start to avoid breaking changes completely and look for quick/cheap hacks that won't interrupt existing systems to avoid another re-work. Nobody wants to be the person to say “ok, we can fix collision, but we'll have to create a new collision mesh style for every room” so you get stuck in kind of a a local maxima where true engine fixes can't happen and you band-aide everything.

SPERMCUBE.ORG posted:

Look the point is CIG has a bridge to sell you.

trucutru posted:

Ok, found the blueprints!

Koil posted:

Daztek posted:

https://i.imgur.com/NkQNzQ3.gifv

Beet Wagon posted:

Man part of me wants to take that Montoya "Star Citizens would never do this" quote into photoshop and just surround it with a cloud of all the loving insane poo poo SC superfans have done and said over the years. Of course, I've already stared into that abyss enough to go a little crazy, so maybe diving right back in isn't the best bet lol

Daztek posted:

https://i.imgur.com/NkQNzQ3.gifv

Pixelate posted:

(I don't speak performance overlays. Does that one say the guy has 17 cores to achieve kinda 30fps?)

GoingPostal posted:

No? I was just curious if Pocket Casts was missing episodes or something. VC was talking about other podcast episodes and I was wondering if there was a side podcast I missed.

Foo Diddley posted:

"They don't charge $1000 to access that page, they just don't let you access that page until you've spent $1000"

What a fuckin' idiot

ComfyPants posted:

Make sure you have a number of quotes equal to the number of people who voted to expand the scope, that way you can prove that it is indeed the majority of backers.

Tippis posted:

A thousand pages too late, but just to add to this, I'll copypaste an old effort post of mine answering a related but slightly different question:


Pretty much… time to effort post.

Level of Detail (LoD):
The method of using different art assets depending on the distance between the viewer and the object they're looking at. Be it sprites or 3D models or textures, lower-detailed ones are used at larger distances because any more detail will just be squished together to a size smaller than a pixel, and be lost. This method has been around for the last 30 years.

Serialised variables:
Serialisation is the method of turning a complex data structure into a much more simplified series of data points. Instead of dumping an entire block of memory onto the client, you compact it into something much mor terse and relevant.

You may have a ship (partially) stored in memory as:

code:

0000AB12_Ugly Ducking____________________006E_
0000000000003039_000000000000D431_0000000000002F59_
3CE4186D399E326B_308D6E044A0A2E92_009BE179CA492B01_

etc etc etc.
…where the different parts are things like ship ID, name, type, x/y/z coordinates, memory coordinates for fitted equipment and so on.

That's a whole bunch of ugly junk to send, and those last bits won't even be accurate because they depend on how the equipment is stored in the server's RAM — the client will be completely differently set up. You have to turn it into something that's not just light-weight enough for transmission, but also actually useful for the client. So you “serialise” it — turn it into a data series that the client can use — along the lines of:

code:

43794,Ugly Duckling,110,12345,54321,1212, …

[and then some serialisation of the different equipment]
The client knows which parts are which, and stores them into memory in a way that's suitable to it, and life goes on.

This is simply a different way of saying that the way data is stored internally is not how it is (or should be) transmitted — it's an idea that is as old as computers, and I'd be surprised if this was news even to Ada Lovelace.

Incidentally, formats like XML or JSON, that you may have heard of in relation to this, are serialisations of variables — they let you express complex objects in a very structured way. The problem is that their focus is on being easy to read for humans and on being interoperable between different software, not on being efficient. So for a controlled and fast-paced environment, you really want something else. Hence why Cryengine's internal XML-based structures make for a very poor basis for syncing objects over a network, and why you had this guffaw a few years back where each ship in SC required megabytes worth of data to be sent to the client — they were dumping the entire inefficient XML structure on the poor users.

Serialised variable culling:
That's all nice and well, but do you really need all that data to be sent, even in a serialised format? After all, the equipment won't really change that often, and even positions may be static. So to reduce traffic even further, you devise a way to inform the client what you're actually sending and what it should just retain based on old data. This may entail either skipping entire variable series, or skipping parts of a series. Either way, you can now use different update intervals for different variables, and the trick is more in figuring out what needs to be processed when — the rest is “culled”, that is, deemed not relevant for now and thus not processed.

Where, before, you might send a compact data structure of the format Ship ID, name, X, Y, Z, equipment data, you can now just send something along the lines of
[FONT=Courier New]ID=43794,X=12355[/FONT]
…because all that happened between the old update and the new is that our Ugly Ducking ship changed its x-position, and we detected that and skipped all other variable processing and transmission.

Again, a thoroughly ancient technique, but since the whole detection of what needs to be updated creates a bit of processing overhead, it may in some cases be easier and faster to not do it at all. It's a balancing question of, does the lowered transmission and (potentially) reduced processing rate warrant that extra book-keeping overhead?

Bind culling:
Even with that reduced and simplified traffic, the question remains: do we actually need to send anything at all to the client? For the vast majority of stuff going on in a space game, the answer is a resounding “no”. They're too far away to have any impact, or they're just in the wrong location, or of the wrong type. A ship that's half a parsec away is not relevant to you; a character that sits inside a different station than yours isn't relevant to you; the colour of Miles Eckhart's third jacket isn't relevant to you (because while he's close-by, he's a walking-around-mode character and you're current piloting a ship).

So you decide that there needs to be no connection between some object the server knows about, and the client. You don't “bind” that object — i.e. you don't make it a part of the list of things you need to update the client on — and as objects move in and out of relevance, you constantly check and cull that list of objects and in many cases don't even get to the step where you have to bother with serialisation and culling of object variables.

This is a concept that is, in gaming at least, 20+ years old. Any game that offers multiplayer and that supports some kind of division of the world into zones does this to some extent. Well… most of them. Cryengine is (in)famous for having particularly non-granular culling methods — all clients get the same updates on all the same objects, and screw their individual preferences…

Object container:
An easy way to figure out what's relevant and not to the client is to group objects together and have a rule that determines when the entire group as a whole becomes relevant. This means you no longer have to check each individual object — a relevance test that might previously have required thousands of checks now require only one. CIG has dubbed these groups “object containers”.

To aid the process further, one group may in turn contain other groups, each with their own relevance rules. That big old station might be an object container, and the rule determines that you should be kept updated on it because you're close enough out in space. The station holds a mess hall that might be an object container, but its rule determines that you can ignore it, because it's inside the station container, and you're (still) out in space. The mess hall container might then have all kinds of chairs and plants and whatnots inside it, but none of that matters, because the mess hall itself is deemed irrelevant to you. So all the server keeps you updated on is the station and maybe the fact that it offers mess hall services — but the exact details of those lower-level distinctions are kept from you. The station object is bound; the mess hall object (and everything in it) is culled.

This is a more complex version of that same old zoning technique that has been around for decades. Indeed, it is really just an extension of the notion of having “sublevels” — going in and out of a house in anything from Zelda to Far Cry.

Object container streaming:
The problem now is one of transition. How do you go from not knowing or caring about the contents of a container to actually doing so? The classical method would be a hard loading screen: everything outside is dumped and deemed irrelevant; everything inside is loaded instead, and there you are. If we want a smooth, seamless transition, things become trickier.

As a container's content is suddenly deemed relevant to you, the poor client will already be shocked by the sudden mass of data dumped in its lap as all those new objects are suddenly bound to you, and as all their variables have to be set up before variable culling can kick in and start doing its job. On top of that, you also have to load all the art assets and draw the darn thing on screen. Loading screens hide all that, so what do you do if you want to avoid the appearance of loading, and also don't want to just have things pop into existence in a really ugly way?

You need to figure out 1) how to set up and build the container in such a way that, by the time the player can actually see and interact with it, that part has already been loaded quietly in the background (the eponymous “streaming”), and 2) when the moment of transition is, so the loading can begin. Many games, in particular open-world ones, habitually do this these days. The Elder Scrolls games did it for the overworld; flight sims have had this kind of “patch-wise appearance” of the world since roughly forever, where entire neighbourhoods would suddenly increase detail; you see it in ED if you stay away from using FSD — the main change over the years is how well the game hides it, in particular in the face of increasing hardware that lets you see tiny details at long distances more clearly, which tends to reveal the tricks used.

A trivial case might be the approach to a station, where the whole thing is built hierarchically from the outside in: as you approach, the game quickly gets more detailed updates on the location of the station, and it loads the outer hull model and textures. The previously mentioned LoD:s offer a logical stepping ladder of increased detail, and in between each such step, more and more details on the internal structure of that station is revealed, piecemeal, to the client.

It may go something like this:
1. At a bajillion km, inform the player that there's a station nearby, hand over the coordinates and load a low-LoD model.
2. At a jillion km, open up the object container and start building the outside of the station — receive data and load the models for docking pads, antennas, wild off-the-rails spinny things etc. Also, pick a higher-LoD model for the station.
3. At a thousand km, start setting up the decorative stuff since it'll be coming into view any second now — receive data and load models for lights, higher-resolution textures and shaders, and also (again) higher-LoD models for the previously loaded objects.
4. At ten km, it may seem reasonable to suspect that the player is actually going to this station, so open up lower-level containers. Receive data and start loading models for, say, the airlocks/docking bay and other areas the player might see and access.
5. When the player lands, fully open up the station object and start initialising and loading all the rooms inside, and maybe even pre-load some decorations that will appear a bit deeper into the structure.

At every step, keep as short a list as possible on what art assets need to be loaded, and what object states need to be tracked. Anything that is too deeply nested into various object containers is culled; anything on a higher level is loaded based on some predefined priority list of what the player will see/interact with first.

This ties together both the network processing and the graphics processing since the stepping-up of the level of detail on some objects (and stepping down for many others) will happen in lockstep. Even so, one actually has very little to do with the other. The streaming of art asset data into memory is separate from the streaming of object data to the client, but it will look really ugly if the two happen out of sync.

Blue On Blue posted:

Can go along way