I'm currently facing a similar problem as you man, reading this thread helped me out as well, thank god for the great responses!

Good luck to all of us!

Im thinking the best way to motivate them right now is not with words, but just do alot of work myself and hope they pick up and follow once they see that the project is making progress.
and the simple agrument that they dont have time outside our studies isnt really valid when i can find time for it while taking evening courses besides my day-school and other activities like sport and volunteer work..but i guess i have no life.

I am sure some of you had the same problems, so let me know how you solved this problem!

When my project first started there was enthusiasm by the ton and there was a little bit of money flowing in. Everyone wanted a piece of the pie but it was still very much a volunteer effort. People started to drop off when they started to see that there was very little immediate return on their time. Then the money dried up and it was 100% volunteer. One thing I tried was to motivate people to use the project to pad their resumes because often times you will not be able to use the latest and greatest technologies in a production environment to the game project was a perfect way to work on a complex setup with cool stuff. That worked with one or two individuals for about two months and then they dropped off as well. Basically they were not totally enamored with pushing out a game. They loved the idea of finishing a game but not the idea of working late midnight hours to do it and there was no incentive ($$$) to do it.

One thing I had to learn the hard way was that it took more of my time to try to coordinate and motivate them than for me to just work on the project. I eventually had to take a hard look at the project and the team members and just let them go because MY return on investment in motivating them was very low. If someone dropped out for two weeks and then came back I would have to spend an evening spinning them up to the recent changes and then something would come up again and they would drop off. Wash, rinse, repeat.

I currently am casually 'advertising' for other developers to help but I tell them right away that it is a labor of love and they will only get experience out of it. They also have to prove that they are motivated by diving in head first with no support from me for the first month. It's harsh, it's not motivating, and I have had no takers.

When you are experiencing lack of motivation on your team take a step back and put yourself into their shoes. What is their incentive to put the hours in? In the professional world that would be money. Maybe they will get experience but in my experience (pardon the pun) that only motivates your visionary A-game types. Bragging rights and prestige will only be gotten after the game is successful which may never happen and even if it does it is a long time from now. If they don't have an obsessive love for the project they will eventually quit. Cultivate that obsession or start waving the money carrot. And ask yourself what is the cost to the project to spend the time to cultivate an obsessive team.

Elements I've used to keep things flowing:

- Keep clear, concise and short-term objectives. ex: This week, we need to complete "this feature".

This needs to be a commitment from the whole team, not you tossing this over them. If they believe its possible to attain, they'll attain pride in achieving this, and shame in under-delivering. Try to keep the objectives realistic, but don't make them too easy or hard to achieve. After a while, the team will know almost exactly whether it can attain or not the objective it set for itself.

You will not need to do much motivation aside from recognizing their effort. They will reward themselves based on the work done.

The problem with not having punctual objectives is that the reward of 'completing the project' is so distant that interest will fade over time. This isn't the case with short-term objectives.

- Axe the obstacles: Your job as team lead is to remove any impediment. In this case, if you're also responsible for creative input, make sure you prioritize the core gameplay features, and are open to discuss the 'other stuff'. Its highly possible that some features won't be 'fun' to work on, despite them being critical to the end product. One way to axe the obstacle in this case is to push this to the very end. As with the following point, when developers see what they're building turns into an actual game, they'll be much more motivated to 'kill tasks' to get there.

But your role is also to bring the donuts, coffee, deal with their immediate constraints, and insure everything is smooth sailing. If there's a wiki to update, do it yourself. The less time they have to do 'something else than what they're good at', the happier they'll be.

One might argue that this makes it a boring job for you then, but you've chosen to be the team lead, plus you have the creative input, so someone's gotta pay for this ;)

- Develop an iterative product: A game with a fairly simple core gameplay will allow people on your team to quickly see 'results'. At that point, they'll want to iterate (beware of feature creep) on it to make it better, and because they have something playable in hand, the big reward of shipping a final product won't appear as far as it would otherwise.

For example, a platformer is good because you can quickly implement a few gameplay mechanics (jumping, running, etc.) and will iterate (add levels, add upgrades/power-ups, etc.)

- Listen. Remember the things they've brought up as potential risks. Ask them their opinion. Not just to motivate them (it will motivate them if you give them the credibility they are entitled to), but to not actually fail. If you've started this project knowing you needed other people, don't consider them machines that produce the stuff you need. More often than not, they will have creative or technical input that is critical to the success of your game. If there is not such a thing already in place, figure a way to have a common build review moment. If you are physically apart, you can do this through screensharing in Skype for example. Worst case, let everyone do their own build review, but make sure you have an open discussion about it (if morale is low however, people won't do the actual review on their own, and even if you insist on a group review, once again, if motivation is low, people will not cooperate).

Any update from the original post by the way?