Jump to content

Collision damage - workaround suggestions


TheRealBeowulf

Recommended Posts

@shynras:

Okay don't know how exactly that works too, but if it's a voxel construct, I would assume that the collision box would have to be pretty much the same shape.

I don't know how they could use predefined collision boxes with custom built voxel constructs.

So, if the engine knows that for example a wingtip, or a landing gear touches a surface, that would be a pretty precise point - at least precise enough to generate an area of effect - or am I missing something?

Doesnt need to be predefined, the domain changes depending on the construct coordinates. The shape is not a problem.

It's pretty much always a single point of contact when there's a collision, it's alway precise. The problem relies on the fact that to identify that specific voxel. You have a huge domain (construct) and know that another domain (construct) collided. Where? You'd need to divide the first domain into many, one for each voxel, so that you'll find the single region of space where it collided. Alternatively you could use vectors, but they requires heavy calculations too.

Link to comment
Share on other sites

@wizardoftrash:

 

Okay I get your points. I didn't mean to offend you, I'm just discussing things. In my opinion this discussion is getting more in the "personal taste" direction.

I don't say that collision damage is something that has to be in the game, for me personally it would just be nice to have.

 

I must admit that I'm more into the building and simulation / survival aspect and don't care so much about the classic MMO mechanics. It's just that DU gives you to freedom to build and engineer a construct and after that actually put it to a good (or bad ;) ) use. Instead of just staring at it or showcasing it on YouTube, you can share it with hundreds and thousands of people - that's what I like the most about the idea of DU.

And I bet I'm really not the only one in the community who sees it that way.

 

We'll have a lot have people coming from NMS, who are more into the survival and exploration aspects, Minecrafters who like to build and of course people from Space engineers (like myself) who like the scifi-engineering part.

Dual universe mixes a lot of genres, so it's not only the MMO aspect that attracts people - so it will most likely also be a genre mix in terms of gameplay, not a classic MMO.

 

Maybe the examples with the racing games weren't the best ones.

What I wanted to say is, that every game expects you to learn it's mechanics - an MMO expects you to learn which skills and armor are the best for your playstyle.

I would also assume that learning how to fly the more basic constructs won't be such a big deal at all, so it isn't that much about unskilled pilots, more about careless ones.

 

The point with the real accidents caused by lags and disconnects is something that is a real problem, but it's pretty much the same if you have a disconnect in the middle of a battle...

 

I would just say that if you are approaching a space station, you should fly a bit carefully anyway - so no bad crash would happen :)

Link to comment
Share on other sites

@wizardoftrash:

 

 

The point with the real accidents caused by lags and disconnects is something that is a real problem, but it's pretty much the same if you have a disconnect in the middle of a battle...

 

Not offended, a little surprised however.

 

There are a lot of games where disconnecting during battle does not penalize you at all, intentional or otherwise. We don't truly know what disconnecting in this game will be like, but I can break down the real concern.

 

PVP probably won't happen often in this game. The focus is "rebuilding civilization together", so it isn't like a MOBA where the focus is player vs player. However, after the initial setup period, players are going to spend a lot of time flying ships. A player might understand losing their ship in combat due to a bug, it won't happen often enough to be a big problem.

 

However, if each time you fly your ship you gamble all of those resources because crashing is so punishing, it will be a serious detractor from the game. Think of the time players will be investing in their ships (according to the devs, ship building will be quite a process). Even if we assume that there will be no bugs, and that a player's connection is perfect, losing their ship more than once because of a minor player error (and this happens often in similar games), will be enough for NQ to lose a potential subscriber. This would be compounded by connection issues, bugs, or other unforeseeable setbacks that can cause a crash by no fault of the player. This is one of the features that keeps me from playing Space Engineers more regularly, as even very stable servers rob you of a ship or even a base because of stability issues+collision damage.

 

Without that collision damage, it would be  a VERY different game. Sure players could fly more recklessly, and battles would devolve to just how many turrents and heavy armor plates you can afford to slap on your ship, but it is basically that way at the moment regardless, and DU won't have that problem since they are borrowing so heavily from EVE.

 

But that's exactly it, Space Engineers is a simulator first, and a multiplayer game second. DU is a multiplayer game first, simulator isn't even on their radar.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

@shynras:

 

I get your point, but isn't that pretty much the same for calculating the impact point of a weapon?

No it's not, and I explained why, even if it could be different since it can be done in different ways. Imagine you're running against a wall. A collision that stops you from doing that, just tell you "you can't pass". Collision damage would tell you "you can't pass" and then "hit in x,y,z". Checking where the entity got hit, is the problem, not the "you can't pass" line. Try space engineers, the difference is quite obvious there, it's not only server heavy, but client too.

Link to comment
Share on other sites

 

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?

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

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.

 

Thanks for the essay, and though your response is articulate, it does not answer my core objection. I'm not objecting to whether or not collision damage can be implemented (which you are attempting to illustrate), I'm objecting to the idea that it should be implemented. My experience in game design is not as an engineer (could you tell?), but I'll try to articulate my technical concerns. And again, this isn't an argument it can't be implemented, it is an argument that it shouldn't.

 

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.

 

