Best approach for working in team?

[RedTiger]

Hello - I apologize for asking if this has already been answered, but search is down, and I didn't see anything like this in the FAQs.

I would like to make a game (duh) but I have one team member in Indiana, and an artist in Orlando, what is the best way to coordinate efforts? Can I use a system like CVS with AGS or is it mostly binary files?

What have other successful distributed teams done?

Thanks!

-rt

[Ishmael]

Welcome to the boards

AGS has no sharing options in itself, so you'll need to move the whole game datafile bouch (room files, sprset.srt (or whatever), editor.dat etc.) around. The best way would be for others to do their work, and then one person puts it together in AGS and compiles the final product.

(I have a faint feeling that Rich will skin this thread, as it, atleast to some extent, is against the rules...)

[RedTiger]

Thanks for the input - and the welcome.

Over the coming weeks, I'll be posting my share of 100% legit technical questions

-rt

[Scummbuddy]

[Moved here from Beginners Tech, since it was not AGS technical related]

Go get your own proboards.com or other free forum type page, and you all can work within the privacy of password-protected areas and discuss your work. Thats what many of the Adventure Team Challenges did here, when those times were upon us. It worked well for many, and good luck with your team. Let us know how it goes, if all goes well, or let us know what went wrong, so that future teams may learn.

[TerranRich]

Scummbuddy: That's exactly what I and several others (ratracer, RickJ, Nellie, Ryan Abes) did when working on the plot for By the Sword. We had our own ezboard for discussion, and having a public file-sharing area would be excellent for working on the game itself. I don't know of any services, except for XDrive, which isn't free anymore (or is it?). XDrive would be perfect for sharing the files among each other.

[BerserkerTails]

Two of a Kind was created almost exclusively through the use of the AGS Forums Private Message system, though a bit of discussion took place on anothe board, and on IRC. It helps to have a really good message board though, as that's what we're using for Bestowers of Eternity, and it seems to be working out quite well.

[MillsJROSS]

It might also be a good idea to get everyone of your team members phone numbers, so you can directy contact them if they've been MIA. Other than that, teams are hard to keep together, mainly because someone loses motivation, and you never hear from them again, or real life kicks in, and they no longer have time. So try to keep everyone motivated as much as you possible can.

-MillsJROSS

[Eggie]

Unfortunately, I think the best way to get a team working is to put them all in a building together and pay them...

[Krazy]

Team working like this only works if everyone working on it has a passion for what they're doing, is assured to do it and not just some guy on a forum who runs off soon into development and the game just falls apart. I know stuff like this CAN work and I think the less people making it who can do more things the more likely it will be to be finished. And I know it will work for some people dedicated to the game, and some it just won't.

[Dave Gilbert]

Ah, the age old question.  How to make a team work over the internet.  Group projects CAN work, but they can oh-so-easily fail.  There are many reasons for this.

A strong, cohesive vision is very important when putting together a team.  Let's you have this great idea for a game, and get all psyched.  This is going to be the best game EVER.  So you start trolling around looking for people to help out.  You find an artist, an animator, maybe even a musician or a programmer.  They all LOVE this great idea and are eager to get started.  However… you don't really have anything planned aside from that initial cool idea.  Then you tell your eager team to wait while you actually design the game.  Interest wanes, and the project dies soon after.  A solid game plan is a must.

Also, think of how many solo projects that get abandoned. Every time you start creating a game you run the risk of  eventually losing interest, real-life issues cropping up, or coming up with something better.  Now imagine that you have a team project.  You run the risk of each member of the team doing the same thing â€" they lose interest, real life stuff comes up, or they find a new and shiny project they can work on instead.  It's HARD to find a team that will stick together until the bitter end, because it's very easy to disappear.

However, you can take some precautions. 

1 â€" Ensure regular communication.  I'm talking at least 3-5 times a week.  This doesn't mean that your team members should be making progress every day, but they should at least be communicating with you to say “Hey, sorry but I've made no progress today.”  If they go missing for a week, drop them a friendly email to touch base.  If this continues for a long time, you might want to consider finding someone else. 

2 â€" Make deadlines.  You don't have to enforce them, but it gives your team something to shoot for.  Let your team members know that it's OK to be late, but they should contact you saying when they think it'll be ready. 

3 â€" Message boards are great!  They are really useful in building a little community within a project.  Encourage your team to use the board and to show off their work.  Enthusiasm is contagious.  I know that if I see other people working hard and producing great work, it encourages me to do the same. 

However, even with all these precautions things can STILL go wrong and usually will.  Be wary and trust your instincts.  You can usually spot the warning signs if a team member is losing interest â€" lack of communication being the key one.  Try and spot this EARLY, as it will save you major headaches later on.  There's nothing worse than sitting by your computer waiting desperately for that piece of artwork/animation/music.  Perhaps this is cynical of me, but if they can't be bothered to send you one lousy email every couple of days, then it's hard to trust them to do much else.

Being a team leader is like being a cheerleader.  You have to constantly keep everybody motivated and enthusiastic.  There will be some rough spots, but you have to stay positive and be a good role model.  It can be tough, but very rewarding if you pull it off.  Best of luck!

[Scummbuddy]

