[Note: This post is quite long. Just wanted to establish that so no one tells me to shorten it. :D ] Designerwatts' 7 rules of making your first team-based indie game. Hi everyone, I wanted to take the time to write out my experiences and lessons learned with the projects I've been working on for the better part of this year as an aspiring designer and indie developer. Most of these rules have come from lessons that either I've had to learn through my own errors or by the nature of the projects I was running. Some of these rules come from practices that I've found to work as well. These aren't expertly proven methods, and I'm not a senior in any regard. But I think that perhaps if I explain why these works for me as opposed to the opposite then you might skip making the same mistakes I did. 1. Design the game before you make it. There are many indie projects that are spontaneous in nature. Designing a game by yourself within a week or month may not require you to create a coherent design as your just "playing by ear" That's a completely valid form of rapid development but I'm referring to project of a team based nature. Within a team environment and on a project that's of a commercial scope. Like say an iPhone or facebook game for instance. It's a good idea to plan what you're going to make before you make it. The design document should be comprehensive but very much to the point. I write my design documents like it's an instruction manual on how to assemble the game and why it works. [And why it's fun.] How much time you dedicate to the initial design of the game is up to you and your team. As an example I spent 2 1/2 weeks writing a wiki based design document for the iPhone game "Mole" to covered the following elements: 1 - Game overview : Why is this game fun? 2 - Singleplayer campaign and Level design : The core elements of gameplay explained. 3 - Player control : How does the player interact with the game? 4 - Menus : How menus work. A listing of every menu in the game. 5 - Level GUI : How the user interface works. 6 - Achievements and Leaderboard mode : How online play works. 7 - Values, art and sound asset list. : The nuts, bolts and numbers of the game. 8 - Production Plan : How long should it take to prototype and produce everything? While it's true that the end product may resemble very little to what you initially designed. I stress that you don't skip this step. If you dedicate the time to think about how the nuts and bolts of how your game works before you go into prototyping then you have a solid foundation to start on. As opposed to no foundation and an idea that may not hold up to the implementation. To summerise this into my own little quote: Start with nothing and you'll end up with something. Start with something and you'll end up with something better. 2. Your team will be small and multi-skilled. This is my opinion. But the smaller and more skilled your team. The more each individual can contribute to the team. As the designer for mole I'm also responsible for all its artwork. Effectively taking on two jobs at once. This works out because once I've written a detailed design document then the designers' job is to play the game to tweak it and to maintain the document. Which for a small-scale iPhone game does not take up all my time. To give some examples of multi-skilling: a: A Game designer who contributes in another discipline like level design, concept, art or programming. b: A Character artist who can rig and animate. c: An environment artist who can also make particles and effects. d: A programmer who can work on more then one feature of the game code side. It's important that you try to keep the team as small and effective as possible. Every new member you add to the team will create new lines of communication that needs to be maintained. The smaller the team the less lines of communication and the quicker changes and implementations can be done. 3. Keep the team local. There are a few reasons why one should at the least initially try to keep the core team of a project in the same country and preferably the same state/city. Firstly communication is easier to maintain when everyone is awake at around the same time. Changes and discussions can happen spontaneously instead of a back and forth e-mail based communication. Secondly if you're trying to make a profit share based commercial game you stand to simplify that issue if everyone is in the same country and has the same rules as to how they are paid and compensated. Thirdly if your team is truly localised then you can hold face-to-face meetings to discuss the project and other endeavours. Which is very important. There's a stronger claim to responsibility in this enviornment. 4. Unified communication is mandatory. Everyone will need to agree on a method of quick, easy communication that is allows all team members to communicate with each other. Any IM messenger service will do the trick. Everyone must implement the messenger service and be responsible to maintain communication with it. If even one team member refuses to use this or is hardly ever online with this then it'll create a communication gap that can undermine the project. Likewise electing a task tracking service is a step forward as well. Not everyone is good at maintaining deadlines and due dates. Task tracking does help in this regard to keep people in the know. Unified communication is very important. Make sure everyone is on the same page with this. 5. Keep projects small in scope and short in time. This rule is for those who are engaging in their first project with a team of people. The project needs to be scoped that there can be no question on how something will be produced or implemented. If you're coming across any "Not sure how this is going to happen." issues of your game then chances are the scope of it is to large for your team and you need to rethink it. The timeline of your project. Not including the initial 1-person design writing period should be anywhere from 1-4 months. Any longer and the project might sink into a lack of motivation or stalled progress. Especially if it's the first game your team is making together and if it's a project that relies on profit sharing. Keep the project short and well within the capacities of your team. The projects after that can focus on grander scales, bigger timeliness and scopes. First you need to prove that the team can actually work together to make something. Even if it's small and simple. 6. Middleware is a great asset. There exist many free engines that can save your team months and months of time of not having to create an engine and it's required user tool sets. Engines like Unity3D give you the power to rapidly prototype a game. As a small indie team you shouldn't snob idea of using free or cost effective middleware. If a member of your team already has something substantial to bring to the dev team that works as well. But otherwise you should explore every opportunity to seize any tool that will cut down your development time. 7. Outsource whatever isn't full time work. For my teams in development iPhone game. "Mole" we outsourced the sound and music for two reasons. First is that no one on our team of two had the expertise to write and create music or sound effects. Second was that music and sound for our iPhone game doesn't constitute a full time development effort. It wouldn't take the sound guy 2 1/2 months to create two digital music tracks and 2 dozen sound effects. So we outsourced the music. This does cost money but it allows for our core team to focus on the implementation of the game in terms of gameplay and art. If the game you where making needed a full-time job worth of sound and music for the duration of the project. Then add a sound guy to the team. Otherwise outsource it. This goes for any facet. [Although you'd probably want at least one dedicated programmer and artist. ] So in summery: 1: Write a design document before you start production. 2: Have a small, multi-skilled team. 3: Keep the team locally based. 4: Everyone must use a messenger service. 5: Keep projects small and easy to complete. 6: Middleware is your friend. 7: Outsource whatever you can't do. I hope you find this helpful. :) Cheers. Who is Designerwatts? My real name is Chris Watts. I'm an aspiring game designer who is trying to become skilled at the craft of game design through running projects and making games. I have a few years professional experience as a level designer but currently work in an indie capacity. I'm working on the iPhone game with the current working title "Mole" The opinions expressed in this writing are of my own and represent no one else's point of view.

