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
threadforum (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.
- 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.
- 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.
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
Post has been edited 6 time(s), last time on Mar 27 2008, 11:04 pm by Tuxedo-Templar.
None.