Well I was rummaging through the staticsen v4 on Doodle77's website and I came across this, I thought it would be a good oppurtunity to help the ever so popular team-mapmaking projects. Tuxedo-Templar wrote this, I owe all credit in this topic to him.

Thinking about it now, one of the major obstacles I see to mapping thus far has been the team element. While many great works have come from individual mappers, the fact is that working by yourself is doing it the hard way. It takes longer to make, depends strongly on your available free time, energy, and most of all, has no contingency or failsafes if you can't or won't continue working on it; if you fail, it fails.

With multiple people, though, you can address those problems. However, there's costs with doing that as well. You have to recruit competent members, manage their productivity, and most of all, bring together all of their efforts to produce a single product. Thus far, it's been that aspect that has been the most trouble with Starcraft. While you can easily divy up aspects like planning, play testing, story/script writing, and maybe production and release, aspects of triggers and terrain; the so-called "meat and bones" of a map, respectively, have traditionally been difficult to divide up. Doing so either requires a "pass the baton" approach with the map (where only one person can work on it at once), or else forcing people to have to copy each other's modifications by hand between edits across multiple copies of a single map.


However, thanks to the power of modern editors, and possibly this guide, you shouldn't have to suffer that any more!

---

Team Mapping Process

---

Roles
Like any group project, the first thing to establish, whether the idea has been conceived of yet or not, is who will be in your group and what they will do. There's two main things that determine who and what you need for a project:

Scale: The more ambitious a project is, the more people it will likely need to cover each aspect. While smaller projects may be able to get away with using only a few or even one person doing multiple tasks, larger ones may need multiple people just to cover a single task effectively. Sometimes you may even need people just to handle communication within the team (a "Producer"), depending upon the number of people or complexity of the project.

Type: Different types of maps/projects have different requirements. An RPG may require several people to be writers or planners to cover story, dialog, and game events, as well as having requisite competency in the terrain and trigger departments. A Defense or Bound map, on the other hand, may not require any writers at all, and only a few (or just one) planner, passable terrain or triggers, but a lot of playtesting/balancing.



Let's assume you're working on an ambitious Campaign or RPG-type map, for instance. I'll use this as my example because it effectively represents the full scope of what you may need for a large-scale team project with Starcraft. Here are some of the roles you may need to cover (note that for some of them I'll be using my own names and descriptions):

- Execution:

• The Project Lead - This is, of course, a given. The project lead is the person whose job it is to see the project gets done. That means commanding his forces, adapting to circumstances, and giving direction to the whole mess.
  Skills needed: Leadership Ability, Vision, Problem-Solving ability, Persistence
  
  
• Producer - For large or complex teams, a middle man to handle the exchange of communication may be needed. This most likely may also be the Project Lead himelf, but it may also be delegated as a seperate role. Producers keep the project and its members in focus by making clear to them the project needs, giving status updates as needed, and helping them to communicate their needs with others in turn. The producer will have to work closely with the Project Lead to keep the project's goals in focus, as well.
  Skills needed: Communication Ability, Reliability
  
  - Planners:
  Writers:
  [LIST]
  
• Story/Plot Writer - This should be pretty obvious. Writers should have a good grasp of how to produce a compelling narrative, as well as how to keep it with the frame of the game itself. This job acts mainly as another planner's position, which should ideally be kept closely in line with the gameplay and area planning aspects (either following or leading, depending upon the story's 'importance' to the game's "experience").
  
  Skills needed: Story writing ability, grasp of the context it's in (Starcraft, in this case), vision for how to map it into gameplay.
  
  
• Scripts/Dialog Writer - Within the frame of the story and events, this role will be needed to add the 'skin' to the project. This includes things story characters might say, in-game messages, briefings, etc. Any of the actual 'text' (or even aural speech) in the map is done by this role, which may also be covered by the writer(s) themselves.
  
  Skills needed: Grasp of emotional and circumstantial contexts, good expressive ability, and even sense of timing.
  
  
