The Lobby That Made Everyone Wait
You know that feeling when you click 'Find Match' and nothing happens? That was our lobby for way too long. A few weeks ago, a player in the Discord typed exactly five words: 'lobby takes too long.' We read it, we agreed, and we realized we’d been ignoring a slow backend call that piled up on peak hours. The original matchmaking loop checked every player’s ping, region, and rank before even looking for a room, and it did it all on the main thread. So during peak EU evenings, the queue would hang for 15 seconds. That doesn't sound like much, but in a browser game where you expect instant, it felt like forever.
We built The Agency as a student project, which means we cut corners to ship fast. The lobby code was written in a weekend back in 2022, and it worked fine when we had 20 players. But now we regularly hit 50 concurrent players on weekends, and that old loop just couldn't keep up. The server would spawn a new thread for each player, but the matchmaking algorithm was basically: grab all pending players, sort them by region, then try to form groups of 2-4. Except it ran in O(n²) because it compared every player against every other player. For 20 players that's 190 checks, doable. For 50 players that's 1,225 checks. And it did this every time a new player joined the queue. You can guess what happened.
We knew the bottleneck, but we kept pushing it off. 'We'll optimize next sprint' is a classic indie dev trap. We don't have a real sprint, it's just three of us working after class. So the lobby stayed slow until that one message in the Discord. It wasn't a rage message. It wasn't a demand. Just a quiet, factual statement from a player who had been waiting. And we realized we owed it to everyone playing to fix it, not next week, but tonight.
So we sat down at 9 PM local time and started deleting code. That's not a joke, the fastest way to speed something up is to remove steps. We cut the region check entirely for the initial matchmaking. If players end up in a high-ping server, they can re-queue after the match. We changed the algorithm to a simple first-come-first-served with a 4-second timeout: collect players for 4 seconds, then group them by party size and throw them into the first available room. No more per-player sorting. The new loop runs in O(n), just iterate the queue once and assign. Done.
By 2 AM we had a working version. By 4 AM we had tested it with a few Discord volunteers. By 6 AM we pushed it to production. That's how long indie game development takes when you actually listen to feedback: one night. No meetings, no tickets, no approvals. Just raw code and a community that tells you what's broken.
The old lobby averaged 12.3 seconds to find a match during peak hours. This is not a made-up stat, we logged it. After the rewrite, average wait time dropped to 2.1 seconds. The player who complained? He messaged us the next day saying 'wow, that was fast.' We told him he was the reason. He didn't believe us at first, but we showed him the commit log. One sentence from a stranger triggered a full rewrite. That's how we work at Inferna Studio.
The Before: A Lobby Built for 10 Players
Let's dive into exactly what the old lobby looked like under the hood. We built it during a 48-hour game jam, so the code was ugly from day one. The matchmaking function was over 200 lines long, with nested for loops and five different conditionals for party balance. It checked each player's kill/death ratio from the last 10 matches, their ping to all available servers, and their game mode preference, then tried to match everyone perfectly. In theory, that sounds fair. In practice, it meant that on a Friday night with 30 players in queue, the server would freeze for 15 seconds while it computed the 'perfect' match.
The frontend didn't help either. The lobby page had a WebSocket that sent a heartbeat every second. Every heartbeat triggered a server-side update that re-ran the matchmaking check for that player. So if you were waiting, your browser was constantly asking 'am I matched yet?' and the server was constantly recalculating. Multiply that by 30 players and you get 30 database queries per second just to check status. No wonder it was slow.
We also had a bug where if you canceled the queue and re-joined, your old matchmaking ticket stayed in the system. So sometimes players would get matched into a game they had canceled 5 minutes earlier. The server would try to assign them, they wouldn't respond, and the room would hang for another 30 seconds before kicking them. That happened more than we'd like to admit. We thought it was rare until a player posted a clip of it happening three times in a row. That was the straw that broke the camel's back, well, that plus the 'lobby takes too long' message.
The worst part? We knew about these problems for months. We had a todo list with items like 'optimize matchmaking' and 'fix double-queue bug' that had been sitting there since last year. But we were busy building new features, the DOMINION mode, the Loadout Lab, the campaign missions. We thought players would tolerate some waiting if we gave them more content. Turns out they'd rather have a fast lobby than a new gun skin. That's a lesson we learned the hard way.
Looking back, the old lobby was designed for a game with 10 concurrent players. When we launched, that was accurate, only 10 people were online at the same time. But The Agency grew, and the infrastructure didn't. We were using a single server instance on a $5 DigitalOcean droplet. The database was SQLite, yes, SQLite in production. We had to switch to PostgreSQL later, but even then, the matchmaking logic was the real bottleneck. The database could handle the load, but the Node.js event loop was blocked by all those synchronous computations.
We also had a leaderboard call that fired every time the lobby loaded. That call queried the top 100 players and their stats, which took about 1.2 seconds on average. So even if your matchmaking was instant, you'd still stare at a loading spinner for over a second while the leaderboard loaded. We removed that completely in the rewrite. Now the leaderboard only loads when you click a button. Sometimes the best optimization is just not doing something.
So the old lobby was a mess. But it worked for the first few months, and that's all we needed. Student projects rarely start with scalable code. You write what works, and you fix it when it breaks. The community helped us realize it was broken earlier than we would have on our own. That's the real power of having an open development process, you don't need to guess what players want. They tell you.
The After: A Lobby That Just Works
The new lobby took one night to write, but the thinking behind it took longer. We stripped everything that wasn't essential: no leaderboard on load, no background matchmaking recalculations, no per-player ping check. Instead, the lobby now works like this. You click 'Find Match', your name goes into a simple queue array. Every 4 seconds, the server takes everyone who has been in the queue for at least 4 seconds, groups them by party size (solo, duo, trio, quad), and assigns them to the first available room with matching slots. That's it. No ping check, no rank check, no KD ratio. Just pure speed. If the room has a bad ping, you can vote to rematch after the game.
The server now handles the queue as a single array with a timer. We used Bull, a Redis-based queue system, to manage the timing. Each player gets a 'waiting' job with a 4-second delay. After 4 seconds, the job triggers a function that groups all waiting players and assigns them. If a player cancels, the job is removed from the queue. No orphaned tickets, no ghost players. The code is now 40 lines instead of 200, and it scales linearly. We tested it with 200 simulated players and the matchmaking took under 3 seconds. That's good enough for now.
We also changed the frontend to remove the heartbeat. Instead of the browser asking every second, the server now pushes a 'match found' event via WebSocket only when the match is ready. That cut the number of database reads by 99%. The lobby page loads instantly now, and the spinner only appears when you're actually waiting for a match. If a match is found immediately, you jump straight into the loading screen. No artificial delays.
One thing we kept is the skill-based matchmaking, but we moved it to after the match rather than before. After a game ends, the server records your win/loss and adjusts your hidden MMR. The next time you search, the system notes your MMR and tries to find opponents with a similar range, but it doesn't block the search if no perfect match exists. If after 8 seconds you haven't been matched with similar MMR players, it expands the range. This way, high-skill players still get fair games, but they don't wait forever. The system learns from each match and adjusts quickly.
We also added a visible timer in the lobby that shows 'Looking for players.' and counts the seconds. If it goes past 10 seconds, the text changes to 'Widening search.' to let you know the skill range is expanding. That small transparency alone reduced complaints by half, even though the actual wait time was already faster. People just want to know what's happening. The black box of matchmaking used to frustrate players more than the wait itself.
The new lobby went live at 6 AM on a Tuesday. By 8 AM, a player posted in Discord: 'Did you guys do something? Matchmaking is instant now.' That was the best feedback we could have gotten. We told them about the overnight rewrite, and they were shocked. The idea that a single comment could change the game overnight, that's the culture we're building. No bureaucracy, no corporate roadmap. Just listen, fix, ship.
Of course, the code is not perfect. It's held together with duct tape and promises. There's a bug where sometimes players get matched into a full room, and the server kicks them with a 'room full' error. We're still working on that. And the 4-second timer means that if you queue at a quiet time, you might wait the full 4 seconds even if there's another player available. But 4 seconds is better than 12, and we can optimize further later. The point is: we shipped an improvement that actually made a difference, and we did it in one night because a player spoke up. That's the real story here.
Why Your Feedback Ships Faster Than You Think
We get a lot of questions about how long indie game development takes. People assume that because we're a small student team, everything moves at a snail's pace. And sometimes it does, the DOMINION mode took us three months to build, and the 24-mission campaign took even longer. But the small stuff? The lobby, the UI, the quality-of-life fixes? Those can ship in hours if we prioritize them. The bottleneck is never coding, it's deciding what to work on. And that's where your feedback comes in.
We have an idea board on the website where anyone can pitch a feature. Each community member gets one vote, and the top-voted ideas become our roadmap. But we also have a Discord where people just shout into the void. That's where the most actionable feedback lives. When someone types 'lobby takes too long,' we know it's a real problem because they wouldn't bother typing otherwise. We don't need a formal bug report or a vote tally. One genuine complaint from a player we trust is enough to trigger a rewrite.
And we trust the community because they've proven they know what's best. Early on, we ignored feedback and built features nobody asked for, like a replay system that no one used. That was a waste of a month. Now we listen. The 'one vote per person' system means that the most popular ideas are the ones that benefit everyone, not just vocal power users. But the lobby fix wasn't an idea board entry, it was a raw complaint. That's even better because it means we're hearing what's actually broken, not what people think would be cool.
We also use open-source tools wherever possible. The Agency runs on Node.js, Redis, and PostgreSQL, all free and well-documented. For browser-based games, there's no install overhead, so we can push updates instantly. Players don't need to download a patch, they just refresh the page. That immediacy means we can iterate faster than games with traditional installers. It's one reason why we chose to build a browser game in the first place, even though it limited our graphics capabilities.
But the real secret to shipping fast is scope. We didn't rewrite the entire matchmaking system. We just fixed the one thing that was slow: the queue logic. We left the ranking, the MMR, and the server allocation mostly untouched. We focused on the 20% of code that caused 80% of the delay. That's the Pareto principle in action. And by cutting scope ruthlessly, we could deliver a fix in one night instead of one week.
We also didn't test thoroughly. We tested with 5 volunteers in a voice call, and when nothing broke, we deployed. That's risky, but it's how we move fast. If something breaks, we can roll back in minutes. We've broken the lobby before, once we accidentally deleted all active games mid-match. That was bad. But we learned from it, and now we always run a canary release: deploy to a small group of players first, then everyone. The lobby rewrite went to 10% of players for 10 minutes before full rollout. No issues.
So when you ask 'how long does indie game development take,' the answer depends on who's listening. If we're listening to you, it can take one night. Your feedback on matchmaking isn't just a suggestion, it's a direct line to the code. We don't have a PR department or a community manager who filters feedback. The server logs are public (well, not public, but you get the idea). When you complain, I see it. And if it's a five-word complaint that's dead-on, I'll probably spend the night fixing it. That's not a sales pitch, it's just how Inferna Studio works.
In the end, the old lobby is gone. The new one is faster, simpler, and built because of a single sentence. We're not going to claim it's perfect, but it's better. And that's the whole point of indie development: making things better, one fix at a time, with the people who actually play the game. So keep typing. We're reading.