Multiple people on one project

I'm part of a small team working on a demo game. We each have different responsibilities and event sheets for the game and are currently using Tortoise SVN to share the files with each other, but it's impossible for multiple people to work on the same file at the same time. Currently we need to make sure that only one of us is working on it at a time and it's not very time-efficient or convenient.

Any suggestions to make the this simpler? How have you managed multiple people collaborating on a project?

Thanks!

I have the same issue.

Yes its an issue ..

Personally, I've worked in & managed many collaborative projects and you can quickly tell whether or not the group will fall apart and get nowhere..its usually due entirely to one simple reason..

NOT ENOUGH PRE-PLANNING

If no one is on the same page when you start the actual 'work'(ie: the asset creation stage)....or if everyone is away on the fairy train to their own kingdom ..often they forget to tell everyone else the way to the kingdom they know so well.

When making any game...

I always advise to make SYSTEMS....

BUT FIRST...plan out your entire game as much as you can from the beginning...and I mean EVERYTHING you can..

There will always be changes and plans that are scrapped , features that just simply dont make it in to the final game.

Some games change entirely direction..Look at HALO..it was originally going to be an RTS!!!

The basic Work flow for ANY project should be this..

PRE PLANNING STAGE

This is where you sit down and talk and discuss the ideas and agree to get working on the project..and in this time you should also..

-Figure out the strengths and weaknesses of your crew...

-Make sure THEY know what their JOB is.

-Get pretty much to close to a final CONCEPT for your game..

-THEN make some CONCEPT ART...

-SHOW IT EVERYONE and discuss the WHOLE GAME AGAIN..adjust and re work any concept art..

-once the concept art is CLOSE to final..

-THEN the programmers are briefed on the gameplay mechanics..

-THEY WILL THEN BUILD A ROUGH WORKING GAME meanwhile the Artists are polishing the ART concepts into MID STAGE ART ASSETS

-At this time....The manager/project director should be making sure that everything is flowing smoothly ..ironing out any issues or problems so that the "underlings" dont have to stop working to solve a problem that the MANAGER should be solving

Advice to each department

ARTISTS & SOUND ENGINEERS-

0-LISTEN TO EVERYONE AND BE INSPIRED BY EVERYTHING THEY SAY.(it makes for rich compost to grow your ideas in :+))

1-WORK ROUGH AND FAST AT FIRST...PRODUCE CONCEPTS ONLY at first..and make sure everyone KNOWS its JUST a concept..

2-DEVELOP PLACEHOLDER ART assets ASAP to stand in for the FINAL ART..

3- WORK ON THE FINAL ART ONLY WHEN EVERYONE IS HAPPY WITH THE CONCEPT ART AND HAS AGREED AND DISCUSSED IT FULLY WITH YOU. (this is really important...other wise you will be remaking the art over and over again because someone doesnt like it..Again the Project director SHOULD have final say..but not always..)Find the Balance but always do your GREATEST and best work..

Programmers-

MAKE SYSTEMS NOT INDIVIDUAL EVENTS

what I mean by this is...if you have say ..a robot that shoots a weapon , moves and also dies ..

but you also have the player and NPC's doing that too..

MAKE A SYSTEM that will handle ALL Of those functions using FAMILIES.

other wise you are going to be grinding through thousands of changes per MOB Type

If you make a system that can process all of the VARIABLES in a single streamlined fashion for ALL objects..YOU have done well..so PLan this out well before you DO any programming..Remember!!

BUILD SYSTEMS THAT WILL HANDLE MECHANICS NOT NOT THE OTHER WAY AROUND..

the basic idea is..create the flow of the river by sculpting the riverbank..trying to wade into the current to change its flow is silly and you will just look wet behind the ears..:)

In addition to solve the TEAM work issues..

Don't make one event sheet with all of the systems on it..

BAD IDEA..

You should have..a layout event sheet that is basically empty except for a few things ..and then INCLUDE the other system sheets that you created.

So what I mean is...PLAN out and make your game using individual systems that interact with each other..

Such as a Player controls SYSTEM which is contained entirely on its OWN event sheet..Named something like "PLAYER CONTROLS"

Another system could be called..

'ENEMY AI'

and all of the events that belong to the ENEMY AI functions..are contained or "NESTED" in a single separate event sheet

This allows the MANAGER to distribute the LATEST event sheets to each person rather than the entire project and each person can immediately see what changes another person has made..These event sheets should really only be distributed once they are more or less WORKING...

once again..EACH event sheet system should be broken up into smaller systems...until you get to actual mechanics of the game...

Systems allow you to pass information much faster up the pipeline to the other systems...providing that you build them correctly..

THINK MARIO plumbing and you get my idea..

each BEND in the pipes is a System that does something to the Actions/water that pass through it..

you can stream trillions of computations/object UIDS through the systems but only the ones that are flagged for that system will be acted upon

IT takes a bit more time to figure out..but at least no ones work interferes...each system has a pipeline that passes information to the other systems..

Does that make sense.?

It's standard practice in Professional companies..for a reason..IT SAVES TIME IN THE LONG RUN

SO...Break up your Game mechanics or components into Different Event sheets

This way each person can work on their part and not affect the other systems.

Then each level sheet just "INCLUDE" the other parts such as...

-PLAYER CONTROLS

-DYNAMIC SOUND SYSTEM

-ENEMY AI

etc etc

this way

the game demo is playable but each person 'CONTRIBUTES' to the game rather than wrecking it..

That being said..as a GAMES developer if you are MANAGING A TEAM..it is your responsibility to make sure that every one is on the same page or at the very least...is organised enough to not step on each others toes...

Proper planning should avoid any of these issues..

Its best to sort this kind of stuff out well before you commence work..

Its called PRE-PRODUCTION..and every day you spend on that..will save you months of headaches later on sorting out where you are...

hope that helps...

once you get it..its pretty simple and will greatly speed up your production time and decrease your errors from department to department..

oh yeah..and BE NICE to your fellow team mates..

You are all in it together..for FUN remember!!

Dont forget the FUN part...

most important

<img src="smileys/smiley17.gif" border="0" align="middle" />

The

• null
Hypothesis is that there is no game...

Sorry for all the CAPS but sometimes you have to SHOUT to be heard..

There is a reason why logical systems work..

You want to avoid shouting at your team mates that is why I am shouting the advice to you...:)

Hopefully you hear me..

LIke I said ..Ive worked on alot of collaborative projects and sometimes it can get so bad that the group separates and dont talk again...I've seen this happen so many times...and its usually because no body knows exactly how to 'organise'

Computers are logical..Games are basically GIANT databases of indexed items that interact and display on the screen...if your organisation method are crap..then your game will have bugs if it works at all....its usually best to start off on the right foot... if you start off right and stick to the plan and follow through with the RIGHT system..you will have your game built in no time and it will be easy as..and the next game will roll out in style because you will know your stuff..ITs all about being organised....oh yeah and..SYSTEMS!!!!!!! remember to build systems!!! not individual mechanics..

Since the first post, Ashley wrote a complete tutorial on how to work on projects with SVN to have multiple persons working on the same project.

It does require indeed planning, but also a bit of setting up of the server as well as a common workflow to prevent issues, but as explained in the tutorial, it's totally manageable to handle it.