Establishing a Videogame Development Club

Oct 24, 2009

Carnegie Mellon’s Game Creation Society

While in school, I helped get a game development club off the ground, structuring its processes, setting the standards, and ensuring projects began in a way suitable for their teams to finish. That club is the Game Creation Society at Carnegie Mellon, and you can find the videogames from it at

[2011 Edit: I have since followed this same general pattern and structure as a grad student at Georgia Tech to establish VGDev. 2015 Edit: I then adapted the same pattern to form Gamkedo Club as a worldwide online version of this independently with no university affiliation.]

Although that game development club was started at a university setting, many lessons learned from it are equally applicable to kicking off and growing a community of game developers, whether locally or online, whether as a high school club or among people long finished with school.

This is What Worked for Us

Every year, many videogame development clubs start. Many of them initiate a handful of large projects, struggle with teams falling apart as member retention suffers, and after a couple years of sliding schedules, either close down or transform into a game playing/culture club instead of game development club.

Of course, what worked for us certainly isn’t the only way to do things. There are surely other organizations out there that have succeeded, doing things very differently and following very different rules of thumb. All I can say for sure is that these rules of thumb worked well for us during the first few years. I’m hopeful that others with drastically different experiences will help share learnings from their organizations, as well.

Lessons Learned

If you don’t build it, they won’t come

Although I developed the process for the group, and led the club for two years, I did not start it. Curt Bererton, then a Robotics PhD student and now the founder/CEO behind ZipZapPlay, Curt founded the organization, writing its charter, posting flyers, building members, and running weekly meetings before he found any of us on campus that helped the group take off. He didn’t kick off the organization with all of the people and resources that he needed – he kicked it off partly as a way to find them. (And what I did wouldn’t have gone anywhere, if members like John Nesky and Greg Peng hadn’t shown up – but we couldn’t have found them without the club first existing.)

Keeping project scope within one semester

Each semester, everyone’s time commitments changed. The longer a project took, the greater amount of uncertainty was involved between starting and finishing. For these reasons, we attempted to schedule every project to fit within the project it was started in. Doing a more complicated project was only possible by working faster, devoting more hours to the project, and being clever about avoiding unneccesary or wasted effort. For the especially ambituous projects, we occasionally would let experienced developers plan for a full release at the end of one semester, then a second release with additional features/content the next semester.

Emphasize completing all games

Finishing virtually every project started is terribly important. This is true even if it means encouraging less ambitious project scope, shorter timelines for greater predictability, and turning down some enthusiastic “I want to make the next big MMO” types. Nothing is worse for new member recruitment than having a spotty track record of incomplete projects, and nothing is worse for member retention than having art, audio, and levels made but thrown away. New members are attracted by the prospect of working with a reliable team, using a known process, in high confidence that their work will result in a finished game.

Vet project leaders

Each project leader had to fill out a simple one-sheet proposal, outlining what the name of the game was, how long it was anticipated to take (again: maximum one semester), what it was about (in a nutshell), and how many people of each position the project would be expected to need. We then met one-on-one for an hour or so, chatting about the project’s goals and schedule. This wasn’t a very strict or demanding filter, but it was an added layer of protection to help minimize the chances of otherwise motivated members being brought onto dead-end projects started by well-intentioned but unprepared project leaders.

It’s ok to lose people that won’t work

Making videogames involves a lot of time, energy, work, and additional learning. Each year, we brought in as many members as we possibly could during the Spring Activities Fair – with as many as 100-150 people showing up at our following meeting – by focusing on the importance of having all kinds of people (artists, writers, programmers, modellers, musicians, testers…) involved in making videogames. In the first meeting or two, we explained the process, and some people would leave when they understood that this would involve more time each week than just attending the 1-2 hour meetings, and wasn’t the same as simply playing videogames. This was a good thing, not a problem.

Leaders pitch games, members volunteer

The project pitch was just a 15 minute powerpoint (showing mock up screenshot, spelling out the project concept or similar games, etc.) and speech about the project leader’s initial vision for the project. The last part of the project’s pitch was the leader’s name, e-mail address, and a list of the minimal roles they need for the project to be made: two 2D artists, one sound person, etc. Anyone interested in those roles would then talk to the project lead after the meeting, or contact them by e-mail. If the project leader didn’t collect enough members within 2 weeks of being pitched, or didn’t adjust its plans to reflect the members that did join, then it wouldn’t become an active project. When people aren’t being paid, and aren’t receiving credit, its important that they’re able to work on something that appeals to them.

