Tips for running a university game dev club

Published 05 Jul 2026

Table of Contents

A few months ago, someone reached out on the UNL Game Development Club Discord server asking for tips on how to start a game dev club at their own university. I wasn’t around for the founding of the club, but as a former president, I had some thoughts regarding what worked well for us. It ended up being a pretty long response, so I figured I’d publish it here…

… well, apparently I had a lot more to say, because this revised version ended up being over 5 times longer! If you’re interested in starting your own club, or looking for ideas to improve an existing one, I hope this helps!

Purpose

As I see it, a game dev club is fundamentally just a structured group to help game devs find and connect with one another. The club should be open to anyone interested in the world of game development, and none of the club’s activities should get in the way of club members interacting with each other.

Even without any more structured activities, a group like this intrinsically opens the door for all sorts of benefits:

That being said, some structured activities can help newcomers learn the game development process, and help all members get more out of their time in the club. I think the most important activity, and the one our club spends the most time on, is…

Team-based game development

At the start of each semester, club members organize into teams, each of which works to develop a fully playable game by our end-of-semester showcase.

These dev teams are the core of our club, in my opinion. They offer members the chance to get practical, hands-on experience with game dev in a team, which can be particularly hard to find on one’s own! And at the end of the semester, members will have a finished game they can add to their resume or portfolio and show off to recruiters.

This structured, team-based development cycle creates motivation and accountability for team members, which I find helpful. It’s easy to let hobbies like game dev fall to the wayside when you have so many other things competing for your time at university. At the very least, the weekly club meeting provides a regular block of time in which you can actually do game dev.

It’s worth noting that club members don’t have to participate on a dev team if they don’t want to! Some members, for instance, don’t have the time to commit, prefer solo development, or just have a passing interest in the game development process. All are welcome to attend club meetings for other activities, and they can still get involved with teams by playtesting and giving feedback!

Pitch meeting

The first step of the process is coming up with game ideas and pitching them to the club. It’s important to do this as early as possible; the semester will fly by, and we want to give teams as much time as possible to develop their game.

In fall, we have our first meeting after the fall club fair, in which we explain the nature of the club to prospective members, and the guidelines for pitching a game. We also do an activity where members practice coming up with game ideas. We randomly choose a theme from the list of past Ludum Dare themes, and club members break into small groups to come up with a game idea matching that theme. Then, we all reconvene and each group shares what they came up with.

The following week, we have the pitch meeting. (In the spring semester, sometimes we’ll have the pitch meeting first, since we don’t get as many new members in the spring.)

Any club member is allowed to pitch a game idea, even if they don’t intend to be involved on the dev team themselves. One can even submit multiple game ideas, though in the unlikely event that there are too many, we may ask them to narrow down which one(s) they want to pitch.

For a member to pitch a game, I suggest having them submit a slide deck describing the game’s:

If someone already has a prototype of the game they want to pitch, that’s great, and they should absolutely show it off during their pitch!

If someone has a finished or nearly-finished game that they want to find more members to help them with, I personally think that’s fine, even though it doesn’t exactly fit the pattern that we follow. At the end of the day, the club is a space for game devs to connect with one another, and I’d say the club is fulfilling that purpose in this scenario.

We usually close pitch submissions 24 hours before the pitch meeting. (We meet on Sunday evenings, so this gives members all of Saturday to wrap up their pitches.) Officers then have time to review the pitches and make sure they cover all the key points, and they can give early warnings about overscoped projects (see Aside: scope!). One officer will then queue up all the presentations on their computer, so we don’t have to deal with the technical hassle of switching devices between each pitch.

During the pitch meeting, each member who pitched a game will present their pitch in front of the club. Our meetings are 2 hours long, so we aim to get through all the pitches in the first hour, and use the second hour for team formation. This informs how long each pitch should be, taking into account time for questions and switching presenters. Once pitch submissions close, we can give presenters a more accurate estimate of how long they have to present each pitch – 5 minutes is our general guideline.

If someone doesn’t want to present in front of the club (e.g. due to public speaking anxiety), they can record themselves presenting their pitch and play it back during the meeting. Alternatively, they can ask an officer to simply read the pitch off their slides, and then they can field questions at the end.

