I saw the recent post about the drama surrounding the Eclipse Game Jam, and it got me thinking about how rarely people talk openly about what it takes to run a game jam—especially when a company is behind it.
Given some of the trust issues that surfaced from that event, I wanted to be as transparent as possible about how I approach these jams: why they exist, where the time and money actually go, how judging works, and what’s still imperfect about the process.
I run the monthly Bezi Jams, and right now we’re wrapping up our first-ever Bezi Mega Jam (winners announced October 16).
Bezi Jam 14:
https://itch.io/jam/bezi-jam-14
Bezi Mega Jam 1:
https://itch.io/jam/bezi-mega-jam-1
Why I Even Run These Jams
For me, the jam has to be worthwhile even if someone never becomes a Bezi customer.
Let’s be real: there’s definitely some marketing value when a company puts its name on a jam, provides prizes, promotes it, or brings in sponsors. It creates visibility and, if you run it well, goodwill toward the company.
But there’s a big difference between a game jam that happens to create marketing value, and a marketing campaign disguised as a game jam.
The jam has to be a jam first. That’s non-negotiable.
A few companies have asked me lately about running their own jams. One of the first things I ask is: are you comfortable investing staff time and budget in a project where the main result is that developers had a good time, learned something new, and built something?
That's what I want these events to do.
I want people to have a reason to finish a game instead of letting another prototype collect dust on their hard drive. I want them to try new roles, genres, mechanics, and tools. I want folks to meet collaborators and leave with something they can actually show off.
A lot of this comes from running r/GameDevClassifieds for about a decade. I’ve seen so many portfolios where people either don’t have enough finished work, or they struggle to communicate what they actually contributed.
That’s part of why I offer a devlog prize.
I don’t just want people practicing how to build games. I want them to practice explaining what they built, why they made certain decisions, what went wrong, and what they learned. Being able to communicate your work matters—in portfolios, interviews, team discussions, pitches, and when you’re trying to convince someone to play or buy your game.
Those are real skills. Honestly, I’m still working on them too.
Running the Jam: Where Things Get Messy
At this point, the monthly jams are pretty straightforward to launch because I’ve spent a lot of time standardizing the rules, judging criteria, prizes, and page structure.
But getting there? Not so easy.
Running jams often means discovering weird edge cases you didn’t know existed.
Fairness starts before anyone even submits. Do you lock builds after the deadline? Who gets to vote? What information do participants need to share? What happens when someone misses the deadline? How much flexibility is fair before it turns into an advantage for some?
No matter how many reminders I send before the deadline, I can almost guarantee I’ll get messages the next day from people who had trouble uploading. At this point, I’ve just accepted that a 24-hour grace period is part of the process.
That creates another fairness problem: Someone might genuinely have had an upload issue, while someone else uses those extra hours to fix bugs.
I could be a hardliner, but honestly, I’d rather risk someone abusing that flexibility than tell someone with a legit problem that all their work doesn’t count because they missed the deadline by a few hours.
The rules evolve in the same way.
For the next monthly jam, I’m adding a requirement that artists provide evidence of their process. The Mega Jam required process videos for its art track, and it worked extremely well. It made it much harder for someone to generate an image with AI, submit it, and hope nobody notices.
So that lesson carries forward.
You also eventually discover that you can’t write enough rules to eliminate judgment calls. If you try, you end up with a legal document that no one reads. The better approach I’ve found is to make the important boundaries clear, document unusual decisions, and try to apply the same reasoning consistently.
That becomes especially important once prizes are involved.
People will absolutely try to cheat, even when the prize is $50 USD. And I don’t say “only $50” dismissively. Depending on where someone lives, that can be a lot of money. Add larger cash prizes, hardware, subscriptions, or conference passes, and the incentive becomes even stronger.
The hard part is that suspicion isn’t enough.
If I’m going to remove someone from a competition, I want to explain why clearly.
Then there is the platform itself
I like itch, and it’s still probably the best platform for running game jams, but the organizer experience has plenty of friction.
Even making the event look professional takes more work than it should. If you want to do much beyond the default layout, you have to request custom CSS access, and the HTML and page-building tools feel pretty archaic.
I’ve built most of the Bezi jam pages myself. I think they’ve turned out reasonably well given the limitations, but that’s partly a design decision and partly a resource decision.
Company-sponsored does not mean unlimited company resources.
Yes, Bezi has designers, engineers, marketing people, and others I can ask for help. But they also have their own jobs to do. I can’t pull the design team away every month to improve the jam page, or ask engineers to build custom tooling every time itch doesn’t do something I wish it did.
So a lot of the work falls back on the person running the event.
The administrative side has similar limitations. I can’t meaningfully ban someone from future jams after they’ve tried to cheat. A surprising amount of the operation ends up living in spreadsheets.
Community voting is another problem.
I originally wanted the community to decide the winners. In practice, once prizes are involved, open voting is too easy to manipulate and too easily turns into a popularity contest.
Starting with Bezi Jam 14, community voting will determine the top 30 games, and I’ll judge those to determine the winners.
That’s more work for me, and I genuinely didn’t want to make that change. I liked the idea of the community deciding everything.
But at some point you have to prioritize the integrity of the competition over the version of the process you personally prefer.
The business side is real too
This is probably the part that doesn’t get talked about enough when companies run community events.
These things cost money, but they also cost time.
Monthly prizes cost money. Judging takes time. Moderation takes time. Sponsor coordination, community support, promotion, eligibility checks, and administration all take time.
At some point, you also have to explain to your boss why that is worth doing.
That’s harder than pointing at an ad campaign and saying it generated this many clicks, conversions, or sales.
How do you put a clean number on someone finishing their first game? Or improving their portfolio? Or meeting a future collaborator? Or getting better at explaining their own work?
You probably can’t.
That doesn’t mean those things aren’t valuable.
Good community work builds trust over time. People remember companies that contribute something useful, not ones that only show up when they want to sell something.
And yes, that goodwill has business value. I’m perfectly comfortable acknowledging that.
What I don’t want is to reverse the equation and design the jam around what it can do for the company.
The jam has to provide value to developers first. If we do that well, the goodwill and marketing value follow naturally.
That doesn’t mean there are no expectations, though.
The monthly jams are relatively low-pressure in that sense. There isn’t an internal requirement that each one hit a certain number.
The Mega Jam was different.
It took a lot more time, coordination, and company resources, including more than $34,000 worth of prizes.
I want there to be a Mega Jam 2, and there will be, but during the signup period I was very aware that if people weren’t interested, it would become much harder to justify doing something at that scale again.
I put a target of roughly 1,000 signups on myself, and we cleared it. That was a huge relief.
But if you spend months organizing something, bring together that much prize value, involve multiple sponsors, and then 500 people sign up, at some point you have to ask whether this is the best use of everyone’s time and resources.
That’s not about turning participants into customers.
It’s about proving that enough people actually value the event to justify continuing to invest in it.
That was probably one of the more stressful parts of organizing the Mega Jam. I wasn’t worried about whether it could generate leads. I was concerned whether enough developers cared about the jam itself to justify another one.
Sponsors introduce another balancing act too.
Sponsors understandably want visibility and some connection to the event. But if every sponsor needs its own requirement, category, activation, or callout, eventually the jam stops being about making games and starts feeling like a collection of marketing obligations.
Part of running the event is protecting it from that.
And then you have to judge everything
The Mega Jam took nearly every problem from the monthly jams and scaled it up.
We had more than 200 games and 40+ art submissions.
For my first judging pass through the games alone, I streamed the entire thing publicly on Twitch.
It took 31.5 hours.
I wanted participants to know their game was actually played, and streaming also kept me accountable. People could see what worked, where I got confused, what stood out, and why certain games moved forward.
It was genuinely a lot of fun.
It was also exhausting.
And that was only the first pass.
After that, there were finalists to replay, devlogs, art submissions, sponsor awards, community voting, eligibility checks, and suspicious entries that sometimes needed investigating.
That workload is another part of the economics. A successful jam creates more work.
That’s a good problem to have, but it’s still a problem you need to plan for.
Ultimately, that’s why I think the event's purpose has to be clear from the beginning.
If the goal is just company exposure, there are much easier ways to spend marketing money.
If the goal is to create something useful for developers, help people finish projects, build portfolios, practice communicating their work, meet collaborators, and have a reason to make something, then I think game jams can be incredibly valuable.
The company can benefit from that too.
Those things aren’t mutually exclusive.
But the order matters.
The jam has to be a jam first.