precaution/tips (con't)
4 - Throw money at them. Money solves everything. Well, okay, not everything, but if you really want a talented artist (bgs, chars, music) paying them a bit for each finished and satisfying peice can be worth it. Maybe only 5 bucks or so each (for amatuers) but when you add up all the bgs, that can add up for that artist to partake in this adventure.

[Pelican]

I suggest you have a read of the Adventure Architect features at the Adventure Gamers website - I've found them very informative. For team building, you'll especially want to read Part Five and Part Six.

[Svartberg]

Great tips Dave, i would suggest everyone to read them
Working on a few game projects myself, i can say a few things from experience :

5 - Leader=Jack-of-all-trades
If the project leader doesn't know the basics of what the other guys do (programming, art, etc) it will hurt his work schedule planning - i found out teams where the leader didn't know programming too well, died quickly. (<- me )  the leader should be the jack of all trades with at least basic knowledge in everything.
If you never programmed a game you'll never know what to tell a programmer to do.

6 - Motivations for members
Don't expect other people to plan things on their own, they need schedules, deadlines (as Dave mentioned) and sort of motivations, the visionist is the project leader - the other members are workhorses (no pun intended) and seeying the project getting complete won't give them motivation, they need other motivations - 90% of the time only money will do it, but 10% of the time feeling they are part of a proffesional team and they themselves are improving with it will do the trick.

7 - Silent time killer1 - The project presentation site
Don't be drawn to work on a fancy site for your project, it will be very tempting to do it but it will give you nothing back. (aside from killing you precious time)
instead make a simple database (php/css/forum) that can be easily updated, check if it takes you more than 5-10 minutes a day to update it it's too much - not updating it will give the impression the project is dying, so if you can't update it under 10 minutes a day, simplfy it. (yes that means removing some of it, i learned it on my last project, and i gotta say it's a very healthy work approach)

8 - Silent time killer2 - Discussion Forums
Forums tend to cause people to waste a lot of their time on fruitless discussion. (look at me i'm wasting time on my day-off's evening on something that gives me nothing, and i won't stop until i finish it ) as the leader it's your responsiblity to note of this or it will wreck the project development.
I suggest dividing the discussion from the main work ones, for example an artist wanting to show the progress of his haracter and seeying a thread in the forum talking about the plot/story/ideas/etc will be drawn to the discussion (or reading), instead put the non-work related discussions in appropriate place so work doesn't get mixed with other things. (workhorses, workkhorses )

9 - Workschedules - a lot of small goals
A lot of big things in life are better achieved by setting small goals, this isn't easy to remember - we ussually have a vision of the end-product and we want to achieve it quickly. however unless we take it one step at a time we'll get depressed and drop the idea :\
That's why when i worked alone i was able to easily set myself small goals and everyday i knew i achieved several things, that's why as a team gets bigger and bigger - the leader gets busy coordinating other people's work more than actually working.
I like the todo list - fix X, make Y, you see the problems and add them to the todo queue this is how the team should communicate between themselves - someone spots a problem he adds it to the todo queue, and fixing it he marks it as fixed and provides snippet code with explanation etc.

10 - Workschedules - need to know basis
Someone who only does X doesn't need to know what Y does - organize the team into departments and make sure each one is busy with their own stuff.


This is a long post because i'm bad at explaining myself, sorry =\
I found out that when i worked alone i worked better and faster than 4 ppl at the same time.
That's what i think should work in team sizes :
1. solo project - don't aim too high, think of a simple yet appealing concept, don't think of the end product.
2. 2 man team - work with someone you really trust. your friend will mainly motivate you, but the project will go nearly as slow as solo.
3. a small team - teammates should be very dedicated to the project - tough chances of working from my experience.
4. big teams neatly organized into departments, the leader ussually busy coordinating everything and making sure everything works (controlling where the project is going). the departments are sort of todo queue based and coordinated by lead artists/programmers/etc - this let's the project stay stable if someone leaves (unless it's the leader, while someone can take over nobody will want to probably).

when money isn't involved less is better ;[]

[RedTiger]

Wow thanks for all the comments. I know it's been a few months, but as MillsJROSS said, real life gets in the way...

We're making progress (incremental at that, but progress nonetheless).

What we ended up doing was getting a shared PHP host, and installing KnowledgeTree http://kt-dms.sourceforge.net/. What we then did was create a login for each member, and started posting game-related files (artwork, sounds, music, the design doc).

What we then did was login and see if anybody posted anything new. It works reasonably well, and it provides rudimentary version control and locking. We're still not sure how to share the game "source" (rooms, etc...) and we have yet to decide who is going to manage putting it all together, or even if we should attempt that and just each build the game separately.

We also all use various IM clients which helps.

So far I think we got a good team, 2 professional software guys, and one professional game artist. We all loved and miss classic adventure games, and we're all looking to just do this for fun and to see if we can.

We've had to do some gentle nudging to keep things moving, but generally everybody is excited to do this and having fun in the process.

What's good about a three man team is that one works a bit, then nudges the other two by his progress. Then the first man goes down (family, work, etc...) and another, motivated by the first's progress, starts cranking.

-rt

[Ginny]

You know, I think doing the game programming together would be a bit messy, unless you do it in turns. For example one person works on the GUI and preliminary rooms and such while the others work on art, story and music. Then you could pass it on to the next person who could put in the final room art, draw the hotspots and areas, add descriptions and "meat" to the skeleton, and so on.
Another option, which I think might mess things up if you're not careful, is sharing all the game files and then each one can work on a seperate room, and if they want to change something in the gloabal script aswell they would post a notice about it to keep all the files consistent.
Anyway, I like doing my scripting bit by bit while making every thing I complete ready so I dont need to touch it again, but I could adapt I guess if ever I was to program alongside someone.

Oh, and Welcome:)

[grandma]

waiting for horror hospital, ben jordan 5, devil's shroud part 3. anybody else looking forward to these games?  ( darth, i do not know where to post this so you can move it. )thanks

[Scummbuddy]

darth is not a moderator of this board. but you could post your post in this thread, and this previous one could be deleted.
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=18169.0