If your club doesn’t end up getting many pitch submissions, you can consider allowing people to present their pitch verbally with no slides. (Historically, slides haven’t been a hard requirement in our club, but I think they’re really worth doing, and even simple slides with a few screenshots can get ideas across much more clearly.)

Aside: scope!

It’s important to keep in mind that the scope of the games needs to be kept small! Especially for members without prior experience, it’s super easy to overestimate how much work one can get done in a semester, and having high expectations just sets you up for disappointment.

To see why this is so important, let’s suppose:

  1. Teams have 12 weeks to work on their games between the pitch meeting and our end-of-semester showcase (which is typical of recent semesters in our club); and
  2. Each team member works on the game for a minimum of 2 hours per week (1 hour during club time and 1 hour during the week)

That’s only 24 hours per person to make the whole game – less than a typical game jam!

Some outliers may contribute much more of their time to the game (which is great!) but you shouldn’t rely on your own team having any such outliers, not even yourself. Studying and coursework always tends to eat up more time than you think (and rightfully so – that’s why you’re at university in the first place).

Therefore, the scope of the games pitched should be about as big in scope as a typical game jam game – think of classic arcade games (e.g. Snake, Asteroids, Space Invaders) and small Flash games (e.g. Age of War, Learn to Fly, Canabalt). It’s really important to emphasize this point about scope in the first meeting when laying out the pitch guidelines.

Regardless, some people will (knowingly or unknowingly) pitch games that are too big to make in one semester. My best advice is to help these teams find a way to implement a playable prototype as quickly as possible.

With larger games, it can be tempting to start on big sweeping systems and trust that the game will all come together in the end, but having weeks go by without something you can actually play can be pretty demotivating, and even if you do get something playable eventually, there’s no guarantee it will be as fun as you hoped.

Instead, focus on the core, moment-to-moment gameplay and get a rough implementation of it as soon as you can. Then, add new features incrementally, building onto the existing game and playtesting each one yourself as you add it. As you do, you’ll see which aspects you find fun, and which ones you don’t, and this can influence your development direction. Playing the game over and over will also help you spot bugs and ways to improve the user experience. Plus, it’ll just make the overall development process more fun!

Programmers shouldn’t wait for the artists on their team to have finished work before they make their gameplay prototype. Use placeholder sprites (programmer art or free assets) in the meantime. Then, as artists finish their work, you can immediately slot it in where it needs to go, and quickly give feedback on whether it fits.

In the same vein, don’t neglect juice early on! Once you have the core gameplay prototyped, consider adding placeholder sounds and small visual effects like screen shake, squash & stretch, hit flashes, and particle effects, even before you move on to other big features. The kind of juice that’s relevant to your particular game may vary, and it may matter more (e.g. for a platformer) or less (e.g. for a grand strategy), but making the game feel satisfying to play will make it more fun to develop.

Anyway, back to club stuff.

Team formation

For the second hour of the pitch meeting, we form into teams. This is a pretty free-form process – we give members some time to mingle and group into teams on their own.

Our one requirement is that each team chooses a team lead, who has a few responsibilities:

It’s important to have this role as it helps ensure that development actually progresses as expected so the game can get done on time. Plus, having the team agree on a leader right away helps preclude internal conflicts over design and development decisions.

The presenter of the pitch is always given the first choice of whether they want to be the team lead for their own game idea or not (assuming they plan to be part of the team in the first place), but they can always allow someone else to take up that mantle – perhaps someone with more time or experience. In such cases, the team lead is expected to give the original vision its due respect, but it’s important that the presenter acknowledges that they are relinquishing control over the design direction and the end result of the game.

While we don’t strictly enforce requirements for teams aside from choosing a team lead, we do encourage teams to think about the following:

You should give members as much time to group into teams as you can afford, but the officers still need to reserve time afterwards to reconvene. For each team, take note of who the team members are, which of them is the team lead, and which game idea they’re working on.

