If it flies, it dies™.

RSS Understanding physics scaling in World in Conflict and MW Mod 6.0 Updates!

Posted by on

Understanding Physics Scaling in World in Conflict

WiC MW Mod portrays combat in around 20-30km of effective front line battlespace for application of most tactical weapons. Weapons of more strategic assets (such as ballistic missiles and cruise missiles) make certain geometry compromises to fictionally portray them in such a small battle space.

FLINT (Flexible Interceptor) is the code base and common source library written in Python which provides much of the physics and guidance algorithms for agents acting as projectiles in game. Agents in game using the FLINT system have completely replaced WiC's HomingShooter and BallisticShooter projectile types altogether.

The problem of small maps

Maps in World in Conflict are statically limited to a square of 1.5km by 1.5km (2.25km^2). Every map is the same size at 2.25km^2 regardless of how the map creator wishes to size his map. Smaller maps are possible by simply disabling play field, but the size of the map remains at 2.25km^2. While EX3D World could address larger coordinate space (10km by 10km is tested so far) to potentially enable future addition of off-map assets, the small playfield of 2.25km^2 that is usable by players severely limits the application of any modern combat systems.

The goal of the MW Mod isn't to simulate realism, but instead, provide an "authentic" combat system experience in a fun arcade setting, where any casual player would enjoy authentic portrayal of modern weapon systems, without expectation of perfect realism or excessive complexity. In order to meet this authenticity in player experience, various physics properties will have to be scaled down fictionally, in order to provide the additional battlespace as required by MW Mod.

Distance (range scale down)

Unit-to-unit separation distance in FLINT is scaled by a factor of 10. For example, 100 meters would equate to 1 kilometer in game; thus, 1500m by 1500m map is now 15km by 15km. Altitude is also scaled down at the same factor by 10. 350 meters altitude height would equate to 3.5km or 11482 ft.

Even with scale down by a factor of 10, weapon systems will have to be range limited for balancing reasons. For example, while Hellfire missile in game kinematically could hit targets out to ~7-9km (depending on trajectory shaping), its firing range is limited to 4.5km by shooter's launch inhibit setting. Of course, players can often cheat range limits by using laser-guided Hellfire (not Longbow) and firing the missile at a blank terrain out to 4.5km as maximally allowed, then extending its range in flight by lasing a further away target with JTAC infantry. Kill distances of up to ~7.5km was reported by players using this method.

Velocity, movement speed, etc.

Unfortunately, simply scaling everything down by a factor of 10 does not work in practice. Everything will look ridiculously small to the point of ruining the game experience. For example, consider that speed of sound (1.0 Mach) in SI meters is ~343m/s. Scaling this down by 10 would mean 34.3m/s, which is roughly about the speed of a scout helicopter in vanilla WiC -- you see what I'm getting at here: everything is going to be so slow and look awfully stupid. Thus, speed-of-sound in FLINT is 60 meters/second, which represents downscale factor of 5.72 times.

Not everything can be scaled down as well. We don't want to make tanks and vehicles move 10 times slower, so vehicles generally move at 8-9 meters/second. When comparing this to the FLINT referenced speed of sound, this means vehicles are effectively moving at 185km/h, which is an impossibly insane speed for a tank, but we choose to ignore the same scale restrictions on unit movements for playability purposes. Having said that, no player usable unit (except for jets) will ever move faster than 28 meters/second in FLINT physics scale -- no user controlled agents may ever reach velocity faster than half of simulated speed of sound, in order to maintain an intricate balance of game playability vs. experience & feel.


Gravity is inversely proportional to the square of the distance from earth. However, gravitational acceleration (1G) in FLINT is capped at approximately 8.75m/s/s. This means
that for up to about 372km altitude, gravity is constant at 8.75m/s/s in FLINT's reference scale -- gravity effect will be the same for an object regardless of whether it is 40km high or sitting on ground level. Above 372km altitude (for IRBMs, SM-3, etc), FLINT proportionally decreases gravitational acceleration inversely with increasing distance.

Dynamic Pressure

Calculation of Dyn Q in FLINT uses real world SI units and US Standard Atmosphere model -- we actually want aerodynamic forces to affect projectiles faster in our small battlespace, so we chose not to scale things down here. This means at roughly around 32-40km altitude, dynamic pressure will practically become close to zero. Currently, only PAC-3 MSE and ballistic missiles can reach this level of 'drag-free' altitude (SM-6, which is under development, is also expected to reach near this altitude at around 31-33km peak height). How the re-entry physics and drag forces will work at even higher altitudes (above 86km) is an ongoing area of study and research for future developments.

Because Dyn Q is computed at real world SI units and atmosphere model, while everything else is scaled down, this does create some interesting observations (though does not ruin the game experience). One of which is excessive G load placed on agents after cessation of thrust whilst under high pressure. While it is normal for rockets to momentarily experience high G load after motor burn out at low altitudes where atmosphere is thick, in FLINT, this effect is more pronounced. It's possible for AIM-120 in game to pull 14 G's at peak simply by the blunt force of atmospheric pressure at lower altitudes after motor burnout. Not an issue from gameplay or authenticity perspectives -- this is simply an observation of having projectiles affected by drag faster in WiC's small world size, compared to other units of measure being scaled down.

Issue of Barometric Altitude

While simulation of Dynamic Pressure substantially improves authenticity and realism feel of rockets in motion, a critical caveat is the issue of reference for the actual altitude in game.

Dynamic pressure is dependent upon barometric altitude from mean sea level. However, FLINT currently does not use barometric altitude, but uses ground-referenced altitude, which is not correct. This means, having excessively high mountains in the game map will have little effect on increasing launch performance of the rocket, as the point of barometric pressure reference is incorrectly made from ground level, not from sea level. But, if the rocket launches at the edge of a tall cliff, it would immediately gain from the altitude benefit, as it would be flying higher once it clears the cliff's edge.

