Byers et al.: Who Is Player Time Designed For? — Fukai Reads

TL;DR

The time you spent on a game today was, for the most part, designed by someone. Today I read a study that asked twenty of those someones directly.HELLDIVERS 2 (Arrowhead Game Studios), from its Steam store page. The paper names it as an example of keeping past seasonal content playable.

Daily quests, seasons, session length, D7 retention. How do the time-shaped parts of a game actually get decided inside a studio? The authors built an account of it out of developers' own words. It is a peer-reviewed CHI 2026 paper, and it received a Best Paper Honourable Mention.

The line that hit hardest was this one: "We're working backwards from a number." The authors close with four heuristics, and one of them is to design for exit and re-entry, not only retention. For a site that ships a puzzle every day, that lands squarely.

About this paper

The authors are Thomas Byers, Martin Gibbs and Bjorn Nansen, all at the Faculty of Engineering and IT, The University of Melbourne. Byers, the first author, is a PhD candidate in the university's HCI (Human-Computer Interaction, the field that studies how people and computers deal with each other) division, and studies how time, pacing and engagement are designed and experienced in digital systems.

It was presented at CHI '26 (13-17 April 2026, Barcelona). It is a peer-reviewed full paper, not a preprint (a manuscript posted before peer review) sitting on arXiv. The full text is readable from the University of Melbourne's open repository.

Why I picked it today. This site ships a puzzle every day, which means we are the ones booking a small slice of a reader's time, every day. Streaks, dailies, archives — all of it is time design. This paper lights that design from behind. It also helps that the last few days here have been AI papers, and I wanted to hear from human makers.

What was known, and what was not

Time itself is not a new subject. HCI has long treated it as something to optimise or schedule, and game studies has offered several scholarly typologies of in-game time. That part of the map exists.

What was missing was the maker's side. The authors write that there is still limited insight into how developers themselves approach these systems. We have player-side experience and outside-in classifications of features. We have much less on who inside a studio decided that this daily, or this season length, was the right one, and on what grounds.

The other body of work sitting next door is dark patterns — designs that nudge people toward choices against their own interest. Gray et al., Mathur et al., and in games Zagal et al. But that frame leans toward "crafted to trick." The authors suspected developer intent was more tangled than that, and went to ask.

Method: twenty developers, an hour each

The method is twenty semi-structured interviews (a fixed skeleton of topics, with room to follow whatever the interviewee opens up). All were held over Zoom and averaged about one hour, with manual notes alongside automatic transcription.

Recruitment ran between March and late April 2025, via email, LinkedIn Premium, blogs, social media and industry events including GDC and Gamescom, using purposive, convenience and snowball sampling — picking on purpose, asking whoever answered, and following referrals.

Of the twenty participants, 18 were male and 2 female. They were based in Europe, the United States, Canada and Australia, with between 3+ and 45+ years in the industry. Roles included quest designers, narrative directors, gameplay programmers, UX leads and studio founders, spanning AAA, indie, mobile and live-service work, and many had experience across more than one kind of studio. Everyone appears under a pseudonym.

The analysis used constructivist grounded theory (a qualitative method that builds concepts up out of the data instead of testing a hypothesis, and holds that data and theory are co-constructed through the researcher-participant relationship). Initial coding broke transcripts into fragments, focused coding clustered them, and after fifteen interviews the authors deliberately sampled from under-represented studio contexts. By interview twenty, the clusters had settled into three categories. Ethics approval came from the University of Melbourne (project ID: 27862).

One thing to state upfront: there are no effect sizes or p-values here. This is a qualitative study, so you read it for structure, not for magnitude.

Three things that came into view

1. Time design rarely gets written down. Participants described it as intuitive work that seldom reaches documentation. As one put it, "The minute I write it, it's out of date" (Rasputin). In larger companies another force pushes the same way: writing ethics policy down can "create[] legal liabilities" (Shin).

Scope — how long the whole thing should last — is settled early, and the yardstick is the previous game. "You know that the last game had 20 hours" (Shaxx), and so this one should go over it. Outside pressure matters too: grant applications ask for playtime estimates before anything is built (Eris).

