Multiple Developers and Collaboration

[academiken]

I am thinking of ways I can get friends involved with a project I have been working on.Ã,  I would like to know if any teams, groups, etc. had come up with a way to simultaneously contribute to the same project.Ã,  I am thinking, with my current understanding, that it would be possible for multiple rooms (.CRM files) to be worked on simultaneously in different locations, but it would be difficult for more than one person to deal with global scripts, sprites, views, etc. without a key person to carefully control the additions of contributions.Ã,  Is that true?Ã,  Any interesting experiences or tips?

[Gilbert]

If the codes written by different coders are more like building blocks, and they're expected to be called independently you may consider usinf Script Modules. So each coder can work independently on their part of codes. Of course, you still need one chief maintainer, who manage the different portions, and re-import the modules independently when they're updated.

[academiken]

That's helpful-- thanks!  So, as far as rooms go, does the editor or compiler mind if .CRM files are swapped out?  (For example, room5.crm is started by the main developer, given to another developer for region editing and room script developement, and then given back to the main developer?)

[strazer]

I don't think that will be a problem as long as you do it with the editor closed.

[Radiant]

I don't think that will be a problem as long as you do it with the editor closed.

Or even open. Just be sure to click 'refresh' on the AGS list of rooms if you've removed any.

[Pumaman]

You certainly can swap out CRM files, but be careful that both of your developers have the sprites avaialble. For example, if your friend creates a new object in the room and imports a new sprite for it, if you then load that CRM file into your game and you don't have the sprite in your sprite manager, it will turn into a blue cup.

[edmundito]

I have been reading some software teamwork stuff recently, and it really got me thinking about having teams work effectively for AGS-built games. I really don't know how difficult would change to improve the way the code works, but it never hurts for me to write what I think:

We all agree that:
1. AGS is easy to use when it's one person
2. It's even better when that person is a guru and can do scripting/writing/and graphics (e.g.- Ben Jordan is a result of this)

But then we have some problems...
1. Sharing code. One person can work on it at a time. Therefore there has to exist an AGS guy who puts everything together.
2. Updates, fixing bugs. Updating a set of sprites takes time, and animations, and all of that. And it takes you out of the "coding zone" because you have to spend time importing and tweaking.
3. People who are not skilled enough don't get anywhere. They got talent in one area, but suck at the other. And it's a burden to get help from other people.

The basic team:
- Simple teams are good: Writer, Programmer, Artist(s), Musician. (each with multiple talents, too, but those would be their primary things to work on)
- Ideally...
--A writer would be behind writing messages, dialogs, and "directing" the cut-scenes. He is not concerned about how many animations per character or if the background has the right hotspots.
--An artist or two would be behind backgrounds and characters. They would be able to update those backgrounds as feedback comes from just testing and the game progress. They could start by just insterting sketches and static sprites, and moving on to animations and finalized artwork.
--Musician can deliver the work in progress and get feedback until everyone's happy.
--Programmers does the work of interface, puzzles, and other gameplay mechanics. He could also be a program manager with the writer.

See where I'm getting at? The problem here is that when it comes to building the game itself. it is a pain in the butt to update anything graphical on ags if you don't have one person do it. The music is perhaps the easiest, as is all being stored into "physical" folders.

My solution? Oh, you're going to like this. Eliminate the way sprite manager works right now. Not easy. Basically, all the graphics would be stored in a physical folder. Yes, it's a much riskier problem, though is much easier to update the file sprite1.jpg by overriding it directly from photoshop than to reimport it on the sprite manager. Backgrounds would also be part of this new sprite manager, as the person in charge could easily just update the background without even entering the room file, which could be in use by the programmer or the writer to make it work. It would also be a whole lot flexible... like if it can't find the file then it will only throw a warning (similar to how music and sound work).

Thewriter can get away with cutscenes at the moment because you could technically write all the cutscenes in module files. But what about room messages?

Basically, ultimately the idea is for the files to be shared somehow. People could easily ftp the game in progress, or if they have a guru they could set up version control of some sort (CVS, SVN, etc.)

It thinksomething to think for AGS 3.0. I don't think it's written in stone either, this is just some brainstorm I came up with while standing in some line at a bookstore. But we have to start thinking about these things. And at the same time, not to make them overly complicated that only people with Comp. Sci/Software Engineering majors/interest would understand.

Thank you for your time.

[Pumaman]

Yes, something like that would be quite useful. On the one hand I like the way AGS keeps all the data packaged up inside its main data files, but that does make team work difficult, so allowing some sort of external file base is something I'm thinking about.

[Alynn]

Well, CJ, how difficult would it be to have a seperate folder like ags.gfx folder, the files are saved in the folders within that directly corrispond with the sprite manager folders.

Now each file is named it's corrisponding number 1.png 2.png... so on and so forth.

AGS can still take all those files and incorperate it into it's executable, but when compiling the game it looks for a checkbox (Use external graphics source), if checked looks for the ags.gfx folder and pulls the graphics from there.

So you can keep the current setup for single users but have that option available, so if a team was working on graphics, they just need to keep up to date on the ags.gfx folder to keep their sprites up to date.

[strazer]

Yes, something like that would be quite useful. On the one hand I like the way AGS keeps all the data packaged up inside its main data files, but that does make team work difficult, so allowing some sort of external file base is something I'm thinking about.

Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=573