next »

[gimymblert]

I use to fail because once the tedious part start people lose motivation. I recently find a simple solution: Talk about the next exciting project we can do, insist that this project is a foundation of this next project, have discussion on what could be done on that project while insisting we must finish the current one before freezing spec and start working on the next. So far it works and we had a boost of productivity and everyone feel creative.

[_Tommo_]

Game projects over the internet WILL fail.

Making games is a job, and one that requires particular effort, by the way... even if you are employed by yourself.
Sometimes before the half of the projects you will feel like you got over the interesting part, and countless hours of bug fixing and tuning awaits you.
Those hours have to be accounted for, and no "for fun" project will ever survive them... because they are NOT FUN AT ALL.
And guess what? They are the most important thing when discerning between amateurish and real games.

So you can't make something that is polished and nice and actually marketable, working at your lowest priority, with ever-changing or badly motivated guys, maybe explaining each other on a crappy MSN chat or even worst on a forum.
There are exceptions with individuals that are really skilled and can manage to put together something awesome in their spare time, but as a rule of thumb I wouldn't count myself between them.

So, if you want to make a _real_ game, you and your friends should allocate some-6 hours a day and go "work" together in some place that isn't your home.
This helps respecting deadlines, communicating better, concentrating on what you are doing, and taking everything more as a serious thing rather than a nerd hobby  

I am saying this because i've seen the failings of many "let's maek a gam" internet projects, they always fail for the same exact reasons, as soon as most of the member realise that something they imagined isn't even real.

I also managed to get one game out working over internet, but with a close friend of mine; anyway the game was very buggy and unpolished, and most of the problems came from the simple fact that it was so difficult to integrate our work.

My two cents  

[mude]

-cut-

I completely agree 

[tergem]

-cut-

I completely agree 

+1

In my sig you may see Spike teh dodge, it was an online project that ended so badly that it can't be released to the public. It would drive away more downloads for my future games rather than get my name out there as a good game creator.

[Pinback]

Game projects over the internet WILL fail.

I totally disagree with this. I can site many examples of great remote team made games using Chris Jones AGS engine for instance, made by peple coming together from all corners of the globe and putting out very respectable games. Eternally Us is a small recent title that springs to mind. Excellent indie game, made very fast by people on opposite ends of he globe. There are a ton of other examples in AGS alone, and even from my own experience I can say wihout a doubt it's not only possible to make a game project over the internet- (communicating only via email and text chat) but it can be buckets of fun to boot.

