Alright, my previous article was a bunch of theoretical garbledegook. Here's what I've learned since then. [SIZE=18][B]Chapter 1:[/B] Tools[/SIZE] [LINE] Here's your checklist:[list] [*][B]Tortoise SVN[/B] [*][B]Notepad++[/B] [*][B]SCMDraft 2[/B] [*][b]Information tracking system[/b] [i](I actually use Microsoft FrontPage for this, of all things :P)[/i] [*][B]A Messenger Program[/B] [I](MSN, Yahoo, etc.)[/I] [*][B]A discussion [s]thread[/s] forum[/B] [I](I recommend phpBB from only my limited experience; others ought to work too)[/I] [*][b]People to help with your map[/b] [*][b]Person in charge (Project Lead)[/b] [/list] That's it, really. I'll leave it to you to find each of these on your own. Consider that the exam for this chapter that'll be the minimum you'll need to go on to the next. :P That includes also learning how to use these tools, which is also outside the scope of this article (they're explained much better elsewhere, anyway). A few things first, though: [b]Forums:[/b] For any decent-sized map project that justifies multiple people helping with it (that is, not your ordinary Bound or Madness crap), a forum is a [b]must[/b]. I can't say that enough times. I've tried squashing even minimal team-based projects into just single threads. Terrible. Never works. Not for me, at least. For any discussions you plan to be going into depth about, or just for information you need to keep track of, you [i]need[/i] at least the equivalent of your own discussion board. I offer subforums at [url=http://www.warbox.us/viewforum.php?f=19&sid=5565ed7b9ece5790643a8c52432567f7]Warbox[/url] to anyone who asks for any project or personal use, for instance. [b]Messenger Program:[/b] Also needed: A messenger program. This ought to be obvious: You can have real-time discussions with project members rather than the staggered ones in the forums; much better at addressing specific nitty gritties and for brainstorming. To understand when to use messenger versus a forum:[list] [*][B]Messenger Chat:[/B] Low IQ stuff such as brainstorming, minor details, getting random thoughts off your chest, debates and other drama. [*][b]Forum Posts:[/b] Information gathered from brainstorming sessions (be sure to keep your chat logs to do this!), elaborate discussions about pros and cons of available options, "formal" communications (such as the state of your progress, new developments/ideas, etc.), and anything you want to communicate to other members whenever they're not immediately available to message to. [/list] [b]Information Tracking:[/b] Here's the important one. Your forum is used for your general project information, but you'd do well to use a separate source for your more specific project details. For ANY team project, you'll want to keep a detailed (and accurate) reference for:[list] [*]How each unit is used for each player. Include as much information about the unit as you can, as well (its stats and such). [*]Locations and how they're being used in general. Mentioning size and elevation flags is helpful. [*]Counters and switches. Be as detailed as you can in describing these, including the player that owns them (for Counters), what each value or range of values correspond to what use by the triggers, etc. [*]Other information relevant to the map. Things such as the cost of items in a shop, the amount of mana for spells, etc. [*]Outline of the map and everything that goes in it. You don't need to be super detailed; the specifics get filled into the other information categories as you go. This is just the most current state of your project's plan. You'll want to keep this up to date with changes and new ideas as much as possible. [*]Current to-do list for each member in your project. This is built based on the project's outline by picking the pieces of the map and delegating them to your team members as appropriate. I'll talk about this in the next chapter. [/list] Again, I use FrontPage for this because I like having my information in frames (and I DON'T recommend inline frames anymore, by the way) to view different parts all at once. You may use whatever method works for you, though. Even regular Notepad may be fine. [b]SVN:[/b] Be SURE you've figured out how to work SVN with your team in order to manage and share project resources. This vital program is the key to enabling powerful team development to work with just a single map between multiple people. Without it, you're stuck manually passing the map back and forth and stumbling with your own clumsy version control systems you have in place (if you've even bothered to arrange any with your team). SVN is designed to allievate that annoyance by handling version control in a centralized, organized way. It comes complete with features for backtracking, resolving conflicts between each persons' versions (such as, if you make a change to the map, but someone made one before you got your copy of it... that's a conflict), and logging information on your progress as you go (which you should ALWAYS use with as much detail as you can; even for trivial changes to the map). [SIZE=18][B]Chapter 2:[/B] Setup[/SIZE] [LINE] Ok. You have the tools installed. And you have a forum setup, and a few guys to help with your map. Now to get started. [b]The Outline[/b] First thing you're gonna want for your project is the idea. You usually brainstorm this first, but you may already have something in mind. Doesn't matter. I'll assume you have one. What to do with it, though, is to start mapping it out on your information tracker. You'll want to use a forum thread or a chat (or both) to work this out between all of your team's members. You'll likely be amending this outline regularly throughout your project's development, so never just write it up and expect to go "Ah! Done!". It helps to go through a few drafts of your outline before you begin, too (the more planning you can get out of the way beforehand, the better). [b]Map Setup[/b] You got your idea outlined. Now to get your map set up. Pick your tileset, map size (be sure to think on this carefully), player settings, forces, etc. Then you'll want to prototype an early sketch of the terrain. Nothing detailed here. One person (your project leader) does all this as best they can from the outline. They also need to set up the basic alliance, vision, unit placement, etc. triggers to get things started. Lastly, go into SCMDraft 2's Trigedit (text-based), and copy the text triggers into their own text files for use with Notepad++ (I'll explain a good way to handle trigger development with this tool in the next chapter). [b]Divide n' Conquer[/b] Finally, with the map set up, it's time to start delegating. Firstly, get your SVN server running with the map on it so people can Checkout their own copies of it. Then, have a look through your outline, and start breaking off pieces of it from the most logical beginning you can think of and put those pieces into each members' own to-do lists. Be sure everyone is clear on their assigned jobs. I'll discuss more in the next chapter on how to keep organized with your project lead. With all of this, you should be ready to go. On to the development! [SIZE=18][B]Chapter 3:[/B] Development[/SIZE] [LINE] [b]The Cycle[/b] When doing maps solo, almost any approach to tackling it can work out. Almost. But with doing a team project, you need to be a bit more organized than you probably would be normally with a solo. What I use for my projects (solo and otherwise) is a cyclic approach. For a team project, it might work as follows:[list] [*]Discuss current progress/brainstorm new ideas in chat. [*]Gather discussed information together once conclusions or dead ends have been reached. Continue with progress on the project with your conclusions. Branch off into sub-processes to address dead ends. Use a similar cycle for your branches as you would for the main one until you can conclude on them (and thus bring them back into the main 'trunk'). SVN has good support for doing things like this. [*]Plug n' chug. You already know what you need to do. Just get at it. [*]Get stuff done up to a safe point. Make sure your team knows what this is so everyone stays on the same page. By safe, I mean a point as far as you feel you ought to go before needing to test out the new changes. A good policy is to make your safe points fairly close together. But if you're in a rush, you could try spacing them out. Just note that you might stand to regret it if you add something that doesn't work and go too far building off of it before detecting that it didn't work to begin with (equals a bigger mess with debugging later). [*]So you're at your 'safe' point. Now you need to test your new changes and additions. If everything works well, go ahead and merge your changes with everyone else's (methods for doing this will be outlined later). If not, try to debug as much as you can until it is at least acceptable for merging. [*]Inevitably, with mergers, oversights, etc., you're going to have issues crop up. Here's the best way to handle issues:[list] [*]Firstly, realize you don't always need to handle issues right away. Some can be put off for later. Others, perhaps not so much. Write a list of all your issues and organize it by priority. [*]Pick the issues you need to do before being able to continue and do those. Push the less important ones off for later. Remember this is about getting shit done: Not dwelling on minutia. [*]If needed, start a new project branch to handle these issues separately before merging it back in. But I'd suggest making sure everyone is on the same page as you as much possible, so try to work out issues together if you can. They sometimes like to come back to haunt you if you think you can ignore them and do them yourself. [/list] [*]Repeat from the top. [/list] This list is the general cycle you'll want to follow. That's not to say it's the ONLY way to do it, but it's the way I'd recommend. [b]Lockdown[/b] You will also want to divide up your project into major 'chapters' while applying the above cycle to your development for each 'chapter'. The point of this is so that, every now and then, everyone can come together then as the project arrives at significant milestones in its development. Like when moving out of pre-alpha to alpha, or alpha to beta, etc. (or just whenever you feel like it :P). For these steps, you go into a mode I like to call Lockdown Mode:[list] [*]Firstly, everyone gets their stuff merged into the branch. No exceptions. [*]The project lead controls the map now. No one else is permitted to add or change shit except by asking him to do it. [*]Any last important issues are resolved now. All the rest gets pushed off until later. [*]Testing commences. All members take the map and start abusing the heck out of it in-game. If anything major breaks, the project lead decides whether to break the lockdown to address it, or to try to fix it themselves. [*]If not, the lockdown stays in effect until everyone is sure there's no more problems. [/list] With the lockdown, the map is brought to a state that's suitable to mark the completion of a chapter of development. These milestones are important because they act as reference points for further development so that everyone can stay on the same page. They're also useful testing out the map, even if it's incomplete, to get as much information as possible without worrying about the little things that keep getting changed with the developing version. This is also obviously what you'll want to do for the official release, except perhaps more thoroughly (more testing and QA, I mean). [b]Project Lead's Job[/b] [I]<fill in later>[/I] [b]Terrain[/b] [b]Triggers[/b] [SIZE=18][B]Chapter 4:[/B] Release[/SIZE] [LINE] [b]Beta Testing[/b] [I]<fill in later>[/I] [b]Locking Down[/b] [I]<fill in later>[/I] [b]Release![/b] [I]<fill in later>[/I] Still writing this. Will edit later. Gotta go do something now, though. brb

Alright, my previous article was a bunch of theoretical garbledegook. Here's what I've learned since then.




Chapter 1: Tools

---

Here's your checklist:

• Tortoise SVN
  
• Notepad++
  
• SCMDraft 2
  
• Information tracking system (I actually use Microsoft FrontPage for this, of all things )
  
• A Messenger Program (MSN, Yahoo, etc.)
  
• A discussion thread forum (I recommend phpBB from only my limited experience; others ought to work too)
  
• People to help with your map
  
• Person in charge (Project Lead)
  

That's it, really. I'll leave it to you to find each of these on your own. Consider that the exam for this chapter that'll be the minimum you'll need to go on to the next. That includes also learning how to use these tools, which is also outside the scope of this article (they're explained much better elsewhere, anyway).

A few things first, though:


Forums:
For any decent-sized map project that justifies multiple people helping with it (that is, not your ordinary Bound or Madness crap), a forum is a must. I can't say that enough times. I've tried squashing even minimal team-based projects into just single threads. Terrible. Never works. Not for me, at least. For any discussions you plan to be going into depth about, or just for information you need to keep track of, you need at least the equivalent of your own discussion board. I offer subforums at Warbox to anyone who asks for any project or personal use, for instance.


Messenger Program:
Also needed: A messenger program. This ought to be obvious: You can have real-time discussions with project members rather than the staggered ones in the forums; much better at addressing specific nitty gritties and for brainstorming.

To understand when to use messenger versus a forum:

• Messenger Chat: Low IQ stuff such as brainstorming, minor details, getting random thoughts off your chest, debates and other drama.
  
• Forum Posts: Information gathered from brainstorming sessions (be sure to keep your chat logs to do this!), elaborate discussions about pros and cons of available options, "formal" communications (such as the state of your progress, new developments/ideas, etc.), and anything you want to communicate to other members whenever they're not immediately available to message to.
  

Information Tracking:
Here's the important one. Your forum is used for your general project information, but you'd do well to use a separate source for your more specific project details. For ANY team project, you'll want to keep a detailed (and accurate) reference for:

• How each unit is used for each player. Include as much information about the unit as you can, as well (its stats and such).
  
• Locations and how they're being used in general. Mentioning size and elevation flags is helpful.
  
• Counters and switches. Be as detailed as you can in describing these, including the player that owns them (for Counters), what each value or range of values correspond to what use by the triggers, etc.
  
• Other information relevant to the map. Things such as the cost of items in a shop, the amount of mana for spells, etc.
  
• Outline of the map and everything that goes in it. You don't need to be super detailed; the specifics get filled into the other information categories as you go. This is just the most current state of your project's plan. You'll want to keep this up to date with changes and new ideas as much as possible.
  
• Current to-do list for each member in your project. This is built based on the project's outline by picking the pieces of the map and delegating them to your team members as appropriate. I'll talk about this in the next chapter.
  

Again, I use FrontPage for this because I like having my information in frames (and I DON'T recommend inline frames anymore, by the way) to view different parts all at once. You may use whatever method works for you, though. Even regular Notepad may be fine.


SVN:
Be SURE you've figured out how to work SVN with your team in order to manage and share project resources. This vital program is the key to enabling powerful team development to work with just a single map between multiple people. Without it, you're stuck manually passing the map back and forth and stumbling with your own clumsy version control systems you have in place (if you've even bothered to arrange any with your team). SVN is designed to allievate that annoyance by handling version control in a centralized, organized way. It comes complete with features for backtracking, resolving conflicts between each persons' versions (such as, if you make a change to the map, but someone made one before you got your copy of it... that's a conflict), and logging information on your progress as you go (which you should ALWAYS use with as much detail as you can; even for trivial changes to the map).





Chapter 2: Setup

---

Ok. You have the tools installed. And you have a forum setup, and a few guys to help with your map. Now to get started.

The Outline
First thing you're gonna want for your project is the idea. You usually brainstorm this first, but you may already have something in mind. Doesn't matter. I'll assume you have one. What to do with it, though, is to start mapping it out on your information tracker. You'll want to use a forum thread or a chat (or both) to work this out between all of your team's members. You'll likely be amending this outline regularly throughout your project's development, so never just write it up and expect to go "Ah! Done!". It helps to go through a few drafts of your outline before you begin, too (the more planning you can get out of the way beforehand, the better).


Map Setup
You got your idea outlined. Now to get your map set up. Pick your tileset, map size (be sure to think on this carefully), player settings, forces, etc. Then you'll want to prototype an early sketch of the terrain. Nothing detailed here. One person (your project leader) does all this as best they can from the outline. They also need to set up the basic alliance, vision, unit placement, etc. triggers to get things started. Lastly, go into SCMDraft 2's Trigedit (text-based), and copy the text triggers into their own text files for use with Notepad++ (I'll explain a good way to handle trigger development with this tool in the next chapter).


Divide n' Conquer
Finally, with the map set up, it's time to start delegating. Firstly, get your SVN server running with the map on it so people can Checkout their own copies of it. Then, have a look through your outline, and start breaking off pieces of it from the most logical beginning you can think of and put those pieces into each members' own to-do lists. Be sure everyone is clear on their assigned jobs. I'll discuss more in the next chapter on how to keep organized with your project lead.

With all of this, you should be ready to go. On to the development!





Chapter 3: Development

---

The Cycle
When doing maps solo, almost any approach to tackling it can work out. Almost. But with doing a team project, you need to be a bit more organized than you probably would be normally with a solo.

What I use for my projects (solo and otherwise) is a cyclic approach. For a team project, it might work as follows:

• Discuss current progress/brainstorm new ideas in chat.
  
• Gather discussed information together once conclusions or dead ends have been reached. Continue with progress on the project with your conclusions. Branch off into sub-processes to address dead ends. Use a similar cycle for your branches as you would for the main one until you can conclude on them (and thus bring them back into the main 'trunk'). SVN has good support for doing things like this.
  
• Plug n' chug. You already know what you need to do. Just get at it.
  
• Get stuff done up to a safe point. Make sure your team knows what this is so everyone stays on the same page. By safe, I mean a point as far as you feel you ought to go before needing to test out the new changes. A good policy is to make your safe points fairly close together. But if you're in a rush, you could try spacing them out. Just note that you might stand to regret it if you add something that doesn't work and go too far building off of it before detecting that it didn't work to begin with (equals a bigger mess with debugging later).
  
• So you're at your 'safe' point. Now you need to test your new changes and additions. If everything works well, go ahead and merge your changes with everyone else's (methods for doing this will be outlined later). If not, try to debug as much as you can until it is at least acceptable for merging.
  
• Inevitably, with mergers, oversights, etc., you're going to have issues crop up. Here's the best way to handle issues:
  
  
  • Firstly, realize you don't always need to handle issues right away. Some can be put off for later. Others, perhaps not so much. Write a list of all your issues and organize it by priority.
    
  • Pick the issues you need to do before being able to continue and do those. Push the less important ones off for later. Remember this is about getting shit done: Not dwelling on minutia.
    
  • If needed, start a new project branch to handle these issues separately before merging it back in. But I'd suggest making sure everyone is on the same page as you as much possible, so try to work out issues together if you can. They sometimes like to come back to haunt you if you think you can ignore them and do them yourself.
    
  
  
• Repeat from the top.
  

This list is the general cycle you'll want to follow. That's not to say it's the ONLY way to do it, but it's the way I'd recommend.


Lockdown
You will also want to divide up your project into major 'chapters' while applying the above cycle to your development for each 'chapter'. The point of this is so that, every now and then, everyone can come together then as the project arrives at significant milestones in its development. Like when moving out of pre-alpha to alpha, or alpha to beta, etc. (or just whenever you feel like it ). For these steps, you go into a mode I like to call Lockdown Mode:

• Firstly, everyone gets their stuff merged into the branch. No exceptions.
  
• The project lead controls the map now. No one else is permitted to add or change shit except by asking him to do it.
  
• Any last important issues are resolved now. All the rest gets pushed off until later.
  
• Testing commences. All members take the map and start abusing the heck out of it in-game. If anything major breaks, the project lead decides whether to break the lockdown to address it, or to try to fix it themselves.
  
• If not, the lockdown stays in effect until everyone is sure there's no more problems.
  

With the lockdown, the map is brought to a state that's suitable to mark the completion of a chapter of development. These milestones are important because they act as reference points for further development so that everyone can stay on the same page. They're also useful testing out the map, even if it's incomplete, to get as much information as possible without worrying about the little things that keep getting changed with the developing version.

This is also obviously what you'll want to do for the official release, except perhaps more thoroughly (more testing and QA, I mean).


Project Lead's Job
<fill in later>


Terrain


Triggers





Chapter 4: Release

---

Beta Testing
<fill in later>


Locking Down
<fill in later>


Release!
<fill in later>





Still writing this. Will edit later. Gotta go do something now, though. brb

Ad-hoc method(1-3 person):[B] None of this is canon, but it does help things go more quickly and smoothly.[/B] First: Outline gameplay genre/framework, Declare terrain requirements for planned trigger systems. <Enter prototype stage> Terrain creates map file and goes to town on terrain with input from balance department, don't worry about getting the map to trigger people yet. Until Terrain has ceded control of map, trigger people need to work in generation code and text, all major systems can be done this way, you don't need access to the map file until you are ready to start on stores and unit placement. Triggers take custody of map file, implement their work. <enter alpha, debug triggers> Balance..... should be by someone good at both melee AND closest related UMS genre. This team member must know damage types and micro techniques extremely well. <enter private beta, continue balance> Release publicly after about a week of private beta testing. [b]Notes:[/b] If you are passing maps over bnet, use the following filename format: [acronym] [prerelease stage] [date][initial of last modifier][daily subversion].[extension] for example: "BCF Beta 4-28-08A.scx" if passed and edited might be renamed: "BCF Beta 4-28-08D1.scx" then "BCF Beta 4-28-08A2.scx" etc. so even if you have multiple people work on a map in 1 day, you know which came last. When releasing a map, use this format: [full map name] [version number].[extension] EG: "BattleCraft Factions 1.34.scx" The full map name should be in the map title, preferably accompanied by version number. If that is impossible, put version number in one of the force names.

Ad-hoc method(1-3 person):
None of this is canon, but it does help things go more quickly and smoothly.

First:
Outline gameplay genre/framework, Declare terrain requirements for planned trigger systems.


<Enter prototype stage>


Terrain creates map file and goes to town on terrain with input from balance department, don't worry about getting the map to trigger people yet.

Until Terrain has ceded control of map, trigger people need to work in generation code and text, all major systems can be done this way, you don't need access to the map file until you are ready to start on stores and unit placement.

Triggers take custody of map file, implement their work.

<enter alpha, debug triggers>

Balance..... should be by someone good at both melee AND closest related UMS genre. This team member must know damage types and micro techniques extremely well.


<enter private beta, continue balance>


Release publicly after about a week of private beta testing.


Notes:
If you are passing maps over bnet, use the following filename format: [acronym] [prerelease stage] [date][initial of last modifier][daily subversion].[extension]

for example: "BCF Beta 4-28-08A.scx" if passed and edited might be renamed: "BCF Beta 4-28-08D1.scx" then "BCF Beta 4-28-08A2.scx" etc. so even if you have multiple people work on a map in 1 day, you know which came last.

When releasing a map, use this format: [full map name] [version number].[extension] EG: "BattleCraft Factions 1.34.scx" The full map name should be in the map title, preferably accompanied by version number. If that is impossible, put version number in one of the force names.

[quote=AntiSleep]Terrain creates map file and goes to town on terrain with input from balance department, don't worry about getting the map to trigger people yet. Until Terrain has ceded control of map, trigger people need to work in generation code and text, all major systems can be done this way, you don't need access to the map file until you are ready to start on stores and unit placement. Triggers take custody of map file, implement their work.[/quote]You do need locations to do triggers, though. Terrain often dictates what locations you'll be using (some exceptions). Therefore I recommend not starting on triggers until a basic, ugly draft of the terrain is settled upon. That is, unless you [i]know[/i] the nature of your locations already. My experience is that I usually don't, though, but it really depends on the map.

Quote from AntiSleep

Terrain creates map file and goes to town on terrain with input from balance department, don't worry about getting the map to trigger people yet.

Until Terrain has ceded control of map, trigger people need to work in generation code and text, all major systems can be done this way, you don't need access to the map file until you are ready to start on stores and unit placement.

Triggers take custody of map file, implement their work.

You do need locations to do triggers, though. Terrain often dictates what locations you'll be using (some exceptions). Therefore I recommend not starting on triggers until a basic, ugly draft of the terrain is settled upon.

That is, unless you know the nature of your locations already. My experience is that I usually don't, though, but it really depends on the map.

Why can't you name your locations as needed in text triggers, making a list of locations you will need to create before inserting the triggers? Obviously this isn't efficient for stores, or other locations that are needed by 1-2 triggers, but any big system is going to be faster to implement if you plan that way. Many trigger systems don't require locations at all, so you can easily get those out of the way.

Why can't you name your locations as needed in text triggers, making a list of locations you will need to create before inserting the triggers? Obviously this isn't efficient for stores, or other locations that are needed by 1-2 triggers, but any big system is going to be faster to implement if you plan that way. Many trigger systems don't require locations at all, so you can easily get those out of the way.

With AG, almost none of the trigger systems I've made did not depend on locations in one way or another. While some of them [I]could[/I] have be amended later to include locations as needed, I have ran into points where I have needed to decide on locations (and thus terrain layout) before I could continue. For example. In AG, the main arena is not a perfect rectangular shape. Plus the shop and hangar areas overlap into its relative rectangular zone. I felt this design was the best approach for what I was intending to accomplish. But, because of it, I couldn't simply make an 'Anywhere' location to fit it; I had to make [i]four[/i] separate locations to accommodate its shape. This was an important decision to establish early on, which I didn't do as soon as I'd liked. It cost me quite a while with both rewriting triggers and debugging issues before I managed to recover from that oversight. That's kinda the reason I think you need to have a good idea on your layout and key locations before getting too far into your triggers.

With AG, almost none of the trigger systems I've made did not depend on locations in one way or another. While some of them could have be amended later to include locations as needed, I have ran into points where I have needed to decide on locations (and thus terrain layout) before I could continue.

For example. In AG, the main arena is not a perfect rectangular shape. Plus the shop and hangar areas overlap into its relative rectangular zone. I felt this design was the best approach for what I was intending to accomplish. But, because of it, I couldn't simply make an 'Anywhere' location to fit it; I had to make four separate locations to accommodate its shape. This was an important decision to establish early on, which I didn't do as soon as I'd liked. It cost me quite a while with both rewriting triggers and debugging issues before I managed to recover from that oversight.


That's kinda the reason I think you need to have a good idea on your layout and key locations before getting too far into your triggers.

True, but that is a lot easier to change if you write all your triggers in a generation script, .

True, but that is a lot easier to change if you write all your triggers in a generation script, .