# Improving Interrupts

1423 views

Most squad based games have an interrupt feature that works as follows:

• During your turn you can arrange it that some of your soldiers don't use up all their action points - leaving enough APs for a "reflex shot" and  facing them in the direction of the expected enemy assault.
• Then during the enemy's turn, if an enemy soldier moves within the range of you soldier it may, or may not trigger an "interrupt".
• If the interrupt triggers, then the enemy's turn is interrupted and it becomes your turn temporally, you can shoot at the enemy, or do any other action until your APs run out, then the enemy's turn continues.

The problem with this is that the interrupt only triggers, based on a random throw of the die (that is for the case of the original X-Com game and Jagged Alliance 2). When you position your soldier for the interrupt, you are putting him in a vulnerable position and if the interrupt doesn't happen (because the random die throw), then your soldier is almost certainly going to get pummelled.

For that reason when I was playing X-Com, I almost never tried to get interrupts, because I didn't like the idea of my soldier randomly getting shot to pieces based on a die throw that was completely unpredictable.

So, for Merc Tactics I have being working on ways of "solving" this problem. This is how it works:

• There is no die throw, instead there is a "counter" which starts at number depending on the soldiers interrupt skill.
• During the enemies turn each time an enemy moves within the soldiers arc of fire the counter goes down by one. When the counter reaches "0" the interrupt is triggered.

In the screen shot below, for example, you see an arc of fire drawn on the ground with the number "3". 3 is the number of times that the enemy can move within that arc before the interrupt is triggered.

Now the interrupt is triggered:

Once the soldier shoots or moves the counter goes back to the original setting, otherwise it holds it's value. So, if the counter didn't hit zero in the first turn, you could keep the soldier where he is and try to get the interrupt in the second turn.

This scheme removes the random element and provides feedback to the player, so they always know the likelihood of an interrupt occurring.

Nice, yeah, the problem with the X-coms, Jagged Aliance, and Xenonauts was always the complete lack of knowledge.  Even a percentage chance being displayed would've been better than nothing.  XCOM, the remake, swapped it to always happening, but only once, and every single person would respond at once, making it mostly useless.  (Especially combined with it's lack of unit facings)

Your method sounds fairly clever.  Is it the number of action points spent, or the number of tiles moved?  I could see advantages in both methods.

Any action taken (moving one square, or taking a shot) reduces the counter by one.

Posted (edited)

On 8/1/2017 at 10:23 AM, ferrous said:

Nice, yeah, the problem with the X-coms, Jagged Aliance, and Xenonauts was always the complete lack of knowledge.  Even a percentage chance being displayed would've been better than nothing.  XCOM, the remake, swapped it to always happening, but only once, and every single person would respond at once, making it mostly useless.  (Especially combined with it's lack of unit facings)

Your method sounds fairly clever.  Is it the number of action points spent, or the number of tiles moved?  I could see advantages in both methods.

XCOM2 has much improved on it, if you haven't played it. When taking the overwatch shots, they track the damage to each unit and if one unit has taken enough damage to die, they direct the following shots at the next nearby unit if there is one or do nothing so no ammo/perks are used during that time.

Edited by noamw

Quote

The problem with this is that the interrupt only triggers, based on a random throw of the die (that is for the case of the original X-Com game and Jagged Alliance 2).

Can't say for xcom, but in vanilla Ja2 interrupts are completely determined (mostly by experience level), there were no random interrupts in original game.

13 hours ago, Shmelkin said:

Can't say for xcom, but in vanilla Ja2 interrupts are completely determined (mostly by experience level), there were no random interrupts in original game.

Ok, I didn't know that. As a player it seemed random. I never understood why sometimes the interrupt didn't trigger.

1 minute ago, Ed Welch said:

Ok, I didn't know that. As a player it seemed random. I never understood why sometimes the interrupt didn't trigger.

It could seem random, but the game just calculates interrupt level for each soldier and then compares them, who has higher interrupt level wins. But since all enemies are different and there are modifiers to interrupt level (shock, running state, the fact that your merc seen this enemy before or not) make it look a bit random. Also, if one sees other and other not, the one that sees always gets interrupt. Also, soldier cannot get interrupt on someone he saw this turn previously. And cannot interrupt at all if he is under fire (even if shooter missed completely).

Could you add maybe similar feature into the game - if soldier is attacked by burst/auto, he cannot interrupt (or his interrupt counter raised by amount of bullets shot at him). Kind of suppression effect.

Jagged Alliance 2 1.13 added new interrupt system (IIS) which works similar to your game - when opponent spends APs in the view of soldier, after certain amount of APs spent interrupt is triggered. Though it's much more complicated, as everything in 1.13.

I personally prefer reaction (overwatch) system of Fallout Tactics, when soldier just fires at opponents who move or fire in his field of view, and you can disable it or set min chance% to fire. It allows faster play than manual interrupts and looks more dynamic and realistic in my view.

