Why don't we use Gaussian distribution for weapon dispersion.

[PIE_OF_DOOM]

Alternate config options still need to be worked on by devs, unless you want them to become massively outdated like Breakoff or Collision Damage.

Did I every say when I want it in the game? I completely expect this not to come before other updates.

 

[Master_Artificer]

come 0n guys, take a step back and relook at the conversation. He is making some good points and agreeing with some people like crusades post.
Don't be too harsh on the guy, jeez.

 

[jstenholt]

I'm being harsh. But only because he actually hasn't made a good point, other than pointing out how bad he is at explaining his point and then failing at making his point again.

 

[Lecic]

come 0n guys, take a step back and relook at the conversation. He is making some good points and agreeing with some people like crusades post.
Don't be too harsh on the guy, jeez.

Could this potentially have SOME use? Yes. I WOULD like to see a slight inaccuracy to rapid cannons, and a randomized pattern for shotguns. But not at the cost of needing to do tons of extra calculations. And definitely not for the reason of "improving accuracy" for people who can't land their shots.

 

[Matt_Bradock]

OK, what's so calculation-heavy about tying a RNG to generate a random angle within specified parameters to which the projectile will deviate from the 0?

 

[Parameter]

from the sounds of it he's trying to apply hitscan logic to projectile weapons in a space game - and hitscan logic flat out doesn't work when there aren't boundaries and skyboxes at a set distance to bounce line of sight checks off of

either that or the bullets fucking curve mid flight

I've worked with random projectile dispersion before, and believe me, it makes for a HUGE amount of extra lag. You're pulling three random numbers, multiplying them by a given value, and adding them to the projectile for every single projectile fired. That generally more than doubles or triples the amount of code involved, depending on how projectile spawning is handled.

Not disagreeing with your general conclusion, but picking a couple of technical nits:

It would be easy enough to use sector boundaries for bounding hitscan detections if you needed a a replacement for a skybox.

Also, with regards to projectile dispersion, I think there's an easier way than you laid out.

1. generate a set of quaternions representing possible angular perturbation to a projectile
2. store those quaternions in a lookup table
3. At runtime, draw 1 random number, look up the corresponding quaternion in the table, and perform one additional quaternion multiplication to your projectile's orientation.
4. Voila! Relatively cheap dynamic projectile spread based on some desired distribution.

So easy a junior programmer can do it

 

[Master_Artificer]

OK, what's so calculation-heavy about tying a RNG to generate a random angle within specified parameters to which the projectile will deviate from the 0?

Probably doing it a thousand times a tick when you have all 20 Point defense turrets open up on incoming missiles. Or when you have 3-4 people firing at each other in a fight when you have cannon-cannons and more than 1 output. People like to make waffleboards, so it is plausible to have over 400 outputs (small 20x20 checkerboard) on a gunship or other small craft. Multiply that by number of players in ships like that, and you can see why it would be cut in an effort to optimize gameplay and performance in situations when you really cannot afford to lag/crash.

 

[Pirate_Ray]

Probably doing it a thousand times a tick when you have all 20 Point defense turrets open up on incoming missiles. Or when you have 3-4 people firing at each other in a fight when you have cannon-cannons and more than 1 output. People like to make waffleboards, so it is plausible to have over 400 outputs (small 20x20 checkerboard) on a gunship or other small craft. Multiply that by number of players in ships like that, and you can see why it would be cut in an effort to optimize gameplay and performance in situations when you really cannot afford to lag/crash.

hmmm, fair points, but that is assuming every weapon gets its own calculation and generator, you can however create a general random generator and link everything up to this single source of randomness to have the rng using 1 generator. problem is that all guns firing at the same time will have the same spread pattern at that specific moment.
to fix this:
you can also have 4 generators running total and have good (and pretty) effect, 1 generator randomly assigning any gun's rng to one of the 3 other generators to have randomness all over the place.
this is slightly more intensive to use but makes sure that you don't "copy" and show every gun having the same randomness every shot (with a multiple output system spread copy's become obvious)

 

[Parameter]

hmmm, fair points, but that is assuming every weapon gets its own calculation and generator, you can however create a general random generator and link everything up to this single source of randomness to have the rng using 1 generator. problem is that all guns firing at the same time will have the same spread pattern at that specific moment.
to fix this:
you can also have 4 generators running total and have good (and pretty) effect, 1 generator randomly assigning any gun's rng to one of the 3 other generators to have randomness all over the place.
this is slightly more intensive to use but makes sure that you don't "copy" and show every gun having the same randomness every shot (with a multiple output system spread copy's become obvious)

