Staredit Network

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!

---

[center]Team Mapping Process[/center]

---

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 himself, 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:
    • 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 good records 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!

Gosh, alot of reading. I must say reading is well worth it, should help out people alot. PIN IT!! MUST BE PINNED. ^_^; good job tuxedo, now soak your fingers in water to help them heal now.

Very useful for big projects indeed. Tuxedo, you wrote it all as if you were map-making in big projects all your life

Personally I think that triggers should be done by one person, because each person thinks differently, and must not force another think his way.

Well if triggers are like programming, and people can agree on conforming to coding conventions (how do you think big companies like microsoft do it?), then there's no reason you can't use conventions for triggers just the same.

It's about weighing out whether you want to do all the work of a large project yourself, or delegate the tasks to actually get it done. Thus far, I think the biggest problem with a lot of projects nowdays is there's too little ability to get them done, due to lack of a good way to divy up the tasks.




I outlined some good ways to use SCMDraft and Starforge to handle terrain and trigger import/export, which is really the last major obstacle to team mapping projects when you think about it. Imagine what it would be like to actually see people finish their maps for a change?

All I can say is.... where the crap was this when the SEN Mapping Team was still around?

Start a new one?


We got those mapping contests going on with decent participation, so clearly there's still mappers lurking around. It'd be nice to see some people's maps that have promise that are just lying around unfinished get completed for a change.

Well done and well written.

You could add in that good examples of team projects are...
Honor The Fallen, Crescent Dyne, Ect...

Actually I was meaning to imply it could be used for projects like those. I don't know about Moogle's map, but with yours I know it would help to be able to divy up the trigger load. As I mentioned, simply having the player and battle systems in place is only a fraction of the real battle (if Rush was anything to go by, at least).

I certainly wished I had some help when I was working on Rush, as its very limiting doing large projects like that by yourself. There's no way in hell ordinary mappers could reliably accomplish that kind of stuff on their own, besides.

I humbly disagree with this section. Any team project, in my experience, needs - and can function with - only one type of content maker, called a 'Designer'. A skilled designer needs both terraining and triggering skills to be truly useful. When I worked with Era Productions for Age of Empires II, that's what we ended up doing.

Also, large teams almost never function well. Most of EP's projects only used a fraction of the total membership of the team.

Well, I'm speechless. Amazing. Well Written. No grammar problems. Correct. I'm at a loss to write complete sentences and.

Lol, Wooden, although crescent dyne maybe is a good team project you were too un-humble to mention it. But what do I know, I'm just a newby compared to you.

And Moose, entirely off-topic, but I have a hole in my ceiling that looks exactly like the one in the link in your sig.

I mentioned you could cover multiple roles with a single person. But depending on the scale and complexity of your project, that might not be a good idea (Rush is a good example... in spite of the fact that I somehow actually did manage to finish it... after a year and a half, anyway )

Delegations may not always be pleasant or desirable (or may even be both just the same!), but they are necessary if you mean to reliably produce things. Working alone reaches its limits fast.


Believe me, I should know. And here I'm the one who'se done more within my individual limits than most mapping clans as a whole can make claim to. And I've still yet to make a perfect hit, in spite of all that.

While I don't deny that work needs to be delegated, I have found that dividing things up between triggerer/storywriter/terrainer/etc., is not an effective way to do things. Usually, any useful designer has something unique to bring to all aspects of the map.

There are exceptions, of course. Terry, a member of Era, had a great eye for terrain, but he he couldn't trigger for crap. However, in the end, he actually came at the end of the project. While it doesn't look nice, the skeletal maps created by trigger experts are usually a good place to start 'real' work.

How you handle roles is based on the project. Most SC maps don't need static role setting for project members, but roles still need to be covered by someone, and having it kept stationary helps keep organized projects. It's nice to get ideas from people during the project, but that's also what the planning stages are for. You generally tend away from changing plans the further you get into the project... if at all possible.

And yes, skeletal maps, or the map outline, are something you're gonna need before being able to grasp the full direction of your plan. Prototyping seperately any ideas you might be considering is also useful (very useful, in fact). You want to keep the trial and error away from the actual map as much as possible, and into a controlled environment.

