If it flies, it dies™.

Blog RSS Feed Report abuse Ballistic Missiles and WiC

1 comment by blahdy on Aug 26th, 2014

Had some interesting tech discussion with a buddy of mine and the discussion revolved around WiC MW's portrayal of ballistic missiles and the authenticity of battle space. "Battle space" in missile defense parlance, is the altitude/distance (kinematic space) and the 4th dimension, the "time" which defenders have to detect, track and engage an incoming missile.

The higher altitudes your SAMs could go, the bigger your battle space is. This is evident in history of interceptor development -- from the Reagan's SDI ("Star Wars") days, the endo-atmospheric rocket-based kinetic interceptor experiment was called "FLAGE (Flexible Lightweight, Agile, Guided Experiment)". After a successful demonstration of hit-to-kill concept with FLAGE in 1987, the SDI project moved to put this concept into practice, and a new project called ERINT (Extended Range Interceptor) was born.

Right from then in the later years of SDI during 1980's, the new paradigm shift in missile defense development was to "increase" the battle space -- intercepting targets in high altitudes gives you two benefits: (1) debris mitigation -- especially very important for chemical-bio payloads; and (2) more battle space means you have more opportunity to intercept, if first attempt fails. The "ERINT-1" prototype missile specified a much higher 28km intercept altitude, aided by low-noise seeker and 180 side thrusters to provide agility. Fast forward to 1994, the "ERINT" technology concept was chosen to become what is now known as the PAC-3 missile segment (yes, PAC-3 missiles are vastly different than the PAC-2 missiles and share no family lineage whatsoever; PAC-2 is the original Patriot missile, PAC-3 is SDI/Star Wars ERINT missile).

WiC Environment

In WiC, playfields are vastly small so we have to downscale a lot of things. Maps are only 1500 meters by 1500 meters maximum, which means, diagonally speaking, the maximum point-to-point distance you will have in game is about 2000 meters or so. So rather than calling these meters, we just call them "wic meters" or 'wm', because of the down-scaling we have to do.

One interesting feature in WiC and Ground Control EX3D world is that while playfield is limited, the game's skybox is virtually unlimited. It takes about 230km of draw distance before the game quits rendering the sky. This virtually unlimited sky box meant that ballistic missiles and anti-ballistic missiles could be portrayed with significantly less down-scaling than ever before, making the engagement feel more realistic.

Basics about Ballistic Missiles
Ballistic missiles really work in orbital and ballistic mechanics. In the simplest form, they are no different than throwing a stone up in the air and aiming it so it lands on the right spot. But since they are "missiles", they have guidance systems that make sure that the missile continues to point to the right launch angle until its booster burns out. Once it's in the space, it's total free fall. We will refer to the 'apogee' of the flight as Peak Altitude below.

Missile Data in WiC

So here is some data about ballistic missiles in WiC and their relevant speeds, altitudes, etc. Note that "wm" stands for 'wic meters' -- meters portrayed in WiC's down-scaled world.

  • SS-21 Scarab (9K79 Tactical Missile Complex Tochka U):
    Peak Altitude:
    4,705 wm (equivalent to about 47-50km in real life)
    Re-entry speed (speed at atmospheric ceiling interface): ~Mach 4.9 - 5.0
    Terminal velocity at impact: ~Mach 3.3
  • MGM-168 ATACMS:
    Peak Altitude: 4,476 - 4,650 wm (equivalent to about 44-49km in real life)
    Re-entry speed (speed at atmospheric ceiling interface): ~Mach 4.9 - 5.0
    Terminal velocity at impact: ~Mach 3.1 - 3.3
  • SS-26 Stone (9K720 Iskander M):
    Peak Altitude: 5,095 - 5,680 wm (equivalent to about 50-56km in real life)
    Re-entry speed (speed at atmospheric ceiling interface): ~Mach 5.7 - 7.1
    Terminal velocity at impact: ~Mach 3.3 - 4.4 (depending on terminal maneuvers)

Note that terminal velocity is slower than re-entry speed -- yes, this is because FLINT engine in WiC actually simulates and calculates atmospheric pressure (drag), decelerating the missile as it negotiates atmospheric pressure at lower altitudes.