Random numbers aren't likely to be the performance culprit here. The issue people are concerned about (I guess) is generating the initial bullet orientation.

Let's say you have a ship with 2 cannons. Every second when you fire, the game has to create 2 bullet entities and give them the kinematics (position, velocity, orientation, possible linear or angular acceleration) that make them "shoot." That's pretty easy - you can use the position of the cannon output for the bullet's initial position, you can use the ship's/gun's orientation for the bullet orientation, and the rest can come from a config value. Voila, a bullet starts at your cannon output and moves in the direction you're looking at a config-determined speed.

Adding randomness to the orientation isn't too difficult, either. In addition to above, you draw a random number and use it to lookup 1 of many precomputed random angle offsets. Then, you combine that offset with the bullet's initial orientation to generate some spread. Voila, your bullet has a slightly different angle than the ship's, so when it shoots it goes a little off kilter.

The only difference between a "straight" bullet and a "random" one is that angle offset. That's usually done under the hood by something called a quaternion multiplication. It's not too compute intensive, maybe a couple dozen compiled instructions. These multiplications are already being done at a minimum every time any entity is rotated or changes it's orientation, and probably a good number of other times besides for other purposes. They're used so often that game engines and 3D rendering APIs usually provide a quaternion math library that's pretty good.

So, the question is, is there a technical limitation to randomizing every cannon bullet's angle when it spawns? The short answer is not yes, but maybe. Take a reasonable worst case scenario: 20 ships, each firing 200 cannon/cannon weapons simultaneously (Some people will say it's not extreme enough, but I don't care, I'm just illustrating a point). That's 4000 bullets being created every 1/10 sec. If the game state updates internally at 30Hz, those entities may need to be created in less than 30ms - let's say 10ms. 4000 quaternion multiplications + misc. may add another 50 compiled instructions per entity - let's be conservative and call it 100 for 400,000 additional calculations. A modern CPU can process ~100 billion instructions per second, or 1 billion instructions per 10ms game frame. From an instruction standpoint, it's feasible.

The bigger question is - how efficient is Starmade's game state update routine? How close are they already to busting their update times in stressful situations? Even if it's pretty cheap to add the random bullet angles, it could be the straw the broke the camel's back and caused game lag. Since this game is in alpha, I'm going to guess Schine still has a lot of code optimization ahead of them, and their current game engine may not be ready for the additional stress from random bullets.

I'm not going to assume that, though. Bullet randomness is technically feasible, and the current state of the game shouldn't keep us from suggesting it, even if it takes a while to implement.

 

[PIE_OF_DOOM]

Random numbers aren't likely to be the performance culprit here. The issue people are concerned about (I guess) is generating the initial bullet orientation.

Let's say you have a ship with 2 cannons. Every second when you fire, the game has to create 2 bullet entities and give them the kinematics (position, velocity, orientation, possible linear or angular acceleration) that make them "shoot." That's pretty easy - you can use the position of the cannon output for the bullet's initial position, you can use the ship's/gun's orientation for the bullet orientation, and the rest can come from a config value. Voila, a bullet starts at your cannon output and moves in the direction you're looking at a config-determined speed.

Adding randomness to the orientation isn't too difficult, either. In addition to above, you draw a random number and use it to lookup 1 of many precomputed random angle offsets. Then, you combine that offset with the bullet's initial orientation to generate some spread. Voila, your bullet has a slightly different angle than the ship's, so when it shoots it goes a little off kilter.

The only difference between a "straight" bullet and a "random" one is that angle offset. That's usually done under the hood by something called a quaternion multiplication. It's not too compute intensive, maybe a couple dozen compiled instructions. These multiplications are already being done at a minimum every time any entity is rotated or changes it's orientation, and probably a good number of other times besides for other purposes. They're used so often that game engines and 3D rendering APIs usually provide a quaternion math library that's pretty good.

So, the question is, is there a technical limitation to randomizing every cannon bullet's angle when it spawns? The short answer is not yes, but maybe. Take a reasonable worst case scenario: 20 ships, each firing 200 cannon/cannon weapons simultaneously (Some people will say it's not extreme enough, but I don't care, I'm just illustrating a point). That's 4000 bullets being created every 1/10 sec. If the game state updates internally at 30Hz, those entities may need to be created in less than 30ms - let's say 10ms. 4000 quaternion multiplications + misc. may add another 50 compiled instructions per entity - let's be conservative and call it 100 for 400,000 additional calculations. A modern CPU can process ~100 billion instructions per second, or 1 billion instructions per 10ms game frame. From an instruction standpoint, it's feasible.

