I'm sure why Space Sim enthusiasts are expected to be interested in behind-the-scenes implementation details, but almost all the CIG videos (not Loremaker's or the ones where they sell you ships) are about how hard it is to make a computer game, not about the features of the game, so it helps to understand what they're wittering about.
I'm sure why Space Sim enthusiasts are expected to be interested in behind-the-scenes implementation details, but almost all the CIG videos (not Loremaker's or the ones where they sell you ships) are about how hard it is to make a computer game, not about the features of the game, so it helps to understand what they're wittering about.
I'm sure why Space Sim enthusiasts are expected to be interested in behind-the-scenes implementation details, but almost all the CIG videos (not Loremaker's or the ones where they sell you ships) are about how hard it is to make a computer game, not about the features of the game, so it helps to understand what they're wittering about.
Now that you are at it - does SC has a lore? So far I haven't seen any video about that, only -as you mention- how hard it is to make the game, and about the dreams what you'll be able to do.
Now that you are at it - does SC has a lore? So far I haven't seen any video about that, only -as you mention- how hard it is to make the game, and about the dreams what you'll be able to do.
You're gonna regret asking that. Check for "loremaker" videos on their site and prepare to be amazed - it's part of what made me start feeling this was all an intentional con - you can't be serious about making a proper game of this scale and still have all your lore at the level of teenage scribbles on the back of exercise books.
Now that you are at it - does SC has a lore? So far I haven't seen any video about that, only -as you mention- how hard it is to make the game, and about the dreams what you'll be able to do.
There was (and probably still is) masses of lore on the RSI website. Far too much of that, and far too many theoretical gameplay mechanics for an ordinary mortal to wade through. There's a story about a war with an alien race that I believe is loosely modelled on the Second World War. The reason Star Citizen starts in 2942 is that that's the thousandth anniversary of Pearl Harbour. It's not so easy to find the lore nowadays, though.
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: 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: 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 ID=43794,X=12355
…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.
Someone more 'versed in this than me - what is going to happen in SC if I have to eject in space but I don't want to just float around waiting for someone to come pick me up?
Someone more 'versed in this than me - what is going to happen in SC if I have to eject in space but I don't want to just float around waiting for someone to come pick me up?
Death of a Spaceman.....
"If you lose a dogfight and your ship is going to blow, you have a few seconds to eject. If you manage to eject safely and someone doesn’t blast your ejected avatar, you won’t have even used a “life”. You’ll end back up at the last planet you docked on, with a new ship courtesy of SystemWide Insurance. You’ll have lost your cargo and any upgrades (unless you managed to insure those and you were destroyed in a system with a risk level at or below your insurance rating)
If you don’t manage to eject in time, or someone blasts your ejected character (which carries a harsh penalty if you do this in “civilized” space), your badly charred and almost dead avatar is recovered and you wake up in a med bay."
Someone more 'versed in this than me - what is going to happen in SC if I have to eject in space but I don't want to just float around waiting for someone to come pick me up?
You die and have to pay for a new avatar.
With your previous avatar, everything you bought for it will be lost, too. Clothes, guns, pocket money, etc. - so you'll have to rebuy that as well.
Death of a Spaceman.....
"If you lose a dogfight and your ship is going to blow, you have a few seconds to eject. If you manage to eject safely and someone doesn’t blast your ejected avatar, you won’t have even used a “life”. You’ll end back up at the last planet you docked on, with a new ship courtesy of SystemWide Insurance. You’ll have lost your cargo and any upgrades (unless you managed to insure those and you were destroyed in a system with a risk level at or below your insurance rating)
If you don’t manage to eject in time, or someone blasts your ejected character (which carries a harsh penalty if you do this in “civilized” space), your badly charred and almost dead avatar is recovered and you wake up in a med bay."
Ah cheers. Elsewhere someone's trying to suggest this is a new and awesome gameplay opportunity where you will float in space begging to be rescued and praying it's by someone friendly
Ah cheers. Elsewhere someone's trying to suggest this is a new and awesome gameplay opportunity where you will float in space begging to be rescued and praying it's by someone friendly
Elsewhere someone's trying to suggest this is a new and awesome gameplay opportunity where you will float in space begging to be rescued and praying it's by someone friendly
Someone more 'versed in this than me - what is going to happen in SC if I have to eject in space but I don't want to just float around waiting for someone to come pick me up?
I wonder how long before a CRobber doll comes out?
As an aside, I did find the "prostrates in deference" comment way more amusing than I should have done, especially considering the way the backers have been treated.
![[VR] optimal_909](https://forums-cdn.zaonce.net/data/avatars/m/109/109067.jpg?1553781733){kind=avatar}
![[VR] Merkir](https://forums-cdn.zaonce.net/data/avatars/m/141/141091.jpg?1553527154){kind=avatar}