You should also quickly run through the above questions as a sanity check. Give team members an opportunity to switch teams to resolve any potential team issues you identify (e.g. no programmers, too many/not enough members) before teams have been formalized. If there’s anything you can’t resolve, just make sure the team is aware of it and consider how the officers may be able to help out. Also, remember that as the semester goes on, new members may join, and existing team members may drop off or decide they want to switch teams, which may help with these issues (or introduce new ones).

Finally, before adjourning the meeting, try to give the newly formed teams a chance to exchange contact info and schedule a weekly team meeting. We typically use the second hour of our weekly club meeting as work time for teams, but we find it helpful to have each team set up their own meeting time too.

After the meeting, the officers update our Discord server, adding a new category for each team with general text and voice channels, as well as any other channels they request. We also create a role for each team (using their preferred color) and assign it to each user on the team. Team leads get a special role too, giving them access to a channel the officers use whenever we need to communicate with them all directly.

Aside: role preferences

Alongside the pitch form, we used to send out a “role preferences” form for anyone interested in being on a team, with questions such as (you guessed it) their preferred role (e.g. programmer, artist), preferred game engine, and level of experience. However, we found that trying to form “optimal” teams by assigning people in a top-down manner just doesn’t work. Since people don’t know what game ideas they’re interested in until after the pitches are presented, you can’t do much work ahead of time to optimize the team formation process.

Hypothetically, you could send out another form after the pitch meeting for people to rank their preferences, and then do some algorithmic sorting, but not only is that more effort for a potentially imperfect fit anyway, it also introduces a delay in this critical phase where people are excited to get started on their idea. Therefore, we’d never really use the data from this form during the actual team formation process, and we’d just end up going around the room asking what team people wanted to be on. Not fun or optimized.

Development process

In the first week, the team lead (or their designated Git expert) should set up the team’s Git repository and give access to everyone who plans to contribute directly to it. Members in certain non-technical roles (like artists and composers) only need to be added to the repo if they want to be; otherwise, they can just send the assets they make to other team members and have them implement the assets into the game.

For team members new to developing in their team’s chosen engine, we suggest they follow some basic tutorials to get their footing, and then have their team lead help guide them through their first contributions. Club officers can also help with teaching and environment setup if needed.

The first hour of most club meetings consists of a presentation or group activity, and the second hour is reserved for team time. Our first meeting is usually focused on teaching game engine basics to new members.

Before team time starts, I encourage teams to briefly show off any visible progress they’ve made in the last week. I think this provides a bit of motivation to make something worth showing off each week, and seeing the progress of your fellow teams can be inspiring (or a source of friendly competition!).

Whether during the club meeting or during their own team meeting, teams can use their work time to:

Additionally, team leads should:

During the team time portion of club meetings, officers are available to help teams with any technical problems or design problems they may have. Officers can also help team leads with scoping and prioritization.

This time is also an opportunity to get feedback from other teams, officers, and members who aren’t on teams. Getting early feedback like this can help identify what’s fun and what isn’t, and feedback from fellow game dev-minded people can give you ideas for new mechanics or new directions to take the game. As mentioned earlier, feedback like this can be hard to come by as a solo developer, which brings me to…

Playtest day

The playtest day is a relatively new activity in the club, and I think it’s a great idea! For the last meeting before the showcase, all club members play all the teams’ games in their current state and discuss them as a group. This has all the benefits of playtesting I mentioned above, but a full group discussion offers more perspectives, helping devs identify which opinions are widely agreed upon and which ones are rarer or matters of personal preference.

The playtest day also acts as a final checkpoint before the showcase, giving the officers a chance to make sure each team has something ready to go, and giving teams one last chance to catch any major bugs.

Showcase

As our last meeting of the semester, each team shows off their finished game in a showcase open to the public. This is a fun event and has the potential to be great for publicity!

In some years, we’ve put the games up on a big screen and had volunteers come up to play them while everyone else can watch and give commentary. Another option that I think would be fun (and more intuitive) is to do it in more of a “science fair” style: have each team set up a booth where people can stop by to play their game and chat about it.

If a team doesn’t have their game ready for the showcase, that’s okay. It’s up to each team if they want to present what they have, or not; they can always just come and have fun playing other teams’ games.