In mobile and live-service work, the job is to make minutes meaningful and months sticky at once. One designer had a name for it: "We politely call it the Starbucks test... what can a player do in a couple of minutes that moves them forward..." (Calus). AAA aims elsewhere — "to keep the disc in the tray as long as possible... ideally, we want them to play it..." (Taniks). And everyone is drawing on the same finite pool: "If you want some of somebody's time, it is a knife fight in a phone booth" (Calus).

On ethics, views split. One senior developer was blunt: "If anything, they're secretly passing formulas of how they can milk you for more time and money. The ethics in Free-to-Play are essentially non-existent" (Zavala). Others noted only the vocabulary had moved: talk of the "addictive loop" disappeared out of discomfort while the practices stayed put (Saladin).

2. Tools turn time into something measurable. Analytics infrastructure was standard everywhere. Named platforms included Amplitude, Mixpanel, Unity Analytics, Datadog and Metabase; larger studios warehoused telemetry in Snowflake, Databricks or Amazon Redshift. Much of it ships inside Unity and Unreal already (Shin).(Diagram) The metrics named in the paper, re-sorted by the length of time they describe. From seconds to months, one word — "time" — stretches across six orders of magnitude. The scale that decides a project's fate usually sits in the middle.

The granularity is striking. At the second scale: time to kill, reloads, respawn timers. At onboarding: time to first input, tutorial completion, first-time-user-experience drop-off. At the session scale: session length, sessions per day, gaps between sessions, day-N retention (D1, D3, D7, D14, D28, D30, D60), DAU/WAU/MAU, churn. Then progression and monetisation: mission completion times, time to first spend, ad frequency, ARPU. "If you can imagine it, we're tracking it," (Shin).

Having the tools is not the same as reading them. One participant named the trap in dashboards: "dashboards... use medians or averages... the interesting stuff doesn't happen in the median, it's in the distribution curve" (Zavala). And at the start of a project there is no data at all — only what Zavala called the Holy Assumption: "The number of times they play, and the number of minutes that they'll play per session, that core assumption drives every decision you make from then on."

3. More and more design starts from a number. The authors call this data-centered temporal design. One designer put it in six words: "We're working backwards from a number." (Saint). It already dominates live-service, mobile and free-to-play, and AAA is adopting the same logic.

Even greenlight decisions lean on temporal metrics — early retention, streaming performance, Steam wishlist counts. Explaining why one free-to-play AAA title was cancelled, a participant said it "wasn't about quality – the retention data just wasn't there." (Crota). Not everyone has swallowed it: "you have to be very cautious about outsourcing human judgment to the data as the driver" (Skolas).

Alongside that, plenty of user-centered practice was described: structures that let players stop without penalty (Taniks), praise for HELLDIVERS 2 keeping past seasonal content accessible (Cayde), reorientation tools for players returning after a break (Mithrax), and the in-game clock in Diablo IV, which Saint called "One of the best things I've seen recently," for letting players track real and in-game time at once.Diablo IV (Blizzard Entertainment), from its Steam store page. The paper cites its on-screen real-world clock as a way of keeping players oriented in time.

Underneath all of it sits a refusal to equate length with value. "I'd rather have a tight 10 hours I finish than a 200-hour thing that just peters out." (Rasputin). Portal and A Short Hike come up as concise, complete experiences. Eris is worth quoting too: "Keeping in mind this tenet of respecting anyone's time – but player time, specifically – is something that's going to be reciprocated and noticed."A Short Hike (adamgryu, 2019), from its Steam store page. The paper names it as an example of a short, complete experience.

How makers can use this

The authors close with four heuristics for organising decisions about player time: (1) treat player time as a resource, not only a metric; (2) make temporal expectations explicit; (3) design for exit and re-entry, not only retention; (4) acknowledge the intended role of the game and the player's capacity for engagement. Here is what they look like in a puzzle maker's hands.

Use 1: don't let a streak become a reason not to come back. This is heuristic (3), almost literally. The authors note that metrics favour continuous engagement while players' lives are discontinuous. If I were building a daily puzzle, I would think twice about resetting a streak to zero after one missed day. An archive of past puzzles, a streak freeze, a catch-up path — each of them makes reopening the tab after two weeks less awkward.

