If it flies, it dies™.

Blog RSS Feed Report abuse (GameDev) Introduction to Proportional Navigation (Part I)

2 comments by blahdy on Jun 28th, 2015

In this tutorial, I will provide a brief overview of proportional navigation family of guidance laws, but more importantly, we will go over some sample code so you get straight to trying it out in your own game. This tutorial (and accompanying demonstration video) is written using World in Conflict MW Mod, with 4.7 early-alpha development build. Sample codes are written in Python for MW Mod's FLINT Missile System.

History of Proportional Navigation (PN)

PN is the foundation of modern homing guidance in virtually every guided missiles in use today. The theory of PN was developed by the US Navy during World War II as desperate measures were needed to protect their ships from Japanese kamikaze attacks, and gun-based defense systems (even automated fire director controlled guns) simply did not have the range to take out the target at a safe distance, and easily became overwhelmed by saturation. Automatic homing missiles were urgently needed to defend ships at sea.

Although theory of PN was apparently known by the Germans during WW II, no applications were reported and the war shortly ended thereafter. The US Navy's experimental Lark missile was the first to implement PN, soon followed by Sparrow and the venerable AIM-9 Sidewinder after the war.

PN is cheap to implement and had demonstrated to provide effective homing guidance-- It is because PN does not require geometry information such as range to target and target speed (though it can also benefit from it), making it ideal to implement on simpler "range-denied" missiles, such as passively heat-seeking IR missiles and semi-active laser homing variants. Not only that, the theory of using Line of Sight (LOS) information to develop collision course is such a powerful concept, that virtually every advanced guidance laws used today share their ancestry lineage back to PN. If you ever see people attempting to code so-called "advanced target homing" missiles in games using quadratic equations and trigonometry, you can clearly see that they're reinventing the wheels and got some learning to do :-) PN totally laughs at, and beats out every other forms of homing guidance used by games, which integrate states by solving for what is essentially a high school geometry.

Understanding Theory of PN

PN works on the principle of "Constant Bearing Decreasing Range" (CBDR), where when two objects are heading in the same direction with no change in Line of Sight (bearing) angle, the objects *will* collide. Line of Sight (LOS) is an imaginary sight-line between you and the target; when target is moving from left to right in your field of view, it is said that the LOS angle is changing from left to right. If however, you were to also run from left to right and accelerate appropriately to keep the target centered in your field of view, it is then said the rate at which LOS angle is changing (LOS rotation rate) is zero ("null"). Continuing to run with LOS rate maintained at zero will result in intercept and "lead to pursuit" collision with the object you're chasing.

Mathematically, PN is stated as follows:

Commanded Acceleration = N * Vc * LOS_Rate

N = Unitless navigation gain (constant) -- between 3 to 5
Vc = Closing Velocity (or "range closing rate")
LOS_Rate = LOS Rotation Rate

To describe this along a two-dimensional missile-target engagement geometry:

two-dimensional geometry of PN

When working with PN, it is important to understand that missile's acceleration is commanded (Acmd) normal to (aka perpendicular to) the LOS, and proportional to the LOS rotation rate. LOS as stated earlier, is the sight-line between missile and the target, which would be "Rtm" line in the above diagram. LOS rotation rate is the angular rate at which the LOS line changes -- denoted by the over-dot theta "LOS" grey angle in the diagram above.

Prerequisites

Before we get started, we first assume that you already have very basic knowledge in implementation of homing missiles in game. If you are this far, you probably know that in order for your game physics to work, you need some sort of integration scheme (i.e Euler, Verlet, Runge-Kutta 4, etc) that provides step-by-step numerical integration at every frame. FLINT missile system in WiC MW uses Velocity-Verlet, but essentially, what it all comes down to is simple: you step forward one step (or frame) at a time and solve for your states. If you need help with game physics and integrators, check out Gafferongames.com

Implementing PN in Game

Now, to implement PN, we need to fill in the blanks from the above equation "An = N * Vc * LOS_Rate." Let's discuss how to obtain the individual input variables to calculate our required lateral acceleration (latax).

1. Obtaining the LOS Rotation Rate (LOS_Rate)

As explained above; LOS Rotation Rate is the rate at which target is crossing your field of view, or more exactly, the rate at which sight-line angle is changing.

