Yes, all that is required is reworking the appropriate game mechanics, or just accepting a new situation. capacitor recharge rates work differently with a smaller time resolution, which makes larger guns somewhat quicker to recharge. movement is altered by a shorter time interval as another example.
In a real time game we get around issues like this using Frame-Independent-Movement. Basically we use the time taken to render the last frame (Commonly called delta time) to adjust thing like movement, recharge times etc.
As an example for a take a player who moves at 10m/s and a delta time of 0. 01667, we would calculate his movement using:
PlayerSpeed = PlayerSpeedPerSecond * DeltaTime
PlayerSpeed = 10 * 0. 01667;
PlayerSpeed = 0. 1667m/s - We only move 16. 67cm that frame.
This scale up for any size delta time.
Applying this to an Aurora Like game, for a ship that moves 1000km/s and an interval of 5 seconds:
ShipSpeed = ShipSpeedPerSecond * Interval
ShipSpeed = 1000 * 5
ShipSpeed = 5000km/s.
Or for Power Recharge rate of 5 Power per Second, and an interval of 5 Seconds:
PowerRecharged = RechageRate * Interval
PowerRecharged = 5 * 5
PowerRecharged = 25.
The thing is to pick one single time unit as the standard unit (in this case a second) and them measure everything in that, m/s, Km/s, Power Recharge per Second, etc. This allows us to use a scalar (delta time) to adjust it.
The one problem with the Interval method is that with larger interval you won’t get compounding affects you get with smaller intervals around acceleration and the like. This could be solved by either always processing in the smallest possible increment (impractical?) or by using formulas like those used when calculating compound interest in finance when using anything larger than the minimum interval.
aurora does not resolve distances smaller than 10km I think, and any ship moving faster than 2 km/s can clear that. with a 20th of a second interval all of the sudden any ship not moving atleast 200 km/s won't be able to move without some specialized handling. My solution thus far is to resolve distances down to 1km, and again do said specialized handling.
As you say these resolution/collision issues need to be resolved using special cases, however if you code the game right this shouldn’t be too had either. A couple of ideas I’ve used include:
Ray Casting: Extend a ray (line) out in front of the ship in the direction of travel and see if this ray intersects any other objects (or any 10km square containing an object). If it does, see if the distance to that object is less then how far you will be moving for this interval, if the distance is smaller than process a collision, else just move. This can all be done using vector maths, a good physics library will have most of this already implemented.
Spatial Partitioning: This can allow us to resolve down to much smaller distances, but only when actually required. First we divide a system up into a grid of squares, say 100,000km to start, if 2 (or more) objects for which we need to process a collision are in the same grid square (say a ship and a missile) then we divide up the the square into even smaller squares, say 1000km and check again. We can keep doing this until we get down to a scale where we can say for certain what is going on. In your case you could use a similar concept to this, resolve down to 10km normally, if things are happening inside a 10km square area then resolve down further, keep going down until things make sense.
Another issue is lightspeed. lasers will travel the appropriate distance for a 5 second interval under all situation(except max tech pdc lasers, who get to travel a little faster), but with a smaller time interval how should that be handled? just FTL lasers? laser "packets"?
Light is probably the hardest thing to work with because it moves so dam fast! One way to handle it is to treat a beam weapon as a ray (as describe above), if that ray collides with ANY object in a minimum increment then a collision is assumed to occur. If it could have collided with multiple objects then whichever is closer is the one that gets hit.
It’s all possible it’s just a matter of deciding at what point it feels “real” enough that we can stop processing to smaller resolutions, that’s what play testing is for, and if we can achieve “real” given the limits of the processing power available.
/endrant
Regarding Pulsar4x, are we going to change the way the increment work, maybe go real time + pausing?
Also RE months and Imperial Verses Metric, I say use Metric and Seconds/Minutes/Hours/Days/Years in the simulation and then add options for displaying Months and units in imperial into the UI later. The important thing is to keep what the engine/simulation uses internally consistent.
