Aller au contenu

Photo

One Module, Multiple Developers...


  • Veuillez vous connecter pour répondre
1 réponse à ce sujet

#1
Challseus

Challseus
  • Members
  • 1 032 messages
Right.

So, I know I'm behind the 8 ball on this, but I just wanted to have some things clarified for me. I currently have a developer that will be editing some dialogue, and he doesn't have any of the designer, or art resources for the module itself.

Would the best approach be to give him the database itself to import? Or, would just giving him the b2b package suffice? Also, when he does make his changes to the pieces of dialogue, and I import his changes, I should keep the ids the same, right? Are there any other gotchas with this?

Thank you.

EDIT - I'm well aware of the fact that having both of us connecting to the same remote database would be the most elegant solution, we're just not there yet :)

Modifié par Challseus, 25 janvier 2011 - 04:23 .


#2
Proleric

Proleric
  • Members
  • 2 361 messages
We've been using the B2B approach.

The key issue is string id management, of course.

Clear team member roles and protocols are essential.

There is good information about B2B in the wiki, but it's hard to get it right first time, so I always back up the data base before loading, then double-check the log.

We have an Integrator role, who publishes the B2B baseline that other team members enhance, then integrates their B2B extracts back into the master.

Art resources are managed in parallel as separate archive files.

Ideally, VO and FaceFX are only generated by the Integrator after all other team member work has been integrated (string id is used in the file names, so you want it to be stable).

The simplest situation is where the team member has no requirement to make new strings (cutscene artist, for example). In this case, they start from a copy of the master module.cif file, so that the string id range is identical. When loading B2B, they select the Use Theirs option for string ids. The Integrator does the same, taking care to load only those resources which the team member was supposed to have created or edited. This prevents unwanted changes.

If a team member has to make new strings, it's good to make their role as self-contained as possible (e.g. do all the resources, plots and conversations for one part of the story). That way, they are mainly sending new material to the Integrator.

In that case, the team member makes a new module with a unique string range, to ensure that there is no risk of duplication. When loading B2B, they use the Create New option for string ids.

This means that their copy of baseline resources has the wrong string ID, but we work around that as follows.

When they send their B2B back to the Integrator, they include only the resources they are responsible for. As belt-and-braces, the Integrator is careful to select only those resources on B2B load, too, with the Create New option to force string IDs back into the master range.

So far, we've often done the simple case iteratively, but only merged dialog once.

For testing, of course, we use .dazip rather than B2B.

Hope that helps.

Modifié par Proleric1, 25 janvier 2011 - 10:23 .