Obtaining LOS_Rate is easy, especially in game environment. In real life, the missile seeker sits on a gimbaled gyro -- the seeker rotates in the gyro to keep the target locked on; the rate at which it rotates is your LOS rate. In real life, engineers have to contend with seeker noise contamination, but in games, we're essentially working in a noise-free environment.

First, you need to obtain the directional vector between the missile and the target (remember "Rtm" in the above diagram?) -- this is your LOS:

RTM_new = math.Vector3( targetPosition ) - math.Vector3( missilePosition )

You will measure and record LOS at every frame; you need to now get the difference between the new RTM (RTM_new) you just measured, and the LOS obtained from the previous frame (RTM_old) -- this is your change in LOS (LOS_Delta).

RTM_new.Normalize()
RTM_old.Normalize()
LOS_Delta = ( RTM_new - RTM_old )
LOS_Rate = LOS_Delta.VectorLength()

2. Closing Velocity (Vc)

Closing Velocity (Vc) is the rate at which the missile and the target are closing onto one another. In other words, as the missile is traveling toward its target, it gets closer to the target, no? So, the rate at which our missile is closing the distance to its target is called the "range closing rate" or simply "closing velocity." This range rate is mathematically defined as follows:

Vc = -Rtm_overdot

-Rtm_overdot = Negative rate of change of the distance from the missile to the target.

Now, this raises a curious question: How do you obtain 'range rate' on a passive heat-seeking missiles that have no radar to measure distance? Well, you guesstimate it (lol) -- that's what the early rudimentary version of Sidewinder in 1953 did. Doesn't work very well against accelerating or maneuvering targets, but it was effective enough for what was world's first PN heat-seeking missile. In modern versions like the AIM-9L, AIM-9X, Stinger etc, you have computation power available in the seeker to "process" the intensity of IR or the image it sees. As IR signature gets closer, it gets more intense -- the rate of intensity change is your range closing rate.

On radar guided missiles, including semi-active homers like the original Sparrow missile, you have better luck! On a radio-frequency based sensor, the seeker can observe Doppler frequency of the target return to calculate the rate at which the missile is closing onto its target. Doppler effect is quite measurable on wavelengths as you get closer or away from the target. Negative rate of change in Doppler frequency is the closing velocity.

Anyway, now let's back to our in-game code. Recall from earlier that we derived our LOS_Rate in vector space as the difference between the current frame's missile-target vector (RTM_new) and the previous frame's missile-target vector (RTM_old). The length of the vector for this difference is denoted as LOS_Rate above. Well, just so it happens, as our missile is closing onto the target, RTM_new is shorter than RTM_old! So LOS_Rate length itself is a rate of change in missile-target distance. Then, conversely speaking, the negative rate of this distance change is our range closing rate, aka the closing velocity:

Vc = -LOS_Rate

3. Navigation Gain (N)

Navigation gain (or navigation constant) is a designer-chosen unitless variable usually in the range of 3 to 5. Higher the N, the faster your missile will null out heading errors. Generally, it is recommended for N to stay between 3 to 5. FLINT missiles in WiC MW use N of 3; most missiles in real-life use 3 as well.

4. Augmented Proportional Navigation (APN)

When implementing PN, it is best practice to focus on target's acceleration normal to LOS'-- we're using a missile to hit a moving target after all. What does 'acceleration normal to LOS' mean exactly? Well, as the missile is homing onto the target, the target would most likely move laterally, or 'perpendicular to' along the LOS sight-line (crossing target would present the most movement normal to LOS).

The reality is that, often times the target is not moving at a constant velocity -- it changes directions, or it slows down or accelerates. You also have upward sensible acceleration of 1 G even for non-maneuvering targets if you're simulating gravity.

To account for these factors, you add a term to our PN formula by adding "(N * Nt ) / 2":

Commanded Acceleration = N * Vc * LOS_Rate  + ( N * Nt ) / 2

Nt = Target acceleration (estimated) normal to LOS

Even for targets that do not maneuver, the target's one-g sensible acceleration is multiplied by N/2, producing a more efficient intercept.

Putting it all together - Sample Code

Below is a sample FLINT missile system code for FIM-92 Stinger heat-seeking missile, written in Python. It is the simplest missile in game to employ augmented PN, as it's a passive heat-seeking missile.

