Shrugger! Unity!

[Draco18s]

Offer it for free and label it "as is" with "no warranty."

Fair point though.

(Personally I'd spend a buck or two to get a system that works well, even if I have to figure out how to use it myself; set up a wiki for it and your users will document it for you!  I've spent a lot of time documenting Mystcraft's API because it had none and I wanted to use it; it's even constantly changing, requiring me to re-figure things every release or two*).

*I'm actually not supporting the current release(s).  Mostly because they're buggier than usual and 95% of the changes are just API changes, meaning that there's little reason for users to upgrade.

[Shrugging Khan]

I'm trying to find a way to standardise the measurement of difficulty of a shot to be fired, using range, projectile speed, and the target's observed ability to accelerate.

Could I simply use something like ((range * targetAcceleration) / projectile speed) = shot difficulty, or would that get me useless results?

[keith.lamothe]

I'm trying to find a way to standardise the measurement of difficulty of a shot to be fired, using range, projectile speed, and the target's observed ability to accelerate.

Could I simply use something like ((range * targetAcceleration) / projectile speed) = shot difficulty, or would that get me useless results?

I think range / shot_speed is reasonably meaningful, so I guess throwing accel in the numerator would work and make some sense.

But my question is: what exactly are you trying to model here? 

The difficulty of computing what point to shoot at to get the shot to intersect the target, given the target's current position and momentum.

The difficulty of knowing the target's position and momentum precisely enough to compute the above.
- due to sensor inefficiency and/or jamming
- or due to distance and the finite speed of light

The difficulty of predicting changes in the target's momentum.

Mechanical variation and/or failure in the weapon (or targeting routing hardware, whatever), such that it doesn't actually shoot at the point designated, or at the time designated.

Etc.

Accel would only seem relevant to that third one.  And I guess that it would be very relevant there: given a known position, momentum, and acceleration, there's a "cone" emitting from that position of where it would be physically possible for the ship to be at time t.  If you know your shot will cross the distance in 0.5s, and the "width" of the cone at t=0.5 is less than the "radius" of the target, then firing at the center of the cone would effectively ensure intersection (exactly what part of the ship you hit may vary).  Once the target's possible positions no longer have an intersection, then a miss would be possible even with perfect sensors, targeting, and firing.  The miss chance would probably have more to do with how much the target is trying to evade and whether there were any predictable biases of the evading helmsman, etc.

Of course, I'm assuming only one significant point of thrust on the target; if it's a fighter with a massive lateral thruster strapped to one side then its "cone" gets way more complicated.

Anyway, just trying to figure out what you're actually doing here.  If it's just lasers and other light-speed weapons at short range with reliable (and undamaged) weaponry without some terri-jamming there wouldn't really be a miss chance.  If it's mass drivers at 10 light-seconds with a ton of ECM then probably just call it a 10% hit chance for dumb luck   Or reconfigure the mass drivers for "meteor shower".

[Shrugging Khan]

I'm actually working with gunpowder cannons for weapons and coal shovellers for a crew...kidding. Still, boring old ballistic projectiles! (LASERs exist, but are considered high-tech, while Missiles are illegal).

The entire "shot difficulty" affair is meant to give the crew a meaningful variable to which to compare to their track record of previous hits, so that they can decide whether or not they are likely to hit any given target. For example, if they have been able to successfully hit targets with a shot difficulty of 10, then if they are in a situation in which firing is considered to be at difficulty 15, they would likely hold fire until better conditions were established - unless they are forced to fire by direct orders or other circumstances. Or it could let them calculate a hit probability, take stock of their remaining ammo, and make a decision on whether or not they can afford to fire.

The entire concept of a single "shot difficulty" variable might be too much of an oversimplification to work, but I wasn't too sure either way.

[keith.lamothe]

Hmm, yea, not sure what to advise there.

How are you computing whether something actually hits?  Actual collision detection?

[Draco18s]

I think if that you're computing a unitless number (in the example, higher is more difficult, by an arbitrary amount) then its on the player to gauge how good they are.  It is essentially the star system for sodoku: 1 star is easy, 5 star is hard, how good are you?

How a "hit" is calculated should be independent of this, if you're using player skill and should only effect the AI's decision on when to fire but not anything else.

[Shrugging Khan]

Slow down gents. Yes - actual collision detection. When firing a gun, a portion of the ships mass is converted into a new GameObject with a rigidbody, collider and a physicalObject script attached. The rigidbody is immediately accelerated by an amount of force dependant on the amount of gunpowder used, and from there on out it's treated as a physical object like any other. When it hits something smaller than a moon (debris, rocks, ships, other projectiles), the physicalObject script gets some relevant information from the collider and proceeds to ponder the nature of the collision according to my limited understanding of kinetic physics. (projectile material and mass, angle of impact, deflection, penetration, deformation, heat from friction and so on.)