School credit threatens agility

One of the advantages of being a non-class/non-workplace organization is that people who are disinterested can just leave, instead of being locked in by their need for the salary, school credit, etc. At first we began to investigate the opportunity for active students to get course credit or some other type of academic recognition for their work in the organization, but after a few semesters we were thankful for the agility that came with members self-selecting based purely on their interest in making videogames.

Reach out to guest speakers

There are a collection of people in the organization that are eager to hear about videogame industry topics, ranging from recruitment talks to more experienced developers sharing their insights. Meanwhile, companies have people who devote their full attention to finding an audience to recruit from, and experienced developers are often happy to have a chance to share their stories. Establish e-mail contact with anyone and everyone that you think might make the trip – more people will say no than yes, but even one yes a year can translate to happier members, new members (guest speakers are prime events to invite non-members to drop in on), and improved networking opportunities for all. It can even lead to internships and jobs for organization members, which translates into lasting alumni industry connections.

Provide optional team resources

We gave every active project team a folder on an FTP server with a custom login/password, for members on the team to share files, as well as a section on a message board to keep a history of each project’s discussion. These were provided as free secondary user accounts on a low-cost account, using ezBoard then phpBB for the bboard system. These minimal resources helped facilitate working around asynchronous schedules for student teams.

[Note: between Google Docs, Dropbox, Assembla/GitHib, and other services already out there, it may not be as useful anymore for the club to provide things like dedicated FTP space.]

Give content creators creative latitude

People want to show off, and get practice in, whatever style or subject they know how to do best. Projects that can accommodate this will come out better, yielding not just better games but happier members.

Weekly goals for everyone

Busy work isn’t a good thing, but people get involved in hobby projects out of an interest to contribute, gain experience, and have something to show off proudly when it’s done. If someone on the project team has a three week period with nothing to do, they may fade away from feeling like there’s no use for them on the team.

Allow proven members to take on more

This partly addresses the above problem – while one project’s need for an artist or audio contributor slows down, another project’s needs may swell. This also creates a greater variety of experience in the same amount of time, and helps project completion.

Encourage historical progression

Although everyone’s temptation is to jump right into the deep end, making games that resemble the ones they’ve been playing lately, that frequently leads to people biting off more than they can chew. The game either doesn’t get finished, or it doesn’t get finished well.

Instead, I’ve encouraged club members to think historically for reference points, as a way to tackle less complex (but fully complete) games before moving on to more involved ones. The best way that I’ve found to get this across is to frame it in terms of decades or half-decades: encourage developers that have never made a game before to start or join teams making games of 1970’s complexity (granted, they may look and sound more modern – this is only about how involved the code and design become, and the game’s overall scale or scope). After they’ve led or been involved with a team of 1970’s, move on up to 1980’s or early-1980’s complexity, then up toward 1990’s, and so on. This gives clear reference frames for what’s appropriate and mountains of enjoyable examples to draw from.

More projects get finished. More projects get finished well. Most importantly, more developers get the foundational skills and production experience that they need to later see through some of their more ambitious ideas together.

Don’t become a game playing club

We had members and non-members alike ask our organization to host tournaments, game nights, game release parties, retro game nights, game movie nights, and every such variation. There’s nothing wrong with those types of events, but as mentioned at the start of this entry, one of the common causes for organizations of this sort losing focus and getting nothing done is on account of becoming a game playing and culture club instead of a game development club.

The videogames developed will be worse, and more likely to wind up unfinished, if a bunch of people are hanging around not for their dedication to game making but for their dedication to game playing. Let those students find such outlets elsewhere. There’s no shortage of opportunities to play videogames with other people in college.

If any game playing goes on under the organization’s name, it ought to be playing games completed by the club, either to help new members see the types of projects that can be done in the timeframe given, or to help recruit outsiders (public demo) by showing that the club is serious about creating finished, playable games.

Actively recruit a variety of people

A room full of people that are experts in the same area will all overlook the same problems and weaknesses. Every type of expert can help fill in for different oversights by others.

Even if it’s a room full of computer science people that know how to program (this was our core group with the Game Creation Society), it helps to find programmers with a variety of side interests in music composition, sprite animation, interface design, etc.

Active recruitment is also an important aspect of this. Flyers are important, but evangelizing for the cause goes a long way, as does being outspoken at fairs and other recruitment opportunities.

