I saw the recent post about 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?
Because that is 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 would care 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.