def GCFLINT_Lib_APN( msl_pos, tgt_pos, msl_pos_previous, tgt_pos_previous, latax, N = None, Nt = None ):
	"""
	Augmented Proportional Navigation (APN)
	A_cmd = N * Vc * LOS_Rate + N * Nt / 2
	
	msl_pos:	Missile's new position this frame.
	tgt_ps:		Target's new position this frame.
	
	msl_pos_previous:  Mutable object for missile's position previous frame.
	tgt_pos_previous:  Mutable object for target's position previous frame.
	Set these objects to "0" during first time initialization, as we haven't
	yet started recording previous positions yet.
	
	latax:	Mutable object for returning guidance command.
	N:		(float, optional) Navigation gain (3.0 to 5.0)
	Nt:		(float, optional) Target acceleration amount normal to LOS
	"""
	
	import wic.common.math as math
	from predictorFCS_flint_includes import *
	from predictorFCS_EXFLINT import *
	
	if N is None:
		# navigation constant
		N = 3.0
	else isinstance(N, float) is not True:
		raise TypeError("N must be float")
	
	if Nt is None:
		# one-g sensible acceleration
		Nt = 1.0
	else isinstance(Nt, float) is not True:
		raise TypeError("Nt must be float")
	
	if msl_pos_previous is not 0 and tgt_pos_previous is not 0:
		
		# Get msl-target distances of previous frame and new frame (Rtm)
		RTM_old = ( math.Vector3( tgt_pos_previous ) - msl_pos_previous )
		RTM_new = ( math.Vector3( tgt_pos ) - msl_pos )
		
		# normalize RTM vectors
		RTM_new.NormalizeSafe()
		RTM_old.NormalizeSafe()
		
		if RTM_old.Length() is 0:
			LOS_Delta = math.Vector3( 0, 0, 0 )
			LOS_Rate = 0.0
		else:
			LOS_Delta = math.Vector3( RTM_new ) - RTM_old
			LOS_Rate = LOS_Delta.VectorLength()
		
		# range closing rate
		Vc = -LOS_Rate
		
		# Now, calculate the final lateral acceleration required for our missile
		# to home into our target.
		latax = RTM_new * N * Vc * LOS_Rate + LOS_Delta * Nt * ( 0.5 * N )
	
	# Update mutable position objects so we can integrate forward to next frame.
	msl_pos_previous = math.Vector3( msl_pos )
	tgt_pos_previous = math.Vector3( tgt_pos )
	
	# my job is done, it's now up to EXFLINT.Integrate() to steer the missile.
	return True
		

Video Demonstration and Wrapping it All Together

The augmented PN (APN) formula above should always be used for any moving targets-- even non-maneuvering aircraft should have upward one-g sensible acceleration in a proper simulation environment, necessitating the need for APN.

The advantage of using APN guidance as compared to classic PN is that the commanded lateral acceleration (latax) is initially high but falls as the missile approaches the maneuvering target. Watch the YouTube video accompanying this blog post very closely-- you'll see that APN guided missile initially makes very violent maneuver to snap itself onto the collision path, then only minor adjustments are made just prior to missile impact. This is how optimal PN is implemented in the real world and how it should be done in realistic combat simulation games.

In the next (near future) tutorial, we will go over advanced guidance laws using theories of optimal control, which are derivatives of PN with more engagement information fed in, such as estimated time-to-intercept; and missile-target range. Feel free to message me on ModDB or YouTube if you have any questions or comments about implementing PN in your game environment.

YouTube HD Link: youtu.be/Osb7anMm1AY

Report abuse On the topic of Time to Go (TGO)

1 comment by blahdy on May 28th, 2015

From my last blog post, I've posted a demonstration of implementing Predictive Guidance (PG) in game environment. In that blog post, one of the things mentioned was the importance of Time to Go (TGO) variable in the homing loop. Just what exactly is TGO and why is it important? Easy question but turns out it was a bit harder than I thought to solve..

Time to Go (TGO)

TGO just as its name speaks for itself, stands for estimated "time to go until intercept". Basically, it's the fancy TOF counter that counts down to 0 when you watch Hellfire kill videos. In missile guidance parlance, TGO opens you up to many many more advanced guidance laws. If you think about it, TGO is the single important number which can express the geometry of the engagement.

As discussed in the previous blog post, having an accurate TGO is very important to achieving good homing performance. If TGO is inaccurate, you could actually have significantly higher miss distance than classical homing methods that you might as well not bother. Higher miss distance means, further correction efforts your missile has to commit to, thereby rapidly draining down energy and lowering the chance of a successful intercept.

