When a die roll is a teacher, and when it is a fog machine
Randomness in games is not one word; it is a set of possible relationships between a player, a system, and time. A good random event can be a story engine: two unlikely outcomes bump into each other, and a player has something to retell. A bad random event is a black box with a smirk, where a player is asked to pay attention without being given a fair chance to form expectations. Legibility is the difference. A system is legible when a person can, after a few trials, name the shape of what might happen, even if a particular outcome is still uncertain, the way a weather forecast is legible about rain even when it is not certain about a minute. A system that mistakes opacity for depth often hides behind “surprise” while selling frustration as drama, and mobile games, with their short sessions, discover that problem faster, because a phone throw is cheaper than a monitor throw, and neither is a metric most teams want to brag about.
Pity timers, transparent floors, and the ethics of a floor at all
Some team designs a hidden “pity” mechanism to prevent extreme bad luck, then debates whether to tell players it exists. Transparency is a design choice with consequences. If you reveal a floor, a subset of players will optimize toward it, and your spreadsheet will change shape. If you hide it, some players will assume the system is rigged in the opposite direction, and communities will run experiments with spreadsheet grief. There is not a single universal answer, but there is a universal question: does the randomness you selected align with the trust you are asking for? A daily pull on a phone is a different trust contract than a monthly pull on a console with a return policy; both deserve honesty, but the time loop changes the social temperature, like weather.
Skill, variance, and the lie of “pure skill”
Competitive formats often want to look like they are pure skill, if only to attract sponsors who are allergic to the word luck, yet a matchmaking system, a map rotation, a critical hit rule—each introduces variance. A healthy discussion names them as design choices instead of pretending they are acts of God. A classroom exercise we like is to have students list the sources of variance in a game they love, from input latency to a random map spawn, and then mark which are communicated well to a new player. The gap list is a map of the real tutorial, the one a manual forgot to print.
Mobile-specific luck: the thumb and the bus stop
Input noise is a kind of randomness, not poetic, but physical. A small jitter in a frame can turn a “skill” event into a coin flip, and a game that then sells an expensive retry is doubly unkind. A responsible approach separates mechanical noise from designed randomness, or at least acknowledges both in a failure screen, because a player is not a theorem; they are a person in wind, in gloves, in a life. This article does not ask you to remove randomness, only to date it honestly, the way a good document dates its own assumptions at the top, so a reader in two years can tell what was meant for a season and what was meant to last.
Closing, with the site’s disclaimer in plain view
Aperture North is an informational publication, not a marketplace, not a service desk. This piece is a teaching essay, not a call to bet or speculate, and the broader site reiterates in the footer: we do not distribute games, we do not sell commercial products, and we do not promise that any design pattern will work for you, only that naming luck and legibility clearly will make your team arguments shorter and your players, on average, less confused about what a fair roll might mean in your particular world, which is a form of care that costs little and returns trust over seasons, the slow metric we still believe in even when a dashboard is silent about it, because a dashboard, after all, is only another interface, and interfaces can be wrong in ways that a story remembers longer than a number.