• Editor - With projects involving lots of writing, this (also overlooked) role may come into play. The editor's job is simply to clean up the writer's works by keeping them grammatically and syntactically clean, to the point, and giving them effective language. They may also be called upon to tidy up the story or the plot itself to keep it focused towards being a good game. In spite of how it sounds, the editor's role actually holds a lot of power over how the final product will turn out, and should not be taken lightly.
  
  Skills needed: Strong command of written/spoken language, grasp of effective language, grasp of how to focus on what's important.
  

• Area Planners - In other words, where to put stuff, or what to put where. This role may be flexibly handled by other members (particularily Terrainers) as needed, but best handled early on (sooner the better, in other words). This also sets the boundaries and definitions of what the Terrainers and Trigger Writers (Programmers) have to work with later, so close collaboration with other departments is needed.
  
  Skills needed: Spacial and asthetic sense, grasp of area requirements, grasp of game limits.
  
  
• Gameplay Planners - This is an important role that will be closely linked with the Trigger Writers' (Programmer's) job later. Gameplay planners outline the meat of the game, such as how the player's systems (leveling up, items, etc.), battle systems, boss battles, etc. all work. Working closely with the project Lead and the Programmers is important.
  
  Skills needed: Familiarity with many gameplay styles, balancing, and creative thinking. Trigger experience helpful.
  
  
• Prototypers - This role could be considered a subset of the Programmers or Terrainers jobs, or even an aspect of Gameplay Planning, but may also be handled centrally as well. Prototypers take requests for specific aesthetic or functional (gameplay) aspects of the project, and create test scenarios to find the best solutions for how to handle them. This is an often overlooked, yet highly useful delegation when methods are needed to solve given problems, where otherwise having to fully implement them into the map to test them becomes impractical. This, like other aspects of planning, is best handled as early as possible, but may be needed often during the project's development just the same.
  
  Skills needed: Solid triggering/terraining ability (as needed), creative thinking, problem solving ability.
  

- Content Makers:

• Terrainers - These are the guys who add the "bones" to the map. They carve out the areas of the map, mold them into shape, add in the needed content, and then pretty it all up for show. Terrainers will need to work closely with the Programmers as they develop each area to ensure each others' requirements are being met. A good terrainer can make an area look snazzy while still doing what it's supposed to do without giving the programmers a hard time.
  
  Skills needed: Strong aesthetic ability, spacial ability, knowledge of tilesets and tile blending, grasp of project requirements.
  
  
• Trigger Writers (Programmers) - These are the miracle workers of the project. Trigger Writers (more formally known as Programmers) take on the job of adding "meat" to the "bones", so to speak. The programmer's job creates and ties everything together, including gameplay, player interface, and story telling, and makes sure it all works right. To be a Programmer, you will have to work well with the Terrainers, follow closely with the project's plan, and put up with receiving the full brunt of the project's requirements. This is easily the most difficult part of the map making experience, which is also coincidentally the most difficult (and necessary) to have delegated between multiple parties to share the load.
  
  Skills needed: Strong trigger writing ability, strong grasp of the workings of the game, logic skills, problem solving ability, patience.
  
  
• Foley Artist - In a nutshell, he who provides sound. Having a good ear for what sounds to use, where and how to get them, as well as a bit of knowledge on how Starcraft treats its .wav files once embedded in a map, and perhaps some sound FX editing knowledge as well.
  
  Skills needed: <See description>
  

- Testers:

• Lead Testers - This role, like the producer, acts as a middle-man between the testers and the Content Makers, and is also charged with delegating testing jobs among the testers as well as maybe tester recruitment. A person with some experience in gameplay balancing should be selected for this job, as well as having good ability to compile and summarize testing results and present them to the project Lead, Producer, and the rest of the team (as needed). He may be called upon to do focus testing for specific aspects of the project, in addition to general balance testing and bug tracking.
  
  Skills needed: Good communication ability, managerial ability (managing a team of testers), and skill at compiling and communicating test results to the team.
  
  