The bigger question is - how efficient is Starmade's game state update routine? How close are they already to busting their update times in stressful situations? Even if it's pretty cheap to add the random bullet angles, it could be the straw the broke the camel's back and caused game lag. Since this game is in alpha, I'm going to guess Schine still has a lot of code optimization ahead of them, and their current game engine may not be ready for the additional stress from random bullets.

I'm not going to assume that, though. Bullet randomness is technically feasible, and the current state of the game shouldn't keep us from suggesting it, even if it takes a while to implement.

This is exactly what I wanted to see as a response in my suggestion. Thank you.

 

[Gasboy]

One thing I notice when shooting AMC, beams, or dumb fire missiles is that they only go strait. This ironically makes aiming difficult and easy at the same time. When a weapon is fired normally there is a Dispersion that fits to a Gaussian curve for other games that have a third or first person view. The further the target the larger the Dispersion.

In starmade there is no dispersion and so the only way you get the feeling of a dispersion is to have a block array of weapons. My stranded for rapid AMC is a small cross or cube array. Now if all weapons had a Gaussian Dispersion I would only use one barrel as at least I'm not always going to miss in the same spot but instead hit many spots more random spots on the ship.

Gaussian Dispersion would also solve the problems with the predictable AMC/missile combo and allow it to act like a more realistic shoot gun.

The thing is, no one really wants the game to be ultra-realistic. More realism means your pilots die when your ship turns because physics dictates an object at rest tends to stay at rest, and an object in motion tends to stay in motion. Your head sits on the end of a relatively flimsy neck, and the first time your ship turned at high speed, well, heads would roll, at minimum. Such fun, yes?

Few people would want randomness introduced for a variety of reasons. For instance, the totally 3D environment means the battlefield... battlearea is incredibly chaotic to begin with. Sure, cannonfire goes in a straight line. However, scant moments after the point of firing, you and your target are likely no longer in the same spots. Sure, that cannonfire goes straight, but you have to guess where your opponent is going to be at the point of impact, not at the point of fire. And in an environment where blues and reds are mingling, no one wants that extra chance of friendly fire. Especially since randomness can actually cause you to shoot your own ship.

And you also have to consider dispersion itself. 1° at 1 meter is a relatively small thing. 1° at 1000 meters is a huge thing. Even .5° means way, way more misses than you seem to think. The frustration of lagbat (combat in laggy conditions, pretty much every large engagement ever) would be further compounded by such introduced randomness. May as well switch to lockon and swarm missiles exclusively, because even if they miss, they'll circle around. And the friendly fire chances of swarm missiles is less than 1000s of cannon rounds per minute missing, unless you're fighting in knife fight range.

 

[Spartan-228]

This is a horrible Idea. Do you even know how hard it is for two ships, even big ones to hit each other with cannons, if they aren't kissing.
Right now it is not easy to eyeball it and hit an enemy ship at raing wile both ships are moving. This would just make it all that much harder. And AI turrets are already have isues with out this.

 

[unelsson]

Great idea that would give unique roles for cannons and beams. Cannons go for damage, beams go for accuracy.

Community is not showing it´s best side though.

 

[Lecic]

Great idea that would give unique roles for cannons and beams. Cannons go for damage, beams go for accuracy.

This would just make it so beams and cannons BOTH need to be close range to hit.

 

[Gasboy]

Great idea that would give unique roles for cannons and beams. Cannons go for damage, beams go for accuracy.

Community is not showing it´s best side though.

The cannons already have a unique role in being the only weapon used for anti-missile systems. They are already a little flaky due to Bobby AI quirks. Adding in extra randomness on top of that kind of defeats the purpose of using an accurate weapon for anti-missile work.

Also, you're right, we should just totally agree with the guy and petition Schema to put this in immediately. It's totally okay even if we disagree heavily with the idea.

That last bit was sarcasm.

 

[Master_Artificer]

This would just make it so beams and cannons BOTH need to be close range to hit.

I think he means beams aren't effected by the randomness, while cannons are. But beams are already useless at range of you or your target is moving because if the beam cant stay focused on a single block for that 1/5th of a second that it pulses, then the damage is "missed", even if you are trying to do shield damage, right? Or is that fixed now? (please tell me its fixed now)

 

[<SCRIPTKITTY>]

Not to make fun of this guys idea, its a valid concept and such, though its questionable in terms of weather it not it fits in this game.

Just about every reply made me think of this:

Don't be Ziodberg. He's a terrible doctor

 

[Zackey_TNT]

No.