Drawing a Crowd

You scan a QR code taped to the side of a screen. Your phone opens a little drawing tool, something between MS Paint and a sketchbook, and you draw a little guy. Doesn’t matter what. A pig with a hat. A french fry with a face. A biblically accurate saxophone. You give it a name and a catchphrase, pick whether it walks, flies, or just stands there like a plant, and hit submit.

A few seconds later your little guy poofs into existence on a giant screen across the room, where it wanders off to join a few hundred other strangers’ creatures milling around a shared plaza. Someone near you points and laughs. You take a selfie with it.

That’s PIGCon Plaza. A volunteer crew from PIGSquad, Portland’s long-running game-dev community, built it for the first-ever PIGCon earlier this year. Over two days, about 1,300 people came through the doors and roughly 450 of them drew one.

The backend ran on Miren, and we tagged along to watch and support. Afterward we sat down with two of the people who built it, Brian Cain on the server and Mike Lee on the screen. What follows is their story, lightly edited, plus what it taught us about our own platform.

Wouldn’t it be cool if

“It started out in DMs with me and Will,” Brian told us. “We DM each other a lot of ideas all the time.” Will runs PIGSquad, which just hit its fifteenth year of game jams and meetups. The seed was the Nintendo Wii. “We wanted to create a live version of the Mii Plaza,” Brian said. “If you’ve ever had a Wii, that was it.”

The version in his head was a single screen. Then it grew. “Someone said, well, wouldn’t it be cool if people could draw on their phones? And all of a sudden it turned into a whole live thing.” A beat. “That’s why we ended up reaching for you guys.”

We know better than most: sometimes what starts as a fun side project slowly turns into a distributed systems problem. A single screen is a weekend in a game engine. A room full of phones drawing pictures that all have to show up live, on one shared display, in front of a crowd? That’s a backend.

The crew was about eight people, all volunteers with day jobs. Will had the vision and an artist named Corwin drew the interaction mockups. Brian took the server, Mike took the screen, and a small hardware team handled the parts of the booth that weren’t software at all: a Wacom tablet for people who wanted to draw with a real pen, and two big buttons shaped like the PIGSquad pig (lovingly referred to as “cubepig”), one red and one blue, that Qristy programmed onto WiFi-enabled Arduinos and Dylan 3D-printed shells for. This is the kind of thing the PIGSquad community is really good at, a skill they’ve built up together over years of game jams and collaborations: a loose crew coordinating on the fly, everyone pitching in what they’re best at, turning a spark of an idea into something real.

The whole thing ran on a budget of zero. “Part of the ethos was: what can I do for literally zero money?” Brian said. “PIGSquad’s a 501(c) nonprofit. I didn’t want to ask them to pay for anything.”

A crowd, made right

Mike Lee has done a lot of different things. He’s worked at Nike and Google, and spent more than a decade at DreamWorks doing lighting, effects, and pipeline work, with credits on Shrek 2, Madagascar, and Over the Hedge. The stretch that matters here is the four years he ran crowds, leading a team of eight on Megamind: the work of making a screen full of background characters look alive without looking identical.

“Crowd” was a precise word there. The hero cast of a film is small, six or so characters; everything from the seventh on is a crowd character, and crowd characters have to be made. The crowd department built catalogs of interchangeable parts, the same shirt in a hundred colors, tops and bottoms and hair and skin mixed and matched, with a weighting system so the art director could tune the distribution and toss the combinations that didn’t work. A crowd of reporters in one shot, a richer neighborhood in another. The job was to fill the background with figures that read as alive and individual without anyone noticing the machinery.

A plaza of strangers’ doodles is the same problem, simpler. Mike hadn’t framed it that way until we said it out loud, but the Plaza put him right back in a crowd system.