Because of this, the only way rockets could surely benefit from high altitude in game today, is by being launched from aircraft, not from tall terrains. Not really a big issue right now, as you'd have to have a pretty tall mountain to provide a measurable benefit for rocket's aerodynamic performance on launch.

This however creates some minor problems in physics with respect to projectiles in motion. For example, objects in free fall will continuously accelerate until increasing atmospheric pressure cancels out the gravitational acceleration -- when this is achieved, it is said that the object has reached "terminal velocity".

Once terminal velocity is achieved, unless the object changes its drag profile while falling (such as breaking apart or deploying a parachute), object will continue falling down at constant velocity which is at an equilibrium of gravitational acceleration vs. increasing atmospheric density. Because of the lack of barometric altitude reference by FLINT, dynamic pressure will change slightly as object traverses over different terrain profiles -- this will make deviations in drag force, where terminal velocity in FLINT is only approximately constant and deviates as the object moves over different terrain heights.

We're looking to fix this caveat and introduce barometric altitude in future versions of the mod, though it isn't really high on the priority list. It is currently an area of research and test with respect to the game itself -- the main issue is that every map uses different water table level in WiC; it is entirely up to the map creator to determine at what height water table will appear in WiCEd tool. So, we will have to find a clean way to load each map's .Ice parasites to find the water table level, or estimate a best guess average of the mean sea level across commonly played maps.

Missile Orientation Rendering

FLINT 7 introduces 3x3 rotation matrix to compute object orientation, which is then converted to yaw and pitch angles to be rendered in game. Unfortunately, WiC CopterMover does not provide a mechanism to alter roll orientation, so the computed roll angle is ignored and not rendered (though this may change in the future via a crude hack).

The introduction of rotation matrix allows orientation rendering from the object's local frame of reference, which is then converted to world space for EX3D rendering. One of the key benefits of moving to the new rotation based rendering is that it allows us to easily render angle-of-attack (AoA) orientation of the missile. Quaternion rotation is under development for the Next Generation EXFLINT Renderer (NGEX), where a single quaternion will replace yaw, pitch and roll computations entirely.

This new method of rendering object orientation finally solves the difficult "vertical launch orientation" problems we've had in the past. This was one of the most annoying holy grail issues during MW Mod development, where vertically launching missiles such as Tor M1 and S-300 were very difficult to orient properly in the game. This was one of the major stumbling blocks that prevented naval unit developments for a while, as missiles are vertically launched from the ship's VLS. You may notice that S-300 and Tor M1 missiles now look beautifully realistic and work flawlessly in FLINT 7 (MW Mod 6 development) videos, compared to older versions -- this is the result of the new orientation rendering.

Angle of Attack (AoA) and Induced Drag

As missile flies higher, atmospheric pressure goes down with increasing altitude. However, the weight force on the missile does not change (actually fuel consumption does lower weight, but let's call that negligible for the purpose of this discussion). With decreasing lift, the missile is continually being pressed down by gravity and guidance system has to work harder to keep the missile flying in the air -- thus, more lift force is required to overcome the force of gravity. To aid in this, missile's angle of attack is increased to generate more lift by forcibly inducing more drag -- you may notice that cruise missiles flying at higher altitudes in game are pointing their nose up by a few degrees to increase the generated lift and help stay afloat in the air.

Looking back in time..

Since the early experiment known as "Flexible, Advanced Air Interceptor Missile Script" (later simplified to "Flexible Interceptor", shortened as 'FLINT') during early days of World in Conflict modding back in 2010, MW Mod development has come a long way in changing the way modern combat systems are portrayed in World in Conflict. Proportional Navigation (PN) theory was understood and implemented for the first time in July 2011, resulting in a major breakthrough in homing missile development for World in Conflict.

The implementation of PN in FLINT was inspiring to say at least, and it's awesome to see that more games and mods are implementing PN as their preferred choice for lead-pursuit homing missiles as well. We're looking forward to collaborating more and will begin pushing more code samples at our Github page (Github.com)

Another aspect of important recent development is the launch of Massgate.org, a community run Massgate service for World in Conflict, which was made possible by Nukem's decoding of the Massgate protocol infrastructure. This also resulted in an extremely positive development for MW Mod as well, especially in debugging new features.

After the Massgate.org implementation, EX-WCC (EX World Weapons Control Computer) runtime environment was also developed, to unify all complex air and missile defense complexes in game under a single program entity. The EX-WCC has a stack machine interpreter for basic tasks, a process scheduler and a dispatcher, and simulates execution environment using POSIX standard model. Using the EX-WCC virtual machine, several different elements in the game (e.g. Aegis, Patriot/IBCS, surface fires, etc) are all able to work together in a cooperative fashion.

Moving forward..

We're planning to deliver MW Mod 6.0 Release this year, with first implementation of naval asset on BLUEFOR side, and corresponding coastal anti-ship/maritime strike capability on REDFOR side, along with lot of improvements made to ground combat elements. As of now, MW Mod 6.0 development is about 65% complete; only major work that is left is complete rewrite of 3M55 Oniks (SS-N-26 Strobile) supersonic cruise missile for REDFOR side. We're not sure if SM-6 will make it to 6.0 release, it may or, may end up being pushed to post-6.0 release, but we shall see.


Fantastic writeup Blahdy, looking forward to see where you guys take this fantastic piece of software engineering!

Reply Good karma Bad karma+2 votes
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Last Online
United States 🇺🇸
Become friends
Member watch
92 (1 today)