How to not estimate TGO

Getting a good estimate of TGO ended up being a bit of challenge. If you think about TGO from elementary and rudimentary perspective, one could just say "range to target divide by speed = time left to go". The obvious problem with this statement is that both the missile and the target are never constant speed objects, they're accelerating more or less unpredictably.

Other more funnier proposals included, solving quadratic equations to obtain time-to-intercept, or even using a trajectory equation to estimate the time of flight. In fact, the sample code from my last blog post used the trajectory equation to estimate TOF:

# Estimate Time to Go (tgo) using trajectory equation.
# self.IMU_Measured_VR is the current speed of the missile as measured by
# Inertial Measurement Unit (IMU) 
v_tgo = EXFLINT_Trajectory_ComputeTOF( 2 * range_to_target / self.IMU_Measured_VR )

Both of these estimations ended up being a comedy. While above estimation resulted in several successful intercepts against slower moving aircraft in the last blog's video (actually in one of the scenes, the missile missed), when engagement was made against high speed targets (like supersonic cruise missile), homing performance went down the crapper to unacceptable levels -- more or less it hit about 2 out of 5 times against high speed targets. Test performance against ballistic missile targets resulted in kill ratio of zero.

The problem of above estimations is that they assume constant speed and that target and the missile are not accelerating. Missile's speed constantly changes throughout its flight envelope -- it accelerates to peak speed, then slows down as it coasts. Accurate estimation of TGO and engagement geometry requires solving nonlinear missile and target equations ahead of time.


How to better "estimate" TGO

Solving nonlinear equations of missile and target flight envelopes is way beyond the scope of math I wish to think about and is too overly complicated. Instead, we need find a much simpler method.

As it turns out, a great reference to this question is "Tactical and Strategic Missile Guidance" by Paul Zarchan; in one of his documents, he states: "the predicted intercept is calculated in flight by rapidly integrating the nonlinear missile and target equations forward in flight at each guidance update".

The keywords here are "integrating" and "at each guidance update." Ah, integration! When we're integrating, that means we only need to deal with 'at each guidance update', or more or less need to find an accurate instantaneous TGO that corresponds to concurrent target & missile's relative velocities. Turns out this happens to be very easy. No need for all that strange math porn!

To estimate TGO at each integration update, one could argue:

Tgo = Rt / abs(Vc)

Rt = relative distance (displacement) between missile and the target
Vc = closing velocity

Rt is the relative distance, or in other words, the displacement vector between the target and the missile at the time of calculation. Vc is the closing velocity.


Closing Velocity

Closing Velocity means "range closing rate" -- it is the rate at which the relative distance between the missile and the target is being closed, or the rate at which it is being "shortened" as the two objects are closing at each other. Relative distance is the distance (displacement) between missile and the target.

So to express closing velocity in integration terms:

Vc = ( Rt0 - Rt1 ) / dT

Rt0 = relative distance between msl & target at T=0
Rt1 = relative distance between msl & target at T=1
dT = time elapsed between measurements made for Rt0 and Rt1
Note that Vc is a negative number

So we can argue that the distance left to go (relative distance, aka "Rt") divided by the rate at which we're currently closing that distance (Vc), equals our instantaneous Time to Go. Very simple solution to a complex problem! Integration ftw.


Putting TGO to work

Recall from my last blog post that at each guidance update, acceleration shall be proportional to Zero Effort Miss (ZEM) and inversely proportional to the square of Time to Go:

Required Acceleration = N * ZEM / Tgo^2 

N = navigation constant (3 to 5; I use 3)
ZEM = Zero Effort Miss
Tgo^2 = time to go squared

Zero Effort Miss (ZEM) is expressed as:

ZEM_y = y1 + yt * Tgo

y1 = vertical (y-direction) separation between missile and target
yt = derivative of y (relative velocity)
Tgo = time to go

# Or more colloquially:

ZEM = Rtm + Vtm * Tgo
Rtm = missile-target relative position
Vtm = missile-target relative velocity
Tgo = time to go

Final Python code in FLINT missile script for AIM-120 AMRAAM:

# Navigation constant
Biased_NC = 3.0

# Integrate missile-target data 
try:
   self.rt_prev_frame
