Playing with Others: Getting ready for fun

It’s a lot of fun to work on a game, right? However, I think that we’d mostly agree that it can be even more fun to work on a game with some other people. In fact, beyond just being fun it might be necessary in order to get all the necessary skills together to create a game. Problem is, it’s difficult to find other people to work with, and harder still to work well as a team. I’m by no means an expert on the subject but I thought I’d write down a few of my observations and experiences. Hopefully you’ll find the useful for your next endeavor and, of course, feel free to chime in with your own experiences. This post I’m going to focus on what you should do before you try to get others to work with you.

Probably the first thing I want to do when I think of some fun game idea is get a bunch of other people excited about it. I love to program but I’m not artist, and to be honest I’m not the mathiest nerd either, so when thinking about implementing this great idea I tend to outline a set of roles which need to be filled. However, this sort of thinking is problematic. As excited as I am about the idea other people can’t be counted on to match my enthusiasm at this point. So I’ve found that you should take some additional steps after the “Ah ha!” moment in order to court potential partners.

First and foremost program a workable prototype. It doesn’t have to be very pretty, in fact it won’t be if you’re not an artist, but it has to be playable enough so that you can show it to someone and catch their interest. With a prototype in hand you can prove to others that you’re committed to the idea and let help them generate enthusiasm for the idea.

Additionally, it’s critical to have a prototype so that others have something concrete to work with. It’s next to impossible to successfully lay out a plan between several people without some foundational work. With the prototype in place you can still invite and encourage brainstorming and new ideas (after all it’s just a throw away prototype) but you also have a context for new ideas and a way to measure their value.

Finally, beyond providing a context for planning the protoype should give you a better sense of the work that needs to be done. This is essential because other people will not make work for themselves. Start others off with simple, approachable, concrete tasks. Anything less is likely to scare off all but the most committed contributors. Use the prototype work to identify a number of work items that you would be comfortable letting others do. Make sure you pick things which are actually fun and challenging. This is probably the hardest part!

Naturally, it’s not enough to simply have a prototype. You need some mechanism to distribute the prototype and even more importantly a means to collaborate. Personally, I suggest picking one of the following solutions:

1. GitHub
2. Google Code

In my humble opinion GitHub is the best solution. While it lacks some features present in Google Code it more than makes up for it by using git. (Which is a topic for a whole other post.)

Once you’ve created a hosted project make sure you take a few steps to set things up for others. In a nutshell make things as easy as possible for others to get started. If you’re writing a game using Slick then that means including all the necessary external dependencies, including instructions for how to set up the project in Eclipse (and possibly a Eclipse project file), and an ant script. Without these things users may download your project and then give up in frustration; make sure that an interested developer has no reason to turn away from your project!

Alright so that’s already too much, we’ll have to leave the rest for another post. I think, though, that this is a pretty good outline for what to do before the real fun (and challenges) begin. As always, let me know what you think or if you have any experiences to share!

Related Posts

• Global Game Jam: A Post Mortem