Regardless of whether or not they finished in time for the showcase, some teams may want to continue developing their games into the next semester. I think this is okay, assuming they’ve made good progress so far. If not, I’d suggest that they consider shelving the idea for now and starting fresh. This can be demotivating, but so is working on a project for a long time without seeing much tangible progress. A new semester provides an opportunity to get a fresh start with a new team and a new idea!

Other club activities

These are the things our club does (or has considered doing) in addition to team-based development.

Workshops and demos

The first hour of most club meetings consists of a workshop or live demonstration of a certain game development technique, led by a club officer.

Early on, we focus on broadly applicable topics like “getting started with Godot” and “how to use Git”. As the year goes on, you can delve into more specialized topics, like level design, pixel art, 3D modeling, or NPC AI. You can find some of the past presentations our club did on our website’s News page (though it hasn’t been kept up to date).

One challenge is that not every topic will be interesting or relevant to every member, nor every game. For instance, musicians might not care much about ECS architecture, while programmers might not care about 3D modeling, and a team making a 2D game in Godot doesn’t need to know how to create 3D environments in Unity. In such cases, I think it’s best to allow members on teams to split off and use that first hour as team time, while those interested participate in the activity.

The more interactive you can make these activities, the better. People already sit through enough lectures in their university classes, and you want to provide something more than people would get just by watching a tutorial on their own.

This is admittedly something that we struggled with during my time as an officer, so unfortunately I don’t have all the answers here. It’s hard to teach something new within an hour and still have time for people to experiment with it on their own. One approach might be to implement a small feature that most games would benefit from (e.g. juice, a leaderboard, or an options system) and each team could follow along for their own game, though even then, generally not everyone on that team would need to be involved.

I think it’s a good idea to open up topic suggestions to the club, but I suggest only choosing topics that at least one officer is familiar with and has time to prepare a presentation for. Otherwise, they’ll have to put extra time into researching the topic themselves before presenting it to others, which can be stressful and still not as helpful as a presentation from someone knowledgeable.

If a club member is really interested in a particular topic that no officers are familiar with, encourage them to prepare a presentation or activity themselves! I recall one of my friends who wasn’t an officer but was really into 3D graphics gave a presentation on the graphics pipeline and how shaders work – it mostly went over my head at the time, but it was cool! Allowing members to present makes them more involved and invested in the club, and frees up officers’ time too, so it’s a win-win scenario! You could even consider having a day for “lightning talks” where members give short presentations on whatever they find interesting, such as a hot game dev tip they came across or a game mechanic they love!

All in all, this whole category of activities is probably the main thing I’d consider doing differently from how our club did it. Here are some alternative ideas you might consider incorporating (in some combination):

I recommend seeing what your (prospective) club members are interested in, and tailor your club’s activities to their interests!

Game jams

Our club occasionally hosts a game jam of our own. In case you’re not familiar, a game jam is an event where people create games over a short time span, often a weekend. They’re a great exercise in scope management and actually finishing a game.

Sometimes you’ll really enjoy the game you made for a jam and decide to flesh it out into a full game. Hollow Knight, SUPERHOT, Celeste, Inscryption, Baba Is You, and many others all started out as game jam games! And even if you don’t think your jam game has a future, at least you’ve only invested a weekend before finding that out.

Planning a game jam takes more effort than a typical meeting, since you’ll need to reserve a space for a long block of time, and probably outside of normal hours. That being said, it can be a fun opportunity to draw in new people from outside the club, and even people from other universities, if you’re willing to put in the extra effort to coordinate that.

By its nature as a community of game devs, the club is a space members can use to find teammates for external game jams too. One of my favorite memories was driving to K-State to compete in their annual game jam when I was only a freshman in my second semester. I made the music for our game, and although the game itself turned out pretty mid, the jam was a lot of fun, and it was technically the first finished game with graphics that I was involved in making!

Nowadays, in our club Discord, members and alumni still share the games they make for big online game jams, like the GMTK Game Jam and Ludum Dare, which is always great to see.

Talks from professionals

This is something our club only did once or twice while I was there, but probably more due to nerves or self-doubt than anything else.