So now I'll gloss over some of the basic factors that would make for an immersive collision damage mechanic.

 

->Damage: for traditional Construct vs Construct damage, the factors are likely to be Player Skill (hit/miss/location), target size (hit/miss/location), target speed (hit/miss/location), Player Skill (intensity), weapon damage value(intensity), damage type(intensity), shields(intensity/cancellation), armor type(intensity). <--this is a guess for Weapons, which is a stretch goal as it is

 

->Armor will need to have Damage characteristics in addition to armor characteristics if it will be a factor in colliding. Non-construct objects will also need Armor and Damage characteristics as ships will crash into non-construct objects. This might need to include things like trees, types of terrain, players, etc.

 

->Momentum: Speed and Mass will both need to be a part of the damage characteristics for a collision, but there will need to be separate sets of factors for Structures and non-structures, as crashing into a huge rock would have a tremendous amount of mass but no speed.

 

->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.

 

->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.

 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.

Link to comment
Share on other sites

No it's not, and I explained why, even if it could be different since it can be done in different ways. Imagine you're running against a wall. A collision that stops you from doing that, just tell you "you can't pass". Collision damage would tell you "you can't pass" and then "hit in x,y,z". Checking where the entity got hit, is the problem, not the "you can't pass" line. Try space engineers, the difference is quite obvious there, it's not only server heavy, but client too.

Okay, but how does the game engine know that the hitboxes are overlapping, if it doesn't know where they are overlapping?

I mean, the game has to keep track of the exact position of the hitbox to determine if there is a collision ir not, and it only stops the construct when it actually touches something - how does that work if the engine doesn't know where the intersection is?

 

Also, the weapon damage model does take the firing angle into account, so it has to know where exactly the firing weapon is, and where the impact point is.

Isn't that also calculation heavy?

 

Sorry if I missed something, maybe I just can't follow you...

Link to comment
Share on other sites

Also, the weapon damage model does take the firing angle into account, so it has to know where exactly the firing weapon is, and where the impact point is.

Isn't that also calculation heavy?

Luckally because it won't be tracking actual projectiles, it won't be quite as nasty as it could be.

 

Since there will be tab-targeting and direct fire, direct fire will likely have a back end snap-to feature to it. It'll be hitscan style, so it is may simply designate an impact area, and if that area is valid, checking your character's stats, the weapons's stats, and the targets stats to determine whether or not it hits and how much damage/size of damage. The snap-to will place direct fire hits from a larger area into a simpler, more specific area (not unlike bullet magnetism). "missed" shots will probably have the same animation as a regular attack, but will look like it missed and do no damage (since missed shots won't be tracked).

Link to comment
Share on other sites

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]

Link to comment
Share on other sites

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?

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?  

 

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.

 

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 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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

 

 

 

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]

 

 

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.

 

 

 

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?

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Okay, but how does the game engine know that the hitboxes are overlapping, if it doesn't know where they are overlapping?

I mean, the game has to keep track of the exact position of the hitbox to determine if there is a collision ir not, and it only stops the construct when it actually touches something - how does that work if the engine doesn't know where the intersection is?

Also, the weapon damage model does take the firing angle into account, so it has to know where exactly the firing weapon is, and where the impact point is.

Isn't that also calculation heavy?

Sorry if I missed something, maybe I just can't follow you...

actually i answered all those questions already i think xD english is not my main language so it is a bit hard for me. The weapon damage model doesnt take account of the angle, it is just a "select" function, there's no projectile so no angles and no intersections. A construct occupies a region of space, the domain is in 3d. The game is set like if construct 1 domain intersects construct 2 domain, stop it. And that's why you don't fall through the ground. the game doesnt know where the domains intersected, but just that they did. To know that, he game splits he main domain into different parts, until it found a single domain, a voxel, and that creates load.

Again, i'm not really a programmer, i just know basic stuff, so take it with a grain of salt

Link to comment
Share on other sites

maybe someone pointed this out, but the constraint isn't collision detection but syncing the changes in real time to all the clients and calculating where the damage applies and deformation.

 

In space engineers, it is as cost prohibitive as it comes. You have to not only detect the collision, but how it deforms the voxels that collide then all the subsequent collisions as the voxels continue to collide since you don't want a collision where a small voxel completely stops the ship and bounces them off, you want it to deform and become destroyed until the inertia is halted. This is an immense amount of data to try and keep real time. So basically a single collision is like 1 calculation. a space engineers collision is like a thousand separate calculations due to deformation as you calculate the effects of voxels on other voxels independently for each voxel.

 

Depending on how they are coding the game, from what I understand floating point calculations are not predictive between different hardware so they can't just sync the player input on each client and have each client reach the same result, different hardware will reach different results so they have to continuously update clients for anything that requires those type of operations to stay in sync with the server.

 

I'd want a balance if possible, I can handle not having deformation from collisions but I still want collision damage of some sort. I don't know if their "constructs" support deformation or partial destruction outside of build mode and I suspect they don't as a performance saving measure.

 