I think the only two positions that really need dedicated people are designer and programmer. Art and sound are much easier to contract out in general. Programming is too but you need that one person who grasps the entire code base. Likewise, the dedicated designer needs to understand the entire scope of the gameplay and how it has evolved over the duration of the project.

I'll admit I've never seen a Lounge article before :P No blog or anything?

Just wanted to say thanks for this. Nicely done. I heartily agree with #3 (but only from partial experience, IM and email exchanges with folks just trying to get a project started weren't fun, I don't want to imagine what full production would have been like).

I can see the value in #1 but I'm wondering what value you place on the whole prototype-play test-refine approach? After all, how many times have we heard of ideas that sound fabulous on paper but suck once in code form? Asking why it's fun is a good idea, but something may not be as fun as you planned.

Quote: Original post by Wavinator

I can see the value in #1 but I'm wondering what value you place on the whole prototype-play test-refine approach? After all, how many times have we heard of ideas that sound fabulous on paper but suck once in code form? Asking why it's fun is a good idea, but something may not be as fun as you planned.

It's a totally valid point you pose.

The prototype-play test-refine approach should be used. It's a process of refinement, trail and error. But it should be done after an intitial design document has been written and approved by the leads of the team and the game has been prototyped to a point where play testing will reveal valid results.

It's true that something that may look good on paper may suck in implementation. But if you have that solid set of numbers and outlined game play mechanics then it's easier to refer back to those mechanics to pinpoint what elements of your game could use the refinement or redesign.

If you start with nothing and just work off a few scribble-notes and your game idea doesn't work out to be that good. You may just scrap the whole thing and move on rather then analyse what should be written out in documentation.

Quote: Original post by Gaiiden
I think the only two positions that really need dedicated people are designer and programmer. Art and sound are much easier to contract out in general.

From my experience (YMMV and all that):

Unless you're at the stage where everything is set in stone (is it ever?) and any content produced is just a variation on the existing assets already tested, I like to consult an artist about technical issues with model formats, level of detail, shaders and the content pipeline in general. And vice versa. If this (lead) artist has outsourced basic modeling work to some group on the other side of the world and has a atrong grip on production and quality, that's fine with me, but I prefer at least one guy close to the project for any immediate problems or questions. Especially in smaller teams/projects, where everything tends to be more flexible.

Also I think it's very important to have regular meetings between key people responsible for game design, development and artwork. For instance, the game designer might have some ideas about the feel the game should have, the artist then gives his more detailed view of how we could achieve that, and the programmer can then determine whether is technically feasible to implement.

Quote: Original post by DesignerWatts
2: Have a small, multi-skilled team.

I'd like the emphasize the multi-skilled part here. Not only does it give a smaller team the necessary flexibility, but it also greatly improves communication between the different fields of expertise. I'd rather have a so-so developer that has some feel for, and is genuinely interested in the art and game design, than a five star programmer with a PhD in mathematics who can only think in terms of code.

I'd add, only use and software tools that you're skilled enough to use. For example, 3d designing tools are so complex , mastering them is time consuming and should not interfere with the core task of making the game.
It's appealing (and a common mistake) to download f.e. Blender or some language or engine , and think: hey this is nice, i'll learn it in the game dev process; let's go!
Keep it simple; don't use Any equipment that you don't fully master. Valuable if you want to avoid failures. (not only indie of course), or projects that linger for years and don't come to fruitation.