In reality, I’m sure there are lots of professional game developers out there – especially in the indie scene – who would love to give a talk to an interested club. It can’t hurt to ask, after all – the worst they can do is say no. So I’d encourage you to shoot a message to the people involved in making your favorite indie game and see if they’d be interested in chatting with your club!

Game nights

Surprisingly, this isn’t something our club has actually done, as far as I can recall. However, I think a game night makes perfect sense as an event to attract more members, and just as a fun activity to let existing members hang out together. After all, people probably wouldn’t join a game dev club if they didn’t like games in the first place!

Miscellaneous notes

Online space

I’ve mentioned a few times that our club uses Discord as an online social space. While I hate Discord as a company, it remains a popular platform, and the network effect is real. Thus, it’s probably still one of the best ways to build an online community for your club, but you should evaluate what platforms are popular among students at your own university.

I think having an online space is important. For one, it lets team members coordinate with one another, but even if a team prefers to use a different platform for their own communication, a common space is still useful for:

Club fairs

As far as I can tell, club fairs were our best recruiting tool. Fortunately, games are great at attracting people’s attention!

If you or your fellow founding members have made any games before, set up computers and let fairgoers play them! Also, if you can, compile a showreel of gameplay footage from your prettiest/flashiest games and play it back on a big TV or monitor.

If you haven’t made any games before, it may be harder to distinguish yourself from your university’s gaming club (if it has one), but replicating the above setup with popular and/or weird indie games might do the trick.

Officers

In our club, the officers would meet for 30 minutes before the start of the general meeting. This gave us time to go over any managerial stuff we needed to discuss, and to do any necessary setup before the meeting.

Our club had the following officer positions:

President, Treasurer, and Primary Programmer were positions that all registered student organizations at UNL had to have. Their responsibilities are fairly self-explanatory, except for the Primary Programmer, which (notably) has nothing to do with computer programming, and is instead in charge of event planning.

Secretary was a position specific to our club, in charge of taking attending and recording meeting minutes. Attendance was important in our club to be eligible to run for office or vote in the annual election (which was usually during the same meeting as the showcase). Meeting minutes, on the other hand, seemed to be rarely referenced, despite the effort they took to write. We recorded the demo portion of most meetings, so those were always available to reference anyway.

Development Lead was another club-specific position, and it’s the position that I held for two years. I believe this position was originally created when the club was small and the idea was that the entire club would develop one big game. That idea had pretty much been abandoned by the time I joined and we had transitioned more toward the team-based development model, so the Dev Lead’s responsibility shifted from organizing the whole club’s game development to coordinating the various dev teams within the club. The Dev Lead is also in charge of preparing the weekly demos and presentations for the club, and being the primary point of contact for team members’ technical questions.

In my experience, all of these responsibilities really added up! Most of the time, the president shared these responsibilities too, and we would usually alternate presentations each week. This trend continued when I took over as president myself.

Overall, I’d caution against this particular structure, though I’m not certain what the best structure is. Of course, you’ll need to include any positions needed to comply with your university’s requirements. Beyond that, here are my hot takes:

Ultimately, you may be able to get away with fewer officers than we had (which might make it easier to get started), but it will require doing things a bit differently.

Worth noting: our officers are absolutely allowed to be involved on dev teams, just with the knowledge that they they’ll be splitting their focus between both roles (officer and team member), so make sure they have the time to spare! I did this twice – I was an officer when I made Minieval and Corsair Warfare – and I had a great experience, but I can attest that it definitely ate into my free time!

Virtual vs. in-person meetings

I was involved with our club during COVID, so for a while we met virtually for most meetings. After the worst of the pandemic was over, we had a vote, and a majority of club members voted to continue meeting online. This is a bit surprising to me, but I think people were accustomed to the convenience of attending online.

Nowadays, the club holds its general meetings in-person, and I would recommend other clubs do the same. Each team can do whatever works best for their own team meetings, and it’s great to be able to hop on a quick call to solve a problem, but in-person connection is valuable for the cohesion of the club as a whole.

Conclusion

Welp, those are my suggestions for how to run a university game dev club. If you have any thoughts about my thoughts, or any questions about my experience, feel free to reach out!