Yeah, the Fallout idea of an automatic reaction fire sounds interesting.

## Create an account

Register a new account

• ### Similar Content

• A new entry in the devlog for 13 Ronin, a retro 2d samurai fighting game, this time it's about implementing the logic for the computer player.
Happy coding!

• Hey,
So I have got this asteroid type game and today I encountered a new issue while testing this game.
What happened was that two asteroids were close to each other and I shot a bullet at them. The asteroids were so close to each other that a single bullet could collide to both of them.
It collided and my game crashed there itself. I figured out it happened because two asteroids and one bullet collided in the same frame.
This is the code -
void Collision::DoCollisions(Game *game) const
{
for (ColliderList::const_iterator colliderAIt = colliders_.begin(), end = colliders_.end();
colliderAIt != end;
++colliderAIt)
{
ColliderList::const_iterator colliderBIt = colliderAIt;
for (++colliderBIt; colliderBIt != end; ++colliderBIt)
{
Collider *colliderA = *colliderAIt;
Collider *colliderB = *colliderBIt;
if (CollisionTest(colliderA, colliderB))
{
game->DoCollision(colliderA->entity, colliderB->entity);
}
}
}
}


void Game::DoCollision(GameEntity *a, GameEntity *b)
{
Ship *player = static_cast<Ship *>(a == player_ ? a : (b == player_ ? b : 0));
Bullet *bullet = static_cast<Bullet *>(IsBullet(a) ? a : (IsBullet(b) ? b : 0));
Asteroid *asteroid = static_cast<Asteroid *>(IsAsteroid(a) ? a : (IsAsteroid(b) ? b : 0));
Bullet *bulletMode = static_cast<Bullet *>(IsBulletMode(a) ? a : (IsBulletMode(b) ? b : 0));
if (player && asteroid)
{
player->playerCollided = true;
//AsteroidHit(asteroid);
//DeletePlayer();
}
if (bullet && asteroid)
{
collidedBullets.push_back(bullet);
collidedAsteroid.push_back(asteroid);
//AsteroidHit(asteroid);
//DeleteBullet();
}
if(bulletMode && asteroid)
{
collidedBulletMode.push_back(bulletMode);
collidedAsteroid.push_back(asteroid);
}
}


void Game::CollisionResponse()
{
if(player_->playerCollided == true)
{
DeletePlayer();
}
else
{
if(!collidedAsteroid.empty())
{
for(AsteroidList::const_iterator collidedAsteroidIt = collidedAsteroid.begin(), end = collidedAsteroid.end(); collidedAsteroidIt != end ; ++collidedAsteroidIt )
{
AsteroidHit(*collidedAsteroidIt);
}
collidedAsteroid.clear();
}

if(!collidedBullets.empty())
{
for (BulletList::const_iterator bulletIt = collidedBullets.begin(), end = collidedBullets.end() ; bulletIt!=end; ++bulletIt)
{
DeleteBullet(*bulletIt);
}

collidedBullets.clear();
}
if(!collidedBulletMode.empty())
{
for (BulletList::const_iterator bulletIt = collidedBulletMode.begin(), end = collidedBulletMode.end() ; bulletIt!=end; ++bulletIt)
{
DeleteBulletMode(*bulletIt);
}
collidedBulletMode.clear();
}
}
}

in my game->docollision() -
whenever an asteroid and a bullet used to collide, the collided objects get collected in collidedasteroids and collidedbullets respectively. When two asteroids collided with the same bullet, the two asteroids got collected safely in collidedAsteroid but the single bullet got collected in collidedBullets twice, so when the deletion was happening, the second time iteration of the bullet couldn't find the respective bullet and it got crashed.

How am I supposed to approach this problem now?

Thanks

• How to calculate angle between two points from a third point with the help of D3DXMATH library?
• By Tanzan
Hello  all,
I just finished my first Android game and published it on Google play...
I know its not the next red dead redemption2 but it would be nice to have some comments/feedback on it if its worth it to go on with a release 2.0. or move on to the next game? (red dead redemption 3  )
Anyway thx for your reading time and i hope on some nice reviews!
Regards,

Tanzan

• By qxsl2000
array of points(green dot) connected into a curve line,It was just nothing more than array of points arranged in order , order of insertion.
As shown in the above figure, my goal is for the player to start from "S" and choose a point that is closest to the player and is naturally reasonable(i mean i can't walk through the wall).
X by BWPlayer         X by BWPlayer           X by BWPlayer           X by BWPlayer             But because the shortest distance between the two points is W, it suddenly move through to the other side, which is definitely not what we want.actually what i desire is "N".
Of course, i have used cross-production to determine if the point being chosen is relative to the left-side or right-side of my current location.with points on the right-side of my position has been chosen as candidates,then pick one of them, which is minimum distance compared with others.

×

## Important Information

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!