He ran it as a native Godot app on one machine he controlled, pointed at one screen, so distribution was never his problem. Crowd control was. Past a point, more creatures just turn the screen to soup, a wall of bodies where nobody can find their own. So he capped the population, around 150, and ran it the way he used to run a film crowd: older creatures randomly poof out of existence, and he weighted the spawning so the newest arrivals almost always stayed on screen, because the newest arrival is the person standing right in front of you, waiting to see their little guy. He even had the camera drift and cut between creatures, so the plaza read as a space you were moving through.

“Just enough to feel dynamic but not chaotic,” he said.

He had a name for the standard he was holding it to. “There’s a concept in location-based entertainment called good show,” he said, a phrase he picked up from the Disney-trained imagineers he’d worked with on Google’s experience centers. It’s the theme-park rule that everything a guest sees should look intentional, down to the trash cans, which are themed and kept clean so nothing breaks the world. On the Plaza, good show meant no stray or glitched bits drifting across the screen, and nobody waiting longer than they had to before their creature showed up, the other reason he kept the newest ones up front. The doodles could be junk. The experience couldn’t look like one.

What we didn’t do for them

Standing the thing up was easy, and Brian said so. “The actual deployment process was easy. You throw down your config file, deploy, done.” The backend was a Go server with a SQLite database in a Docker file he’d carried over from an earlier experiment. Getting it onto our shared developer-preview cluster took a config file and a command.

The easy part is what we’d hoped for. The rough edges are what we actually wanted to hear about, though, because those are the ones we can do something about. And the handful of things that came after, the ones a public launch leans on, he had to handle himself, because we don’t smooth those out for you yet.

Start with the thing he was most worried about. By design, anyone could draw: you scanned a QR code and the drawing tool opened on your phone, so the endpoint that accepted submissions was sitting on the open internet, reachable by anyone with the link. And the link could travel. “I was afraid,” Brian said, “if Will shares this on Bluesky, someone’s going to write a for loop and submit a bunch of characters and press a bunch of buttons.” A for loop pointed at a drawing endpoint can fill a disk with PNGs in a hurry. So he asked us: do you rate limit? Not yet, we told him; we hand you the machine’s capacity and otherwise stay out of the way. So he wrote his own, on the drawing submissions and on the button presses, and put the buttons behind an API key so no one could juice the red-versus-blue race from a laptop. Part of it was protecting his game. Part of it was something else. “This is a shared cluster. Other people are running their stuff,” he said. “I was trying to be a good neighbor, basically.”

The same gap turned up with the admin panel, the moderation queue where the team approved each creature before it hit the screen. It needed a password, and the obvious place to keep one is an environment variable, except on our cluster every app shares a permission model and anyone with cluster access can read anyone’s environment. A dozen-odd people could have read his admin password. So he worked around us. What he landed on was storing only a one-way hash of the password, never the password itself. “I don’t know if that’s a great solution,” he said, “but it worked for the weekend.” It isn’t how we want you to have to do this.

He was relaxed about the stakes, at least. “Honestly, if it had leaked, it’s not like we’re storing credit cards. We’re storing characters. Just little goofy guys.”

The backups were the most Brian part of the whole thing. Our disk backup and restore story is still early days, so he kept his own copies. Paul was there for the weekend:

Brian was religiously running backups, like once an hour over the course of the weekend. He’d sit down, open his laptop, and run the backup script fresh.

“If you had some disk restore I could trust,” Brian said, “I wouldn’t need to run this.” Fair.

And the observability was a stack of bash scripts. He wanted to know if anyone was hammering the API, if anything was throwing 500s, if his rate limits were tripping. We don’t give you that out of the box, so he grepped his logs with jq. It mostly worked, and parsing the logs was the one thing he noticed get slow during the con. Still, he’s clear-eyed about how much of this a project like his actually needs:

“If it’s just a little goofy thing you share with friends, you probably don’t need the battleship observability. But if you’re building something serious, you need to know it’s healthy.”

All of this is the kind of work we want Miren to take off your plate, and the gaps Brian hand-built around are the roadmap you’ll see us ship against. Since PIGCon we’ve already closed one of them: route protection puts a password, or full SSO, in front of any route with one command, with the session and hashing handled at the edge and your app none the wiser. It’s the admin login Brian built by hand, minus the building.