It's all rather overengineered (and unfinished, at present), but I like it this way. Fewer shots are possible before the CPU waves the white flag, but every shot is special :>

Anyways, yeah. I'm not determining the actual hit probability here; just what the crew of the ships assumes it to be, in a rule-of-thumb fashion. It's really meant for comparison rather than as an actual measurement of probability.

[keith.lamothe]

just what the crew of the ships assumes it to be

Hmm, you may need to factor in the crew's average, median, and maximum blood-alcohol level.  Or equivalent, depending on alien biochemistry.  Also, whether or not the proper shanty is being sung.


Anyway, I think your suggested (range/shot_speed)*accel is a decent approximation

[Shrugging Khan]

It's actually a bit of a plot point that militia ships are not allowed to be computer controlled (missiles are subject to the same law), and tend to be manned by scores of barely-qualified personnel that tend to live off biscuits and morale. I thought it would be more interesting this way - I don't want to break the laws of physics to make a space game interesting, but having limiting legalities seemed to be an acceptable way of keeping the combat relatively personable. Otherwise it would have likely been nothing but tiny drone craft throwing missiles at each other from half the solar system away. A bit like The Forever War, really...but that's not very fun. That, or it would be a physics orgy of orbital mechanics. As I plan it right now, by keeping advanced machinery out of the combatants' hands, it will be a lot more close-range and exciting.

So yeah, I'll just use some sort of ( Range / Projectile Velocity), multiplied by the target's agility unless the shooter has the initiative.

[Aklyon]

Might not help much, but all of this talk of aiming correctly reminds me of Transcendence.
That had a facings system, but if you could aim well and/or drift right, you could snipe large things from maximum range of your current weapon, assuming your current weapons would actually do more than chip damage against said large objects . Having bad aim tended to get you nowhere fast unless you were using an omnidirectional instead and sacrificing power for much more forgiving aim.

[Shrugging Khan]

Been working on my geology project again. Simulating aeolian erosion as a simple random vector that checks whether a geological unit is open to the wind (or covered by its neighbours), I'm using a formula that calculates the wind vector's y component as

Code: [Select]

Mathf.Pow(Random.Value, windFlatness)with windFlatness obviously determining whether the wind actually comes from random angles with a tendency towards the horizontal, or just from any random angle above the horizontal. Now, my question is: How badly would increasing windFlatness affect performance?

[Draco18s]

I am not sure that that is going to do what you want it to do.

Not without knowing the range of values for windFlatness

[keith.lamothe]

Performance-wise, Mathf.Pow with non-integral exponents isn't any fun.

[Shrugging Khan]

What's the performance-optimal way to make objects keep track of time?

All of my physical objects are using an attribute to store time passed, and per-frame checks in Update() to see whether the time has reached the point at which they need to do something. In the past, I did it like this:

Code: [Select]

int time = 0;
int frequency = 12;

Update() {
   time ++;

   if (time % frequency == 0) {
      time = 0;
      DoThings();
  }
}

Some variations also checked if the timer had exceeded a certain limit, or reset the timer only once it reached a certain limit.
Now, I noticed that that system is fine when the frame rate isn't an issue, but it kinda breaks down when it comes to flexibility. So I tried this:

Code: [Select]

float time = 0;
float frequency = 12;

Update() {
   float += Time.deltaTime;

   if (Mathf.RoundToInt(time % frequency) == 0) {
      time = 0;
      DoThings();
  }
}

But that's a lot more resource-hungry, not to mention that it triggers several times in a row (with the RoundToInt) or almost never (without it), so it's not even a solution.

I'm probably trying to work out a roundabout solution while much simpler ones already exist...I think?

Help, please? :/

[keith.lamothe]

What's the performance-optimal way to make objects keep track of time?

All of my physical objects are using an attribute to store time passed, and per-frame checks in Update() to see whether the time has reached the point at which they need to do something. In the past, I did it like this:

Code: [Select]

int time = 0;
int frequency = 12;

Update() {
time ++;

if (time % frequency == 0) {

}
}

I guess it depends on what you're trying to do and how many things you have doing it.  One low-change optimization there is to drop the % operation (involves division, which generally consumed significantly more processor cycles than add or branch instructions) in favor of "time >= frequency", and doing "time -= frequency" inside the branch.

But the more fundamental issue is: if Update is called once per frame (and never any other time), then why is this concept of time independent of how long it's been since the last frame?  In our stuff we set our "Game.Instance.GameDeltaTime" field to Unity's "Time.time" at the beginning of each Update call, and use the former whenever we need to increment something's idea of how much time has passed.  Though we only store "time remaining until" or "time saved towards" variables when specifically necessary.

Of course, Time.time is a float, so operations on it are substantially slower than the int math you're doing there, but the most important optimization is correctness   The question here is "what is correct?".