I like to think about game development as product velocity, and velocity is a vector. It has a magnitude, which is how fast you build, and a direction, which is whether you’re building the right thing. AI is pushing the cost of building toward zero, so magnitude is becoming less of a problem. Direction is now the bottleneck. Knowing what to build is the hard part.
The usual answer is "listen to your community." Studios are already great at that. They run Discords, read Reddit, watch Steam reviews and send surveys. The trouble is that most of this is listening to what players say, and I’ve written before about why stated preferences are such a weak signal. Some of the biggest ideas in games never came from a survey. They came from the community. MOBAs came out of a Warcraft III mod. DayZ came out of Arma 2. Auto Chess came out of a Dota 2 custom game. Players didn’t ask for those genres. They built them.
So for this episode I wanted to talk to someone who sees what players actually do, at scale, before a studio does. Pedro Esparza is Head of Growth at Bisect Hosting. He has spent roughly 20 years on the business side of game servers: MC Pro Hosting (where, he says, they were the first to support Hypixel), Tebex, Overwolf, and now Bisect. In my words, he’s a landlord for tens of thousands of game communities. He watches them form, monetize and die, and he sees demand in raw numbers before the studio knows it exists.
My claim: the best signal for what to build is what players are already paying for in time, money and effort, and a studio’s job is to make that behavior visible before it commits resources. Pedro’s framework is a practical way to do that. It comes in three parts: what counts as a signal, how to rank the signals, and the loop that turns a signal into a build, partner or leave-it-alone decision.
One disclosure up front. Pedro’s company hosts dedicated servers, so he has a natural interest in studios supporting them. I don’t think that changes the framework, and you’ll see he argues against building multiplayer in plenty of cases. But you should know it.
Part 1: Behavior beats opinion
I opened by asking whether studios are doing enough to learn from their communities. Pedro didn’t hedge:
"Are game studios doing enough? I think honestly the answer is no."
He described two very different kinds of signal. On one side, a Discord channel might ask for multiplayer 500 or 1,000 times, and a community board might have a request with thousands of upvotes. On the other side:
"If players take the time and effort to actually reverse engineer a game to take it further, like you mentioned with DayZ coming out of Arma 2, that to me is a much louder signal. They built multiplayer, they maintain it, they run the servers, they pay for all of this."
His summary is the line I’d put on the wall of every community team: "Community behavior for me is more valuable than just opinion." Studios, in his words, are great at collecting opinions. What they should care about is revealed demand: where players are investing their time, their money and their technical effort.
This lined up with something I found when I studied a set of recent PC and Steam hits last year (Lethal Company, Project Zomboid, No Man’s Sky, Phasmophobia, Schedule I and others). I saw three common traits: small teams (often under 20 people, sometimes one to three), strong community engagement, and long development cycles run with the community. Pedro agreed there’s a correlation, but he pushed back on the cause. Small teams and long development don’t create success by themselves. Plenty of studios of every size sit on a project too long. What matters is the length of the feedback loop between the players and the studio.
His example was Schedule I. Tyler built it on his own, which meant no red tape: no path from community to product to leadership, back to product, onto the roadmap and then to engineering. At a larger company, a good request can lose all its momentum somewhere in that chain. My read (this one is mine, not the tape’s) is that as budgets grow, decisions drift from the product people to the money people, and that’s where the loop gets long.
Part 2: Adoption, persistence, friction
Next I wanted to get specific. When a community builds something the studio didn’t ship, like a mod, what tells you it’s real? I asked Pedro what he actually looks for, and he named three things.
Adoption. Are people using it beyond the creator and a handful of friends? Downloads, likes and comments on a UGC platform help, and real usage telemetry helps more.
Persistence. Does usage survive the novelty spike? "It’s great, it’s awesome, but then two weeks later people aren’t using it anymore. What happened?"
Friction. How much pain will players tolerate to get it? Pedro called this "a very strange criteria, but it’s probably the most important of the three." Think of what it takes: downloading unofficial tools, joining Discords, configuring servers, troubleshooting mods that don’t work out of the box, and sometimes paying money for a feature the game doesn’t officially support. "That tells you a lot."
He was careful to add a caveat, and I think it’s the one a lot of studios skip. Hitting all three doesn’t mean the studio should build it. It tells you demand exists. The studio still has to decide whether that demand fits the game, the roadmap and the economics.
The friction point hit home for me. I have a friend who is widely seen as the creator of one of the world’s biggest games, Valorant, and he told me something similar: if a game is good enough, you don’t need to worry much about the first-time experience, because players will push through and bring their friends. What players are willing to put up with is the signal. I remember playing the original DotA mod in Warcraft III. It was brutal to get into, and on my first game people were cursing at me. And so many people played it anyway.
Part 3: Rank the signals (Discord size comes last)
Every community I’ve seen has a vocal minority that wants something, and they may or may not be telling you the right thing to do. I asked Pedro how he separates those signals from the ones worth acting on. He ranked them, and I found the order more useful than any single metric.
Retention first. "A thousand servers appearing for three days is interesting, but 500 servers still running months later is a lot more interesting." At MC Pro Hosting his team went past overall churn: they measured churn by game type and then by title (Rust, Minecraft, ARK), and shared what they found with the studios, because the studios didn’t have that view of their own communities.
Active server count.
Actual mod usage. Downloads matter, but downloads can mislead, because downloading something once costs essentially nothing.
Steam reviews for overall sentiment and repeated requests, and YouTube for what’s breaking and the culture around the game.
Discord size, last. It’s the metric he trusts least, for a reason anyone in a Discord will recognize: the first thing most people do after joining a server is mute it.
Then he gave me the line I used to open the video, and I think it’s the best summary of the whole conversation:
"If I had to choose between 100,000 people saying they want something and 5,000 people repeatedly doing something, I’d start looking at the 5,000."
The community validation loop
Next I asked Pedro to walk me through the framework itself. As I understand it, the community validation loop exists because building multiplayer is so expensive. When he ran the P&L at MC Pro, it came down to hardware, people and marketing, each roughly a third, with people the most expensive. Multiplayer means networking, sysadmins, matchmaking, orchestration, moderation, security, compliance and live ops. These aren’t launch costs. "You don’t just flip it on for like 30 days and then that’s it." His point is that if the community is already experimenting, a studio should learn from that before making the investment:
"Infrastructure should follow validated player demand rather than being the thing you use to discover that player demand exists."
Here’s the loop as he laid it out for me, in five steps.
Find the signal. What are players repeatedly asking for, or already building themselves?
Enable an experiment. Give the community enough access to test the idea: mod support (for example through mod.io), dedicated server binaries, APIs, or at least not stonewalling them.
Measure behavior. Are people using it? Are communities and servers forming? Are players coming back? What is it doing to your north-star metric?
Validate persistence. Does the behavior survive past the hype? Are people investing meaningful time or money?
Decide. With real evidence, choose one of three paths: build it officially, keep it community-led, or leave it alone.
That third option is the one I think studios forget most often. Pedro’s example is Minecraft Java Edition, where Mojang largely lets the community run the server and mod side. The community drives more things to explore, more players see the game, and that drives game sales.
When I asked how a studio should choose between a prototype, player research or a community-built experiment, he said there’s no single method. Sometimes demand is overwhelming enough that direct feedback is fine, sometimes players prototype it through mods, and sometimes the developer can prototype it cheaply. His rule is to ask: what is the cheapest credible experiment that gets you to observed behavior instead of opinions? "If you can test something for weeks or months before committing years of development and live ops resources, then that’s going to be incredibly valuable."
Three cases: Schedule I, RimWorld, Skyrim Together
Schedule I shipped as four-player peer-to-peer with no official server, and it has sold around 8 million copies. Players wanted a world that stayed up 24/7 without depending on one friend to host, and a community mod made dedicated servers possible. Pedro wouldn’t tell the studio "build dedicated servers." He’d tell it there may be enough evidence to investigate: look at occupancy, unique players, session length, and server retention at 7, 30 and 90 days, and check whether it’s moving your metrics in the right direction.
RimWorld never got official multiplayer from Ludeon, but the community mod RimWorld Together exists (Bisect is its official host). Pedro’s view is that a studio has a range of options here. It can leave a mod alone if it’s humming and everyone’s happy. It can support it officially, expose more APIs, work with the modder, hire them, or partner with them. Or it can simply leave the door open: "Hey, you’re doing great things. We appreciate it. If there’s anything you need from us, we’re just a click away."
Skyrim Together is the counterpoint, and I think it’s the most important case in the conversation. Years of demand and hundreds of thousands of downloads, and Bethesda still didn’t build multiplayer. I asked Pedro whether that was a mistake. His answer:
"I don’t think the existence of demand automatically means that Bethesda was wrong. I think a community can prove that players want something. It can’t prove that the economics work for the studio."
He listed what Bethesda has to weigh: engineering, QA, platforms, support, security, moderation, brand risk, and the opportunity cost of what those developers aren’t building instead.
What to do on Monday morning
I asked Pedro to get tactical. Say you run a 10 to 20 person studio, you have a hit, and your community starts building something you didn’t ship. What do you do next week?
Here’s his sequence, which I’d steal as-is.
Don’t put it on the roadmap. Find the people building it and talk to them: what they built, why, who uses it, and what limits they’re hitting.
Instrument it. Ask permission to see their numbers. How many people use it, how often, is usage growing after the honeymoon phase, is it bringing new players into the game, is it lifting sales or player counts, and are people still doing it at 30, 60 and 90 days?
Make the smallest investment that removes friction from their experiment. Maybe that’s documentation. Maybe it’s an API.
Leave the door open (and know when to say no)
This part matters most to me, because I come from mobile. Most mobile games have almost no modding support or community tooling. No mod support, no dedicated server option and no API means no signal. You can’t read behavior you’ve made impossible.
Pedro doesn’t think every game needs Steam Workshop, a full SDK, dedicated servers and APIs on day one. The cheapest door is designing the game so experimentation isn’t impossible. If dedicated servers make sense architecturally, consider exposing the server binary. If configurations can be safely exposed, document them. Don’t encrypt or lock things down without a reason. And when someone builds something interesting, don’t make a cease and desist your first move. Reach out first. His view is that a takedown is for mods that break core mechanics of the game, and only after the creator won’t engage.
"You don’t have to build the experiment. Sometimes you just got to make sure you haven’t designed the game to prevent one."
I also asked him when the answer is simply no, and he was just as clear. "There’s plenty of games that I would tell them to stay single player forever." Multiplayer isn’t an automatic upgrade. It changes the product, and taking a four-player game to 20 players changes its mechanics. If the community signal is weak, retention is poor, and the game doesn’t get meaningfully better with more players, don’t build it. But that’s a different decision from stopping players:
"There’s a huge difference between 'we shouldn’t build this' and 'players shouldn’t be allowed to build this.'"
If you run a studio, my suggestion for this week is simple. Pick one thing your community is doing that you didn’t ship, and find out how many people are still doing it 30 days later.
The full conversation with Pedro is in the audio player above and on Spotify. The 31-minute YouTube edition is at the top of this post.