Game day

It held. “During the weekend everything seemed pretty smooth,” Brian said. “I don’t think we had any outages. We did a deployment in the middle of one of the days, and that worked great.” Roughly 450 creatures over two days, no outages, one clean mid-event redeploy. The backend stayed boring all weekend, which is the only thing anyone wants from a backend.

The interesting failures all happened somewhere else, on the screen and in the moderation queue.

Mike found a bug between day one and day two using about the lowest-tech debugger there is: he drew numbers. “I drew the number one on the first one, the number two on the next.” He’d glimpsed it earlier, in pre-con load testing, but it only bit for real on day two. Day one never put enough creatures on screen to hit his cap; day two, with every creature from day one still in the world, sailed past it, and the bug in his prioritization logic surfaced: the newest arrivals, the ones people were waiting on, stopped showing. He caught it Saturday night and fixed it before the doors opened Sunday. “You can’t test the environment until you’re in the environment,” he said.

The other bottleneck was a human one. Every single creature was moderated by hand. You can guess why, given a public URL and what people will draw. Exactly one submission got rejected outright. But the moderation queue itself bogged down as submissions piled up, and approving them got slow. It dragged on the two volunteers working that queue, while the crowd out front never noticed a thing.

“We were the ones with the bad experience,” Mike said, “which is fine, because it’s something we just hadn’t thought of. Unless you do it, you don’t know.” Brian shipped a fix for it mid-con, the redeploy he mentioned earlier. “It’s an audience of two,” Mike said of the moderation tool.

The little guys

Nobody had to engineer the best part.

“We never told people to take a selfie with their creature,” Mike said, “but they were doing it.” People drew a little guy, waited, watched it poof onto the screen, and took a picture. Then they watched everyone else’s and pointed and cheered. “Not only were people excited to see their own characters,” Brian said. “People were celebrating other people’s. ‘Look at that, look at that.’” Even the buttons drew a crowd. Brian’s favorite small detail was how many people were nervous to press them.

A couple of the little guys came from people who’d know. The creator of PICO-8 was sitting right next to Mike, and drew one. And late on Sunday night, one of the co-founders of id Software walked up to the Wacom station and drew Commander Keen.

That one got Brian. “As a kid I played their software,” he said. “Now, 30-some years later, he used something I built. I think that’s really awesome.”

Ask him to name a favorite creature and you don’t get one. “I like every guy.”

Would you do it again

“I’m at the whims of the people,” Brian said, “but I’d do it again. I had a lot of fun.” The people, for the record, were clear: the loudest feedback after the con was do the Plaza again. Mike is already past the point of pretending he has a say. “I feel too attached to it now. I can’t abandon it.”

The con ended and people kept asking to see the creatures again. Brian put up a gallery of every character, running off the backend. And Mike, who’d skipped the browser for the live game, started baking an offline version of the actual plaza: the whole world, everybody still milling around in it, no server behind it at all. The web export nobody needed for the live game is exactly right for the keepsake.

For us, the Plaza was the best kind of feedback: a real thing, built fast by a small team with no budget and no ops person, that held up in front of a crowd. It handed us a precise to-do list of the work we’d rather take off your hands, and we’re working through it. But the part that was already true on the day matters more: there’s a version of this platform good enough for eight volunteers to put a live, multiplayer, draw-your-own-creature game in front of 1,300 strangers and have it just work.

What sticks with us isn’t the to-do list, it’s the screenful of goofy little guys and the people laughing and taking pictures of them. We’re glad we got to host it.

Special thanks to all the PIGSquad members who helped make PIGCon Plaza possible: Will Lewis (design), Brian Cain (programming/design), Corwyn Prichard (design), Mike Lee (programming), Qristy Overton (programming, button programming & assembly), Dylan Bennett (button printing), Ragonia Art (art), Eerywax (Ian) (programming/art).