My idea would be to figure out a way to calculate partial construct states, basically have a system that after finishing a build calculates a model for partial collision damage on lets say from 18 or so different directions, or 6 different directions with 3 levels of damage. so basically the model automatically degrades based on precalculated models that can be generated based on the voxels you made the construct out of.

expanding on that, have precalculated deformation states to mix between the damage states. So basically where there is "bend" between each damage state so it gives the appearance of some basic level of deformation and is easily calculated in real time by the clients and synced.

 

All you need is both the constructs locations relative to each other and come up with as efficient a solution as possible to determine which of the 6 angles is closest.

Link to comment
Share on other sites

My two cents on this topic:

 

As we do not know how the voxel system interacts with game engine is nigh to impossible to estimate the overhead that collision coordinate computation (first step to implement any collision damage) adds. We know that the engine computes voxel collisions, but there are algorithms that do that and do not compute the intersecting coordinates. That said, if the engine computes by itself that coordinates, implementing a simple damage model in the line of weapon damage is only moderately difficult (in terms of overhead) and completely doable.

 

Regarding all the fuss about the pertinence or not of allowing collision damage, I am all in the wagon of its pertinence. Because without collision damage flying near structures has near to no significance. And too many immersion is lost without them. For the issues given against this mechanic:

  • Griefing is natural to MMOs. We can think about that what we want, but because most griefing conducts are not absolutes one action that will be considered to some griefing, others will see it as permitted (even if esteemed unfair) play.
  • Ramming will be very difficult if Newtonian physics are implemented in flight. IF IT IS the case, I expect that most ships will have enough thrust to accelerate to at least to 1G (otherwise, flight can become something very very boring), and some Km/s relative speeds will be common in most combats. Combat ranges will be in this case in the order of hundreds of kilometres, if not in the few thousands. Even if you are able to achieve a low relative speed to your target to make feasible to start a ramming maneuver, in the majority of cases target will be able to avoid you, or will have enough time to pour a hell of fire on your ship.
  • I think that most of you are underestimating the total costs of building anything greater than a few tens of meters. A ramming ship big enough to do any sizeable damage (with maneuvering and flight capabilities that will make ramming something achievable) is going to be no more cheaper than a combat ship of the same tonnage. Mostly because hull cost in big ships are going to be a big part of the final cost. Add this to the above point, and ramming will be only the last maneuver of an already dying ship to try take someone with him to the tomb.
Link to comment
Share on other sites

I have a couple of thoughts on this topic, I agree creating a system where ramming is a valid tactic is a terrible idea but arguably having no collision damage is going to lead to stupid immersion breaking behavior like people flying into the hanger at top speed and stopping dead when they hit the back wall without any consequences.

 

At its simplest the the equation for kinetic energy is E = M x A, this is real world physics.

 

My suggestion would be to generate collision damage purely on mass and decreases in velocity when a collision occurs. I'm assuming that mass is something that will have to be calculated for the flight model and we would know the velocity before and after the collision.

 

There would be two parts:

 

1. A G-Force threshold that would "gib" any players in the construct.

 

An instantaneous change in velocity of more than 25m/s would be fatal to most people this equivalent to driving into a concrete wall at 60mph without any breaking. Something like 40g, at 100m/s you are unlikely to find any bones, just a red paste :D

 

2. Damage that is distributed to the hull and elements:

 

Using E = M x A, calculate damage energy to be dissipated in the construct. You could have a offset that removes a certain amount damage energy so that you can land without damaging your ship and perhaps the presence of shock absorbing landing feet could increase this offset (so long as contact point is on the foot element)

 

The rest of the energy would be converted into hit point damage and applied by removing voxels expanding out from the area until all the energy is absorbed, different materials can absorb different amounts of energy. If this was still too complicated you could just have a simple HP bar for ships but that's kind of lame.

 

In this scheme, stationary "static" constructs are totally invulnerable to collision damage this could have some weird consequences but I would argue its an acceptable trade off.

I'm not sure what would happen if you tried to "push" another players ship using yours, potentially you could limit damage to deceleration so the pushed ship would accelerate a bit from the collision and take no damage whilst your ship would decelerate slightly to conserve momentum thus taking damage. This could potentially be devastating if you trying to push at high speed.

 

I think this is pretty do able, it is based on very simple variables, I'm just not sure if there are any gaping holes in the idea that I cant see.
 

Link to comment
Share on other sites

Hello,

 

TLDR: Ships as 1 unit, collision makes the ship of lower kinetic energy 2 units, the destroyed portion and the surviving portion, destroyed portion originates from point of impact.

 

Using maths to see a construct as 1 unit of kinetic energy (mass*velocity) as it collides with another ship (mass*velocity) the ship of lower kinetic energy could be divided into 2 units the surviving unit and the destroyed unit, this division could occur as a percentage (the damage cause by collision) and a shape (the rough shape of the other ship). This should yield relatively low server overhead, especially if collision damage is limited to ships above a certain size (capital ships only) thus eliminating the value (in general), of mass torpedos. 

 

If this was simple enough as to allow sufficient server overhead collision damage could be mutual, and percentages of each ship could be destroyed using the method described above.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...