except NameError, ValueError:
   # first frame initialization; IMU speed is safe here as missile hasn't accelerated yet
   self.rt_prev_frame = range_to_target
   Vc = -self.IMU_Measured_VR
else:
   # at each integration update, we compute Tgo; 
   # EXFLINT_TICKTOCK is simulator update constant (dT)
   Vc = ( range_to_target - self.rt_prev_frame ) / EXFLINT_TICKTOCK
   self.rt_prev_frame = range_to_target

# Compute Time to Go
try:
   v_tgo = range_to_target / abs(Vc)
except ZeroDivisionError:
   raise EXFLINT_GuidanceLoopError(167)

# Compute required acceleration command
latax = LOS_new * Biased_NC * ( ZEM / ( v_tgo * v_tgo ) ) + LOS_Delta * ( Biased_NC / 2 )


Demonstration

Here is the concluding demonstration of the new homing performance by AIM-120 after applying the new Tgo estimation as described above. Is the homing performance any better? I surely think so, but you be the judge!

Report abuse Concept testing for Predictive Guidance (PG)

0 comments by blahdy on May 26th, 2015

I'm testing a new homing guidance algorithm for WiC, known as predictive guidance (PG). It's an advanced derivative of proportional navigation using optimal controls, also known as "the mother of all guidance laws."

Proportional navigation (PN) uses LOS rotation rate (the rate at which 'line of sight' between the two objects changes) as the only important parameter when computing steering commands.

PG integrates missile & target kinematics/geometry data in relation to the LOS rate, producing a steering command that takes into account for geometry of the pursuer & target. The kinematics data is computed into "time to go until intercept" (TGO).

The formula is described in many places online; but this document is particularly easier to understand: Dtic.mil

Zero Effort Miss (ZEM) is the miss distance if the target continues along and interceptor made no efforts to correct its maneuver. Like with LOS rate, ZEM of 0 means no miss distance, hence collision intercept will occur.

The relation of ZEM to LOS rate is somewhat interesting:

LOSr= ZEM / ( Vc * Tgo2)
ZEM = Vc * Tgo2 * LOSr

Vc = closing velocity (best estimate)
Tgo2 = time to go squared
LOSr = LOS rotation rate

The formula to generate guidance command is:

La = ( N * ZEM ) / Tgo2

Tgo2 = time to go squared
N = navigation constant
ZEM = zero effort miss

The guidance command should be proportional to the ZEM and inversely proportional to the square of Tgo.

Putting this all together in FLINT missile code:

# LOS to target
LOS_old = ( targetPos_Old - myPos_Old ).NormalizeSafe()
LOS_new = ( targetPos_New - myPos_New ).NormalizeSafe()

# Find LOS rate
LOS_Delta = math.Vector3( LOS_new ) - LOS_old
LOS_Rate = EXFLINT_Kalman_Filter( self.LOS_data, LOS_Delta.Length() )

# Navigation Constant (3 to 5)
Biased_NC = 3.0

# Estimate Time to Go (tgo) using trajectory equation.
# self.IMU_Measured_VR is the current speed of the missile as measured by
# Inertial Measurement Unit (IMU) 
v_tgo = EXFLINT_Trajectory_ComputeTOF( 2 * range_to_target / self.IMU_Measured_VR )

# Calculate Zero Effort Miss
ZEM = -LOS_Rate * ( v_tgo * v_tgo ) * LOS_Rate

# Sensible target acceleration (aT) term
APN_bias = LOS_Delta * (0.5 * Biased_NC)

# Compute required acceleration command
latax = LOS_new * ( ( Biased_NC * ZEM ) / ( v_tgo * v_tgo ) ) + APN_bias

return latax


And the result so far. It looks quite cool -- the missile seems to lead itself to point ahead in time (where it thinks target is going) before smacking onto it like dart. YouTube direct link: www.youtube.com/watch?v=1eTaygcTN68

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.

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:
			path=[]
			while end != None:
				path.append(end)
				end=predecessors.get(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
					predecessors[neighbor]=start
		
		# adj nodes processed, mark current node as visited
		visited.append(start)
		
		# 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


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
		target.
		
		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|
			  -----------------------------------------------------
								|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 ;-)

Level
Avatar
Avatar
Offline Since
Aug 30, 2015
Country
United States United States
Gender
Male
Member Watch
Track this member
Blog Statistics
Articles
7
Views
2,316
Views Today
0