Use 2: state the time cost up front. Heuristic (2). Expectations about session length, log-in cadence, event duration and reward permanence, the authors write, are often implicit or buried in patch notes and marketing prose. If I were shipping a hyper-casual puzzle, the first screen would say "one puzzle a day, about five minutes." That one line lets a player fit you into their schedule.

Use 3: when a metric goes up, ask who benefited. Heuristic (1). D7 rising is a fact; whether it rose because the game got better or because quitting got harder is not visible in that number. And, per Zavala, look at the distribution rather than the median. If I were shipping Sokoban-like levels in bulk, I would go straight to the long tail of completion times. That is where the stuck players are.

Use 4: decide what role your game plays. Heuristic (4). If every game tries to be someone's main title, everyone ends up in the phone booth with a knife. A puzzle site is better off accepting from the start that it is a side dish, not the main course. Puzzle weight, notification frequency and season length all fall out of that decision cleanly.

Use 5: write your Holy Assumption on the wall. This is not one of the four; it is the part I found most usable. The "N times a day, M minutes each" guess made at the start quietly governs everything downstream. So make it explicit and visible. Then, when real numbers arrive, you can update the assumption instead of defending it.

Limits and open questions

Starting with what the authors admit. The sample, though diverse in role and studio type, was geographically concentrated in Europe, the United States, Canada and Australia, and they write that it overlooks relevant insight from other regions such as Africa and Southeast Asia. They also flag that only 2 of 20 participants were women. Beyond that, what is reported is developer speculation rather than direct player feedback, and they note the need for deeper analysis within each studio context.

Three things I would add as a reader. First, the heuristics are hypotheses, not tested results. They are an organising scheme distilled from twenty conversations; nobody measured what happens to a game that follows them. Reading them as a checklist rather than a conclusion seems right.

Second, I could not clearly read off how many participants sat in each studio context. That is partly because many of them span several, but it does make it harder to weigh whose voice carries the account. Third, the interviews were conducted in spring 2025. This industry moves fast enough that the gap is worth keeping in mind.

And one unavoidable property of qualitative work: everyone appears under a pseudonym, so a reader cannot verify any single quote independently. Trust here rests on the transparency of the method description and the ethics approval.

How Fukai reads it

Here is my own reading. I would place this study as what comes after dark-pattern critique. The vocabulary of dark patterns is good at naming a bad actor. But the developers in this paper are not moved by malice. The previous game's twenty hours, the grant application, the retention curve shown at the greenlight meeting — what pushes them usually sits outside the design itself. In the language of design criticism, this is a shift from "who is to blame" toward "what is making someone write this." Which means the four heuristics read less like an appeal to personal conscience and more like a tool for changing what an organisation measures. For those of us building something small, that is also the hopeful part: if you are the one choosing what gets measured, you can change it tomorrow.

Closing

If you want to go deeper: the same three authors published "Shaping Time in Games: Developer Approaches to Temporality" at DiGRA 2025 in Tampere. It is continuous with this CHI paper, and reading both shows where the team walked in from.

For the player-side view of the same phenomenon, the Lu et al. paper covered here recently — on whether flow comes from difficulty or from invested effort — pairs well with this one. Seeing the same thing from the maker's side and the player's side sharpens the map.

References

Papers and materials referenced in this article:

・From Quarters Per Minute to Daily Quests and Seasons: Developer Perspectives on Temporal Design in Video Games (Thomas Byers, Martin Gibbs, Bjorn Nansen, 2026, CHI '26, peer-reviewed, DOI: 10.1145/3772318.3790636)

・Full text of the same paper (open-access version, University of Melbourne Minerva Access)

・Shaping Time in Games: Developer Approaches to Temporality (Byers, Gibbs, Nansen, 2025, DiGRA 2025) — earlier work by the same team

・Tom Byers (first author) homepage

・Images in this article come from each game's Steam store page: HELLDIVERS 2 / Diablo IV / A Short Hike