- Dropbox - for assets, design documents, you can also store here todo lists, assets list, some other project files, etc.
- SVN/Github/Bitbucket - for programmers specifically as for example Visual Studio and Dropbox seem to hate each other. When you and others work on the same project opened several times on Dropbox, it will start to create some crappy database files or other shit that takes quite a lot of space. It's just irritating.
- Forums - can work the same way as Dropbox, surely brings better organization of files and may look better but isn't so convenient, Dropbox is much faster to use, though we still use forums for some development-related things.
- Wiki - project documentation, not every project needs it though, for some forums work just as fine
- Skype/MSN - for chatting & conferences.
- Google Docs - sharing documents, with the possibility of real-time co-writing is surely something that could be useful.
Let's see, we already have a game prototype and a team of quality people. What do we do now? Well, you could always actually start working on your game and maybe someday finish it and release it. After all, that's what we strive to achieve. And if there's something that could help us all in that long journey, it's called work organization.
First of all, I'll remind you once again that the more people you have on your team, the worse - the more people you've got, the bigger the tension and stress can get and you may easily lose control of them. There are many approaches to working on a project, I'll present you how I do this.
Now, if everyone has already looked through the prototype, group yourself up and start a conference on Skype or any other communicator of your choice that allows more than 2 people to chat at the same time. Or just meet IRL if you can. During that 'brain storm' everyone should give their own ideas, remarks and comments about the project. Even if the idea might seem meh at first, someone might be able to modify it and turn it into a very good one, so never be afraid to share your thoughts. Someone that is working as a designer in your team should be writing down all those ideas.
After the 'brain storm' he should sit alone and separate good ideas from the bad ones, bearing in mind that he has to limit himself to not design a project that would take too much time to complete. He should also take into account that the team is most likely inexperienced and so very complicated mechanics shouldn't be included in the final design. Surely there might be many great features you would like to see in the game, but you have to be realistic - someone will have to implement them and do all that in an optimal time. Pick what you're capable of, you don't want to sit on your first project for two years.
After the initial adjustments, the designer shows a more detailed vision of the game to the other team members. And again - discussion. Now without those big ideas, just do the small changes if needed and you're ready to go. Keep in mind that you don't have to plan all maps, missions, vehicles, enemies or anything like that at the beginning. Those details you can always do further in your development cycle. Programmers and artists should know from start what to expect from the game and what is needed (it sucks when you realize in the middle of your work that half of the code is trash as someone just thought of changing one feature or that some of the assets are going to waste because something wasn't clarified from the beginning).
Someone who is handling organization in your project should write down all the needed assets (sprites, sounds) and create some sort of milestones for the development process. Sure, you could go with just todo lists, but the possibility of 'unticking' more tasks at once as you approach your big milestone, which puts a solid closure on this particular part of the game, is a much better motivator. You will always know what is done, work will be divided into portions that are easier to handle. It's also easier to force yourself to work when you see that there are only a few more tasks until the end of the current milestone, instead of seeing a 2MB txt file with the todo list of all things needed to finish the game.
And picking tasks for the next milestone is always a fun event for the whole team ;)
Here is a list of some tools that might help you in your work:
Let's see, we already have a game prototype and a team of quality people. What do we do now? Well, you could always actually start working on your game and maybe someday finish it and release it. After all, that's what we strive to achieve.
Advertisement
Recommended Tutorials
Other Tutorials by CodeDaemons_com
25937 views
Advertisement
This lightly touches on an important aspect of team development. You should never do actual work from a shared folder in any cloud platform. Each team member needs their own folder to work from (it's great to have constant back ups of ones own work) and at key points upload to a central repo (git,svn,perforce, etc etc)
My personal recommendation is Dropbox for your personal work folder and git that you host yourself. With a bit of work dreamhost can actually run your git server quite well. Been using this system for awhile with a geographically separated team for years and it works well. I recommend hosting it yourself because almost every team has and can afford a website but github can get expensive for an indie team just starting out and you certainly don't want all of your work to be public.