Ireland edition. This guide is written for volunteer-run clubs in Ireland. Where rules differ — grants, tax, incorporation, safeguarding — follow the Ireland-specific pointers below or check with your national body.
Here is the reframe that changes how a game development club is run: your club's product is not meetings. It is finished artefacts — builds people can actually play, a showcase night with a queue at the door, a credits list with real names on it. Everything else is scaffolding. A club that meets forty times a year and ships nothing has had forty conversations; a club that meets twelve times and ships four small games has a portfolio, a reputation and a reason for the art students to keep coming.
That distinction sounds obvious and it is quietly violated by almost every dev club. The default meeting is a group of people sitting in a room with laptops, working on their own long-term projects, occasionally showing each other a shader. It is pleasant, it is popular, and it produces nothing the club can point at. Then the committee turns over, the two people carrying the momentum graduate or move on, and the next group starts again from an empty room.
This guide is for whoever runs a game dev club, society or collective — at a university, in a city, or somewhere in between. It covers building a calendar that forces things to ship, running a jam properly from theme to judging, fixing the discipline imbalance that leaves you with nine programmers and no artist, putting on a showcase, and writing down who owns the work before anybody has anything worth owning.
A calendar built around shipping
The strongest structural decision a dev club makes is to run in cycles with a hard end date, rather than as an open workshop. A cycle has a start, a deliverable and a night where the work is shown to people who did not make it. That last part is the engine: the deadline is only real if somebody outside the team is going to see the result.
A twelve-week cycle fits most club calendars and can be repeated two or three times a year.
| Week | What the club does | What each team owes |
|---|---|---|
| 1 | Kick-off, pitch night, teams form | A one-paragraph pitch and a named team lead |
| 2 | Scoping workshop — cut every pitch in half, then in half again | A scope document and a target platform |
| 3–4 | Skills nights on the disciplines the cohort is short of | A playable prototype, however ugly |
| 5 | Playtest night one, teams swap builds | Something someone else can launch |
| 6–7 | Work nights with mentors floating between teams | Core loop finished, art direction chosen |
| 8 | Playtest night two, with people outside the club | A build with a title screen and no crashes |
| 9–10 | Polish, audio, accessibility pass, build pipeline | A packaged build that runs on a clean machine |
| 11 | Submission and credits deadline, showcase setup | Final build, credits list, screenshots |
| 12 | Showcase night, public, with a queue at the door | Show up and watch people play it |
Two rules keep the cycle honest. Scope gets cut in week two, hard, by someone who is not on the team — a club officer or a mentor whose only job is to be unreasonable about ambition. And week eight's playtest happens with strangers, because a build only tested by its authors is not tested. Both of these are unpopular in the moment and are the difference between four finished games and eleven abandoned repositories.
Publish the calendar before the cycle starts, with each night as a separate event people can put in a calendar. Running the cycle as an enrolment program with a sign-up per cohort is more useful than a series of one-off invitations — you get a roll, you know who is on which team, and the people who missed week five can be contacted directly rather than hoped at.
Fit the cycles to the academic year if any part of your membership studies. The year starts in early autumn, which makes those first few weeks your strongest recruitment window by a wide margin, and the long break falls across the summer — a natural moment for a short remote jam rather than a full cycle. Plan a second, smaller intake in the new calendar year, because that is when people who missed the first wave come looking.
Running a game jam
A jam is the highest-yield thing a dev club does. It produces finished artefacts in a fixed window, it forms teams that outlast it, and it is the one event where a complete beginner can genuinely contribute by the end of a weekend.
Before the weekend
The theme is the least important decision and gets the most argument. Pick something evocative and constraining rather than clever — a two-word phrase, a mechanic constraint, or a limitation ("one screen", "no text", "you cannot win"). Reveal it at the start, not before. Have a backup theme in case the chosen one turns out to duplicate a well-known jam running the same weekend.
Team formation is the decision that actually determines outcomes. Three approaches, and it is worth telling people which one you are using in the announcement:
- Pitch and pick. Everyone gets ninety seconds to pitch, then people join a pitch. Produces enthusiastic teams and leaves the quiet people stranded — pair it with an organiser who personally places anyone still standing alone after fifteen minutes.
- Assigned teams. Organisers build balanced teams from the sign-up form's skills data. Feels bureaucratic, produces by far the best discipline balance, and is the right call for a club that skews heavily to one discipline.
- Free-for-all with a floor. People form their own teams, but no team may have more than four members and every team must have at least two disciplines represented. Cheap to run and prevents the eight-programmer team.
Collect the skills data at sign-up rather than on the day. A short sign-up form asking for primary discipline, secondary discipline, experience level, whether they are willing to lead, and any accessibility or dietary needs takes two minutes to complete and turns team formation from guesswork into arithmetic.
Write a one-page rules document and publish it with the announcement: the window (start and end times, stated with the time zone), whether pre-made assets are allowed and which kinds, engine and tool restrictions if any, team size limits, what must be submitted, and how entries will be judged. The most common jam dispute is about pre-existing code and assets, so be explicit — most clubs allow personal libraries and licensed asset packs if declared, and disallow work begun on the project before the theme reveal.
The weekend itself
| Time | What happens |
|---|---|
| Friday 6.00pm | Doors, food, welcome, code of conduct in ninety seconds |
| Friday 6.30pm | Theme reveal, then twenty minutes of silence for people to think |
| Friday 7.00pm | Team formation, with an organiser placing anyone unattached |
| Friday 8.00pm | Scope check — every team says their idea out loud in one sentence |
| Saturday 10.00am | Mentor sweep — someone visits every team and asks what is blocking them |
| Saturday 3.00pm | Vertical slice check — is there anything playable at all |
| Saturday 8.00pm | Feature freeze announced; from here it is polish and bug fixing |
| Sunday 10.00am | Build check — every team produces a packaged build on a machine that is not theirs |
| Sunday 2.00pm | Submissions close, credits lists locked |
| Sunday 2.30pm | Play session — everyone plays everyone else's entry |
| Sunday 4.00pm | Judging results, awards, photos |
The two checkpoints that save jams are the Saturday-afternoon vertical slice and the Sunday-morning build check. Teams routinely have a working project on a developer's machine and no idea that it will not run anywhere else; discovering that at ten on Sunday morning is recoverable, discovering it at two is not.
Submissions and judging
Require the same package from everyone: a playable build for a stated platform, a short description, two screenshots, a credits list with roles, and a declaration of any pre-existing or licensed assets. Missing packages are the reason good entries do not place.
| Criterion | Weight | What judges are actually looking for |
|---|---|---|
| Use of theme | 25% | An interpretation with a point of view, not a keyword |
| Fun and feel | 25% | Does the core interaction feel good in the first thirty seconds |
| Presentation | 20% | Art, audio and interface working as one thing |
| Completeness | 20% | It starts, it ends, it does not crash, it explains itself |
| Technical achievement | 10% | Something genuinely hard, done well |
Recruit three judges, at least one from outside the club, and give them the rubric in advance with a scoring sheet. Add two or three unweighted side awards — best first-time entry, best audio, funniest — because they spread recognition to people who will never win the main prize and are disproportionately likely to come back. Publish the scores or at least the reasoning, briefly, for every entry.
Skills nights and the discipline problem
Nearly every game dev club has the same imbalance: too many programmers, not enough artists, and almost never anyone doing audio. The clubs that solve it treat it as a recruitment problem rather than a rostering one, and they solve it outside their own membership.
Recruit deliberately from institutes of technology and university art, animation and music courses, and from the local games and creative meetup scene. A club project is a portfolio piece for a design student and a rare chance for a hobbyist composer to hear their work in something interactive — pitch it in exactly those terms rather than as an invitation to a hobby group.
Keep a skills register — a simple list of members with primary discipline, secondary discipline, tools they use and whether they are open to joining a team. Update it at each intake. It costs nothing and it means that when a team says "we need someone who can do a bit of UI", you can name three people instead of posting into a chat void.
Rotate the format of your regular nights so the club is not just a co-working session:
| Night type | Runs for | What it produces |
|---|---|---|
| Skills workshop | 60–90 min | Everyone can now do one specific thing they could not before |
| Show and tell | 45 min | Accountability, and the club sees what exists |
| Playtest night | 90 min | Feedback from people who did not build it |
| Post-mortem | 45 min | A written record of why the last project went how it went |
| Guest session | 60 min | A working developer answering real questions |
| Open work night | Whole evening | Momentum, and nothing else — cap these at one in three |
Mentoring works best as pairing rather than as lecture. Ask experienced members to take one newer member for a cycle: two conversations a fortnight, a look at their code or art, and an introduction to a team. Name it publicly, thank them publicly, and rotate it so mentoring is a role people step into rather than a personality trait two members have. The volunteer mechanics are the same as anywhere else — recruiting club volunteers covers slicing roles small enough that people say yes.
Showcases, and the night the work meets an audience
A showcase is a demo night for people outside the club — friends, other societies, a couple of local developers, and anyone curious. It is the deadline that makes the calendar work, and it is also your best recruitment event, because prospective members can see what they would get to make.
Run a build checklist a week out, and treat anything unchecked as not shipping:
- The build runs on a clean machine with no development tools installed.
- It launches to a title screen that names the game and the team.
- Controls are explained in the game, not by the developer standing next to it.
- There is a way to quit, and a way to restart without relaunching.
- Audio has a volume control and does not start at maximum.
- A basic accessibility pass — readable text size, no essential information conveyed by colour alone, and a difficulty or assist option if the game is hard.
- Someone who has never played it has completed the first two minutes unaided.
On the night, one machine per game, a printed card beside each with the title, the team and the credits, and a volunteer per two machines to reset builds and answer questions. Capture feedback in the moment — a short form on a tablet beside each machine with three questions beats a survey emailed on Tuesday. Photograph the room; those photos are what you use to recruit next intake and to approach sponsors.
Invite deliberately rather than broadcasting. Two or three working developers, someone from a related course or society, and anyone who mentored during the cycle. A small room with the right ten guests does more for your members than a big room of strangers.
Who owns the work, and who gets credited
This is the section every club skips and every club eventually needs, usually at the worst moment — when a jam project turns out to be genuinely good and two people disagree about what happens next. What follows is general information rather than legal advice, and a club with anything commercially promising should take proper advice early.
Agree a written club policy before your first jam, not after. A workable default:
- Contributors keep the rights to what they personally made, and grant the club and their team a licence to use it in the project, to show it publicly, and to keep it available afterwards.
- The club claims no ownership of members' work beyond that licence, and says so plainly.
- Any commercial release is a separate agreement, made by the people involved, in writing, before money is involved.
- Third-party assets are declared — engine, asset packs, fonts, music, sound libraries — with the licence for each recorded in the project. Check that every licence permits the use you are making, including a public showcase and a free release.
- Anyone may withdraw their contribution from future distribution with reasonable notice, which is rarely used and enormously reassuring to have written down.
- Credits are non-negotiable. Every contributor is named with their role, including people who left partway through and people who only did one thing.
Keep a credit sheet per project, updated during the cycle rather than reconstructed at the deadline. Name, role, and one line about what they did. Late-added credits are one of the most common sources of quiet resentment in creative clubs, and the fix costs a shared document.
Copyright in original work generally arises automatically on creation, and there is no registration system to file with — which means the practical protection for a club project is the written agreement and a dated record of who made what and when. Keep your version history and your credit sheet; between them they are the evidence you would actually rely on. For anything commercial, take advice from a solicitor with intellectual property experience before you publish.
Tools, money and keeping the lights on
A dev club's costs are small and awkwardly shaped: a venue or room, a domain and website, engine and tool licences for anything not free, a build or storage service, food at jams, and prizes. Food at jams is usually the largest single line, and it is also the one that most affects whether people stay for the whole weekend.
Fund it from four places rather than one — memberships, a small charge for jams that includes food, one sponsor or partner a year, and grant funding aimed at creative or digital participation rather than at sport. Studios and local technology employers are a realistic sponsorship target because they are hiring from exactly your membership; what they want in return is presence at the showcase and a chance to talk to your members, which costs you nothing.
Numbers to argue with rather than copy — clubs of this kind commonly charge around €15–€30 a year for membership, with jam tickets around €10–€20 covering food. On the funding side, arts and creative funding bodies run digital and interactive streams worth watching, local authority community and youth grants suit equipment costs, and student societies should exhaust their students' union grant scheme first — it is the least competitive money available to you.
Standardise the club's tools lightly rather than heavily. One recommended engine for beginners, one shared version-control setup that everybody learns in week one, and one place where builds live. Beyond that, let people use what they use. The clubs that mandate a full toolchain spend their first three weeks on installation problems instead of on making anything.
Giving the club a home that outlasts the committee
The recurring failure of dev clubs is not talent, it is continuity — every second year the club restarts from scratch because the calendar, the sign-up forms, the member list and the archive of past projects lived in a departing officer's account. ClubHelix gives the club a website it actually owns: forms for jam sign-ups and skills registers, events for every night in the cycle with RSVPs, program enrolment for running a cohort properly, and a members' chat that new committees inherit rather than rebuild.
It is free to start, the pricing is public rather than quote-based, and it is designed for volunteer committees who hand over every year. If your club's showcase archive currently lives in a shared drive nobody can find, you can build the club a proper site in an afternoon — and the university clubs pages show what a student-society setup looks like.
Frequently asked questions
How do you run a game jam for beginners?
Give them a way in on day one. Collect skills at sign-up and use them to build balanced teams rather than leaving people to self-organise, cap team size so nobody is a passenger, set a Saturday-afternoon checkpoint where every team must have something playable, and add side awards for best first entry. Publish a one-page rules document covering the window, pre-made assets and what must be submitted.
What should a game dev club do at its weekly meetings?
Rotate the format rather than running an open work night every week. A useful mix across a month is one skills workshop, one show and tell, one playtest night with people who did not build the game, and one open work session. Every cycle should end with a showcase where the work is played by an audience outside the club — the deadline is what makes the rest of it real.
Who owns a game made by a club?
Agree it in writing before the first project, and treat it as general information rather than settled law until you take advice. A common default is that contributors keep the rights to what they personally made and licence it to the team and the club for use, display and continued availability, with any commercial release handled by a separate written agreement. Declare third-party assets and their licences, and credit every contributor by name and role.
How do you get artists and audio people into a programmer-heavy club?
Recruit outside your usual pool — art, design, animation and music courses, and local creative meetups — and pitch the specific thing they get, which is a portfolio piece and the experience of hearing or seeing their work inside something interactive. Then protect them once they arrive: balanced teams, credit by name, and never treating art and audio as a final-week task.
Does a game development club need its own website?
It needs somewhere permanent that survives a committee handover. Sign-up forms, the cycle calendar, the member list and an archive of past projects should not live in a departing officer's personal account. A club site with forms, events and an archive gives new members something to look at and new committees something to inherit.
Related reading: how to run a student society covers the committee and handover side in depth, and how to run a retro gaming club is a useful companion if your showcase involves hardware.
