[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.
- Log in to post comments