My team and I have several thousand combined man-hours on our current (fairly ambitious) adventure game project, working remotely, a mostly unpaid team (we trade skills on each others games, and I'm trying to scrape some cash together to pay them something too) of 4 core team members and maybe a half dozen voice actors. We live in Australia, America, Greece, Great Britain, etc, have all been working hard for 6-7 months, and I've yet to see anybody lose interest or slow down asset production in any significant way. In fact, I'm astounded by just how goddamn cool these guys are to work with- and I'm looking forward to starting another project with them as soon as our current game hits the shelves.

Now, we're not exactly on the cusp of finishing yet or anything- but we have a polished game build that plays for several hours, is quite highly polished and, in my opinion, rivals a large commercial quality game.

I find the best way to keep the team/myself motivated is thus;

Lead by example, whatever your strength is- work at it hard, and send it around to the team as much as possible. I make graphics mostly so I try to show the team my concepts and graphics where possible, and of course get them early game builds when I can.
I don;t think it matters if your work is brilliant or not, just show enthusiasm and hard work and the team will hopefully follow suit. Keeping up your own creative momentum can be tough, but I just try to at least do a little every day- and of course 'when the pen is burning the paper never fold it up'- ie, burn that midnight oil whenever you can.

[Nix]

While online teams are maybe a bit more difficult, they are by no means impossible. Don't drag down all the successful online teams with your own failures, please! An important thing to keep on top of is deadlines. While you probably shouldn't treat deadlines as ultimatums with a casual team, it is important to maintain goals and a timeline, even if they are loose and flexible, to keep everyone moving forward. Constant communication and solid organization are vital. I convinced my team to start usin Teambox recently, and it has been a great help. But even just well organized email and a Dropbox folder can make a huge difference in the productivity of your team. Having a team who actually understands what is needed to complete a game helps too.

[phubans]

In my experience, I would not recommend working with more people than is absolutely necessary (ie; 1 but never more than 2; even 1 is a huge liability). Some great projects of mine have been dropped thanks to flaky dev partners.

Sword of Legends was a promising action-RPG platformer that was pretty much feature complete by the time my partner (programmer) decided he didn't have the motivation to continue working on it and just kind of faded away. I still get messages about the game to this day.

Spuck was a casual arcade-style game that was meant to be a quick and easily completed project in order to test the iPhone and Flash market. Even though this was a simple concept that was pretty much 100% complete on my end of things (design and art assets), the programmer decided his priorities were elsewhere. The game is currently being redeveloped by my roommate for the Windows Touch Phone and XBox 360, but it could have been finished long ago had the original programmer stayed with it.

Solipsius was a project I decided to do on my own, until I let a personal/local friend of mine in on the project because he would be able to take the art to a whole new level with his 3D skills, but he became a victim of circumstances shortly after, lost his home and is now busy with a new job. The project that was planned to be released in fall of last year has been put on hold since Spring of 2010.

Now I'm coming close to finishing The Indie Game Legend and the only thing I've had to rely on anyone else for is the music, which was only about 50% complete by the time the game reached 90% complete. My music guy is sleeping on an inflatable mattress right next to me as I type this; held captive here until he finishes the soundtrack. This is the only way.

So here we have four cases of why it's never a good idea to rely on anyone else during the development of a game, unless you're paying them and/or putting them in an environment where they're obligated to work. The first case is just a result of losing steam and flaking out. The second case is a result of other priorities (wife, job, etc). The third case is a matter of circumstances outside of the person's control (becoming homeless). In the last case, it's mostly a matter of not being able to put one's mind to working on stuff when you're in your usual environment.

In any case, there are plenty of teams that successful complete games and if you're lucky enough to find that person that's right for you, then that's a wonderful thing. I've just had a bad run of luck, but I would imagine it's not an uncommon thing for people to let you down when working in a team. Game dev is a three-legged race.

[Muz]

I haven't read all the responses in this thread, but I will later. Responses seem a bit depressing though. Personally, most of the fun I've had was working in teams. So much fun in fact, that I'll never work solo on a game from now on. It's pretty amazing seeing what people can do.


0. Convince them that they'll get something out of it. Nobody likes to waste time.
0.1. If your game is free, at least convince them that it won't be vaporware. Really, vaporware is a major threat when in teams. Or that they'll learn something from it when it is, get your free art, engine, world design, etc.
0.2. If it's something for profit, ensure a fair payment. Vaporwarism matters less if you give them a wage or contract.

1. Establish a proper team (or partner). They need to have the same vision as you. Listen or explain on the overall idea and feel of the game.

If you're opposing each other on ideas, the idea will get locked somewhere and you'll argue (and reluctantly accept) an idea going in one direction. If both of you think the same way, you'll go right and even help motivate each other. You'll be more than the sum of your parts.

Try to make sure both have the same level of ambition too. If it's a casual side project, all members should treat it that way. If it's an epic Dwarf Fortress-level game worth quitting a comfy job over, treat it like an epic project. You can't force a dabbling indie developer to be very ambitious; they'll get tired and frustrated and quit. Force ambitious people down and they'll leave.


2. Get a proper communication channel. If you can't communicate with your partner often, you might as well not work together, unless you're on a loose schedule. For 2 people teams, any medium is fine - email, IRC, Skype, whatever.

When it gets to 3 people, communication becomes vastly more complex. At the very least, you should always CC each other. Real time meetings become twice as hard to organize. You DON'T want to be passing discussions to the other party, being a middle man in communications is very annoying.

At 4 and more people, I very highly recommend getting at least a simple forum. You want a place to sticky notes, plans, art, etc. The few minutes in registering a forum pays off. Some people like to just assign a manager - dumb idea. Often the manager (not always the head designer) quits or goes missing, and the whole project is dead.


3. As a corollary to (2), keep your teams to a minimum size. More members mean more politics, more disagreements, more weak points. On the other hand, you can have a huge team (like some oldskool indie teams did) with excess members who'd work together.

Note that two people do not make a project finish twice as fast! In fact, 3 people may make a project finish slower than two, especially with the overhead.

3.1. If you do have a huge team, you tend to get some kind of useless noob who can't do anything, but is fun to have around. Don't kick him out, he becomes a sort of mascot or cheerleader. Moral support. With a huge team, there's bound to be some bureaucracy; assign him to the simple things.


4. Make sure the leader is competent and very active. I'm personally a management kind of guy; I love working with people and making a team run well. But indie peoples hate guys who just sit around and boss people around. Everything centers on the leader. The leader is often not just the head designer, but also very competent in something else.

The members will rarely be more productive than the leader. If the leader goes idle, the whole team would go idle. This is where the passion in (1) kicks in - someone else has to take over the project if the leader goes on hiatus.

Which is one major reason I often say that if you don't have something to show, don't look for a team yet.


5. Accept that people will go missing. This is why you document and comment everything. Someone has to pick up the scraps if someone else leaves. If you don't like documenting, don't work in a team.

Also, have backup plans. Don't panic when people go missing. Don't have tight deadlines or rely too much on one member. If the team leader goes idle, coup him.


6. Have a leader/head designer. He makes the final decision. I remember one situation where two people used to have different ideas for the game's story and the enemy design - the original designer wanted a serious storyline, Secret of Mana style, the other wanted a fun, trippy Sonic style game.

They wrote different threads and documents explaining their game. Most of the other team members didn't care too much and let both of them ramble. Eventually, people didn't know which idea to start work on. After a few months of nothing happening, one of the 'designers' conceded that he was wrong and said that he killed the project by branching away from the original design. It was too late, the project was dead, and everyone agreed that there should've just been one clear goal instead of two vague ones.

This could all have been avoided if the head designer was strict and just cut off that secondary design. Two good leaders are worse than one bad one. Nobody can go off in two different directions. Encourage creativity and ideas, but crop them.

[Tiderion]

I think it is important to remember that major studios use a hierarchy designed to limit decision making to a few people and expand creativity in localized areas. Generally speaking, All artists work under an art lead and all programmers work under a programming lead, etc. All the leads report to a producer. Indie game creation can limit the success of this model because the model requires a lot of people.

Most mod communities, of course, suggest making mods in groups of two or three because coming to agreements is hard with more people. If you are one powerhouse of a guy, then do it alone. The rest of us have to find ways to limit how decisions are made and most of us assume that means limiting the team size.

I happen to be better these days at leadership and design that programming or art. I can tell you that it takes a good leader to keep everyone satisfied that their voice is heard even if their ideas go unused. More importantly, it also takes good workers to give up a lot of creative control in order to just finish a product. I know that a lot of us, myself included, don't finish projects because it's too much for one person, especially when you are not being paid for the work. Again, the only alternative is to be willing to give up something in order to finish.

[dantheman363]

My guess is that that most games attempted to be made over internet by amateurs would fail. But leadership and vision in a group would help those team members achieve their goal of making a video game together.

[Tiderion]

I think an interesting phenomena is the mistrust in the game community for people who do not program or do art specifically. Number one thing you will find on modding sites is the advice to stay away from people who do neither because it's a waste of your time. I happen to believe that a lot of design teams fail because they do not have the appropriate leadership. Leading can be as much of a full-time job as programming.

That said, yes you should avoid the people who have "great ideas" but need you to do the work. But I think we need to be more careful about excluding everyone from teams who is not skilled in the primary fields of game design.