Timers and dynamic mission structure

Stop me, if you heard this one before. Why doesn’t X go to Y on his own? Just put a timer on it. Rocco, get down here!

The whole timers vs proximity triggers was a hot topic since 2016, and it seems that most people around here in favor of timers. However, I don’t think there ever was a dedicated thread where we could discuss the specifics of timers and their implementation, at least beyond the fact that they should be in the game.

Warning: the rest of this post is just armchair game design bullshit and probably pretty stupid.

Problem with timers

Why aren’t there more timers in the game? We actually have an answer to this question with specific example.

Here’s a quote from Torbjorn_IOI:

We try to limit proximity triggers, but having Silvio’s session on a timer would have players wait a very long time for him to return to his main loop. That is not a good experience, especially if you’ve just set a trap and now have to wait a long time for him to return.

What I find interesting is that this issue seems to stem from another problem, IO faced early in development. Here’s a quote from an old PC magazine interview

Initially, Francesca De Santis, Sapienza’s secondary target, would wander around the town. “She went to the church and the cave during her main loop,” says Christensen. “Because of the very long travel times between those locations, we decided to not do this, as it wasn’t fun to wait that long for her to do her loop. Silvio had similar issues, so in order to fix this, both targets’ main loops were shortened.” For both, Opportunities were implemented that let the player trigger events to lure out their targets—furthering the Hitman fantasy of manipulating your quarry.

So, targets used to have long and complicated loops that were shortened for players’ convenience. And opportunities were introduced to give players ability to pull targets away from their regular short loops. But this in turn made timers unviable, since that would effectively bring back those longer inconvenient loops.

And I certainly can see the rationale here. For every clever plan that is built around target’s schedule, there would be dozens of failed plans that would be screwed by unfortunate timing. The unfortunate truth is that timers would be more of an obstacle to players than an asset.

Timers done right.

Despite that, there are still quite a few timed events in season 1. Most of them exist simply because they don’t break anything. Jason Portman being called to his checkup does not affect targets’ routes and thus it can be set on a timer. It’s nice, helps with immersion, but it doesn’t add much to the game. You have to nab Jason within first seven minutes, and if you don’t you have one fewer opportunity for infiltration but that’s about it.

Hitman 2, however, has one example of a timed event that can and should be considered to be the golden standard moving forward. And that is the race in Miami.

There are several things that it does right: it is a mission wide event; players are properly informed about it; there are several ways players can manipulate this timer. But the most important thing is that it involves permanent change to the map and NPC loops.

Sierra has two separate loops that are both appropriately small and contained enough so that players wouldn’t have problems with either. And timer simply counts to a permanent transition from one loop to another. Which somewhat solves the waiting problem. You never have to wait for Sierra to get back on track, because she never goes back. If you want to snipe her in the car, then you have to work within a specific timeframe.

Using Finish line as a starting point, I tried to formulate a list of key elements that I think are vital for proper implementation of timers.

  • Timers must be used to separate distinct mission states; changes must be irreversible.
  • If timed event pulls target into a new location, target must switch to a new loop in close proximity to that location afterwards.
  • Players should have the ability to mess around with said timers, preferably, by being able to both speed up or delay the event.
  • Players should be informed about timed events beforehand.
  • If there are any variations within timed event, the default version must be the shortest one (Sierra does not visit podium unless player makes her do it).
  • None of the above is necessary for events that do not affect target’s loops (ex: Jason Portman, Helmut Kruger)

What can be done with timers?

Now this is the most important question. Obviously you can have dynamic, naturally progressing missions. As long as those changes are represented through discreet states with nested loops.

But you can also do so much more. You can approximate complicated routes for targets by creating several short loops connected through timer. Perhaps sending Francesca to roam entirety of Sapienza isn’t practical, but giving her small loop around the church and another one in the mansion and then tying them with a single timed event would be s lot more manageable.

Another thing that can be achieved here is variable loops. We do have a small example of this in Moses Lee who has two different, albeit similar, loops depending on the outcome of the race.

How far can this thing be stretched?

That is the question that currently has no answer. In case of Miami, there is only one timer, and by default it only affects Sierra. With this set up Robert becomes a sort of a selector for Sierra’s loop. If player decides to tackle Robert first, Sierra most likely will finish the race and move on to her second loop. If player goes for Sierra first, then she will likely die in her car.

But can you make a target with more than one timer? Can you give timers to more than one target? I have no idea. Technically the answer is yes, of course. But would this be even remotely manageable? I definitely would like to find out. And given advances in terms of mission design between 2016 and 2018 games, we will probably find out somewhere around 2020.


I am also for timer generally, you can rely on them without having to get into an area of unknown size. But they work out the best if they can be skipped with manual triggers.

The race is obvious here as there are multiple ways to stop it, and less obvious ones like doing the medic opportunity.

This would not make much sense unless you design a very abstract reason for it. Usually you stack timers if you want to give them multiple things to do after each other. This is more clean technically and easier to track/debug.

Start --short timer–> event
Start -------long timer------->event

Start --timer–> event --timer–> event

Only if the timer is the only trigger of an event. In the race example you connect the trigger to the race and the race to the target. Robert seems to not be attached to the timer as the timer is only triggering Sierras defeat, which makes Robert not talk to her.
But he does react on the race if she wins. And this too is easier to track if connected indirectly.

They “fixed” that in a new way in H2, targets who are requested to arrive often run now. For example the car kill on Robert where you sabotage it first makes him run.
Not all opportunities make use of that but I guess they always try to justify this.

1 Like