hide results

    Mapmaker's Guide by Renolan

    Updated: 06/26/02 | Search Guide | Bookmark Guide

    Starcraft Mapmaker's Guide
    by Renolan
    History of this FAQ:
    8/06/01 Initial version.
    8/13/01 Reorganized a few of the sections so that they are slightly
            more readable, added a few new bits here and there.
    6/26/02 Added a few more sections
      Part I: Frequently asked questions
      Part II: Tips and aesthetics
      Part III: Type-specific
      Part IV: Special utilities
    This is a guide to using the starcraft campaign editor to make your own
    maps. It covers how to use it in order to make a map, but it also
    discusses what it is that makes a 'good' map (yes, I know that's a
    loaded and opinionated word, but bear with me =P). I've tried to avoid
    the technical stuff because MPeyrard's FAQ already covers that pretty
    well (and more thoroughly than I would have the energy to do besides)
    except for some specific questions that seem to come up a lot. This
    focuses more on how to make the map look interesting, not how to make
    the map functional (if that makes any sense).
    Finally, if there is anything in this guide that annoys you, it is
    probably an opinion, and as such is not worth getting annoyed about,
    since very few (if any) people will care if you do... although there
    are definitely some exceptions to that rule.
    Part I: Frequently asked questions
    How do I use different tilesets? When the editor starts it always gives
    me the badlands terrain.
    To use different terrains, or to resize the map, go to new, and then
    select the size and tileset that you want.
    Why is it that whenever I tell it to place a certain terrain, it puts
    some other terrain around it?
    Some types of terrain require certain other types - for example, on the
    badlands tileset, the structure terrain type can only be placed over
    asphalt. If you try to place it over ordinary dirt, the editor will
    create a section of asphalt, and put the structure over it. There's no
    way to get around it (except maybe with a special utility). That's just
    the way it goes.
    Why can't I place structures?
    Different types of terrain may or may not be built on. The entire
    installation tileset is unbuildable - no structures are allowed unless
    you are using a special campaign editor. (more on that in the special
    utilities section)
    How do I change a unit's starting health, shields, and stuff like that?
    To edit the properties of units - % of HP, energy, whether they are
    invincible, etc. - right click to turn the unit into a cursor, then 
    double click on the unit(s) that you want to edit. You can use shift
    and/or dragging and drawing rectangles to select multiple units. You
    can also delete units by selecting them and then clicking on the 'x' on
    the toolbar, selecting clear from Edit, or simply by pressing delete.
    Properties of units can also be edited using triggers - any of the
    'modify' type triggers will work.
    What is the purpose of the starting location?
    Starting location is what part of the map the player first sees when
    the game starts. In a non-use map settings game, it is also where the
    player's command center/hatchery/nexus starts. Random start location
    means that the starting location for each player within a force is
    picked randomly from among all the players' starting locations within
    that force.
    Why don't any of the units I place show up?
    This is probably because you are not playing in use map settings mode.
    The only units that get carried over into normal melee, free for all,
    top vs. bottom, or whatever, are mineral fields, vespene geysers,
    critters, and starting locations.
    How do I get doors and floor/wall traps to work in installation maps?
    Use the 'set doodad state' trigger, and put the location around the
    doors/traps you want to affect. An enabled door is one that is closed,
    and a disabled door is one that is open. A left door is one that starts
    low on the left and slopes upward to the right. A right door is one
    that slopes upward to the left. A pit door is one that is over
    substructure, and part of the substructure doodad set. An upper level
    door is one that is over a normal floor, and part of the wall doodad
    set. Enabled guns and flamethrowers attack anything hostile, disabled
    ones don't.
    I made a map with a computer player in it, but it doesn't do anything.
    How do I make it gather/build?
    If you're making a map with computer towns, use AI scripts. This is
    one of the most common mistakes. In order for the computer to gather
    or build, you have to define the location for its base first. It
    doesn't have to encompass the whole base, just the hatchery/nexus/
    command center and maybe a few paces around it. Then, use the 
    'run AI script at location' trigger, select that location, and then the
    script that you want. Obviously, you want it to be the same race as the
    computer player in question. If you want it to use brood war units, the
    script has to have 'expansion' in its name. Expansion here does NOT
    mean the script for an expansion into a second resource node - it means
    the brood war expansion pack. If you want it to gather but not build
    (like in an expansion, gameplay terms) then make sure the script has
    the word 'town' in it. Using the 'town' script on a main base will mean
    the computer will never build anything, so don't. Wonderfully intuitive,
    isn't it?
    How does elevation for locations work?
    Basically, anything that can block line of sight for a ground unit is
    considered an elevation change. That means dirt to high dirt on the
    twilight tileset is an elevation change, while sunken ground to crushed
    rock is not. The lowest elevation possible on a map is considered low
    elevation (surprise), and it goes up through mid to high from there.
    When I start a map I made using map settings in a multiplayer game, the
    briefing displays but it acts like I hit start and ends right away.
    Actions in a trigger inside a briefing or the game itself happen right
    after another. You need to put in 'wait' triggers to make it so only
    one thing executes at a time.
    Why don't the computers attack each other when I put them in separate
    Computers are allied by default in all game types except free for all.
    You have to use the 'set ally status' trigger to make them enemies.
    What's with 'modify resource amount' and 'modify hangar count'?
    Resource amount is used for mineral fields and vespene geysers only, it
    sets the resources remaining in them. You cannot set it to 0 and
    eliminate it, but you can set it to 1 and it will give about the same
    effect. You can also you it to make sure certain resource patches never
    run out. Hangar count is for carriers and reavers only, it modifies the
    number of interceptors/scarabs it has in storage.
    What is the 'in transit' property?
    Check this box on a terran building's properties to make it start the
    scenario flying.
    Why do my triggers only execute once?
    Triggers are by default one-time only happenings. If you want the map
    to continue checking the trigger, you will have to include 'preserve
    trigger' in the actions part.
    What are switches?
    I've seen this question asked *a lot*, and part of the reason for that
    is that it's hard to explain to someone who's never used them. I'll try
    to go in order of decreasing coherence, so you can just stop whenever
    you want to and be no worse off for missing anything.
    A switch can have one of two states: On (set) or off (cleared). Think of
    it as a light switch. 'Toggling' a switch flips it to the opposite state.
    If it was on, toggling turns it off. If it was off, the switch will be
    turned on. 'Randomizing' a switch picks one of the two states randomly.
    Think of it as a coin flip, with set being one side and cleared the
    There are three main reasons why you would use a switch.
    1: Randomness
    Switches are the only way of using randomness on a map. Just use it in
    the way explained above. If you want to have more than 2 possible
    outcomes, you'll need more than 1 coin flip. Using two randomized
    switches gives 4 possible combinations (Set Set, Set Cleared, Cleared
    Set, Cleared Cleared), using 3 gives 8, 4 16, etc. If you're at all
    familiar with binary, this is a similar thing.
    If the number of possible outcomes is not a nice power of 2, use all
    any remainder combinations as 'reroll triggers' - just randomize the 
    switches and check again.
    2: You want the map to 'remember' something.
    Trigger conditions can only depend on what's happening in the present.
    You can say, 'Player brings at least 1 unit to location', but not
    'Player brought at least 1 unit to location within the last 5 minutes.'
    Switches can help keep track of this information for you.
    A common application of this is setting the difficulty level. A lot of
    maps ask the player to select a difficulty at the start of the game,
    typically by moving a unit onto one of several different beacons. The
    rest of the game is determined by which beacon was selected.
    One way of doing this would be to create a certain number of units in
    a blocked off corner of the map, and refer to that as difficulty.
    Condition: Player brings at least one men to easy
               Neutral brings exactly 0 men to 'difficulty level'
    Action: Create 1 unit for neutral at 'difficulty level'
    Condition: Player brings at least one men to normal
               Neutral brings exactly 0 men to 'difficulty level'
    Action: Create 2 unit for neutral at 'difficulty level'
    And so on. You could then check to see how many units are at 'difficulty
    level' every time you did something that depended on it. But there are a
    lot of problems with this. You might want to use that corner of the map
    for something else, for instance. Switches are a much cleaner way of
    doing things, and since there are 256 of them you're not likely to run
    Condition: Player brings at least one men to easy
               DiffSet is cleared
    Action: Set 'DiffSet'
            Set 'Easy'
    Condition: Player brings at least one men to normal
               DiffSet is cleared
    Action: Set 'DiffSet'
            Set 'Normal'
    3: Reusable triggers
    If there's one particular trigger that you're using again and again, but
    with different conditions each time, you would have to copy that trigger
    once for every condition you had. This is redundant, annoying, and
    ultimately unnecessary. Instead of copying that trigger, you can just
    set a switch. Then the real actions take place inside a different
    trigger, one that simply checks to see whether that switch is set. If
    you've programmed before, this might sound familiar. These switches are
    being used as simple functions. (Void and parameterless, but still
    Let's say you wanted to 'heal' a player's units every time he brought
    a unit to a certain spot, but also every time his enemy loses a unit.
    In addition, you want to heal the units to a different % of HP depending
    on how much ore he has. (I know this is convoluted as hell, but it's
    also the only time I can think of where such a thing would actually be
    useful, so skip if it's not making sense.) Using normal methods, you
    would need to use the same ore conditions twice - once for the 'bring'
    condition, once for the 'death' condition. All triggers are preserved.
    Condition: -Player brings at least one unit to 'heal'
               -Player accumulated at most X ore
    Action:    -Set HP for all men owned by player to 70%
    Condition: -Player brings at least one unit to 'heal'
               -Player accumulated at least X+1 ore
    Action:    -Set HP for all men owned by player to 100%
    Condition: -Enemy suffers at least 1 death of unit
               -Player accumulated at most X ore
    Action:    -Set HP for all men owned by player to 70%
               -Modify deaths for enemy: Subtract 1 for unit
    Condition: -Enemy suffers at least 1 death of unit
               -Player accumulated at least X+1 ore
    Action:    -Set HP for all men owned by player to 100%
               -Modify deaths for enemy: Subtract 1 for unit
    The same thing, using switches.
    Condition: -Player brings at least one unit to 'heal'
    Action:    -Set 'do heal'
    Condition: -Enemy suffers at least 1 death of unit
    Action:    -Set 'do heal'
               -Modify deaths for enemy: Subtract 1 for unit
    Condition: -'Do heal' is set
               -Player accumulates at most X ore
    Action:    -Clear 'do heal'
               -Set to 70%
    Condition: -'Do heal' is set
               -Player accumulates at least X+1 ore
    Action:    -Clear 'do heal'
               -Set to 100%
    It doesn't really help here, but if you have a dozen or more situations
    where you'd want to call the heal trigger, it really does add up. The
    only time I can think of where you'd have to do that is in an RPG, so if
    you're not into those, byte me.
    Part II: Tips and aesthetics
    This part contains general tips on how to make your map function well,
    and look interesting.
    Terrain and doodads: 
    In order to make your hills or temple walls thinner, create one, then
    set the brush to its 'parent' terrain - whatever it is that the higher
    ground sits on. Then, put that terrain one square away from the hill
    or wall. It will remove one half of that wall and replace it with the
    lower ground. This is nice if you want to create a maze-like feel, or
    if you just want thinner walls to accomodate more buildings. Units will
    be unable to move on top of it, but they won't be able to move through
    it either. Using this, you can even create 'pillars' where 3/4 of the
    hill/wall has been shaved off by surrounding terrain. Of course, you
    could just use a doodad pillar instead.
    If you want your map to have a lot of detail, don't use the infernal
    ash world tileset. High ground and the fog of war blend into one black
    mess, and it is hard to distinguish anything when you are on low ground
    surrounded by cliffs.
    If you want to have something going in a straight line (say a walkway)
    do it on a diagonal. This may be somewhat inconvenient for you, but it
    is much better for the person who has to look at it and play on it.
    Because of the way the editor is set up, terrain running straight up
    and down or to the side will take on a squiggly, and, in my opinion,
    ugly look. There is a utility that lets you place terrain nice and
    geometric, but it does this by sacrificing edges and making everything
    look generally uglier and artificial.
    If you have too many of those straight lines and are doing something
    other than a space or installation map, you should stop it. You want
    your map to look like a real world, and nature does not use nice and
    straight coastlines or hillsides. Don't make your map predictable -
    that's one step away from boring. Make terrain boundaries slightly
    irregular, and vary the terrain types. If you're doing space or
    installation, it's somewhat more excusable, since this is manmade stuff
    we're talking about, but you should still use different types of
    terrain even if it's not necessary to make it work.
    Doodads work the same way. Scatter them over the map, even if you don't
    need them, and don't use a whole bunch of the same type in one area.
    Don't make so many that it would block buildings or units, though.
    Mission briefings:
    It's hard to estimate how long it will take text to scroll. Keep
    testing different wait times until you find a speed that you like. You
    do not want it to go too slowly, or the players will get bored, but
    you do not want it to go too quickly either. If it's any consolation,
    few people ever read mission briefings anyway, even if it's their first
    time playing that map.
    Some people like to put long waits at the end of their briefings,
    others like them to just end when they end. There are pros and cons to
    either choice. If you put a long wait then a player who isn't ready to
    start yet isn't forced to press start until he is ready, but if you
    don't put in a wait at the end at all then it's impossible for a player
    to screw up the game by never pressing start or by dropping out in the
    middle of the briefing.
    Put useful information in the mission objectives - don't just say 'made
    by ____'. Tell the player what they have to do to get to the next
    stage, or to win. If you have space, also put general gameplay
    information in there that they can refer to - even if they do read the
    mission briefing they probably won't be able to remember all of it.
    Keep anything you say short and to the point.
    One of the things I've noticed on many maps is that the creator will
    spend the first 10 seconds of the briefing doing a little ASCII-based
    animation to introduce the map in style. This severely pisses me off,
    and I'm sure I'm not the only one. People read briefings for information,
    not to watch text-based movies. If you must put these in there, at least
    have some consideration and put the goddamn movie in the mission
    objectives box *while* the rest of the briefing is giving useful
    information. You might think that forcing people to look at something
    will make them like it more, but anyone who has had to deal with popup
    ads while surfing the web will know that this is NOT the case.
    i. Style
    Name your switches, and comment your larger blocks of code. Not only
    does it make it easier to understand, it also saves space. Comments
    are lines of text that appear in place of the trigger body when you're
    in the triggers menu.
    Organize your code well. Put triggers that have something to do with
    the same thing (like, say, handling a player's level ups in an RPG) in
    the same place. It makes it easier for you to find things and harder to
    forget about crucial triggers that you haven't seen because all your
    triggers are in obscure places. You might even create blank triggers
    (using the 'never' condition) with comments saying what each set of
    triggers does. Example: Condition -Never, Actions -Comment: Triggers
    for controlling Mrs. Claus (that's from one of Blizzard's old holiday
    maps). This is the only real use for the 'never' condition, actually.
    One thing to note if you are into writing really long text messages
    is that the editor does have a string limit. This means that there is
    a limit to the amount of text you can put in a map. You should not run
    into it unless you're making a large or trigger-intensive map, but if
    you are, it is sadly the comments that are the first things to be
    ditched when you run up against a wall. So don't count on them too much.
    ii. Streamlining
    Don't use long wait triggers, they may be convenient but they have the
    potential to screw up every other trigger on the map by keeping them
    waiting. Only use them in mission briefings or in-game cutscenes, where
    everything is scripted and always does the same thing. For gameplay
    triggers, use alternatives instead:
    Original trigger:
     Condition: -Player brings at least one men to 'start'
     Actions:   -Wait 30,000 milliseconds.
                -Do X (yeah, this is major pseudocode)
    Method #2:
    Countdown timer. The game keeps track for you, but you can only have 1
    timer running at a time.
    Modified triggers:
     Condition: -Player brings at least one men to 'start'
     Action:    -Modify countdown timer: Set to 30 seconds
     Condition: -Countdown timer is at most 0 seconds.
     Action:    -Do X
    Method #3:
    Patrol counter. Have an invincible, neutral, and preferable invisible
    unit patrol between two points. When it comes back to its starting
    position, resolve the trigger.
    Modified triggers:
     Condition: -Player brings at least one men to 'start'
     Actions:   -Create one observer at 'patrol start' for neutral
                -Order all observer at 'patrol start' owned by neutral:
                 Patrol to 'patrol end'
                -Set 'patrol'
     Condition: -Neutral brings at least one observer to 'patrol start'
                -'patrol' is set
     Actions:   -Clear 'patrol'
                -Do X
    Method #4:
    Unit counter. This is a bit more complicated than the others, but it's
    my personal favorite because it lets you keep a more precise track of
    time than the patrol thing without having to use the countdown timer.
    The drawback is that it doesn't adjust for the game speed, since
    triggers will always take exactly the same amount of time to preserve.
    But that's not really a problem since 99% of all games are played at
    the fastest setting.
    It goes something like this:
    Modified triggers:
    Condition:  -Player brings at least one men to 'start'
    Action:     -Set 'start counter'
    Condition: -'start counter' is set
    Actions:-Create one burrowed, invincible, neutral zergling at 'counter'
             (via 'create unit with properties')
            -preserve trigger
    Condition: -Neutral player brings at least 30 zerglings to 'counter'
    Actions:   -clear 'start counter'
               -remove all zergling for neutral at 'counter'
               -Do X
    Yes, it is complicated. But it works. The computer checks triggers
    about once every second, so it will come out to about 30,000 mils.
    This concept is similar to the for loop in programming.
    Method #5: Custom score clock
    This is probably the best method in the group. The only reason it's not
    my favorite is that I find burrowed zerglings funny for some reason.
    It's a very similar concept to that of the zerglings, and allows you to
    create a universal 'clock' that all other time-based triggers can refer
    to. It requires that you have at least one player (usually a neutral)
    whose custom score you are not going to refer to in any way except in
    these types of triggers. It goes something like this:
    Condition: Always
    Action: Modify score for neutral: Add 1 custom. Preserve trigger.
    Condition: Neutral player custom score is at least 30
    Action: Modify score for neutral: Set to 0. Preserve trigger.
    That sets up the clock. Now here's an example of how it might be used.
    Condition: -Neutral player's custom score is exactly 15
               (Any number between 0 and 30 will do)
    Action: -Create 1 unit at 'spawn'. Preserve trigger.
    Note that this method does not do anything that burrowed zerglings
    cannot. The only reason why I put it in is because on large maps you can
    sometimes run up against the unit limit, and it's nice to have something
    that will always work even if you've already created the maximum number
    of units the poor game can support.
    Whenever you create new units at a small location, you should check to
    see if whatever you're placing will fit. Usually, locations for
    structures are the same size as the structure itself, so even one unit
    can make it unplaceable. So, if you wanted to place a bunker somewhere:
    Condition: -'Place bunker' is set
    Actions:   -Move all men owned by all players at 'bunker' to
               (somewhere else)
    Or, you can use:
    -Remove all men owned by all players at 'bunker'
    This is somewhat more cruel, but it works too.
    Then, just place the bunker:
    -Create 1 Bunker for current player at 'bunker'
    Another thing to note about building placement is that the triggers
    are very finicky. The exact center of the location has to be clear -
    anything less, and the building won't place. For this reason, placing
    more than one building at a time at the same location will *never*
    work. It's usually best to create a separate location for each structure.
    However, you can't always do that. Say you want to create a building
    next to the player's unit. If you center a location on that unit (via
    the move location trigger) and create, the unit will naturally be right
    in the middle of the spawn location and the trigger will not work. The
    easiest way to get around this is to put a wait trigger of a second or
    two in between the centering and creating. This gives the player time
    to move the unit out of the center of the location before the building
    comes in. Problem is, there's still a chance that some unit will still
    be there, leaving the player with a 'Warning! Unit unplaceable' message
    and nothing else.
    The safest way to get a structure next to a moving target it to create
    it somewhere else first. Choose some clear, isolated spot on the map
    that nobody ever goes, wall it in, and place a location over it to act
    as the original spawn point. Then:
    Condition: (Whatever triggers the creation of the building)
    Action: Create 1 building at 'Original spawn'
    Condition: Player brings at least one building to original spawn
    Action:-Center location labeled 'final spawn' on target unit owned
            by player at 'anywhere'.
           -Wait 1000-2000 milliseconds
           -Move 1 building at original spawn to final spawn for player
           -Preserve trigger
    iii. Special effects
    Part 1: Explosions
    Yes, everyone loves explosions. They make a map look cool and spice up
    those dramatic moments. To simulate an explosion, choose a unit with a
    rather explosive death sequence (like the archon or dark archon) and
    create them and kill them at the same time. Spider mines also work well.
    It looks something like this.
    Condition: -Player brings at least one men to 'Explosion activation'
    Actions:   -Create 1 Exploder at 'Explosion area' for player
               -Kill all Exploder at 'Explosion area' for player
    You can create fog or mist using a similar effect - create a
    hallucinated unit via the 'create unit with properties' trigger and
    then kill it immediately afterward. Some maps create some pretty
    graphic displays of blood by killing marines/medics/zerglings/whatever.
    One of them kills a whole string of medics, spelling out the word 'DIE'
    in white suits and red blood.
    Part 2: Rockets, Death spikes, and other fun stuff
    This is an extension of the explosion concept. Say you want a
    projectile to shoot towards a certain destination and kill anything
    that it touches.
    (All triggers are preserved)
    Condition: -'Do Fire' is set
    Action:-Center location labeled spawn on shooter controlled by Player
            at anywhere 
           -Create 1 Bullet at spawn
           (Bullet should be a flying unit, preferably small and fast-moving.
            Scourge is a good choice.)
           -Center location labeled spawn2 on target controlled by enemy at
           -Create 1 Target at spawn2
           (Target should also be flying, and invisible so it isn't
            completely obvious. Observer is a good choice.)
           -Order all bullet controlled by neutral at spawn - move to spawn2
           -Clear 'Do Fire'
    Both 'Bullet' and 'Target' should be neutral and invincible.
    Condition: -Neutral player commands at least one bullet
    Action:    -Center location labeled 'kill' on bullet owned by (you know)
               -Do explosions at kill
               -Kill all men owned by non-neutral players at 'kill'
    Condition: -Neutral player brings both 1 bullet and 1 target to kill
               (ie the bullet has reached its destination)
               -Kill all bullet and target for neutral player at kill
    You can use other variants, like setting all the HP of all units in
    blast radius to 1% instead of killing them outright.
    Part III: Type-specific
    There are many different maps on Battle.net and elsewhere, and more are
    created every day. They vary a lot, but there are some map types that
    pop up again and again. This section deals with tips for *some* of
    those specific types of maps.
    This is the standard 'build up and kill your enemy' map.
    General tips and style:
    If you are going for even matchups (i.e. humans vs humans) then you
    should try to make the map roughly symmetrical. No player should have
    access to more resources than any other player, and no player should be
    able to drop tanks on an opponent's ledge when their own base lies on
    the high ground. In other words, you want it to be fair. Use Blizzard's
    maps as examples. Don't go too heavy on the doodads or rough terrain,
    part of the fun of the terran race is being able to plant fortified
    outposts wherever you want.
    If you are doing a human vs. computers map, you should give the comps
    more than the players... unless you want to create a newbie map or
    something. Give them sizeable starting forces and nice little choke
    points to defend themselves. Putting extra minerals or vespene near
    their starting positions also helps.
    If you use the lower level AI, (easy or medium) give the computers
    plenty of starting buildings and resources, or else they will spend the
    entire game in a drunken stupor doing essentially nothing. If, on the
    other hand, you use hard or insane AI, you should do the opposite,
    since they will build fast and you don't want them to hit the players
    until they are ready. Blizzard's Endurance map of the week (back when
    they were still doing map of the week and not trigger map of the month)
    is a good example of how to handle different AIs to create a challenge
    that is tough, but not impossible.
    Keep in mind what type of map you want while you create it. If you want
    players to have a lot of minerals, you should scatter the map with
    expansions or maybe go the big game hunters route. If you want the
    whole game to be a desperate scramble for resources, you should limit
    the expansions and put those in heavily contested areas like the center
    of the map for some fun. Most maps are somewhere between the two.
    Similarly, you have to decide how easy it is for players to attack each
    other. Do you want winding paths and high ground protecting each base,
    or the cutthroat, no-holds-barred feel of hunters? It's up to you to
    This is a map type where players get unlimited men and have to destroy
    their enemies' bases.
    General tips and style:
    You should put in some anti-rush mechanisms here, because maps like
    these can see the tide turn very quickly. Using a bunker or other
    defensive structure as the spawn point is a good idea. Give the
    structure a lot of health and armor. (Go to scenario in the menu, then
    unit and hero settings)
    Keep in mind your unit counters. Don't make one side so horribly
    unbalanced against everyone else that they always lose. In other words,
    don't put vultures in the midst of dragoons and goliaths.
    Don't make the map too big. The whole point of a madness is for things
    to happen abnormally quickly. Don't force the players to go on a long
    hike to reach the others' bases, unless all the units are fast moving.
    Even then, you want to keep the map size down somewhat.
    Don't feel like you have to ignore terrain. Keeping the map small
    doesn't prevent you from placing high ground to be used by the skillful
    Do something that makes it unique. There are so many madnesses out
    there that are essentially the same thing: a bunker as a spawn, and
    players getting infinite units out of it. Add upgrades. Give them an
    SCV, drone, or probe so that they can build. Make it so that they get
    cash for kills. Changing the names of your units to the names of
    characters in a popular game does NOT automatically make it as good as
    that game - none of the final fantasy madness maps I've seen come
    anywhere close to living up to their namesake. Actually, in my opinion,
    it is impossible to make a madness unique, but you can certainly try.
    Find out how many units can fit in a spawn point, then set up a block
    so that it stops producing units when it hits that number. Madnesses
    are infamous for creating WARNING! Unit unplaceable(Name, x, y)
    Conditions: -Player bring at most X units to 'spawn'
                -Player commands at least one 'Bunker'
    (Actually, it can be any structure, but I'll just use bunker because
    it's the most common.)
    Actions:    -Create 1 (player's unit type) at 'spawn'
                -Preserve trigger
    Because players will be controlling so many units, it helps to have a
    'mass assault' option of some sort. Either place beacons representing
    different parts of the map, or create an invincible, non-damaging
    flying unit for each player and keep a location centered around it,
    like this:
    Condition: -Always
    Actions:   -Center location labeled 'target' on 'Observer' owned by
                current player at 'main game area'.
               -Preserve trigger
    Note that in order for this to work you have to make sure the player
    has only one observer in the main area.
    Then, give the player a unit that s/he can move to a certain location
    to start the assault.
    Conditions: -Player brings at least one 'Civilian' to 'Mass assault'
    Actions:    -Issue order to all men owned by current player at
                 'main game area': attack to 'target'
    In this case, 'target' is either a specific location on the map, or
    the location that is being kept centered around a unit.
    These are maps where each player controls one powerful unit that has to
    defeat an array of lesser enemies.
    Actually, the definition of an RPG is so fuzzy that there are a number
    of ways of doing any particular thing. As a result, this guide will end
    up making certain assumptions. I have nothing against trying something
    new in map making - I'm all for it. But it's hard to predict the
    unpredictable, so you'll have to bear with me here.
    General tips and style:
    Because these maps generally involve little building, you can go
    overboard with the doodads and terrain types. If there is any patch of
    ground that looks too plain to you, just throw some doodads on it or
    brush on a different terrain type on top of it. An RPG which consists
    of one long, winding dirt road that is separated off by one-block
    length dirt walls is very boring. (And you would surprised to know how
    many RPGs are like that) You should put in alternate paths for the
    player even if they don't lead anywhere except more enemies or minor
    treasure. You want to give the players some choice in things.
    In general, you want to give the players plenty of opportunity to heal.
    Put it in the town or main base, or somewhere that is easily
    accessible. There are some RPGs that do without this entirely - The
    Nearly Impossible RPG is one example, and a quite fun one at that.
    Give the RPG a gentle learning curve. Don't force a player to do too
    many unfamiliar things at once. The first few battles, dungeons,
    stages, whatever, should be winnable without the players having to use
    special spells or stuff like that. Don't bombard the players with
    text - phase in gameplay or plot information one block at a time.
    Update the mission objectives each time the plot advances so the
    players can remember what it is exactly that they're doing. It's easy
    to lose track of things in the midst of monster bashing and leveling.
    Keep the players balanced. If you plan on giving each player a
    different unit, make sure those units are of relatively even strength.
    Don't just look at numbers, think about versatility, speed, and special
    abilities as well. Two units you should perhaps avoid using entirely
    are the marine and zergling. These units have a fast attack, normal
    damage, and can get incredibly powerful. They are much better off
    being computer units. If you do decide to give them to the players,
    limit their damage and damage bonuses. A lot.
    Disable special abilities like spawn broodling or stasis field. You
    don't want the computer casting it on the players, and you don't want
    players casting it on enemy bosses. To disable units, upgrades, or
    special abilities for a specific player, go to player in the menu, then
    settings. Whether you decide to get rid of lockdown, parasite, and
    other less harmful abilities is up to you. You should definitely give
    the players the ability to get medics and restoration if you leave
    lockdown enabled.
    If you allow the players to upgrade their units, make them take as
    little time as possible. You want the players to spend as much time as
    possible actually playing, not sitting around waiting for a green bar
    to advance.
    One interesting thing to note is that you can make units inside a
    stasis field killable by using the 'modify unit invincibility' trigger.
    Rather fun. Stasis field becomes like an evil maelstrom. You have to
    have the trigger executing all the time to make it work, though.
    Experience handling and level ups:
    Many RPGs involve giving the player money for kills. Doing so is
    relatively simple. It uses the kills score (or the kills and razings
    score, if you'd rather use that). Every unit in Starcraft already has
    a point value, used in calculating the scores in games. You can also
    take advantage of it in your maps.
    Condition: -Player kills score is at least 50
    Actions:   -Modify score for current player: subtract 50 kills
               -Modify resources for current player: add 5 ore.
               -Preserve trigger
    Unfortunately, doing this is rather slow. In large battles, the player
    will end up with a much higher score than 50 and this only exchanges 50
    every 1.5 seconds or so. You'll have to add in some others for larger
    amounts of kills. You will have to use the 'score' type condition and
    action, and then select the score type. Note that kills score is
    different from kills - kills is just the number of kills the player has
    for any type of unit, regardless of their point value.
    Condition: -Player kills score is at least 250
    Actions:   -Modify score for current player: subract 200 kills
               -Modify resources for current player: add 20 ore
               -Preserve trigger
    Condition: -Player kills score is at least 1250
    Actions:   -Modify score for current player: subtract 1000 kills
               -Modify resources for current player: add 100 ore
               -Preserve trigger
    And so on. If you want, you can even modify the score value of specific
    units. For example, the hydralisk ordinarily gives 350 points when
    killed. However, by using this trigger,
    Condition: -Player kills score is exactly 350
    Actions:   -Modify score for current player: subtract 350
               -Modify score for current player: add 500 custom
               -Preserve trigger
    the hydralisk now gives 500 when killed. This is one of the many uses
    of the custom score. This is risky, though, because the player might
    end up getting 350 by killing a combination of lesser units, or could
    skip over 350 altogether by killing a mass of hydras at the same time.
    In most RPGs, player characters improve as the game goes on, and they
    usually use experience levels to represent this. One method for keeping
    track of experience levels is vespene gas. It is extremely convenient
    to do it this way because then you can set all upgrades so that the
    player needs to be of a certain level to use them.
    Conditions: -Player kills score (experience) is at least 1000
                -Player kills score is at most 5000
    Actions:    -Modify resources for current player: set to 2 gas
                 (2nd level)
                -Preserve trigger, so that it keeps the gas at 2 when it is
    Then, you can just set your upgrades using scenario -> upgrade
    settings. If you want it so that the player can upgrade his/her
    weapons at levels 2, 7, and 12, then set the initial gas cost of
    the weapon upgrade at 2 and make the factor 5.
    In addition to weapons/armor, you usually want to allow the heroes to
    gain HP. There are a couple of ways of doing this. The easy way is to
    give the player a completely different unit at certain exp intervals. 
    For example, you could start him off with a zealot, then go on to a
    dragoon or archon. Each form would have successively higher HP, and it
    would be easy to handle healing since no matter which form he's in it
    will be setting his HP to 100%. Still, this can get a little annoying.
    No two units in starcraft are alike, and a player who has just gotten
    used to playing with one unit type might be thrown off if you gave him
    a different one, especially if the second one suffers from poor AI or
    inferior firing rate. At the very least try to keep the unit upgrade
    types the same - if the original was protoss ground, the successors
    should also be protoss ground.
    A second way of handling HP is to give the starting unit a fraction of
    its full health. Then, each time the player levels, the unit's HP will
    go up by a little, until at the highest level it will be at a full 100%.
    This way you don't have to worry about switching units or upgrades -
    it'll always be the same. It makes healing complicated, though. You have
    to check for the player's level and write in a trigger for each. So:
    -Condition: Player commands exactly 1 exp level
                Player brings at least one hero to heal
     Action: -Set HP for all hero owned by player at heal to 15%
             -Preserve trigger
    -Condition: Player commands exactly 2 exp level
                Player brings at least one hero to heal
     Action: -Set HP for all hero owned by player at heal to 20%
             -Preserve trigger
    This gets tedious rather quickly.
    Another drawback is that the player will know right at the start what
    his final hit point total will be.
    Special Effects:
    Some maps allow the players to use spells or special abilities that are
    different from the ones in normal starcraft. These effects are entirely
    trigger-driven. Usually, there is an area off to the side of the map
    where the player has a unit and a set of beacons the player can bring
    the unit to. Each one of those beacons represents a spell. Let's take
    a common example: A player moves the unit to a beacon, and an infested
    terran appears at his hero's location. A message appears on the screen
    saying 'fireball cast' or something like that.
    If you are going to use spells, you will need something to keep track
    of mana or the number of spells the player has left. You can't have the
    players constantly using their spells with no penalty. Most maps use
    vespene gas to represent mana, and subtract from it every time a spell
    is cast.
    To keep the mana recharging:
    Condition: -Player accumulates less than 200 gas
    Actions:   -Modify resources for current player: add 1 gas
               -Preserve trigger
    To keep track of where the hero is:
    Condition: -Always
               -Center location labeled 'hero' at (whatever unit the hero
                is) owned by current player
               -Preserve trigger
    and to do the actual spell-flinging:
       -Player brings at least one selector to 'spell beacon'
       -Player accumulates at least 50 gas
       -Move all selector at 'spell beacon' to 'spell ready area'
    (this is so the player doesn't inadvertantly cast the spell more times
    than s/he wants to)
       -Modify resources for current player: subtract 50 gas
       -Modify energy for all units owned by enemy at 'hero': set to 0%
       -Modify energy for all (hero) owned by current player at 'hero':
        set to 100%
       -Display for current player: "MP Drain cast"
       -Preserve trigger
       -Comment: 'Cast MP Drain'
    This is only an example. You can make whatever spell effects you want.
    There are a number of times in an RPG where you might want to create
    cutscenes where you just show the players something without them 
    doing anything. To prevent players from trying to do anything during
    these, either give their units temporarily to a neutral player, or
    create barriers that block movement like rows of crystals or
    invincible neutral dark templar. The downside is that by doing this,
    you are now forced to make those cut scenes interesting, or else the
    players will become annoyed and bored.
    Part IV: Special Utilities
    You might have to do some searching around to find these. I suggest
    StarGraft: This tool lets you edit tech trees, unit dependancies,
    create new commands, stuff like that.
    StarDraft: Lets you modify unit graphics, properties, (like having a
    hunter killer with cloaking) etc.
    Both StarGraft and StarDraft were created by Camelot Systems. I have
    not used either, so do not know much more about them.
    Emerald StarEdit: This special version of staredit allows you to place
    units of all three races for a single player without having to use the
    create trigger. It also introduces a whole bunch of new units and AI
    scripts, including target nuke and recall. Some versions also allow you
    to ignore building placement restrictions and have up to 255 upgrades.
    Map Colors: Allows you to color the text in mission briefings, unit
    names, and trigger messages. Simple, yet neat.
    Hexedit (Actually, I'm not even sure what the name is):
    This lets you make terrain so that it goes in straight lines up and
    down, allowing you to create a checkerboard feel, or to make a map
    with long, straight corridors that go up and down instead of
    diagonal. I've never used it, so I don't know how exactly it works.
    Examples of maps that use it are Zone Control and Chess.
    As you can probably tell, my experience with special utilities is
    extremely limited. You'd be better off asking someone else if you
    really want to take advantage of them.
    If there is any disparity between this guide and another of the same
    name and author, the one at http://www.gamefaqs.com/ takes precedence.
    This is due to reasons of laziness only.
    This guide was written by Carl Morita August 2001.
    You can copy or excerpt it as much as you want, but give credit where
    it is due, and do not give credit where it is not due.

    View in: