Common question: Why didn't we go with a gamespace jungle timer? (i.e., a timer in Baron's camp). There were a lot of considerations that fed into the final product.

There's certainly a lot of tangible benefits to a gamespace, spatially-situated timer--but first I want to address the notion that one of the benefits is that it introduces opportunity cost in checking the timers. This is to say, by asking players to move their camera *to* the camp, we incur effort that could otherwise be spent elsewhere (such as micromanagement), and thus it becomes a differentiator of skill. Now, as a designer, it's frightening that one would ever consider *increasing* cognitive load when there are less stressful alternatives available. Imagine if we purposefully obfuscated the purchasing process by adding a confirmation to each item purchase, or structured the contents through pagination rather than scrolling. Sure--the player who buys quicker suddenly becomes better at the game, but *why* would we ever purposefully muddle the interaction process?

No, gamespace timers could never be the sole solution. We did however consider them as an addendum to the UI-level, non-diegetic timers, and here's why: they provide potential didactic benefits, as they very clearly tie the clearing of the camp with the timer itself. We didn't settle on this solution for a few reasons--we didn't want another persistent piece of UI in gamespace (especially in high-traffic areas like jungle camps!), any level of UI in gamespace degrades the artistic quality of the game, and quite frankly--settling on a clear but pleasing visual language was going to be way more work than it was worth. The charge indicators on Twisted Treeline and Crystal Scar actually aren't great solutions either; they're fully diegetic elements, but really don't make much sense in the game world--we wanted to avoid falling in this trap (plus, they could use a UX overall themselves!).

We also tried minimap solutions; this included a mini-countdown on the jungle camps themselves, but this also ran into several problems. Trying to depict a timer accurately with such few pixels was nigh impossible, and that's not even considering all the players who scale down the UI. Then, rather than continuous timers, we experimented with discrete states--for example, the camp icon would change color or shape a minute before respawn. This too failed; suddenly we introduced a vast array of states into the camps:
- Icon 1: Camp is alive (or you think it's alive)
- No Icon : Camp is dead, but you didn't see it die so there's no icon
- Icon 2: Camp is dead, but you saw it die so there's an icon showing it died
- Icon 3: Camp is dead but respawning in a minute,
Icon 2 is actually superfluous under that scheme, but I'm including it for the sake of completion. The issue remains though--suddenly you had more than one icon/state that meant *dead*, and that in itself was creating noise.

That's why, in the end, we went with the non-diegetic, UI-level timers!

Reply · Report Post