Explore How Player Polls Shape What Online Game Studios Build

When I covered local referendums for a newspaper website in 2008, the hardest stories to explain were never about the result. They were about the rules: who could vote, what share was needed to pass, and what happened to a measure that narrowly failed. I find myself asking the same three questions now about online games that let players vote on what gets built.

Polling players is not new, but a few studios have turned it into a formal system with thresholds, ballot wording and repeat votes. Their experience offers a surprisingly detailed record of what direct democracy looks like when the electorate is a game community.

Old School RuneScape: a game born from a vote

Old School RuneScape is the clearest case, partly because its existence began with a poll. In 2013, Jagex asked players whether they wanted an older version of RuneScape restored, and the strength of the response led to Old School launching that February. From the start, the community was promised a say in its future.

That promise became a structured process. Major content proposals go to a player vote, cast at in-game poll booths, and for most of the game's history they needed 75 percent approval to pass, a bar Jagex later lowered to 70 percent. Either figure is a higher bar than most legislatures set for ordinary laws. In the United States, a supermajority of that kind is closer to what it takes to propose a constitutional amendment, which requires two-thirds of both houses of Congress, than to passing a regular bill.

How a proposal moves through the system

From following poll cycles over several years, the typical path looks like this:

1. The development team publishes a blog post describing the idea, often with concept art and rough numbers for rewards.
2. Players respond on forums, Reddit and Discord, and the team runs surveys to gauge where objections sit.
3. The proposal is revised, and each part is turned into a separate poll question.
4. Eligible players vote over a fixed window, with results shown openly.
5. Questions that clear the threshold go into development. Questions that fall short can be reworked and polled again later.

Not everything is put to a vote. Bug fixes and what Jagex calls integrity changes, such as measures against cheating and botting, can go ahead without a poll. That carve-out matters. It resembles the way many democracies keep certain emergency or administrative decisions out of the referendum process.

What failed polls reveal

A supermajority rule produces plenty of near misses, and those near misses tell the more interesting story. The best known is Warding, a proposed new skill that failed to reach the threshold in 2019. A new skill touches nearly every player's account, so a sizeable minority objecting was enough to stop it, even after extensive design work.

The team's later approach was instructive. In 2023, it presented several skill concepts and let players choose among them before committing to detailed design. Sailing came out of that process. Asking "which of these do you want?" before "do you approve of this specific design?" reduced the chance of spending months on a skill that would then be voted down. Election officials will recognise the logic: a primary narrows the field before the general vote.

Minecraft and the limits of the yes-or-no ballot

Mojang tried a different format with Minecraft's mob votes, which began in 2017 when players chose the Phantom. Each year, viewers of Minecraft's live event picked one of three proposed creatures, and only the winner was added to the game.

The format drew increasing criticism. Players disliked that two of the three designs were set aside each year, and the 2023 vote, won by the Armadillo, prompted an online petition from players objecting to the structure itself. In 2024, Mojang said it would no longer run mob votes.

For anyone interested in voting systems, the contrast is useful:

A plurality contest among three appealing options guaranteed that most voters would see their favourite discarded. An approval vote with a high bar produces fewer winners, but every winner carries broad consent. Neither format is flawless. Each makes different people unhappy.

The case against "just let the players decide"

A common line in gaming communities, repeated in comment threads whenever a studio makes an unpopular change, is that developers should simply poll everything. I have heard this advice dozens of times. The experience of studios that actually poll suggests it is weaker than it sounds.

First, turnout is never the whole player base. The players who vote are typically the most invested, which is not the same as the most representative. Newer players and casual ones are underrepresented, much as low-propensity voters are in local elections.

Second, wording shapes results. A question that describes a reward in attractive terms will get a different answer from one that lists its costs first. Pollsters and ballot designers have known this for decades, and game studios relearn it each time a carefully phrased question passes easily while a blunt one fails.

Third, a poll cannot design anything. Players can approve or reject, but somebody still has to make hundreds of small decisions about balance and pacing that no ballot captures. The healthiest polling systems treat votes as consent for a direction, not a substitute for a design team.

What players can do with a ballot

For players, the practical lesson is that a poll rewards engagement long before voting day. In Old School RuneScape, the proposals that pass comfortably tend to be the ones that changed after feedback, and the feedback that changes them is specific: a reward that breaks the in-game economy, a requirement that locks out lower-level accounts, a gameplay loop that turns into an endless grind. Vague objections rarely move a design. Players who read the blog post, test the numbers against their own sessions and post concrete criticism have far more influence than those who simply click no.

The civic tech parallel

Participatory budgeting, which began in Porto Alegre, Brazil, in 1989, lets residents vote on how part of a public budget is spent. Cities that run it well share traits with the stronger game polls: proposals are published early, residents get time to debate them, and officials explain afterward what was funded and why. The weak versions hold a vote, announce winners and go quiet.

The same accountability loop matters in games. A poll result becomes a promise, and players then watch whether the patch notes deliver it, a dynamic examined in our piece on patch notes that work like promises. If you want the wider picture of voting inside game worlds themselves, see online game worlds where players vote, and for more on digital participation tools, our civic tech section collects related reporting.