Well, that's what team hierarchy is for. One person has got to be the Lead, whose ideas and thoughts take precedence. To the others, if they disagree, it's up to the lead to show them whose boss.

I've tried democratic teams before and they just don't work. Not for serious projects, or the later stages of one, at least.

Definately seconding the bit about democratic teams not working. Era Productions only becacme effecient when it became autocratic, with a well-defined hierarchy.

I work almost solely around team projects (usually just only with RIVE and I). We make a good comedy series called ZvsR (#4 coming out soon, check it out )
But I also make a few of my own too. I started Duck Hunt a while back, I think its may have even been a year ago, but its still not done. Mainly all the detail work and random trigs gimme headaches, then I don't feel like working on it.

Anyway, RIVE and I are total lazy asses, neither of us actually care to make maps that quickly (unless we're really bored) But even with our total lazy-ness we together still get them done pretty quickly for just two people working on triggers/text/storywriting/script (erhm.. i mean quotes of people from in channels.. pssh we dont WRITE the script what u talkin bout ) Although we don't really work much on the terraining other than just reusing the same terrain and just add a few details and such.

We have created a pretty efficient system our selves, where one of us works with the map while the other mainly gives input, unless say RIVE smurfs it up..then I DL it from him, fix it, and then he DLs it from me, and continues on. Then for the next vers/episode the roles are reversed. Although it's just not the quickest way to produce maps, I believe its faster than your process because too much time is wasted deligating.

A solo/duo process vs. team process is like that of a high end PC vs. a super computer: Sure, you could say the PC could do a given computation faster than the super computer would at a given time (as it would be slowed down by the process of dividing up the problem between its many processors). But what about two computations a time? Or 10? Or 1 million? That's where the super computer wins.

That's roughly why you would want to use teams. Though admittedly, teams are better suited for larger projects where dividing up tasks to eleviate the work of an individual outweighs the added complexity of managing those multiple moving parts at once.

I agree, we need a super computer.

The biggest hinderence in team mapping, is the ability to get people to follow a set of orders, I'm sure many of us think we can. But when we get right down to it, will you spend much effort on a project that is the vision of someone else?
The key here is to find aproject manager who shares a vision with the people working on the map. If the members working on it do not share a vision of a completed project, it will never become a reality.

I suppose I'm just saying that is one skill all members working on a project must have, is the ability to work with others. (Seems like a given, but meh, I had to mention it.)

You don't need all members to have the same vision, either. In fact, it's best to leave the 'vision' up to the leader, or there's bound to be conflict.

Or at the very least, the leader's 'vision' should have precedence. There's no harm in the subordinates wanting their own thing out of the project, as long as it doesn't confuse it in the end. Leaders should be open with their 'vision', as well, as being too rigid can mean excluding others and/or better ideas. But at the same time, weighing between exclusion and actually getting the project done is important just the same.

You've out done yourself Tuxedo Templar, what i really loved about this essay is what kind of things it inspired me to do, especially with communication.

before i say anything i have to tell you that you should definately put this on the new wiki

for communication, i really loved the source code...I had never thought of that!! but with team mapping you need communication, this is why it is a good idea to make a clan or be in one. exchanging through websites, IM, and even mail through a stealthbot. i just thought of it giving each other trigger source code through stealthbot mail!!

but through this essay one of the most important things is the leader, he/she must have knownledge of everything that a map needs (in this case, the person who read your essay ) he must have a skill in everything (terrain, triggers, storyline, ect.) but what a leader also needs is the ability to access sounds/editors in a fast and easy way, to get it to the person in minutes(which also requires communication). but that's pretty easy because tuxedo templar himself put all the Rush needs right on his website. Thank you.

you must have people you trust and you know will get the job done with flying colors, in this case a clan member of some sort.

the only thing i can say is your insane Tuxedo Templar. Oh and i love your Tiger Tuxlar also!!!

Glad you liked it.
Maybe, but I might redo a few portions of it first. Mainly the team roles and the terraining process. I've since thought of a few more roles that could be delegated, as well as a better way to handle terrain division that cleans up the process a bit.

Woah....so much reading. Thanks though, this really helps all of us! (i hope).