• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • 🏆 Hive's 6th HD Modeling Contest: Mechanical is now open! Design and model a mechanical creature, mechanized animal, a futuristic robotic being, or anything else your imagination can tinker with! 📅 Submissions close on June 30, 2024. Don't miss this opportunity to let your creativity shine! Enter now and show us your mechanical masterpiece! 🔗 Click here to enter!

Basics: Working on a Editorial Team

Status
Not open for further replies.
Level 1
Joined
Jan 20, 2013
Messages
2
Hi everyone. I've developed SC2 maps before, but I'm wondering what the best procedures would be for developing a map with a team. I couldn't find any reference to this in the forums.

My questions:
  1. Have you worked on a sc2 developer team?
  2. What went right, and what went wrong?
  3. How did you protect the groups intellectual property from team members / outsiders??
  4. Do you believe it is better to work on a team, or would you suggest map makers to work alone?

Feel free to add whatever you would like to this.
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,208
Have you worked on a sc2 developer team?
No but the processes are exactly identical to developing anything as a team.

1. Break up work, you want as much to happen in parallel as possible. Avoid big monolithic tasks as they are difficult to produce and carry a lot of risk.
2. Allocate work, each team member should always have something to do. Do not allocate all work at the start, only allocate work as nescescary (when someone complets their current work).
3. Define work, each piece of work needs a clear definition if a person is to be able to produce it as desired. Especially if the work interacts with another piece of work this is important to assure correct behaviour.
4. Keep at it, piece bu piece the project will come together. If a piece of work becomes more complex than expected it should be broken up into smaller pieces of work.

That is all there is to it. The problem is defining pieces of work (tasks) and specifying them in enough detail that they can be produced accuratly.

A good task size is something that can be done over a single weekend without spending all the time on it. For example, 4-8 hours of work would be a good maximum task length. A single unit, trigger or ability would be a good example of such a task.

When specifying a task you need to mention all important properties about it. For units you should mention the artwork and its ingame properties. For triggers you want their behaviour and any prototypes for interaction with other triggers. For abilites you will want to specify their full behaviour.

You may find the project developer spends nearly all the time specifying tasks.

What went right, and what went wrong?
Cannot really comment with SC2 but it did not work too well on a software project. Leadership is an important skill needed for team projects to suceede.

How did you protect the groups intellectual property from team members / outsiders??
This is entirly unimportant in SC2. BattleNet itself provides some form of copyright against people claiming ownership falsely (proof you uploaded it). Idiots will always try and steal maps but since this is only a game you can ignore their childish antics.

Do you believe it is better to work on a team, or would you suggest map makers to work alone?
It all comes down to how much you want to project to succeed. Team work will always be better than solo work but it will not help a project become finished. Only the director of the project controls that and if he gives up the project will die.
 
Status
Not open for further replies.
Top