Be technology and tool agnostic

Some 3D artists prefer Maya to 3D Studio, or vice versa, while some others are most productive in Blender (or they may not have $3,500 laying around to spend on their hobby). Some programmers swear by C#, some prefer ActionScript 3, while others are content to script in Unity or Game Maker.

Whatever tools and technology platforms that people know best, welcome them to use those platforms to their fullest extent. At the end of the day happy members and well-developed content will go further. Giving people freedom to teach themselves new things is awesome – but forcing them to teach themselves new things is what their classtime is for (!).

Minimize content bottlenecks

Role-playing games and adventure games are scary. No matter how simple they look, they require (at a minimum) dozens of pieces of enemy art, level layouts for dozens of cities, outdoor areas, and dungeons, balanced stats/prices/art for a wide variety of items, several emotionally intense songs, and countless pages of strangely paginated written dialog for dozens of characters. It probably needs at least a minimal in-game scripting engine, too. After I had been making videogames for seven years, I was able to lead a small team to make this really weak, limited RPG. That isn’t offered as encouragement, but as a warning.

Side-scrolling beat-em up games and platforming games also involve a huge amount of animated art. Variety in badguys, bosses, and backgrounds are what compel people to keep playing them.

Some types of videogames scale much better, and don’t require mountains of different art – especially puzzle or action games that take place in non-scrolling/one-screen levels. When beginning teams present their first projects, it’s best to favor games that will be able to efficienty reuse content in different combinations, and get away with minimal content. Not only does it improve the chances of that particular project succeeding, but it prevents any one overly ambituous, epic project from gobbling up all of the club’s content creators into a black hole that (likely) won’t turn into a finished game.

Project leaders must be able to finish alone

People will leave the organization. People will leave teams. No matter what people intend, and no matter how nicely everyone is treated, things will change, and priorities will shift. To the outside world, it’s very important that the club maintains a reputation for finishing its games. Internally, this means it’s very important to the club that project leaders ensure that the game they start gets finished. This requires that project leaders have at least minimal fluency in digital art, programming, and finding/editing/making audio for use in the game, such that if everyone else left the team, it could be finished, even though it may not look or sound as good as was intended. This accountability further motivates project leaders to keep their project members content, and to seek replacements any time project members leave the team, since work they can’t get someone else to do is work that becomes theirs.

The demo is the game

As a scheme for scope reduction, one thing we did to help reel in project scope during pre-pitch meetings was to ask the project leader what is the minimal amount of functionality and content they would need to create a demo for the game.

Since it’s a portfolio and experience piece for the team’s project members, this demo size is about as much content as most outsiders will digest. Making a larger version of the game would have diminishing returns on learning, in addition to increasing the odds of the game never being completed. And a videogame that isn’t completed isn’t a videogame to the outside world.

In consideration of this, we adjusted plans, content, team size, and story for the “demo” sized version to be the finished game. Before the project was ever pitched or started.

(This has the unintended side effect of increasing believability and buy-in from members to the project pitch. When someone tries to entice members to join their project that is planned to have 20 worlds, 30 weapons, and 16 main characters, no one takes a pitch like that seriously.)

Focus on videogames, not games

A club that tries to be for everybody is a club that works for no one. A board game, dice game, tabletop/D&D game, casino game, sports game, game show, game theory, or Conway’s game of life club is not a videogame development club. Even if those are things that may appeal to some categories of videogame designer, they’re less likely to appeal to 3D artists, software engineers, dialog writers, playtesters, animators, music composers, sound effects specialists, and the whole host of other skills that go into hobby and professional team videogame development.

Welcome members that have an interest in those things, just as much as members are welcome that have interests in programming operating systems, animating feature-length films, and writing novels. But keeping it clear that the organization is not there for pitching, producing, and networking games other than videogames, just as much as it isn’t for film making or novel writing, helps keep the core strong.

Be ready to adapt

Depending on who the organization’s leaders are, what the project leaders want to make, the rules of thumb will need to be different. How established the club is will also lead to huge changes in organizational needs – a young club is battling aggressively for growth, credibility, and clarity, whereas a more established club does well to focus on retention, visibility, and stability. I’m good at the first 3 of those 6 ideals, and I struggle with the latter 3 – which is how I knew when it was time to establish officerships and transition to new leadership.

(Originally posted as Vol. 7 Sec. 2)

Este artículo está disponible en español. Traducción por cortesía de Andrés de Pedro.

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.