You can see that Iskander M comes with highest speed and the most devastating performance of all. Its terminal velocity has the greatest variance, because it throws 10-20G lateral maneuvers while it's coming down at Mach 6+, in order to make interception more difficult. This slows down the missile and exerts great deal of energy loss -- finally, missile then locks onto IR signature and tries to hit a moving target -- another huge G's it has to pull.

Interceptors in WiC:

Let's take a look at counter defenses in WiC for ballistic missiles now:

  • PAC-3 MSE:
    Maximum intercept altitude: ~3,216.2 wm (equivalent to about 32km in real life)
    Typical intercept altitude: ~900 - 2,800 wm (equivalent to about 9 to 28km in real life)
    Maximum speed in game: ~Mach 3
    Maximum defended footprint size: ~2.25 kwm^2
  • PAC-2 GEM-T:
    Maximum intercept altitude: ~2,200 wm (equivalent to about 22km in real life)
    Typical intercept altitude ~450 to 1,800wm (equivalent to about 4.5 to 18km in real life)
    Maximum speed in game: ~Mach 3
    Maximum defended footprint size: ~0.42 kwm^2

Based on these factors, it takes on average of about 14-17 seconds for PAC-3 missile in game to fly out of the launcher and reach its target at about 2,200 wm altitude. ~15 seconds is very realistic feel in portraying missile defense engagement times, as it is also about the same time it takes for a real-life PAC-2 missile to intercept a ballistic missile target at low altitudes. Engagement times could last for as long as 20-30 seconds in real life, but 15 will do for us in WiC.

Some interesting facts for missile defense system in game:

You'll note that sometimes you'll see a flash "bang" effect when a PAC-3 hits something in the high altitude, but sometimes you don't see anything (yet you know target got intercepted b/c your TA/score just went up). When a target gets intercepted and you don't see the "flash", the interception had likely occurred above 2,100 wm height. Particle effects do not draw at distances longer than 1,500 wm. If you see the flash, but it seems very high, then the target got intercepted at around 1500-1900wm, which it would still be traveling extremely fast (pretty much close to reentry speed with some deceleration).

The "TLL" parameter you see next to TBM count in Patriot message display stands for "Time to Last Launch" -- the amount in seconds the system has to launch its interceptors, in order for them fly up there and hit the target before it becomes unengageable. "Unengageable" means, the target has breached the minimum altitude distance, where it is now impossible to intercept geometry-wise.

Sometimes you'll see a ballistic missile coming down with TLLs decreasing pretty fast (i.e. 13s then 12s, 9s, etc) -- it's probably an Iskander coming down at Mach 7. Or, sometimes you'll also see the rate of "TLL Drop" suddenly slow down or reverse itself where it increases -- this can be caused by one of two things: either (1) the ballistic missile has hit the atmospheric ceiling and is decelerating quite hard due to drag; or (2) it is probably an Iskander that's currently pulling 20G lateral maneuvers, burning energy and slowing down its free fall in the process.

When TLL reaches negative (number turns to red), no more interceptors can be launched -- if the existing interceptor already launched misses its target, it's now considered a "leaker" and no further intercept attempts can be made.

Report abuse Cruise Missile Navigation AI for World in Conflict

1 comment by blahdy on Aug 22nd, 2014

Cruise missiles are essentially unmanned aircraft (just without recycle feature). For accurate portrayal of such weapon for World in Conflict, we need to make sure they use a set of navigation waypoints, flying low (at height of between 25 to 50 ft) and evading radar detection.

We would prefer that the cruise missiles use fly around the edges of the map, preferring to avoid contact with enemy and maintain the element of surprise for as long as possible -- at the expense of missile taking much longer to arrive on its target.

In order to program such artificial intelligence into the system for navigation, we use Shortest Path First implementation utilizing Dijkstra algorithm. Every waypoint known in game map is a "node", and distance to every node is known and calculated, to dynamically calculate a flight plan based on the least amount of total "link cost" across the entire path. Come to think of it, Dijkstra algorithm is also very popular with internet routers for calculating shortest paths on network's Interior Gateway Protocol (IGP) topology.

