I've been using Encounter Timer for a few months, I have thoughts

By JimmiWazEre

Opinionated Tabletop Gaming Chap

---

A few months back I made an Android app called 'Encounter Timer'. It was the first app I've ever made and I was so chuffed with it that I decided to make it available to my subscribers for free.

You're welcome mum!

Since then, I've been using it in play at every opportunity in sessions of Mothership, GOZR, and D&D. So much that the Metal Gear Solid style "!" alert sound the app plays has become something of a meme in my games now.

Now, Domain of Many Things was very much still a baby blog when I first released the app. Readership was very low, so I think we’re long overdue an article revisiting Encounter Timer.

You can read all the details, including operational instructions here. However, if you just want the basic gist: It’s a countdown timer that starts at a random number within a range (default: 5–15 minutes). Once it hits zero, that’s your cue to roll on your encounter table.
No more remembering dungeon turns. Just tap, forget, and play.

Encounter Timer Demonstration

What I like About It

The Core functionality just works

The whole reason Encounter Timer exists is because I suck at remembering dungeon turns. Years of 5e's free-flowing narrative left me untrained in structured time tracking outside of combat.

So, having a simple countdown that automates this? Absolutely perfect.

Helpful usability features

In the real world, as a GM, you're going to want to adjust the timer in response to events at the table.

Encounter Timer has you covered there too, as you’re able to easily reduce the remaining timer by a chunk simply by tapping the countdown after the PCs have done something to draw attention to themselves.

It’s a nifty bit of useful functionality even if I say so myself.

---

---

There’s also a “High Danger” toggle which halves the countdown, letting you quickly increase encounter frequency for tense environments.

What I think it's missing

More Encounter Details, Faster

As cool as it is, unfortunately it remains a bit of a badger to have to manually do reaction, specific monster, and distance rolls. Encounter Timer could easily streamline the process further by making these further random rolls for you. The only thing I want to leave out of hardcoding into the app is the specific thing you’re encountering, so perhaps in that case Encounter Timer could use return a d6 value for me to quickly cross check against my own prewritten table.

Support for Systems with Motion Tracker style Mechanics (AlienRPG)

I also quite like the idea of using this timer in games of AlienRpg, however, in that system the PCs often have a motion tracker, which tells them the distance and direction of any threat at whatever point in the game that they decide to use it.

By rules as written, the GM is supposed to be moving their NPCs around the area on a map hidden from the PCs, so the idea of a motion tracker can easily be resolved by the GM consulting their hidden map and relaying the results back to the PCs.

But how would this work with no hidden map, relying instead upon Encounter Timer driven NPCs?

Well, here’s a fact for you: The exact, specific location of the NPCs, whilst it is not known to the PC’s, is totally unimportant. If we can accept that, then it removes the need to be running NPCs around on a hidden map for a start. But it does underline the problem we have with motion trackers, because I hate GM Conflict of Interest, and I don’t want the responsibility to have to decide the details of every encounter using GM fiat.

So, what if, when the encounter timer is running, it also presents the following information to the GM: The direction of the current location of the encounter, and the abstract distance of the location of the current encounter. For example, we might have the following information on screen prior to the alert sounding:

67 seconds (counting down - existing Encounter Timer functionality)

North West (randomly determined, stays static)

Near (Near, Medium, Far - This should update dynamically as the clock runs down past certain milestones)

As GM, what we should infer from this is that the encounter will trigger in just over a minute, the cause of the encounter is currently NW of the PCs position, and right now, it’s in the next area in that direction.

So assuming they’d whipped out their motion tracker and had all that information fed back to them - what would the players want to do with that?

Avoid the Encounter by going in the opposite direction

If they go in a different direction then we could delay the encounter - In terms of app functionality this means we need to be able to add time to it rather than simply remove it.

Avoid the encounter by hiding

If the PCs chose to hide, as GM we can cancel the timer and skip forward in time to the point where the encounter is in the same room as them and then make our checks to see if they’re discovered or not. If not, the encounter moves on and we can reset the timer to start counting down again.

Prepare an Ambush

Similar to hiding above - except the result of failing to detect the presence of the PCs will result in the PCs getting the drop on the NPC.

Cunning Shenanigans, like venting the airlock in the room to the NW

Assuming the PCs are able to do this prior to the encounter timer ticking down far enough to change the abstract distance, then I’d simply cancel the timer and the encounter has been resolved.

Conclusion

After months of real-world use, I’m still thrilled with Encounter Timer. It works exactly as intended, and I’ve got ideas to push it even further, especially for sci-fi TTRPGs.

Have I missed anything? Got an idea you’d love to see added? Drop it in the comments.

Hey, thanks for reading - you’re good people. If you’ve enjoyed this, it’d be great if you could share it on your socials, and maybe think about subscribing to the Mailer of Many Things! Either way, catch you later.

*This article contains affiliate links