• Play Testers - These folk will start to come into play during the late alpha and early beta stages of the project. The only real requirements for them are to be relatively trustworthy (so as not to leak or steal the map, if that's an issue), and to have some interest in the relative type of map being made. Beyond that, a good Lead should select as diverse a group of testers as possible, while keeping them relatively centered within interest range of the map they're supposed to be testing.
  
  Skills needed: <See description>
  

Task Allocation

---

If you were to be working on the above-described ambitious Campaign/RPG, you'd need to fulfill each of those roles in some way or another. Chances are, you could recycle team members to cover those, or even do them all yourself, but again, if you expect to actually produce something in a reasonable span of time (or even at all), delegating tasks is really the only way to do it. Most of the Execution, Planning, or Testing tasks can be easily delegated with the right people, but the it's the Content tasks that need some special help. This is where I come in with some handy methods, and a few modern tools, to help.

Terrain:
Terrain is usually pretty straightforward, once you have the plan for it. However, sometimes terraining has some requirements or limits, which plans may need to accomodate at times. But I'll spare you a tutorial on how to make terrain, and tell you instead how to go about making it not all by yourself!

• Step #1: Get your outline made. This includes a rough carving of all the main areas, approximate sizes, what they should do, etc. Nothing really goes in it, yet, but make sure it's as accurate as possible for what it's supposed to do. The future of your project will depend on your how much foresight you put into this aspect, so do your best. You'll save yourself a lot of trouble later if you get this step right early!
  
  
• Step #2: Break it up! With your outline, get your terrainers ready, give them an area to work on seperately, and let them at it. The best choice for how to divide up terrain would be to coordinate it with what part the Programmers are working on, which in turn is based on what part of the project plan is currently in priority. Certain parts of the terrain might need special priority, though, like for areas that have immediate affects on other parts of the map (like a layout for the player's control panel or a central hub area of the map where things take place, etc.). Terrainers will need to closely follow their Programmer counter-parts, keeping good communication about their requirements, and visa versa.
  
  
• Step #3: Fit it back! When a terrainer has finished fleshing out their part of the terrain, it's time to combine it with the others. This is also where things can get tricky, as there's no formal function for merging parts of terrain together with the usual Staredit-family editors. Enter SCMDraft or Starforge. SCMDraft's most recent versions come with a handy cut and paste feature for terrain (and units!), while Starforge comes with the all-powerful Brushes feature which lets you select sections of terrain of any size and shape (cut and paste works only in squares, for comparison). Using these tools, the finished terrainer must combine his product with each of the other terrainers' products seperately, as needed (like for adjacent or connected areas of terrain that are being worked on). In doing this, the terrainers get to see how their outlines fit with the other terrain pieces, as well as telling the rest of the terrainers how they need to adjust their terrain in turn for compatibility.
  
  This stage will involve a bit of trial and error, and is not meant to be for making a final draft. One important consideration with this part, also, is that when terrain is merged via. brushes or cut and paste, it loses its ISOM data in the process. That means editing it in its combined state will be difficult, except by using brush samples or individual tiles, so any changes needed should be made to the terrainer's own samples of each area, and then recombined for (re)fitting, as needed.
  
  
• Step #4: Repeat Steps 2-4 while areas still remain or until everything fits and is shaped as needed. When that is done, it's time for...
  
  
• Step #5: Bringing it together! At this point, you will need to say goodbye to your beloved ISOM and combine each section of the terrain into its final form. There shouldn't be any heavy detailing yet, but everything should fit together nicely and do what it's supposed to do.
  
  
• Step #6: Spit n' polish! Now comes the fun part. As this is not an all-important stage, this part is best handled as a 'pass the baton' fare. Terrainers can go back over each others/their own areas and add in detailing, such as doodads, terrain blends, unit effects (be sure to check with the Programmers on these!), and even some flora and fauna if appropriate. This stage should be regurgitated while waiting for the Programmers to finish their parts, which more than likely will be the ongoing stage long after the terrain has reached its final draft anyway.
  

Triggers:
Here it is. The devil of all major projects. Traditionally, due to both complexity and singularity (read: no way to divy up triggers without breaking them), this is almost doomed to be a one-man task. But with careful commenting, information records, and closely following the project's plan, delegation of this tedious task is far from impossible. Furthermore, thanks to the technologies of recent editors (SCMDraft, GUEdit, etc.), triggers can now be imported/exported via. text, and treated as 'source code' just as with traditional modding/mapping projects in non-Starcraft games.

For simplicity's sake, I'll just describe how to handle this process by refering you to SCMDraft 2's handy TrigEdit feature (GUEdit's has known issues I believe). Keep in mind, however, that due to a number of issues with SCMDraft (specifically, it's string recycling features), you will not have good backwards compatability with Staredit-family editors. If you plan on doing anything in particular with them, you had better do it before you start dividing up your triggers for this stage. Though there is a way to make backwards compatability work, frankly, it's probably just more effort than it's worth (it involves using Proedit or Uberation's string unrecycle features, but neither of those tools are altogether stable in their own right, so I would recommend avoiding having to do this.)