python code:
def Generate_Waypoints( self ):
  global nodes
    RGM-109E Tactical Tomahawk for WiC MW
    En Route Navigation for TERCOM mid-course guidance
    Rather than running straight to the target and have everyone
    and their grandmother shoot at the Tomahawk, we'd prefer the
    missile to fly low and sneak around on the sides of the map,
    using a set of waypoints.  It will take longer to get there,
    but it allows the Tomahawk to minimize radar detection and
    maintain the element of surprise.
    Calculate the shortest 2D world waypoints (X, Z) for the
    cruise missile to navigate thru to approach the terminal
    acquisition area (kill box).  Upon arrival, missile will
    need to transition from en-route control (mid-course) to
    terminal guidance, pitching up to about 100wm height and then
    diving onto the target.
               1500 +------------------+--------------------+
                    | (*7) Delta     (*6)      Charlie (*5) |
                    | 1490,0,10     November    1490,0,1490 |
                    |              1490,0,750               |
                    |     Grid         |           Grid     |
                    |      D           |            C       |
                    |                  |                    |
            X   750 +-(*8) Whiskey-----+----------Echo (*4)-+  
           axis     | 750,0,10         |         750,0,1490 |
                    |                  |                    |  
                    |     Grid         |           Grid     |
                    |      A           |            B       |
                    |               10,0,750                |
                    | 10,0,10        Sierra       10,0,1490 |
                    | (*1) Alpha      (*2)       Bravo (*3) |
                  0 +------------------+--------------------+
                                      750                  1500
                                     Z axis
    Navigation nodes
    alpha: 1     sierra: 2     bravo: 3   echo: 4
    charlie: 5   november: 6   delta: 7   whiskey: 8
    Implement ECMP routing for salvo fires against target grids
    having equidistant paths?

  INAV_MAX_COST = 32768
  def SPF(graph, start, end, visited=[], distances={}, predecessors={} ):
    # Dijkstra Shortest Path First (SPF) Algorithm
    # Credit to/courtesy of:  http://rebrained.com/?p=392
    # First time init
    if not visited: distances[start]=0
    # Terminal node: find path to it and return
    if start==end:
      while end != None:
      return path[::-1]
    # Process adj nodes and keep track of predecessors
    for neighbor in graph[start]:
      if neighbor not in visited:
        neighbordist = distances.get(neighbor,INAV_MAX_COST)
        tentativedist = distances[start] + graph[start][neighbor]
        if tentativedist < neighbordist:
          distances[neighbor] = tentativedist
    # adj nodes processed, mark current node as visited
    # Find the closest unvisited node to the start
    unvisiteds = dict((k, distances.get(k,INAV_MAX_COST)) for k in graph if k not in visited)
    # Get the minimum key in dict unvisiteds
    # This method requires python 2.5+... WiC cpython uses 2.4:
    #    closestnode = min(unvisiteds, key=unvisiteds.get)
    closestnode = min([ (unvisiteds[x],x) for x in unvisiteds ])[1]
    # Now take the closest node and recurse, making it current
    return SPF(graph,closestnode,end,visited,distances,predecessors)
  nodes = {
      1: math.Vector3( 15, 0, 15 ),
      2: math.Vector3( 15, 0, 750 ),
      3: math.Vector3( 15, 0, 1485 ),
      4: math.Vector3( 750, 0, 1485 ),
      5: math.Vector3( 1485, 0, 1485 ),
      6: math.Vector3( 1485, 0, 750 ),
      7: math.Vector3( 1485, 0, 15 ),
      8: math.Vector3( 750, 0, 15 )
  # Get the nearest ingress &amp; egress enroute waypoints for missile
  # launch location and desired target coordinates (terminal basket).
  start_max_dist = INAV_MAX_COST
  end_max_dist = INAV_MAX_COST
  for i in nodes:
    len_to_start = ( math.Vector3( self.current_state ) - nodes[i]).Length2D()
    len_to_end = ( math.Vector3( self.PN_Terminal_Basket ) - nodes[i]).Length2D()
    if len_to_start < start_max_dist:
      start_wp = i
      start_max_dist = len_to_start
    if len_to_end < end_max_dist:
      end_wp = i
      end_max_dist = len_to_end
  # SPF link path costs; IGP adjacencies
  graph = {
    1: { 2:7, 8:7 },
    2: { 1:7, 3:7 },
    3: { 2:7, 4:7 },
    4: { 3:7, 5:7 },
    5: { 4:7, 6:7 },
    6: { 5:7, 7:7 },
    7: { 6:7, 8:7 },
    8: { 7:7, 1:7 }
  self.ENR_waypoints = SPF(graph, start_wp, end_wp)
  return True
Report abuse Command to LOS (CLOS) Guidance Implementation

0 comments by blahdy on Oct 26th, 2013

Implementing the Command to Line of Sight (CLOS) guidance method in World in Conflict (also can be ported to other game environments).

YouTube Video:
Link - Youtube.com

python code:
def GCFLINT_Command_to_LOS( msl_pos, launcher_pos, tgt_pos, latax, cre_data, beam_motion_data ):
    Command to Line of Sight (CLOS) Guidance
    msl_pos     = (Vector3) missile's current position
    launcher_pos  = (Vector3) launcher's current position
    tgt_pos     = (Vector3) target's current position
    latax       = (Mutable Vector3) mutable object for providing guidance command
    cre_data    = (Mutable dict) dict object for Kalman estimation states on CRE
    beam_motion_data = (Mutable Vector3) mutable object for recording previous
               beam motion
    Command to LOS (CLOS) Guidance or "three point guidance" is probably the
    oldest and the first rudimentary form of missile guidance methods.  
    Tracing its roots back to the Nazi Germany's Wasserfall experimental SAM
    and early forms of anti-shipping guided PGMs, it was originally conceived
    as Manual Command to LOS (MaCLOS or MCLOS), where a human operator
    remotely steered the missile along his visible line of sight toward the
    After the World War, MCLOS was further modified with improvements in
    sensors and analog computing technology, spawning new derivatives such as
    Semi-Automatic Command to LOS (SACLOS), Automatic Command to LOS (ACLOS or
    simply CLOS) and Beamriding Guidance.  In case of SACLOS, the operator has
    to maintain his sight on the target and the guidance computer will
    automatically generate the necessary steering commands to the outgoing
    missile -- a good example of this is BGM-71 TOW missile.  Fully automatic
    CLOS (ACLOS) was used on first generation SAMs (i.e. Talos, Nike Zeus, etc).
    Even to this day, ACLOS is widely popular for cheap short-range AA uses
    (i.e. SA-22 Pantsir/SA-19 Tunguska, Crotale, RBS-70, Roland, etc), because
    the missile is very cheap to manufacture (there is no need for seeker and
    complex embedded electronics).
    CLOS works on the premise that the target, outgoing missile and the launcher
    are all on the same Line of Sight (LOS) line.  As missile is outgoing, the
    guidance computer on the launcher will steer the missile to snap it on its
    sightline/LOS toward the target.
    The outgoing missile's distance normal to the launcher-to-target LOS (that
    is, how far the missile is off from the LOS line) is known as the
    'Cross Range Error' or 'CRE'.  It is this 'CRE' that the guidance computer
    will have to reduce to zero in order to get the outgoing missile to snap
    back on the LOS line toward the target.  CRE is to be calculated as follows:
    CRE = |radar_to_missile| x<cross product> |radar_to_target|
    The guidance computer will calculate the required lateral acceleration to
    bring CRE to zero, where:
      required acceleration = K * CRE + Beam_Motion_Term
      K = optional Guidance Gain
    Because CLOS relies on the launcher-target LOS as its principal tracking
    reference, it is quite vulnerable to high velocity situations, especially in
    situations where the target is crossing; in such cases, it can behave as bad
    as pure-pursuit/tail-chase homing guidance.  To help mitigate the increased
    acceleration requirements against crossing targets, a "Beam motion" term is
    added after the guidance command.  Beam motion is the target's acceleration
    normal to the launcher-target LOS.
    Addition of beam motion term allows CLOS missile to more quickly react to
    changing LOS rate, but ultimately, CLOS is at best, good for producing lot
    of cheap anti-aircraft and anti-slow-moving (i.e. tank) missiles.  For
    intercepting high performance targets with good accuracy, or to achieve
    sophisticated "hit to kill" type of interception, you would want to use one
    of the modern derivatives of Proportional Navigation (PN) family of
    guidance methods.

  import wic.common.math as math
  from predictorFCS_flint__includes__ import EXFLINT_Kalman_Filter
  launcher_to_msl = math.Vector3( msl_pos ) - launcher_pos
  msl_heading_direction = ( math.Vector3( tgt_pos ) - msl_pos ).NormalizeSafe()
  command_los = math.Vector3( tgt_pos ) - launcher_pos
  # Cross Range Error (CRE) -
  # radar_to_msl <X cross product> radar_to_tgt * ( 1.0 / radar_to_target )
  CRE = EXFLINT_Kalman_Filter( cre_data, ( launcher_to_msl.Cross(command_los) * ( 1.0 / command_los.Length() ) ).Length() )
  # Beam motion term -- perceived target's inertial acceleration normal
  # to Line of Sight
  Bmp = math.Vector3( tgt_pos ) - beam_motion_data
  beam_motion_data = math.Vector3( tgt_pos )
  # Now, calculate the final Lateral Acceleration required for our missile
  # to home into our target.
  latax = msl_heading_direction * CRE + Bmp
  # my job is done, it's now up to EXFLINT.Integrate() to steer the missile.
  return True
Report abuse The Story of World in Conflict MW Mod

1 comment by blahdy on Sep 5th, 2012

The Story of World in Conflict MW Mod

The Beginnings: Air and Support Roles in WiC

Initially, WiC had a simple arcade battle concept of rock-paper-scissors. The most powerful role of World in Conflict is arguably the Air role. Even though Air cannot capture nor hold the ground, its high mobility meant that an air player could set the terms of the battle, forcing the defenders to respond when and where he chooses.

This phenomenon was clearly noted during ESL and CPL professional league games between 2007 and 2009. The fact that Air player sets the tempo of the battle and acts as a primary TA generator for his team speaks volume about the role's powerful capabilities in the game.

However, in order to balance the game, Air's real power projection capabilities have been limited to very short, within face-to-face ranges. Likewise, air defense units also have such smaller ranges. Against a seasoned air player, Air defenders (support players) must maintain a passive posture and focus on setting up a wide area net of short range AA units. Spacing of AA units is critical, so that when one area is breached, AA units from nearby locations can quickly move in and reconstitute air defense at the breached sector.

Although the developers have simplified the Air power in game for balance reasons, they did however score well when it comes to portrayal of realistic doctrines - throughout history of warfare, anti-aircraft defenses have been passive by nature and air power always held the initiative. It is said that the best counter to enemy aircraft is another aircraft. Ground-based air defenses from the days of WW I had always strategically failed when no friendly aircraft were available to help them.

Fun Mod (pre-MW Mod) and Enlarged Air/Support Fire Ranges

During the early versions of MW Mod (formerly known as Fun Mod), air units had their range of fire increased from that of the vanilla game. The balancing problems were obvious. Even though air defense units also had their ranges increased with introduction of Heavy SAM units, the increased stand-off capability of the Air role had given support players a very stressful situation when dealing with a real human air player on the opposing team.

The increased stand-off range of Air role in Fun Mod meant that air player could hide and surprise the opposing player with pop-up attacks. This gave little to no warning to the defenders, and required the support player to rapidly predict the air player's next moves. Paranoia was natural when playing support.

Despite this, a skilled support player could very well manage and still control the battlefield. The game effectively became a ‘hide and seek' situation between air and support players, with both sides constantly predicting each other's moves.

From Fun Mod to MW Mod: Firepower Madness

When Fun Mod transitioned to MW Mod beta, numerous enhancements in gameplay had created new challenges for balancing in multiplayer matches between online players. There was one dramatic game changer - cruise missiles. Now the game introduced automatic robotic units that auto-pilot themselves into suicide and then blowing themselves up once closing on their targets.

Previously, with increased stand-off fire range of the Air role, a paranoid support player could deal with an air player on one-off basis - one support player could deal with one air player. However, with cruise missiles, things have changed dramatically to a new level that would draw the blueprint for MW Mod's future developments.

Cruise missiles by nature fly extremely fast. During multiplayer games, it took the attention of an entire team to shoot down or evade a single cruise missile. The high speed of cruise missiles allowed the air player to quickly apply firepower to anywhere on the map without having to risk his own helicopters - effectively a big artillery. This also allowed the air player to punch through enemy AA belt by attacking the air defenses themselves. Short range AA guns could shoot down the cruise missile, but became vulnerable to saturation attacks.

Heavy SAM units were given a new offensive special ability that gave them highly agile homing missiles to take out fast moving targets like cruise missiles. This required the support player to manually target the cruise missile. Even then, cruise missiles still consistently made onto their targets - the tail-chasing nature of the homing missile caused even the high-speed SAM to lag behind the cruise missile. By the time a SAM could intercept the cruise missile, it would have already struck its target.

But all of this talk is relevant to defending from a single cruise missile. It became painfully obvious that air players would employ saturation tactics to simply bulldoze the entire opposing team. Human support players were simply unable to react fast enough to manually identify and target incoming cruise missiles in time. At most all they could do was pop smoke and move out the way; some players simply disbanded their units when enemy cruise missiles became visible.

The problem of cruise missiles had forced us to re-evaluate their role in the game. As an interim measure, their prices had gone up substantially to the point that nobody used them anymore - they were effectively removed from the game until a better solution could be found.

Defeating the Vampires - PythonShooter h4x

At the time when cruise missiles were introduced, numerous capabilities of WiC's PythonShooter have been discovered. Instead of just firing projectiles, the PythonShooter could be used as an API to fool the game into doing many more things. The improvements made in working with PythonShooter had allowed us to figure out a robust solution to the cruise missile problem.

The idea was simple: if the cruise missiles were to remain in game, they would have to be countered. It was obvious that the reaction time, firepower and operational availability of existing AA units did not match the advancing air & missile threats.

With this in mind, the first ambitious work using PythonShooter was to develop an Integrated Air Defense System (IADS) in an RTS game, with conceptual ideas borrowed from the US Navy's Aegis Combat System. Reduction in reaction time through automation and computer-aided command and decision process for the support player became the primary goals.

The new IADS was programmed in Python with an exact scenario of saturation air and missile attacks in mind. Once activated by the player, the automated program immediately identified the incoming air and missile threats as hostile and assigned each a priority of destruction. From that point on, the computer was completely on its own, free to fire on its electronic will at anything diagnosed as a threat. Once the IADS is "weapons free", support player is detached from the entire process - the human players can now focus on what they do best in WiC - strategize their next moves, while the computer deals with the ongoing chaos of incoming enemy air & missile attacks.

Integrated Air Defense System (IADS) Development

The development of IADS for WiC was the most protracted and ambitious project in the entire MW Mod development history. The goals were ambitious for a mod with just one person doing most of the development work - World in Conflict would have to become the first casual game in history to fully simulate a working IADS, with fidelity rivaling those of air combat simulation titles.

In addition, ease of use was a must - support player must be detached from the technical mumbo jumbo, while maintaining a high degree of realism. A fine balance had to be achieved, where a casual player without any knowledge of military technologies would enjoy the game, while military technocrats would appreciate the authenticity and degree of realism delivered by the game.

All of this effort just to make sure cruise missiles stay in the game - some in the community had suggested that cruise missiles simply be removed altogether rather than spending protracted development time on IADS. Instead, they argued that it would be a much better use of our time to add new models, new units, new tactical aids (like hydrogen bomb, more nukes), etc.

However, the counter-argument was that MW Mod would bring "nothing new" to the table if we just keep adding new units that would all behave the same (a tank shoots a vehicle, a helicopter kills a tank, what else?). I was adamant that MW Mod should try bringing realism in a different direction - a direction where no strategy games have ever gone to in the past. Of course, there is the old saying "if you are not being criticized, you may not be doing much." Controversy amongst those in the small WiC community regarding the IADS development was something I had valued as a compliment.

The IADS development was started at the time when I had no experience whatsoever in Python. Coming from limited programming experience with C, Python was quite awkward. It took a while to get used to Python's object-oriented structured programming, but its ease of code readability made it lot easier to quickly learn and pick up the language.

New Discoveries

During the IADS development, lot of new discoveries were made surrounding how the World in Conflict's Server Game environment known as "WICG" (stands for WIC Game) works behind the scenes.
PythonShooter interface that Massive developers left behind was really the lucky shot that saved MW Mod from being abandoned.

Looking back, Massive devs would have never thought that PythonShooter would be used for activities other than shooting projectiles. Well, they inadvertently left a loophole and we capitalized every cent out of it - the IADS working through PythonShooter interface was being coded to act as a artificial intelligence system. Everything from target detection, tracking, classification and prioritization of targeting was being done by the IADS - activities far from simply ‘shooting projectiles.'

With these new discoveries, one of the new tricks I learned was sharing of information between different units across the game (data-link). This opened a pandora's box to all of future MW Mod developments.

The concept of data-linking developed for the controversial IADS so cynically called "overpowered, moditis-induced toy" was so versatile, that development of IADS had contributed to the future Fixed-Wing Aircraft system. Without IADS development, Fixed-Wing Aircraft would have been simply impossible.

Fixed-Wing Aircraft and Prelude to MW Mod 2 for World in Conflict

The development of IADS had produced new knowledge to proceed with the concept of fixed-wing aircraft system for WiC. However, the work was dead on arrival - I was adamant that fixed-wing air in WiC would look stupid under the existing game environment. In order to properly introduce fixed-wing aviation, we must first fix the underlying problem - the homing missiles.

If we were to introduce air force units into the game, the combat scenery would have to look beautiful - this meant that homing missiles used in game would have to be changed to use "lead-pursuit" guidance. Under the lead-pursuit homing, the missile would lead the target into a mid-air collision, rather than chasing after it. The resulting hit would look like something out of Star Wars.

Initially, the concept of revamping the homing guidance law of projectiles in WiC was deemed impossible and was considered the "holy grail" of WiC modding. It simply could not be done with the limited access that WiC SDK provided. However, during the development of IADS, it was discovered that the PythonShooter had an unintended write access to a player owned unit's EX_World (3D space) position coordinates. At first, this was thought as a game bug; but then it too quickly became a new opportunity for innovation.

Immediately, work was done to put the "EX_World write access phenomenon" to a test to study its feasibility. An Mi-24 Hind helicopter unit was given an experimental PythonShooter code that changed its EX_World position every frame. This resulted in the Hind chopper following the target in an automatic pursuit. A fat Hind helicopter had become a homing projectile!

After the test, an experimental project was started on the backburner - it was to be named Flexible, Advanced Air Interceptor, later re-named to simply "Flexible Interceptor" or "FLINT" for short.

Initial Development of Flexible Interceptor (FLINT)

The concept behind FLINT was actually not my idea. It was first suggested by DeltaWulf, one of the voice actors for the MW Mod team, back in 2009. His idea was to spawn a helicopter unit and create a mechanism that would automatically "drive" this unit without player's input.

However, this "mechanism" was the problem - just how do we do it? Well, with the discovery of "EX_World write access" phenomenon during IADS development in 2011, we finally found the solution to make his idea work.

A second problem rose during protracted FLINT development cycles. None of us had any working knowledge of math or rocket physics beyond the basics taught in high school and college courses. None of us had any idea on how a real-life missile "leads" the target. None of us had much idea in basics of linear algebra and working with vectors in general. This created an enormous challenge for FLINT development that almost killed the project. Never before, a hobby for gaming became as stressful as a day at work.

So, it was time for a crash course. Where the basic knowledge of linear algebra and mathematical concepts were lacking, Kahn Academy and YouTube came to the rescue. The next was learning how missile guidance systems work in real life - this was even harder. It quickly became obvious as to why missiles behave silly in most games - most game developers have no idea on how to do it, and neither did I.

During this time, an air combat simulation game by Eagle Dynamics (ED) known as Digital Combat Simulator (DCS) was very inspiring to the development of FLINT. The high fidelity and realism delivered by DCS in every respect only inspired me to go one step farther. Browsing through the ED forums, I've learned more knowledge about combat systems, but more importantly, the raw data and truth about those systems, rather than fanboyism, which the internet is full of. Particular attention was given to forum posts made by GGTharos.

Putting Knowledge to Work for FLINT

I have soon learned that many missiles in real-life use Proportional Navigation (PN), first developed by the US Navy during WW II, and first implemented on the AIM-9 Sidewinder in 1954.

Putting the concept of PN into mathematical formula is one thing - Wikipedia has that. Putting the concept and mathematical formula into a workable software code with limited math knowledge was completely another. You actually had to understand the meaning behind the math and physics involved between the lines - I didn't at the time. Google searches and books on missile guidance had produced nothing - many of them were written by academics and professors who use the same old mathematical jargon that noobs like me would never comprehend.

During the quest to understand missile guidance, I've run into Defense Technical Information Center (DTIC), run by the US Department of Defense. The DTIC archive is full of declassified military technical and scientific information that were cleared by the DoD for public release. Many of the archived and declassified writings publicized there were put together by those who practiced them, rather than being written by academics.

Studying through DTIC archives, a breakthrough in understanding of PN and the most basic principles of homing guidance have been made. On July 14, 2011, an experimental FLINT Python code using my new understanding of PN was put into action for the first successful guided intercept test. Again, ceremonially, we had decided to use the Mi-24 Hind helicopter model to represent the homing kamikaze missile for this experiment.

After much anticipation, the Hind unit was coded with target information and given the Attack order to initiate the test. It worked! - the Hind smoothly accelerated like clockwork and started leading the target as it flew, then collided with the moving target. Other mod team members on TeamSpeak and xfire watching this event had cheered in joy as history has just been made in World in Conflict modding.

World in Conflict is a game that was abandoned by its own publisher. Its own developers have their hands full working on new projects that they couldn't possibly help modders. All felt lost and WiC seemed hopeless to achieve portrayal of modern firepower. On July 14, 2011, the first successful guided intercept test of FLINT changed everything we knew about WiC. It was a historic day for World in Conflict as a game and changed the course of MW Mod development forever.

Recent Developments and Going Forward

With FLINT maturing and transforming the homing missiles in WiC, fixed-wing aircraft were quickly introduced. The introduction of fixed-wing air had completely changed the gameplay - even the old players who criticized the mod for whatever grievances they had were impressed.

What started as a humble Fun Mod with overly ambitious and tenacious goals had ended up into a full blown modern combat simulator for arcade-styled RTS genre - something no other game has ever achieved before.

Where do we go from now? Well, World in Conflict is a dead game. Ubisoft and Massive had confirmed to us that franchise has been killed and that there will not be a WiC 2. But bad news is always a time for new opportunity - the extensive knowledge we had gained developing FLINT meant that we could now port the entire system to another game. FLINT engine would go on; it just needs a new home.

However, the new challenge is that many game publishers are increasingly becoming uneasy toward community developers. I'd love to mod Battlefield 3 using FLINT tech, but unfortunately there are no plans to allow modding. Such is true with many other games.

Wargame European Escalation seemed to be another promising game, but it just didn't click with me. World in Conflict is still my favorite RTS. There is just one thing that other RTS games can't seem to figure out - the camera. In WiC, camera can freely behave to the point that you can play the game as if you're in a first person shooter. No other RTS games seem to have figured this out. I am however interested in the upcoming W-EE: AirLand Battle title from Eugen (but ofcourse, will they allow modding? Time will tell.)

We're also evaluating feasibility in modding for ArmA. ArmA has very extensive modding support and a very strong community. However, being new to a completely different environment, it would take a while to get used to. It may be easier to join an existing successful realism mod for ArmA (i.e. ACE) to provide whatever assistance I can on missile simulation.

With all of this said, until we find a new viable home for ourselves, WiC is still our most favorite RTS game and WiC MW Mod will continue on in incremental updates (even if we move onto another game) -- that is, until Ubisoft officially pulls the plug. As long as WiC lives, so will the MW Mod ;-)

Report abuse Mid-course guidance for ABM in WiC

0 comments by blahdy on Jul 26th, 2012

Testing a simple alpha-beta filter concept for estimating target positional changes during mid-course guidance phase of an interceptor missile.

python code:

def FLINT_Kalman__ab_filter( self, aPos, aVelocity, dTime ):
    FLINT_Kalman__ab_filter( aPos, aVelocity, dTime )
    A test case for using simple alpha-beta filter to generate
    estimated target positional updates during mid-course guidance.
    aPos = target position vector
    aVelocity = target velocity vector
    dTime = time constant for testing (TGO?)

  xk_1 = math.Vector3( aPos )
  vk_1 = math.Vector3( aVelocity ).NormalizeSafe()
  dt = float(dTime)
  a = 0.85
  b = 0.005
  # signal input - x_measured
  xm = math.Vector3( aPos )
  # predicted position
  xk = xk_1 + ( vk_1 * dt )
  # angular position estimation
  rk = xm - xk
  xk += rk * a
  # velocity estimation
  #vk = vk_1
  #vk += ( rk * b ) * (1 / dt)
  return xk
Offline Since
Apr 27, 2015
United States United States
Member Watch
Track this member
Blog Statistics
Views Today