You have experience making–and most importantly, completing and releasing–videogames.
A lot of other people want to make videogames, too.
If you’d like to expand your hobby development from solo to team efforts, I’d encourage broadening your search for teammates to include people that don’t necessarily have as much experience.
No book, no blog, no tutorial, and no classroom assignment can compare to the sort of learning that can come from experience creating and completing a project together. But what’s in it for you as the more experienced developer?
I was wondering this shortly before helping establish the Game Creation Society in 2004. I had a 6-8 year head start in solo game creation, whereas most of my peers in the group would be working on their first game. I was worried I might spend too much time trying to catch others up, instead of developing games.
What I discovered was that by getting people together, ensuring everyone started on track with a few separate teams (don’t put all your eggs in one basket!), each working on small projects and a modest fixed deadline (one semester / 4 month development cycles), bringing the teams together weekly to demonstrate their progress, for the most part people in the group caught themselves up on whatever skills they needed to know for their projects.
It went so well that I’ve been doing the same thing at Georgia Tech, beginning in 2010. (If you’re in a situation to start a college game development club, I wrote an entry about what worked for us, and slides to help ramp up Georgia Tech’s group.)
It’s rewarding to see people progress in their skills and confidence. It’s rewarding to help people bond through teamwork, producing something that they can remember the semester by and proudly show others. Everyone comes away from the experience with improved technical skills, additional leadership or teamwork experience, a few extra friends, and a helpful habit of taking on sizable side projects that no one explicitly assigned or incentivized. Members of every team gained experience developing and articulating their ideas, which is beneficial in any walk in life.
Less experienced developers bring fresh ideas, fresh energy, a different set of media examples to draw upon, familiarity with newer tools, and an interest in trying different processes. Some of those peers from Game Creation Society and VGDev have gone on to videogame development careers, increasing the size of my professional network. A few became coworkers in the years I worked between completing undergrad and starting grad school.
The semester that we made Zylatov Sisters in VGDev, I was thinking of not leading a project, and to instead just pitch in helping other games. I still wound up assisting with some of the other projects, however I led Zylatov Sisters, too. I did this both because it opened up more opportunities for newcomers, but also because it enabled us to create a game with more content, while taking less of my/our individual time to do so, making it possible for me to focus on the parts of the project that I’m most interested me and the same for others on the team. The exact same reasoning resulted in Freezing Solid.
Those games are by no means breakout famous, but they’re hobby projects, and weren’t especially difficult or time consuming (compared to a commercial project) to make. I’m proud of how they came out, I enjoy playing them, and they’ve made some strangers on the internet happy. Meanwhile both games gave a number of beginning developers experience with learning and practicing new skills – several team members went on to lead projects on their own the next semester – while producing another tangible example to include in their technical, design, artistic, or personal portfolios.
There are, obviously, a number of challenges in working with less experienced developers. There are thankfully some folks newer to game making are a terrific fit for the task: eager to learn, willing to try out different roles, and realistic in expectations. There are others, unfortunately, that resist learning new skills, and insist that they should be on a 40 person team writing lists of ideas for an MMORPG, to be built atop an open-source 3D engine they found made in Java. The latter are not always a hopeless case, but can be difficult to help, and effort may be needed to prevent them from steering the former newcomers off-track into quagmires. In general though the benefits greatly outweigh the downsides, and there really are a lot of reasonable and very capable people looking for a fair start.
A necessary disclaimer: I’m not (directly… more on that in a minute) advocating this approach for commercial projects. When there’s money at stake it’s much more important to have some evidence that the people being hired will be able to deliver on what’s needed. On commercial videogames I’ve taken a bet or two on subcontracting new developers looking for experience, and when it didn’t pan out I was on the hook to make up for the work they couldn’t do.
Meanwhile for hobby projects, it’s ok to be the most experienced person on the team. It’s ok to give people a shot, and if their contributions or availability don’t work out, no harm done, just adjust the scope around it. Hopefully they’ll find another project or role that’s a better fit.
Of course–and here’s how doing this can indirectly help your commercial projects–creating opportunities for others helps build up your personal codebase, portfolio, experience, and exposure. If you get lucky, one of those projects may take off (Vision by Proxy: Second Edition, another hobby team game I worked on, has more than 6 million plays). Meanwhile, creating opportunities for others is also a great way to discover and vet future recruits. My most dependable, capable, and versatile subcontractors* I worked with from 2007-2010 are people that I found through one of the game development clubs I helped establish. Their prior contributions on hobby teams produced an huge pile of evidence that they could and would figure out how to do what we needed as our various iPhone projects took shape.
That’s a clear case where creating an opportunity for others wound up later creating opportunities for me.
* For programming, art, and additional design, that was John Nesky. The last released game he worked on was Journey, with thatgamecompany. He and I worked together on Topple, iZombie Death March, and Alice in Bomberland. He also came up with the name, logo, and idea for the photo feature in burnit. For sound effects that was Joe Pfeil, a guy I met at GDC 2005 that, after doing all of the audio on two of the more ambitious club projects I led, became my go-to guy to hire for audio on commercial projects for the next few years.
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!