LurkNautili
-
Posts
150 -
Joined
-
Last visited
Posts posted by LurkNautili
-
-
It's not twitch-based and it's not Simulation. FPS games have simulations, they simulate gravity on bullet drop and momentum loss that way and the Projectile itself a PHYSICAL presence in the game.
Not all FPS games by any stretch of the imagination. For example, Quake is pure hitscan without any such simulation, and CS:GO is a game with a model similar to yours, where you have a cone-of-fire inaccuracy model.
What I am describing, is an emulated version of that. It is emulation of FPS. There are not projectile bullet drop, there is Target's Speed and Muzzle Velocity, then it comes down to the Surface Area of the Target that is exposed to you in comparison to your Cone of Fire at such a distance, then how much your skills reduce your Cone of Fire to beigin with and a weapon's quality on Damage Bubble Dispersinon.
There's no Simulation in this. Simulations cost, Emulations are simple stat comparisons.
What you're describing sounds exactly the same as a typical arcade type FPS shooter where ballistics aren't simulated. The problems the devs are highlighting as reasons not to do this come from the fact that firing events have to be networked between clients and servers, and the way they're doing their clustering or octree division of space into cells results in more delay from further away players and with less frequent updates.
Mind you, personally I've argued that you could probably still implement at least some semblence of a twitch shooter on top of such architecture, but I've yet to receive a response from the developers to my question post regarding this topic, so I cannot say for certain that it could be done. But some sort of compromise could probably be arrived at.
Rather, what the developers seem to be aiming for at present is a system where you merely "aim" at a target merely to indicate the entity/construct which you wish to fire upon, and then instead of doing ray-intersections and interpolation and lag compensation and all the other funky business that you have to deal with in shooter netcode they'd just do some kind of heuristic approximation of damage based on stats and maybe relative acceleration and such. So in that model there wouldn't be any "cone of fire", per se, but rather a probability value calculated server-side. This could, of course, be represented by a circle on the players screen to give visual feedback about the probability but the actual math running server-side wouldn't have anything to do with cone or ray intersections.
And again, I'm not for this personally and will be sad if we can't have something that at least resembles twitch shooting, at least in avatar vs. avatar combat (ships I can believe would have automated targeting so it won't wreck my immersion as much).
WoW does this. EverQuest does this. Every MMO that utilises a form of Lock-on does this when it comes to Area of Effect Skills.
If you cast a Flame Strike in WoW, you click on the skill, then move your cursor to an area you want the Flame Strike to hit, then cast the spell for two seconds at the expense of Mana.
That in DUAL, would be in the context of scanning the target, then locking on the target for a moment or two to reduce your "AoE" Cone of Fire, then firing.
I would not call WoW as a First Person Shooter. If you did because of the aforementioned mechanic, then you clearly missed the memo on what an FPS simulated physics' grid is.
As someone with some experience in reverse engineering MMORPG netcode, I feel fairly confident in saying they don't use CoF. Rather, they keep track of player positions server-side (with noticeably lower frequency than FPS, usually, mind you), and when a client fires an AoE spell, they create a circle (basically a cylinder volume) on the ground and simply test intersection with that, which is a really fast and inexpensive process, also it's less time-sensitive than shooting bullets -- as well as less frequent -- and it's precisely placed on the ground rather than being randomly placed based on some probabilistic spread. Also, lock-on attacks don't even have to involve dodgeable area of effect spells, which are actually kind of similar to FPS (in that they suffer from the same problem of having to maintain consistency of events in different clients, like whether I actually dodged a spell on your screen or not). In its simplest form a spell is just something that either hits or doesn't based on some evasion change and hasn't got to worry about netcode. A game like guild wars is surprisingly similar to FPS in terms of what the servers have to do, and as such I feel the devs are just as unlikely to implement your type of avoidable cone/circle of fire AoE attacks as they are to implement FPS.
-
First, there will be warpspeed, so you won't have to travel between planets for 3 to 5 hours with sub-light speed.
Yes, exactly the kind of compromise with realism I was refering to. So since you're warping, you get to travel at relativistic velocities without having to deal with relativistic effects. Yay.
Think more like top acceleration being 0.2 c , and that's a very generous acceleration as far as my expectations go.
Speed, not acceleration. And yeah, maybe, but it doesn't really matter.
Third, the way their servers update, if you were to go at - for the sake of arguement - 0.99999999999 c, a person looking at you 1,000,000 kilometers away, would see you moving very very very fast on their perspective and would have no way of predicting your position with accuracy for an intercept as you would be practically move to fast for them to know where you are at. That's the closest thing to relativity in a game, as NOTHING in simultaneous on the server, except for people and objects that are nearby. Everything else, has a time delay. So, if you were to start turning going a 0.9999 c, they observers would not be able to tell until you were already turning and heading their way.
That's not the kind of simultaneity I'm talking about. Additionally, the difficulty in "leading" targets doesn't come from velocity (which is trivial to compensate for with simple extrapolation), but from acceleration (for which you can only have probabilistic models to predict with, in the case of non-formulaic, stochastic motion) and other, higher derivatives of position with respect to time (jerk, snap, etc.). A computer can predict a perfect shot on a target moving at constant velocity, and a human operator of the weapon can arrive at it with heuristically (shoot too far ahead, behind, eventually hone in).
My guess is also that light speed will not be modeled as a finite quantity. That is to say, that the only delay between an explosion happening on the other side of the solar system would be the time it takes from it to arrive from the server responsible for simulating the explosion to your client machine, i.e. less than a couple hundred milliseconds. Mainly because it would not yield much benefit (as far as I can tell) and would add some overhead.
Fourth, the maneuverability and inertia play a role on ship to ship engagements and pilot skill being needed for a 6 DoF cruise control of a ship. Without inertia, mass and speed become irrelevant, and ship builders do not have to compensate for anything, which can lead to banana shaped ships. Why put effort and thought in thrusters placetments for spins and turns? So yeah, those micromanagements in Lua do not only come into play on cruise controls, but also on regulating how much a ship can turn, given how many G the crew could tolerate depending on inertia, either an enclosed frame as I suggested, or the unified field shenanigans which can be emulated via the "Artificial gravity" route. The point is, earth applies gravity to all of us, but last I've checked an earthquake will sure as heck shake me around. Same deal with ships. They gather speed, hence mass and they tremble due to that, so the gravity idea can't really work, cause it would mean that the ship's part can't be moved by any external force, hence, indestructible ship, like the conundrum of the Stark Trek inertial dampeners, that for some reason, make the ship shake
If you were to maneuver around in a ship, going at 0.1 c and begin to turn at an angle the ship shouldn't, the Lua scripts of the navigator would prohibit them from doing so. That's what te Lua are here for.I'm still not convinced you understand what inertia means, but regardless, I'm not advocating implementing inertialess (i.e. massless) ships. That's part of the reason why I corrected the usage of the term inertia and specified what I was talking about with inertial dampeners. The term "inertial dampeners" as it stands, is a misnomer -- the mechanism I described (also how it's used in popular culture) has nothing to do with inertia, per se. It is about applying acceleration uniformly, rather than only to, say, the back of a passenger (because they'll break down based on the sedimentary principle due to the force being applied as a pressure to the back rather than to every particle individually).
Your earthquake analogy is not applicable. What's a more apt example of the effect is how it feels to be in freefall in earth's gravitational field, versus how it feels to stand on the ground. You can feel the strain the force the ground is exerting on you to stop you from being accelerated by the field is causing to your tissue (compared to falling, where you feel no such strain at all). In free fall, while you're still being accelerated at 1g, you can't feel it, because the acceleration is being applied by a gravitational field (I won't confuse you any further by bringing relativistic interpretations into this so we'll just treat gravity as a force/field). Similarly, you could accelerate at 10-20+g if you got close enough to Jupiter, for instance, and that 10-20+g would feel like nothing so long as you were being accelerated by the field rather than by being pushed by an object (analogous to a rocket).
Also the whole "gather speed, hence mass" part is nonsense, if we're talking about inertial mass. What you're probably trying to get at is kinetic energy or momentum, which are different things entirely. And I've no idea where you called that indestructability thing from -- it's not a consequence of "inertial dampening", a function of the ship being applied inwards to its occupants, rather than to any parts of the ship itself -- and even if it was, external forces would still cause the same kinds of differentials that accelerating in a ship without dampening would cause, i.e. damage.
In my opinion, the Devs have an excuse for making quality of materials that reduce the effects of G-forces via the Unpure Kyrium explanation of the lore. It would make miners and smelters create a cartel of Unpure Kyrium, it would allow good builders to shine and it would make pilots who know of their ships' limits distinguish themselves from the average nooblord. The Devs only need to make the engine figure out an enclosed voxel space of that material frame is meant to take less G-forces. Who knows, if they do that they would also be able to emulate atmosphere and depressurisation as well.
Yeah, whoever wrote the lore on Kyrium doesn't seem to understand physics very well either if they imply that somehow blocking gravitons from entering the ship (which is the only real consequence of having "graviton absorbing ship material" or whatever, is that these particles would be blocked from entering or leaving the ship, thereby limiting the effect of outside gravitational fields from affecting the occupants, which could be useful near a blackhole or other strong non-homogeneous gravitational fields where tidal forces become problematic) would save the occupants from the detrimental effects of acceleration by pushing, which it most certainly wouldn't, since other force mediating particles (gluons and photons mainly) could still move through the Kyrium hull, not to even mention the fact that the passenger-surface interaction doesn't work through the hull at all, it's decisively internal and hence completely independent of any particle absorbing effects the hull might have -- the force carrying particles would have no issue whatsoever effecting the particles of the passengers' surfaces in the normal, destructive way in high acceleration situations.
Putting all of that aside, however, I see no reason to just either forego simulating g-forces altogether or to add some sort of feathering effect based on how good your ship is or something -- and then give a physicist-friendly lore explanation for it (e.g. some BS about artificial gravitational fields somehow generated without lugging around actual planets with your ship -- still better than "graviton absorbing" at any rate).
-
There seems to be some confusion in this thread about the physics and terminology.
Inertia doesn't refer to motion or kinetic energy or whatever. Inertia is a property of mass, or in fact a numeric quantification of mass, that describes the propensity of the object possessing that mass to resist changes to its state of motion (i.e. resist acceleration, hence F = m * a -- acceleration due to a given force depends on mass, AKA inertia).
To me, the sci-fi term "inertial dampener", refers to a technology that allows e.g. passengers of a vessel to accelerate at rates that would otherwise injure them (squish them like pancakes, rip their cells apart and turn them into a paste like a centrifuge would, etc). This is achieved by creating a force field that uniformly accelerates the occupants (only force I know that does this to all matter equally is gravity, but for argument's sake lets say an EM field of some special construction) instead of squishing them forwards mechanically. This is more or less a given in a game that involves interplanetary travel within play-session-sized time frames (a trip to Mars in a few minutes or hours? Well, you could do it in maybe a day or so if you accelerated half way at 1g, and decelerated the rest of the way -- but if you wanted to do it in minutes you'd be exposed to hundreds of times the equivalent of earth's gravitational acceleration and ... you'd die ... so you definitely need dampening for that). Other compromises in realism will also have to be made when you consider you'd be traveling at notable fraction of the speed of light in doing that, and we really don't want to model time dilation and other relativistic effects (Right, guys? Given the fact that the game is being played in a more or less inertial frame of reference where simultaneity is a given? It wouldn't make for fun gameplay -- it should play more like a space opera than ultra-hard sci-fi).
On the other hand, hovering in place without user input, or bringing a moving ship to a halt on its own, represent completely separate mechanism, and refers to delegating the responsibility of applying force to the craft to an automatic control system rather than having a user micromanage thrusters individually. Given that the developers have already outlined roughly how ship building and scripting will work, and that in general we'll be allowed to program the behavior of elements such as thrusters and automate them to some degree, I can posit with pretty good confidence that it will be possible for individuals such as myself to create such automatic reaction control systems and the like at our leisure, and the OP needen't worry about it.
As for realistic Newtonian physics being involved in space travel, or motion in general -- I'm all for it. Sure it might be difficult for a layperson to grasp that you need to decelerate to stop in a vacuum devoid of friction etc. but the aforementioned control systems and scripting should allow for players who do understand physics to make crafts that are automated to a degree that they seem intuitive for a layperson to pilot. I think it would be cool and worthwhile to have the underlying physics to be realistic, and just allow the players to build a layer of abstraction on top of that to make ships behave more like what people are used to on earth, or at least make things easy to pilot.
-
What you're describing is essentially mathematically equivalent to FPS (raytrace with cone of fire). Haven't they already stated that they won't have twitch based combat mechanics? I mean as an FPS player I'd love nothing more, and I've argued for it in the past -- but as it stands the developers seem set on having a system where you merely lock on to targets (i.e. target acquisition, impact probability, etc. are hidden behind abstractions rather than being simulated FPS style), fire, and then have some statistics (like shielding, piloting skill or whatever) based math figure out location and severity of damage and so on.
-
[snip]
Yes, I concur. This is more or less my line of thinking as well. We can minimize the impact of any possible griefing by making it economically unfeasible as well as enabling players to forge systems to penalize such behaviors in whatever ways emerge as most effective and so on.
Your idea, as already discussed, is just not possible
His specific mechanics may be nonsensical, but overall the notion of collision damage isn't impossible at all, and a reasonable solution can be devised ... as previously discussed.
-
I disagree =\= stop talking
Similarly, I would argue against the notion that scrutiny is not in the spirit of suggestion topics. You have heard your fill users asserting that this isn't going to make it into the game. You have dodged the assertion that collision damage was sacrificed to the altar of stable multiplayer (despite that being the dev's reasoning for not incuding it).
I can't prove to you on a technical level that what you are proposing is infeasible, and you disregard feedback outside of the technical as not constructive.
It kind of sounds like your mind is made up, and as such it seems like there is nothing left to discuss.
PS: have you considered offering to volunteer for NQ and desing their collision mechanics for them? Having an extra pair of hands might alleviate the strain of building the game they actually said they wanted to make.
Edit: spelling
My point is, they don't need my help. These developers are smarter and more experienced than I am. If I can think of ways to implement, they can do that many times better.
I've already tried to give you a rough idea of the trade-offs involved, to steer the discussion back into the gameplay impact etc.
Ultimately, neither you, I nor anyone else outside NQ can prove or disprove the technical feasibility of this kind of mechanic.
So no, I haven't made up my mind, I'd just like to keep the discussion on topic, rather than focused on "dodging the issue" as you say, by asserting things about technical feasibility or making some grand, sweeping assertions about impacts on an abstract level, and then not addressing responses to those assertions.
[EDIT:]
I mean look, just present arguments for and against, let's not have this devolve into a sea of ad hominem.
I think it's a good idea because it would make the world feel more alive and immersive, it would add an element of skill (either in piloting a bad ship, or designing a ship well that's easy to pilot), and it would give people reason not to fly too risky.
So far the points I've read against it have been that it's not computationally feasible (I've demonstrated that at the very least, we need a developer to comment on that, as none of us can really determine this for sure -- but my semi-educated guess is that it isn't as bad as you think). And the other concern seems to be griefing. I think I've addressed both of these points -- if you have concerns with my responses, you should respond to my posts about these things rather than responding to the off-topic post I wrote for someone else. If you think there's some aspect of your message that I've glossed over, you'll have to point it out to me.
So can we stay on topic?
-
I'm currently working on a diagram of the model. I'll post in the next day or so hopefully. Then we can rip that apart until we have something that feels like it might be a viable back-end for DU. Then I will probably tinker with an implementation of it for performance checking and we can go from there.
Oh you're going way more ham on this than I am, or that I anticipated you'd be. Godspeed I guess. o.o
-
Dunning-Kruger was inspired by a study about a bank robber who thought that lemon juice would make his face invisible to security cameras because it's used as invisible ink. To go straight to the Dunning-Kruger effect is to assume that this guy is in the bottom quarter of the general population IQ-wise, which seems a bit much. It is true that nobody here knows your education and experience in gaming and game development. Would you care to provide us with your credentials?
The effect isn't about IQ, it's about the tendency of people to overestimate their grasp on a topic if they don't understand it well enough to know where the gaps in their knowledge are. I don't know where you got the IQ-connotation from, but that's not what it implies and that's not what I meant to convey either.
My whole point was not to target people's character (including IQ or credentials) but rather comment on the facts and structures in their posts. Are you deliberately misrepresenting what I said, or did you not read the block of text you're quoting?
I'm a software engineer with 17 years on the job and in my opinion, while realistic collisions would certainly make for better cinematics, there's a lot more to calculate than a simple bounce when two collision meshes intersect, and based on my experience in big data cloud environments (medical IT, not gaming), nobody can know what the server load would be unless we actually simulated 100,000 simultaneous collisions. And the amount of coding to get there would delay a lot of other deliverables, so it would be a considerable risk.
That was my point as well; we don't know if we don't try. I was just giving an oversimplified, first-order estimate. And I don't care who you are or what you do, as I've already stated.
[EDIT: my proposed model is actually on the post after the one you quoted, but still, we agree on the difficulty/impossibility of intuiting performance impacts of rough ideas on an architecture that we don't know the details of -- seriously though read that post, as it may answer some of your worries]
The developers also said they don't want people creating ramming ships that are kamikaze'd into exquisitely engineered, well designed constructs because they think that would make the game a lot less fun, and that would make people stop paying for subscriptions, so in that regard, this is as much a business decision as it is a matter of judgement in design. Even if characters didn't resurrect, there would still be a problem where players would create new characters who's reason for existence is to drive an iron brick with an engine and a cockpit into another ship while yelling "Leroy Jenkins!"
This has been already addressed in the thread prior to this, so I will try to be brief. It wouldn't make economical sense to create ramming ships, ammunition will likely be cheaper. You can create new characters and grief in a whole host of ways. You can use the same argument against including any game mechanic that can alter the world in some way. There might be ways to mitigate the griefing aspect, like (bad example) ability to pilot being revoked based either on reports or blacklisting people that exhibit these kinds of behaviors and shoot on sight, or a whole bunch of different things you could think of. You might also simply opt to not have ship-on-ship damage, if you still deemed it to be a problem, and strictly keep to taking damage from collisions with terrain.
This is a management-level decision as much as a design decision, and I really don't think this hill is worth dying on. Collision damage would be fun, but so would weather, planetary rotation, agriculture, animals, alien biospheres, a survival system, a FPS aimed combat system and a hell of a lot of other things we're probably not going to get until later, if at all. I'm not saying collision damage would be bad, or it couldn't be made to work, but computer science is partly the art of giving up something you want in order to get something else you want more. Is collision damage the most important thing to you?
And that's an argument against discussing the idea in the idea section of the forum how exactly? It doesn't have to be the most important thing to enter into a conversation about. And I think it might be more important than some of the things you mentioned, like maybe animals or weather or whatever.
The focus of this forum is supposed to be on bringing up possible features and avenues of development, and pointing out potential pitfalls and then iterating the ideas based on problems that arise. Your input, and that of many others, seems to be focused on negatives and absolutes, with the focus being on making sure an idea doesn't happen in any form and isn't even discussed. How is that constructive?
-
Well, they've stated that they're using dual contouring, so in theory creating all sorts of shapes is possible, within the confines of the contour "stencils" or whatever you'd call those they'll end up providing. Right now they have a sphere, triangular prism (Toblerone basically), cube (basically no contour) and cylinder. Combining these, if I understand the technology correctly, would allow you to create more elaborate shapes within a 25cm voxel. E.g. if you place a sphere and erase everything except one border voxel, you'll have a round cap thing that could be used as like a rivet or whatever.
[EDIT] As for sculpting tools and the like, I don't see why at least something like that couldn't be implemented, seems like the technology would allow it, and it wouldn't be any more resource intensive assuming they have some kind of a lower bound on the octree resolution, or however that works =p
-
To buy and build a cloud yourself would be insane. The kind of infrastructure that DU would require would have enormous front-end cost. Certainly, at least 100s of thousands, but in the millions probably. NQ has stated (referenced earlier on this thread) that they will be using a cloud service. At launch, at least. So my speculations assume they make the sane choice: a pre-existing cloud, with pre-made and configured core infrastructure as with something like Azure or Amazon cloud, and not reinvent the wheel. If, by chance, they do decide to try to create their own cloud.. I would be willing to make bets that initial launch would be a complete catastrophe.The intention was an in-depth software/developer discussion, moreso than IT.
Yeah, that does seem reasonable.
I'm not sure how we veered this far off-topic, though I'm not sure what more to speculate about their backend... Specific implementations of various microservices and such, assuming your Azure model?
-
First, your comment on griefing being unavoidable is correct, but that does not mean we should give griefers tools to make their mischeif easier. Griefing will be against the rules, NQ will be taking measure to make greifing hard, and to allow players to report griefers. The notion that it will inevitably occur some of the time does not make attempts to reduce greifing less valid.
I think it's more like almost any mechanic can be used to griefing, and intuitively I'd say that the more freedom (and note, this is a sandbox game) you have, the more potential there is for griefing. So to mitigate it, I posit that instead of focusing on banning the mechanics that may enable griefing, we focus on:
A. Creating mechanics that enable players to combat and report griefing
B. Fostering a community that doesn't breed attitudes that incite griefing and other disruptive behavior (kind of a nebulous idea, but I might be able to provide some examples if prompted)
And again, this isn't an argument it can't be implemented, it is an argument that it shouldn't.
That's kind of what we were discussing before the conversation veered into "it's not possible!" "yes it is!", which I felt like I needed to address.
So we can assume that collision mechanics are tracking moving objects, and seeing where they intersect to stop them. Before we start talking about damage, top speed and how often the server is checking for collisions are two key factors that need to be balanced.
->how often the server checks for collisions is going to determine how fast ships can go without passing through stuff and having a bad time. This is a major technical limitation for games with large numbers of players. More players means more moving objects, all of the data the server will need to track for collisions will be multiplied by the number of moving objects.
->top speed is going to be tied to this mechanic in some way, as the server will have to check for collisions often enough that an object can't cross certain thresholds in-between checks. If this is messed up, that's how you have an object passing through another object, or an object being stuck inside another object.
->depending on how player input during flight is taken, steering is also going to Bork up this process a bit. More responsive controls=more taxing to track collisions, because the server can't look as far ahead to predict collisions if course can rapidly change.
->If you don't have collision damage, and the server checks for collisions and finds an object inside another object, crisis can be averted: separate the objects in some way. If you do have a collision damage mechanic when the server finds an object inside another object, welcome to hell.
Polling frequency is a factor, yes. But it's a factor regardless of whether you have damage or just collisions. And I already presented a case for why you need at least the latter.
Player input, trajectory prediction, etc. are not relevant. We're likely going to end up with an "a posteriori" collision model, so we don't check if something is about to collide, but whether bounding volumes are intersecting on a given simulation step.
Regarding the last part, what? That's the definition of a collision in this model. An object is found inside another object -> collision is detected -> velocities and other relevant properties are retrieved and used to determine damage, new velocities, angular velocities and so on.
->Impact surface Area: Wedge vs flate plane should feel different from flat plane vs flat plane. This hurts to think about, so I'm not going to try to figure it out.
This would put your system in the middle of my complexity range -- as I said, it doesn't have to be that realistic to satisfy me. (You can come up with some Sci-Fi BS like... the shield absorbs some of it or whatever, to justify using rounder colliders)
I have a feeling there might be a simpler way, but I'd have to bust out a pen and paper and think about it (or do extensive googling to avoid re-inventing the wheel).
->Splitting Force: Not all of this will turn into damage, an object ought to "bounce", especially if both objects are in 0g and mobile. Or maybe not, soft compressible structures don't really bounce. This also hurts to think about.
->Shields: should have an impact on collision. Stronger shields cancel more force? perhaps it just shaves off a hard value from the damage characteristic of the collision? good questions here.
The force splitting could just use the same coefficient that determines how elastic the collision is (it's kind of a measure of conversion of kinetic energy to something else, after all). So if you go thud and don't bounce, you're going to be hurt pretty bad. If you bounce, not a lot of energy went into breaking you. This is kind of oversimplifying, and it will be up to things like material properties and such. Personally I'd be fine if it just ignored conservation of energy, you can do convincing effects without.
Regarding shields, yeah, makes sense.
My point is that up there, there is a lot of factors to unpack, a lot of decisions to be made, and it needs to be balanced against Construct vs. Construct weapons and damage... which is a stretch goal
And that brings me back to my core objection. As it stands right now, collision damage is not something that is on the table for NQ. Construct vs Construct PVP won't even be a part of launch unless its stretch goal is hit, and they are only planning a few armor and damage types. If NQ set Construct on Construct PVP as a stretch goal, it is probably because it is a small staff with very limited resources. Implementing a mechanic like Collision Damage probably isn't something they have the time or resources to do well. I think most of us would rather have a game with less immersive collisions than a game that will either be next to unplayable for 4 years, or no game at all.
CvC combat is a stretch goal (which we might still reach, mind you), but collisions aren't. I'd wager the bulk of the complexity/work of implementing CvC combat would come from creating weapons, damage types, system damage (which, yes, would have to be in a collision damage model), etc.
Most of the notions in a collision damage model are simple, and the bulk of it will be implemented (I'd assume, I mean surely we won't be able to fly through things no matter how badly development goes) regardless of whether you add the damage on top or not. The damage model to voxels isn't a trivial thing, I grant you, but you could just remove some based on some random distribution, weighted based on distance from point of impact, bounded by a sphere, sort of how I described earlier. Adding/removing voxels and elements is kind of a basic operation in the game.
The rest of that block is mostly conjecture. Also, note that I'm not saying anything about how high on a list of priorities this should be, just that it's something that can and I think should be added by launch, or soon after it, for reasons that were outlined by me and others earlier on in this thread. I think a balance can be struck between simplicity, development time, believability, immersion and quality.
[EDIT: Crap these character counts are getting out of hand]
[EDIT: typos, grammar, formatting issues]
-
In your typical service provider patterns, yes you're assigned personal IP addresses. But in a cloud situation, providers like Amazon and Azure, etc are assigned huge blocks of IP addresses which are used as needed by various clients. If you're using static, very long-term IPs in a cloud provider, you're probably not making full and true use of the full power of cloud.
The full power of cloud comes from throwaway virtual machines and dynamic, fluid hyperscale capabilities.
I guess I was starting with the assumption that NQ would build their backend entirely by themselves. Is it more typical game servers (for the biggest games) get hosted by someone else? I'm guessing MS and other similar actors in this market provide tools to their customers that allow them to manipulate some well defined part of MS's cloud infrastructure?
I'm more used to the kinds of systems where you do all the hosting yourself. So you just buy a connection in a datacenter, build a machine and park it there, or buy servers that are already in place.
I thought you guys were talking about NQ building the cloud infrastructure themselves between the hardware they'd own, rather than building on an already existing layer of hardware and higher level protocols.
-
I'm pretty much done here.
If you'd like to know how to create IPs in a cloud environment, google "Amazon elastic IPs."
It doesn't matter whether NQ uses Amazon, or some other party to host their servers. Any decent hosting company has an equivelant solution.
So you're presupposing they're behind some kind of DDoS mitigation service, the kind that I mentioned in the post that you were quoting?
I think we're in agreement, then.
-
Your attacks are on addresses (and their resources) that you are aware of.
I can procedurally create as many server names and IP addresses as I need. Even IPs hosted by completely different providers.
For every address you know about I can create 100.
Now I've taken your argument to an extreme, which isn't realistic. But your arguments haven't made a dent in my solution.
I've taken a central point of failure and a bottleneck and distributed it across a redundant solution.
That's something that's not possible with websites.
Yes. Given the size of the botnet, my solution can be taken down.
But it's decentralized AND redundant. And much more difficult than taking down the Whitehouse's website.
Wait, how are you creating IPs? In the system I'm familiar with, IP addresses are assigned to you by IANA, via your service provider -- you can't just make them up, right? And even if you select a different IP from a block of IPs assigned to you, the attack will still reach the link between the closest router to your endpoint, and saturate it, until you get your ISP to start dropping packets at the edges of their network that are trying to ingress to the address under attack, at which point the attacker just needs to get the new IP.
You can pick another IP (let's assume we're on IPv6 and you have a large block to choose from), but when your service is back up, I connect with my legit user client again, get the new IP and start attacking that instead. And so on.
-
Did I hurt your fee-fees? My comment addressed the whole thread, including myself. It is common for people who lack coding and game design experience to expect it to be easy, and many suggestion threads fly under the assumption that their request is simple. I addressed that no one who has commented thus far was qualified to make that judgement call, including myself. Am I wrong?
Also, I'm seeing a great deal of "I know you are but what am I" style arguments, and I fully expect a response to the tune of "if you don't posses the knowledge, then how do you know this isn't feasible?" I've presented the closest thing to evidence that I could (i.e. comparisons to other games, with large budgets and brilliant minds, that either took for ever to make a much simpler version of this mechanic work, or that still can't get this right). Just rolling out "this isn't the same game" doesn't actually refute my examples, your statement is accurate, but I presented them as examples of how hard these mechanics are to design.
I can look at those examples and imagine how hard it could be to make ship crashes not suck for everyone, and if what we lose by not having that mechanic in the game is a bit of immersion, that is a very easy design decision. The actual developers have commented on collision damage, and they commented on it in the context of sacrificed that they needed to make for multiplayer to work smoothly (i.e. it is not feasible to have collision damage and stable multiplayer).
This is not OP presenting a novel idea and users rushing in to stomp on it for funzies. OP is trying to make the case that a mechanic should be added that the devs already have plans not to add. If the goal is to pressure the devs to consider adding collision damage with user feedback and requests, expect to see the other side of the coin. A mechanic like this can have disastrous consequences even if it works perfectly (griefing), and can cripple the game if it does not work perfectly (and it likely won't). What you have to lose here way outstrips what you have to gain.
My feelings? Not really. I'm just saying that if you want to be taken seriously, you need to structure your input in a different way, that's all.
I don't care if you have a piece of paper that says you're qualified or not, I care about whether or not a proposed model or criticisms of that proposal make sense and are logical, or not.
Oh and griefing will happen in a sandbox game, just about any mechanic can be used in that way so that's kind of a moot point, isn't it?
To bring us back on topic, here's my take on actual implementation:
So we know they must have some form of collision detection in place regardless. Why? Because if you don't detect when objects collide and take away their velocity or whatever your intended behavior is -- the objects will simply pass right through eachother.
We also know the bounding boxes used will have to be at least somewhat sophisticated(read: concave hull of some kind encompassing the voxels belonging to the construct), since the devs have said they're planning on having ships be able to enter things like bays in other ships, which won't be possible if you use a concave hull type of bounding volume.
I'd also assume that they'll implement collision physics of some kind, regardless of whether they have damage or not, since without collision physics, the whole "passing right through everything" thing still happens. The simplest model (barely even counts as physics) is that when two moving constructs intersect, you just zero the components of their respective velocities that point towards the other construct. In this model, objects that come in contact would sort of just slide off of eachother, or if they were moving directly towards one another, they'd simply stop. I don't think I'm alone in thinking that that would be ridiculous. A more sophisticated model involving forces, torques, momenta, angular momenta, friction and so on, would be required to have something that resembles real life. So if you want a ship to settle down flat on its feet when you land it, or if you want to bounce off of the surface you fly into too fast, you need physics simulated as well.
Given those two things, all you need is a damage model, which can range from very simple to very complex, with corresponding increase in computational cost.
A model on the simple end would do something like take the intersection point (already calculated) and apply damage in a sphere with radius proportional to velocity (maybe the square or sqrt, doesn't have to be linear, can have low/high cutoffs etc.) centered on that point. This would require very little calculation, but things like reads and writes to datastructures corresponding to the voxels and what have you would depend entirely on their implementation. Overall, if they do things "right" this model wouldn't have much larger impact than anything else in the game.
A step up from that would be to have falloff in the sphere based on distance from the center. This is not a big increase in complexity (I think it'd be O(n)).
To give an example of the extreme of the spectrum, you'd have things like material strength properties (tensile, shear, compression, all of that), you'd maybe have springs to simulate stiffness of the construct. Pieces could break off if they have enough force/torque exerted on them, you could have collisions within the different pieces. You'd also simulate tension in a rotating construct, where the tensile strength of the voxels and the angular momentum of the construct would determine whether it holds together or breaks apart. In terms of complexity and computational costs, this model is off the charts. It's almost certainly impossible, unless you make an MMO that's all about breaking things in realistic ways.
Between those two extremes exists a continuum of possibilities, each of which would have to have its viability assessed on a case-by-case basis. So unless you're refering to a specific model, don't come here and say "that's not possible" without even defining what you're talking about, you only demonstrate how poorly you understand the topic. Thanks.
-
The "sector server" could be impacted but it would only effect a small number of users, and I addressed those concerns in my original post. Including determining WHICH game client was the actual hacker so they could be banned.
All sectors hosted on that same server/datacenter would be affected, since my attack would be saturating their uplink. There are many bandwidth amplification attacks that make it kind of easy to block traffic in an entire region local to that endpoint (attacks of 10's of Gb/s of size are pretty common, several hundred Gbps not unheard of -- that will drown out an entire datacenter's traffic).
[EDIT]
And I think someone pointed out that they won't be hosting in several places across the globe, just in one or two places.
If they want to not be subject to smaller DDoS attacks, they'll have to hire someone to do mitigation for them.
-
Sorry about the misunderstanding.
To clarify about the algorithm. My suggestion would indicate the server name doesn't necessarily need to be static. It just needs to be known on both ends. That's why DDOS is so effective for web browsers and websites. There's no way to do this with a generic browser, but its completely doable with a game client. A generic browser has one URL that its attempting to connect to. As long as the attacker floods junk packets to the URL, it doesn't matter if the hosting company changes IP addresses, or points the URL somewhere else. The DDOS just hits the new location.
The server needs to know the randomly generated name so it can setup the name in DNS. There's no charge for a third level name, So, there's no additional expense. The server DOES need to create the name at least 24 hours in advance to account for DNS propagation.
The client needs to know the name so it can connect to the server. The server names could be stored statically, but a hacker would eventually find them.
An algorithm could be used to generate random names on both the server side and client side. The client could also have 1 or 2 static names in the list for redundancy, but they're the ones most likely to be attacked. The client just needs to go down the list of valid server names until it connects.
The static server names AND the algorithm could be changed at NQs discretion via the standard client updates. This would make it more difficult for a hacker, because they would need to start all over to hack the algorithm.
But my point is, the IP addresses behind the DNS aren't going to be changing much while the server is running. Once an attacker knows where your server is, all he has to do is get enough traffic to concentrate somewhere in the logical viscinity of your server, and he'll bring that whole region of the network down.
So within your system I could:
1. Set up packet capture locally.
2. Play the game normally, like any other legitimate customer would.
3. Obtain the NQ server(s) IP(s) by reading the traffic leaving my machine.
4. Use my C&C to issue an order to my botnet to nuke NQ servers. NQ servers are now offline.
5. ????
6. Profit.
Lesson? IP addresses aren't secrets, and you can't treat them as such in this kind of model.
Point being, that there is no easy defense against DDoS, all the mitigation systems I know of primarily work based on distributing the load of the attack, but you can't do that if you just have the one or two servers. Only players like Google can do that sort of thing.
-
Diving in... What can you achieve with a DNS layer protection system? A couple of things. Primarily: automatic geographic distribution, initial load balancing, and DDoS protection. Because IPs can be in flux, a cloud-based DNS server can protect against DNS-level DoS attack by simply blocking evil IPs from the DNS layer. That prevents a level of DoS traffic from even getting to your app. This is more beneficial if IP change regularly. However, most app public access points are fairly static.
How would you distinguish between a malicious user asking for your IP via DNS vs. an innocent user? Many DoS attacks spoof source IPs for instance, right? What would prevent someone from playing the game innocently on their computer, mapping out the backend IPs and attacking those IPs with a completely unrelated botnet? I don't see how it's possible to keep IPs secret, and treating them like secrets seems like a bad security practice.
There's a reason why DDoS is an unsolved (possibly unsolvable) problem.
Secondly is geographic distribution and load balancing. In something like the cloud DNS, you can have the server know about a number of affinity points for your app. (read: datacenter location specific) Lets say you have "connect.dualthegame.com" as your primary connection point. This service is distributed amongst 30 nodes/IPs in 3 geographically dispersed data centers. The DNS layer can know that you also have "america.connect.dualthegame.com," "europe.connect.dualthegame.com," and "asia.connect.dualthegame.com." When that initial IP resolution query comes in, the DNS service can look at your IP, check it's geographic location and return the appropriate CNAME for your region. It is also possible to select based on latency, I believe. Each of the geographic CNAMES has a list of IP addresses for each cloud load balancer on the connection point for that datacenter. When multiple IPs are returned, the client will essentially just choose one at random and connect to that. This gives a degree of initial load balancing before your client even tried an actual connection to the app.
See that's the sort of thing I meant might make more sense than using anycast (I still don't understand how that would work, I've never seen anything like what was mentioned -- as I don't work in that industry).
The malicious botnet will be mitigated in some respect on that initial connection attempt, if it uses DNS resolution. The cloud DNS/front-end load balancers can pick up a list evil IP based on network traffic and prevent before it even touches your app. The load balancer denial also protects your app from direct IP address attacks. If the hackers get through even that, the ingress layer has it own protection now, as I mentioned, because individual nodes are fluid and disposable.
If I can get a list of IPs as I mentioned above, I wouldn't have to have my hypothetical botnet connect via the provided interface at all, I could just launch an attack of my choosing on any of the IPs I've discovered.
Distribution, on the other hand, is a valid strategy to mitigate against traffic concentration (network congestion) based DoS attacks, I agree.
-
DNS allows for changes to IP addressing. Novaquark would not need to know the IP address provided by the hosting company until the server name was created. There's most definitely a reason servers have names instead of just having IP addresses. Ask any Admin.
Yeah I realized I kinda derped with that remark, obviously you wouldn't actually store the IP in the client regardless of what backend you had, rather you'd find the first point of contact via DNS. I should've more specifically refered to the part about generating addresses algorithmicly.
TCP is a poor choice for gaming. It would never be used for FPS, and I wouldn't use it for "tabbed targeting" RPG games either. There's a lot of redundancy and overhead with TCP. However, it won't make much of a difference for DU. I just believe the server resources could be used more effectively elsewhere.
UDP can be used for unreliable data AND reliable ordered packets.
For more information:
You have a point there, I somehow had the notion in my head that games I play use TCP, but now that I think about it, the ones I know about probably use UDP.I'm talking in the context of a "dumb" ingress layer. Yes, at the TCP level, packets would be ordered and retry as normal. But once through to the ingress nodes, that traffic is authenticated, validated, decrypted, and passed on to the actual game logic nodes. It is at this level that I image a queuing system might be necessary. If you have 100 ingress nodes and no queuing, that is a lot of asynchronous traffic (100 streams) being dumped into the game services (let's say 20 server nodes) and it all needs to be handled and processed at once. By implementing a queue (either in process or separate/distributed) you can quickly accept that traffic, then process it as quickly as possible without fully flooding the services. If you use something like Azure Service Bus or Event Hubs (again, sorry for always posting M$ tech), then those cloud services can ingest the millions of messages per second and use Message Queue "topics" to intelligently route to only the nodes that requires the message. instead of the connected node receiving EVERY message, always. Again, it's a trade-off between raw performance or adding a bit of latency to be more intelligent and reduce overall traffic ingestion on specific nodes.
Yeah ignore what I said about TCP, hah. -
On the note of griefing, have you seen the posts about characters suggesting an imprisonment system like DayZ, or anything CaptainTwerk posts?
But I do believe that "rust" style players would back this game for some of the similarities, because they see "sandbox" and immediately think anarchy death carnival of fun.This is an MMO. Immersion is not a high priority, not as high as smooth multiplayer, the sandbox functions, etc. FPS shooting, tracked projectiles, collision mechanics, these are the kinds of features that make multiplayer impossible to code in a way that plays consistently and smoothly. Desynch will happen, and you won't want a hiccup in an otherwise solid internet connection to cause you to crash your ship. Don't get me wrong, I do love Space Engineers, but that game can barely handle 8 players little lone 8,000. Even minecraft, one of the simplest sandbox games, took years to keep Boats from desynching in servers that had as few as 30 players, and Boats were only tracked on a 2D plane, and could only destroy themselves when they crashed.
No one in this thread REALLY has any idea of how fragile multiplayer mechanics are. Without collision damage, a bug simply causes you to fly strangely or boot you for a minute. With collision damage, a server hiccup could cost you your ship, someone's base, your inventory, possibly skill points, and a huge police bounty. just for Emerson, that is not worth it
Are you mentioning that first thing as an aside, or are you actually somehow equating a collision damage system to anarchy? By the way, many of us play DayZ and Rust as the hero type, including myself. In a game that touts being all about "emergent gameplay", it's up to the community to determine what kind of values gameplay will express, and it's up to us to foster the kinds of community values we want to see. Oh, and the beauty is that even two diametrically opposed sub-communities can exist within the game, if all the carebear types group together and create an entire solar system where nobody can harm anybody without facing heavy penalties, while the PvP anarchist guys can go have a nuclear war somewhere else -- and then you can have historic events if these two groups clash in game... anyway as I said, that's all tangential and off-topic.
Regarding what's possible and what's not possible to code, how about you let the actual developers comment on feasibility, especially since we haven't even proposed a detailed enough model for you to evaluate it's feasibility or performance impact? You're kind of jumping the gun with such grand conclusions. This is the ideas/suggestions forum, after all -- you can't just shoot down everything because you have a negative knee-jerk reaction to it (i.e. it reminds you of something else that doesn't fit within your model of a perfect game -- e.g. the Rust anarchy remark way out of left field). Let's keep the discussion factual.
Space Engineers is a different game, with a different engine. If I told you we were going to have a single-shard, continuous universe, with potentially tens of thousands of players, would you shoot me down because "Space Engineers and Minecraft can't do it!" ?
Regarding the last part, you don't know me. You don't know my educational background, my gaming background or anything else about me. How can you just flat-out assert that I don't understand how multiplayer mechanics work? You don't see me undermining your intelligence; instead of focusing on arguing against your character, I argue against the factual/logical content of your posts and judge them on their own merits -- separate from your character. Regarding actual knowledge of game design, have you heard of the Dunning-Kruger effect?
-
@LurkNautili:
Connections between nodes would be direct yes, but messages would need to be queued once received to ensure they happen sequentially. But once in the queue, they can be processed and acted on asynchronously, with some intelligence to resolve conflicts. Individual services, such as the region, can also make use of replicas to allow certain read operations to occur across nodes, while write operations would happen on a single primary node to protect the system integrity. A lot of this can just happen automatically thanks to the cloud services / service fabric layer.Doesn't TCP just do this own its own (sequence numbering in packet headers)? If I send that player A moves to point x, then y, then z, those TCP packets have to arrive in the order I send them and I don't need to worry about it, right? Or if you mean players A and B both in different regions distinct from mine and from eachothers' violating causality... Well I guess you'd have to maintain some sort of server simulation time indexing as well, which you could use to sort data arriving from different regions -- is this what you meant?
[EDIT] That could cause delays, though, if you allow a lagged up packet from one region (at say, server tick 1500) delay the processing of events from other regions (at ticks 1501, 1600, whatever), right? It would have to be smarter than just a queue that you sort and execute in order. Is this what you're eluding to with read vs. write (some kind of analogy I don't get there)?
-
I'd love for you to shoot holes in my solution.
Well, as stated, I don't know a whole lot about networking...
However, wouldn't anycast require you to have access to the routing tables of the ISPs carrying the connections? Like, say I get an IP address for a US from Level 3, which is from a block of IPs assigned to them, how would I set that as the IP of e.g. a German server connected to the internet via Deutsche Telekom? I mean I know that as an autonomous system, you can set up anycast within your network, but how do you set something like that up for IPs you don't own (or from within networks to which that IP is not assigned to)? How does NQ who isn't even an AS do something like that? I'm confused.
Also, what's the point of using DNS for a system where they make the client and the backend infrastructure? It won't obscure the endpoints clients connect to, IPs aren't secret information, you can just look at the traffic and aggregate a list of servers over time.
Wouldn't it be best to have your client connect to a service (behind some IP, maybe the client could store a list of alternatives) to log in, and at the same time a backend service would negotiate a connection to a cluster local to you?
As for DoS protection in general, the kind of architecture CodeGlitch0 mentioned would, on its own, go a long way against mitigating DoS, since an in-game region's corresponding cluster might be geographically disperse, DoSing would have unpredictable effects, and since you're probably trying to mess with some specific org or player, you can't point the attack very effectively (you'd have to know where they live, and target their closest NQ server).
Of course if you're just trying to bring down game service across the board, you just target all the NQ servers, whose IPs would be public record -- just the nature of IPs and routing, nothing you can do about it. In order to protect the login service from being brought down by a cheaper DoS attack, the login backend would just have to be distributed across all the NQ servers as microservices, as CodeGlitch0 outlined above.
-
So you think it is a problem then for the game to assume that your character in the game is a skilled enough pilot to avoid crashing. The game does not expect you as the player to know anything about how to refine ore into materials, nor does the game expect you as the player to know how to build a jet engine from parts. However you think the game should expect the player to be an expert pilot to avoid crashing?
This seems a bit silly to me for the game to potentially aim for you, but not avoid crashing for you. I'd be happy to see this compromise from the prospective of "one of the many things the game assumes you character is smart enough to do", mainly fly without crashing.
Also, have we considered not crashing as a potential extension of shield systems? It it impossible to imagine a science fiction universe where tech is advanced enough that no one crashes accidentally? or is this still a covert scheme to get ramming into the game as a griefer tactic.
Technical solutions to technical problems... If you give me thrusters, gyros, distance sensors and the like, I can build you a vessel that you cannot crash even if you try -- if that's the sort of digital life you wish to lead. Personally I'm like the dying breed of present day car owners, desperately clinging to the sense of danger and independence afforded by a car that doesn't drive itself.
Oh and on the topic of lock-target combat for avatar vs. avatar, I'm really not happy about that, and am constantly trying to come up with some alternative that would allow me to keep my immersive FPS type combat that I've grown accustomed to. But that's a conversation for another thread.
Also, I can assure you, I don't want griefing in this game any more than you do ( I mean do you *really* think I'm backing a game, posting on the forums, trying to improve the game, all for some sort of elaborate plan with the ultimate agenda of griefing people for some lulz? I assume that remark was tongue-in-cheek), and I am quite happy with missiles being VFX and stats based things with no corporeal form. This is purely a matter of immersion for me.
-
It's a tricky problem.
I'll start by mentioning that JC recently said in an interview that if an organization claims 70% of the tiles on a planet, the planet and the space around it, will be considered "owned" by that organization. If it gets back down to 60% they lose it. The 10% buffer insures the planet isn't constantly changing hands.
I suggest a combination of territorial claim and procedural generation method. By default, the names of planets are procedurally generated (perhaps the the nearest 100 planets near Alioth the devs will selectively name). However, if an organization has reached the 70% bar, they get to name it whatever they like. This way reduces the the likely hood of low-quality names while preserving the emergent aspect.
This is basically what I was about to post.
Start with procedurally generated names, and if an organization gets 100% (maybe less) control of a region (planet or larger) either delegated to them, or through total domination, they get to choose the name through voting or whatever system they please. Therefore it would be up to the community to make sure unqualified people (read: trolls) don't get absolute power over a region (probably won't happen). And then developers would naturally have a veto abilities to remove names that are against their ToS or whatever.
Inertia Dampeners?
in Idea Box
Posted
That still wouldn't work as well as the typical Sci-Fi dampeners. Even if you were immersed in fluid, it still wouldn't permit hundreds of g -- because although the surface that's accelerating you is now touching every part of your skin, your body is still non-homogeneous and the denser parts will concentrate towards the way you're being pushed from. And it would have to be completely solid or you'd just slowly drift through the material, depending on density -- so really a pod of some kind would be more desirable. The kinds I've seen in Sci-Fi books actually involve filling the lungs and other cavities in the body with the gel as well which further helps with structural integrity, but it only works down to the level of tissues (cells would still get ripped apart at centrifuge-levels of acceleration).
The incorrect parts that I'm talking about specifically are where you say things like "absorb inertia", or that inertia increases with velocity, neither of which makes any sense. Inertia can't be "absorbed" or "transfered", unless you mean transfering mass (which is basically the same as inertia) -- you're probably talking about kinetic energy or momentum. Also, inertia (resting mass) is constant and independent of velocity, unlike for instance the aforementioned kinetic energy and momentum.
You're confusing inertia (resting mass) with relativistic mass. I doubt the game will incorporate Einstein's theories of relativity, or have relativistic effects of any kind -- as I already stated. I avoided bringing up the topic as much as possible to avoid further confusing people who struggle with basic mechanics (a far simpler collection of physics principles than relativity).
Relativistic mass arises from the mass-energy equivalence that comes into play at relativistic speeds. But as I said, I don't think there's any benefit (especially considering the cost of simulating things of such complexity, not to mention the difficulty of designing a game around such models) in including relativity. I won't go into the very complicated math/physics involved as I don't think there's much point in the context of a thread where people struggle with basics like the Pythagorean theorem -- and it wouldn't serve any purpose anyways.
As for your comment regarding Kyrium, you either don't understand the notion of g-forces or you didn't read the part where I underline how there are more than just once force mediating particle (that, unlike gravitons, actually exist and are much more germane when examining things like collisions, where gravitons are not a factor).
To re-iterate: things like touch (e.g. crashing into a planet) are mediated by particles that give rise to electromagnetic force (read: photons, not gravitons) and therefore Kyrium, as described by their lore, is useless when it comes to sustaining crashes and protecting the crew inside. I already explained possible use cases for such a material but they're few and far between and certainly not what the writer intended.
[EDIT:] I also urge you to note how far off-topic this discussion is veering, and remind anyone still reading that we've addressed the OP's inquiry in that I think we all agree that the kind of system he's refering to (due to Space Engineers confusingly introducing a third use for the term in addition to the typical scientific and the typical Sci-Fi sense of the word) probably will be in the game in some form. So... /thread, I guess?