Anyway, let's begin:

• Step #1: Get your relative trigger plan outlined. Unlike terrain, you may even have to go as far as adding in a portion of the gameplay before you know how you're gonna organize your triggers. But organize you must! Trying out different trigger models, pass it around between other Programmers, and prototype! prototype! prototype! are all key to this aspect. And once you have an idea of how to go about organizing things:
  
  
• Step #2: Convert to code. This is where the real fun begins. You will need to be well organized to handle this part effectively. You will need 3 main systems to keep things organized:
  - Source Code: Using SCMDraft's TrigEdit, extract the trigger data to a text document and save it. Then, pick apart the triggers and seperate them into seperate text documents by category. This is where your categorical system will be put to the test! It is important to get a good system worked out as early as possible, as unlike terrain, triggers are a royal female dog to have to "fit together" if (and possibly when) they get out of alignment. Plus, having it divided up by section helps keep it conceptually easier to manage, anyway.
  
  - Commenting Conventions: You must agree on a good convention to use for commenting triggers, naming your locations, switches, etc. Before, with Staredit-family editors, you had to rely on using lots of blank comments to compress large sections, and use the topmost trigger of each section to put in the necessary trigger data. However, using the Source Code system, you can bypass formal trigger commenting altogther and encase your comments with lines preceded with // symbols (C++ style line comments). Additionally, you can add in white space to pad out distinct sections, to your discretion. And because you are dealing in text, you can even go as far as to use a formal coding IDE to help with the process. I would recommend using a program called Notepad++ for the job, as I find tabbed editing, session saving, language definitions, and the ability to zoom text (as well as the dozens of other cool features) to be especially useful for text-based trigger editing.
  
  - Information records: Due to the nature of Starcraft triggers, unlike scripting or programming languages, you can't formally "declare" things like variables or other data storage means. Instead, you have to "borrow" from a pre-existing one, such as a unit's death counters, switches, or even use in-game units to hold data somehow (if you're a Trigger Writer, you should know this stuff, though). It is vitally important to keep track of all these "borrowed" resources, especially if you plan on delegating the task of triggers among multiple people. Conflicting use of a given death counter or switch can spell hours of debugging nightmares, which is the last thing you want on top of the existing difficulty level
  
  Here are some of the things you'll need to keep a good record of:
  - Death Counters: That includes which units, which players, and what it's used for (Counting something? Using it to activate something like switch? A timer?)
  
  - Switches: The number, the name, and what it does. Note: Switches use up strings, so avoid counting on them if you can get by with Death Counters or other means. They do have their uses, though (randomization being one).
  
  - Locations: The name, size dimensions, elevation flags, its purpose(s), and its location (if used statically). You will often need to compare this information in particular with the other programmers, so be sure to keep it as up to date as possible.
  
  - A possible fourth system, and one I would highly advise, is a good backup system. Every time you make any notable changes to your triggers, be sure to back it up (a system of version numbers helps too). Also try to keep a log with each backup of what has changed since the last one, so you can backtrack.
  
  
• Step #3: Break it up! With these systems in place, it's time to get cracking! Have your programmers pick an aspect of the map's triggers to work on, such as the player's interface, the gameplay, battle systems, area triggers, story sequences, etc. Be sure not to be too broad in how these tasks are delegated, though, as you don't want to end up drinking from a fire hose by having too much going on at once. Focus on one or two main parts, get it ironed out, and move on to the next. The better you iron it out, the less you have to worry about it later when doing the next stage(s).
  
  
• Step #4: Compare information. Any time you decide to use a new Wait blocker, Death Counter, Switch, or Location, or put to use an existing Death Counter, Switch, or Location in some particular way, be sure to confirm it first with the information records of the other programmers. For locations in particular, you may want to create copies of the ones they used in your own copy of the map, in addition to your own locations (if any). This way, you not only stay in sync with the other programmers, but you can make use of their locations as well if need be!
  
  
• Step #5: Bring it together! So you finished your current section of triggers. Good job. Now you have to combine it into the main set. Here's what you do:
  - First, be sure your information records are up to date with the other members. Now's a good time to do that.
  - Once you've confirmed that, then you'll have to combine your stuff with the main copy. Be sure your records are up to date with this main copy as well.
  - In addition to individual copies of the map and code, your project should have one main copy of both map, triggers, and information seperate from the rest (probably entrusted to your Project Lead himself). Combine your code with this copy, updating the information as needed, and then test for compatibility.
  - Chances are, in spite of your best efforts at recording all the necessary information to prevent conflicts, it is likely something will still go wrong. Do not panic. This is standard debugging. You'll have to trace through your new code as well as the existing code to find the discrepancy.
  Your fellow programmers and even some testers should be able to help you with this task,
  though if the bug(s) aren't that significant you can opt to push them aside for later (or if you need additional resources before you can track them down). Just be mindful of pushing too many things aside, as it'll wind up on your Project Lead's plate in the end, and he'll probably have more than enough on it as is.
  - Once your code works reasonably well, you should run it by the testers or other programmers once or twice just to be sure. If no more major issues arise, or if you can safely ignore whatever does, then it might be ok to call it done. From there, it's on to the next task!
  
  
• Step #6: Repeat steps 3-6, and maybe even 7 every now and then, until all tasks are finished.
  
  
• Step #7: House cleaning. Once everything is done, combined together, and up and working (well enough for early beta, at least), it's time to squash those nasty leftover bugs! Chances are, between multiple programmers and a hugeass project, there'll be no shortage of them. While bug hunts can be a bit frustrating at times, just remind yourself that there's no magic at work here: Everything has a reason for doing what it does. All you gotta do is look through each possibility, and find that reason. More often than not, it's something silly that you just overlooked in a hurry. Just stick with it though, and eventually you'll figure it out. I guarantee it.
  

---

So there you have it. This isn't quite as in-depth as I could have made it out to be (if you can possibly believe that), but it should help you get the beginnings of a process established for doing team-based maps. You'll need to work out some of the process-related details for yourself, though (project plans, project stages, terrain allocation, managing Source Code systems, etc.), as well as of course having the right competencies available to pull it all off. To that, I wish you good luck, and happy mapping !

All of this was written by Tuxedo-Templar.

To Admin and Moderators: Do not take this as an attempt to get minerals, this is mainly for the purpose of helping people, please sticky this if you feel the need to.

Post has been edited 1 time(s), last time on Mar 24 2008, 11:06 pm by lil-Inferno.

This is a good guide. I don't map but this is a well written text. I shall use the format used here in my soon to come General Moddery Guide.

It's a good guide, but it would be a nightmare to go through all of that. Personally I think the best way to do a map is to have a triggerer and a terrainer who collaborate on an idea, much simpler, but not as large scale.

This article woefully out of date. This was based on ideas I had that are mostly grounded in theory instead of practice. I'm gonna need to re-write it again at some point.

I wonder if a copy of the tut me and Tux put up still exists, i think it was on how to actually finish a map.

I think that would be more helpful.

Problem with that was we couldn't agree properly on whether maps should be taken just for fun or whether they need to be taken seriously to be finished. Personally I think nearly any non-trivial map is going to cross into the 'not fun' realm at some point or another. I think the major reason people don't finish their maps is because as soon as this threshold is hit, they realize the map isn't "doing it for them" anymore, and decide to go find a cheaper source of personal gratification.

See, that's why I think that it's necessary to learn to fight past that shit. And to do that, you need to develop a way to endure the 'not fun' part; meaning you need to take it seriously to a certain degree.



A good way to be serious about maps is thinking in the mindset of making them for people to actually be playing them; not just as a source of kudos. WoodenFire got more than his map's worth of kudos just from showing off its unfinished terrain and the 'ideas' he announced for it, for instance, and I think that was part of the reason we never got to see Crescent Dyne.

That's just the wrong reason to be making maps.

Post has been edited 4 time(s), last time on Mar 25 2008, 2:23 am by Tuxedo-Templar.

So peotical

PEOTICAL!

Define wrong? What if I thought the journey was more satisfying than the destination? Crescent Dyne was one long journey. Making up bullshit and getting praise from others could have been what the Crescent Dyne supporters wanted.

Wrong in terms of:

• Kudos: No map = an eventual end to praise over the idea once people get over it. Ideas, unlike real products, do not have substance to them. The idea itself is only half the equation. Without the other half, it's only hollow suspense and anticipation. You miss out on the long-term investment if you can't put an idea into reality.
  
• Community: No map = nothing to play, learn from for other mappers, or to provide new avenues to sustain interest in UMS maps and mapping.
  
• Learning: How can you know what went right or wrong about a given idea if you don't get to see the results of it in practice?
  

Etc.

It's just plain wrong in just about every way that ought to matter.

Post has been edited 1 time(s), last time on Mar 25 2008, 2:48 am by Tuxedo-Templar.

And why are those things "wrong".

Well I guess they wouldn't be wrong if you weren't interested in Starcraft.

In which case you should probably go troll somewhere else.

Post has been edited 1 time(s), last time on Mar 25 2008, 8:40 am by Tuxedo-Templar.

How would they be wrong if one was interested in Starcraft?

Of course, I'm just being philosophical here.

Post has been edited 2 time(s), last time on Mar 25 2008, 7:01 pm by devilesk.

Team map making has its pro's and con's. Some include:

PRO'S
New ideas to your map
Expansion on your map making ability ( two people, one may be good at something that your not good at )

CON'S
Requires more then 1 person
Most people have a life outside of StarCraft and can't devote much effort and thought into map making
People can dissagree on a subject of their map

Team map making is something I would like to try. If anyone would want to try it with meh, let meh know.

I'd like to try it too. I'm usually only motivated to finish something when I know someone wants me to.
So, yeah Brontobtye, if you want to form a "team" of mapmakers, then I'd want to be part of it.

I wouldn't mind taking a stab at the good ol' team map making...

No new maps = lost interest in general. I don't see how this is something you could want if you were at all interested in SC.

This kinda falls into the duh category.

No.

I still may make a multi-user editor if people spam me with motivation.
And I still could give it an HTTP module for clients to edit in their browser (for those who have not seen it, I do have the foundation of a browser-based editor... it already does unit placement and such. )