| Table of Contents |
|---|
| Preface |
|---|
|
The Author My mapping name is Tuxedo-Templar (I sometimes simply go by Tuxlar), and I've been creating custom maps for Starcraft for the last 7 years on and off. I've never really stuck to one style of map, preferring instead original concepts (or twists on existing concepts) over rehashes of existing ones. Though I have been guilty of the occasional juvenile humor map every now and then. Though I've tried many map ideas over the years (with varying degrees of success), I think I've found my enjoyment in the past simply from making exotic concept maps more than actually having them be practical or playable. Lately, I've been pushing away from that trend to try to make maps that are more palatable, while still holding to my principal of using only original ideas. Astrogears, I think, is probably my best completed work in that regard.
Astrogears I started this map back in July '07 when Starcraft 2 was first announced by Blizzard. I had a number of ideas on my mind that I never gotten around to making suitable maps for, so I put them all together in one big curry pot and started on a new map. Originally, I was going to call it TechnoGears, as a sort of spiritual successor to my previous map, MechnoGears (read: I messed up and wanted a rm :P). But having the hindsight to see where I went wrong/right in MechnoGears, and realizing that I wanted to make a proper map for a change, I overhauled my original concept into a new idea. As it started to take shape, I renamed the project to Astrogears to try to better represent its departure from my original failed idea. Now, as of this writing, the map is nearly finished, and hence I figure the time is right to write a bit about how I made it. Mainly I'm doing this because I wish to finally bring to light some of the methods I've developed and used for making my maps thus far in the hope that it might benefit others interested in the ornate, ancient art of Starcraft mappery. Or at the very least, to try to illustrate what it takes to actually make a large-scale Starcraft map like this. |
| Tools |
|---|
|
The first thing I think I should talk about are the tools. They are the defining aspect of how I do a lot of what I do. Without the right tools, I simply couldn't do certain things. Or else they'd become so difficult as to be impractical; especially on large scale projects like this.
I couldn't possibly begin any tools discussion without the basics first: The editor. Or editors, in this case. Though I could say this map was done entirely with ScmDraft 2, old habits have had me make use of the original Staredit (comes with Starcraft), Xtra Editor, Starforge, and even old stuff like GUEdit at times. For simplicity, I will just recommend SCMDraft 2 above anything else, since it really has come together over the years thanks to Suicide Insanity's continued work on it.
While SCMDraft 2 was used for the majority of the terrain, and its Trigedit plug-in used for the triggers, a few other tools were used for the actual trigger creation process (which, I should note, is where the real meat and bones of the map itself lay). Trigedit's text-based triggers have proven invaluable to the creation process, as they allow me to simply port all my triggers into any text editor and make them there. Once you're dealing with anything in text, you have a ton more options available to work with! The main tool I use for my text trigger editing is Notepad++. This is a very nice and versatile tool because of its many built-in features, including macros, multi-file find and replace, regex find and replace, tabs, custom language definitions (useful for programming in other languages too!), customizable shortcut hotkeys, and my personal favorite feature: Text collapsing. I've since defined a number of handy macros that I use for quickly creating Trigedit-style triggers. I've also made my own language definition just for Trigedit triggers. This might seem like overkill, but the language definition I made allows the utterly helpful ability of collapsing triggers into sections, making large projects much easier to manage!
To set it up (after you've downloaded and installed Notepad++), download this file and unzip its contents into your Documents and Settings\Owner\Application Data\Notepad++ folder (or whatever the equivalent path is for your system, if different). You may have to override the existing files, but you should back them up first in case of a newer Notepad++ version that doesn't like the ones I've provided (or else if you've defined your own Notepad++ macros that you don't want to lose). To use my language definition, first be sure to copy your Trigedit triggers into Notepad++ and save them as a .trigger file. Later, to open up the file, Right click on it, select the Open With option, and then select Notepad++ (and check the Always use the selected program to open this file option as well). That lets you open up .trigger files from now on by simply double clicking them normally. After opening your .trigger file, if the
language definition's formatting does not automatically appear, then open the
Language menu, scroll to the bottom, and select Triggers.
Parts of the trigger text should now have noticeable red highlights.
Now, to add collapsible groups, you'll need to add a
//> at the start of the triggers you want in your group, and a
//< at their end. Note that any
// (double slash) denotes a line of
comments, which will NOT be present in your real triggers after
importing them back into Trigedit (which I do with a simple copy and paste
from Notepad++). Finally, to use my macros, be sure Num Lock is turned on, and then press Ctrl and a numpad number. I used numpad numbers 0 through 9 for the following macros:
Ok, what does a Microsoft web site editor have to do with triggers?
Well, not much, except that of all the other programs I've used (regular
Notepad, WordPad, Microsoft Word, and even Notepad++), I find FrontPage to be
a good program for managing project information. It's probably not the
best program in the world, but it works for me.
With all the text triggers, the map itself, web page files, and other map
resources (sounds, test maps, etc.), there is still one more important thing
that needs to be addressed: Backups. My old method involved manually
copying project files into backup folders. Later, I evolved to using a
script to do that automatically, but it created many ugly issues that I'd
rather spare you from even knowing about. One day, though, I heard
about a program called
Tortoise SVN.
This handy tool is designed to introduce version control into projects.
While this ability can be abbreviated well enough for a backup system, it is
primarily intended to be used for projects that are shared across multiple
users (like those who are miles away).
Though Astrogears itself was a solo effort (except for the help of my beta testers), I do hope to attempt a proper multi-person mapping effort eventually. I've always believed the major hurdle against map makers working as a team has been the ability to keep on top of a map's triggers. Because of the rigid way Starcraft forces a lot of things to get done, it's always been difficult for one person to make an edit, hand it to someone else, and expect them to pick up the baton where the other left off. Even for myself, I find I have an easier time simply redoing whole portions of others' maps simply to fix issues than to try to debug them. My hope is that, through the combination of text triggers, an SVN system, Notepad++'s handy features (including the almighty collapsing), and a proper to-do and information tracking system, team triggering can become as doable as any normal programming project.
|
| The Project |
|---|
|
Since I'm releasing this map as "open source", I figure it appropriate to also release the project's source materials as well. This includes the Trigedit text triggers (saved as .trigger files) and the project's full to-do and information tracking lists (as HTML files). You can get them all here:
To set them up, you'll first need to be sure you have all the tools I've listed above installed and set up (or at least ScmDraft 2 and Notepad++). Then unpack the above zip file into a new folder in your Starcraft\Maps directory. You should move the map itself to this folder as well (you can still play it from there). Once set up, all you need to do is open the .trigger files in Notepad++, being sure the trigger language definition is up and running (remember you should see red highlights for the triggers in each document). For each open document, press alt+2. This will collapse them into chapter-like blocks, each conveniently labeled to indicate what is what. For a reference on what all the Death Counters, Switches, Locations, etc. used, refer to the main project HTML file Astrogears.htm. If your browser can't correctly displays it, you may need to open it up in Frontpage instead. Below the table of contents in the Astrogears.htm file (some of the links there may not work, by the way), the Tasks list you see next is where I put all my To-Do list stuff. You can safely skip this, unless you want to get an idea of how much work went into this map (the grayed out portions all represent the map's completed parts, as of this writing). Instead, refer to the embedded frame containing the project's Information (the lower one). Refer to this for all the project's information that you need. You can also open it as a separate document, if you like (Astrogearsinfo.htm). |
| Development |
|---|
|
Conceiving of the initial idea was easy, since I had already decided it to be a remake of Mechnogears. But when I decided I wanted it to be an actual playable map instead of just a petty remake, I had to put on my thinking cap for a while. Basically, I started out with a brainstorming session. When I brainstorm ideas, though, I usually am not altogether formal about it. I like to combine both depth first and breadth first planning as I go. All my ideas get compiled into a list outline, using nested lists to describe aspects of each elements as needed. I usually prefer to wait until I have some confidence in a given idea before venturing too much into the specifics on it, too. After my first outline, I then began on another from scratch. In this next iteration, I will filter, reinterpret, expanding upon, combine, separate, and otherwise format the many ideas from my earlier brainstorming to try to make them come together for the final plan. It is here that I start making decisions for the overall gameplay, too. Criteria such as cool-factor, gameplay role, compatibility with existing ideas, accessibility, technical limitations, and even plausibility all come into play when deciding on given ideas.
For instance, I'd originally wanted to add a sort of "mortar" system for Gears, allowing them to fire ranged, dumb-fire projectiles across the map at enemy targets (similar in a way to my old Cannonballs map). I thought this might introduce a sort of Battleship element to the gameplay. Eventually, I realized that any approach for this idea would involve a clumsy implementation requiring some kind of grid system. The general rule with grid systems is that they often require a lot of overhead to work properly. Either requiring a lot of units, locations, or simply a clumsy and/or extremely complicated trigger implementation. Not to mention the potential for lag. Technical limitations aside, the other problem behind the mortars idea would be the random aspect they would introduce to the gameplay. A player could terrorize an enemy base without much accountability; a fact that could end up throwing a big monkey wrench into the base building aspects I'd had in mind. Therefore, I decided eventually to divide up the idea between a combination of launchable 'guided missiles' from players' Gears and a special Bomber vehicle to drop explosives behind enemy lines manually. When I finished my final outline draft, it was time to create my game plan. First, I would create a to-do list of all the major (but not the specific) elements from the latest outline draft in the most logical order I could think of. I also set up separate lists for map information (death counters, location use, unit information, etc.) and any issues or improvements that I might need, which would be embedded into my main to-do list document using HTML inline frames (to keep them all roughly in the same area, but still separate). The latter list I would use consistently during development as issues arose, new ideas surfaced, or simply wherever I thought general improvements were appropriate. I would keep these lists separate from my main to-do list so I could keep my focus on forward progress on one hand, and take on the assorted bugs, issues, and tweaks when I would get breaks or lull during the main line of development. After that, it was time to start the map itself. My original thinking was to make the map as large as possible to accommodate players filling in the map with their own bases, masses of spawned units running around, and the strategic element of mortars that I'd originally planned for. I decided on a large (256x192) space tileset map using each horizontal side to house an opposing team. Adding in the terrain was to be a relative non-issue given the sandbox nature of the gameplay as I really only needed to designate the general physical shapes for things such as the main arena, players' hangars, and the purchase areas for each team. I would later add onto and tidy up each part of the terrain as the map progressed, and mainly worry about prettying it up only towards the very end.
With my initial plan set, the base map ready, and everything else set up, it was time to begin on the meat and bones of the map: The triggers. I would create my triggers under SCMDraft 2's Trigedit text format as a Notepad++ text document and then import them into my map via. copy and paste into Trigedit as needed. The nice part about this approach (versus Staredit/Xtra's wizard editor) was that text triggers could be copied, duplicated, deleted, divided up, commented out (using real comments now, thanks to Trigedit's C-style double-slash commenting) and easily rearranged en mass. Also, I can't even begin to tell you how useful having a good Find and Replace option is (especially Notepad++'s tricked out one). But more importantly, my custom Trigedit trigger language definition (see above for information) lets me do probably THE most useful thing of all: Text collapsing. Astrogears, by its end, had built up well over 5000 triggers. Trying to manage all of them with a Staredit-family editor would become a living nightmare. The trigger comments alone would suck up the map's entire string allotment. However, by a combination of dividing my triggers up into multiple text documents (I only used four), organizing them via. collapsible groups, and keeping proper documentation all throughout, I never really had any trouble keeping on top of things.
As I would chip away at my project plan, I'd make a habit of doing several things. Originally, I'd wanted to document EVERY change or addition to the map. Everything from death counters, switches, locations, units put to use in some way, stats, techs, upgrades, etc. Unfortunately, I wandered into the delusion that I could finish the map in only a few weeks, and thus got lazy and ended up only documenting only half the stuff I should have. I would later go on to regret that mistake, though, as issues arose from conflicts over which units and locations were designated for doing what. Lesson learned: You can never have too much documentation! In addition to documenting changes, I'd also add on to/fill in the outline itself continually as I'd go. Eventually I would stop using the outline altogether and migrate fully to my primary to-do list, but during the early stages I'd opted to keep my to-do list small and not looking too far ahead (which was what the outline itself was for). I discovered that turned out to be a good way to handle the project, both for psychological reasons (not seeing an 8 page long to-do list ahead of you, for instance) and because, as I've learned from past maps, no plan is ever immutable. No matter how far into the project you get. Rather than trying to predict ever possible tiny step along the way, I find the best approach is to have a clear general idea and some key specifics, but otherwise let Starcraft's limits and available options tell me how to go about each step of the way.
When I started into the guts of the map, there were still few parts of my plan that were shaky. While I was fortunately not to suffer too much because of this (compared to some of my past maps), I think now that I definitely could have benefited from more planning time in some areas. One issue in particular that turned up while I was working out the Gear's combat system was the nature of the Gear's defenses. In Mechnogears, I'd used 3 distinct types of units (Bits) for shields: Units designated to absorb enemy attacks. Unfortunately, there was no fundamental distinction between each of the 3 options. They were just 3 different amounts of HP to chose from. With Astrogears, I'd decided I wanted to slim things down to only the basics. Instead of Bits, I gave Gears the innate ability to use multi-unit "shields". These units would be replenished automatically as they would die at the cost of the Gear's energy supply. I didn't completely discard the designated shield Bit idea, though. I soon realized that another layer of defense might fit in as an alternative to the shield ability. By letting players purchase special Armor Bits, I could provide another defensive option for their Gear to meet that end. I realized later when examining the differences between using one main unit for defense (the Armor Bit) and many multiple clustered units (shields) that two different strategies came into play for countering each one. I decided to capitalize on this, and ended up totally re-planning my original lineup of attack Bits to accommodate these two defensive strategies (a lineup which, too, had been slimmed down from Mechnogears'). As I moved past the Gear aspects of the map and into the NPC spawning portion, I soon discovered (or rather just then remembered from Mechnogears) that I hadn't given players much incentive to bother building their spawners away from their initial starting area. Back in Mechnogears, winning the game was often as easy as simply building a massive amount of spawners in a single area and letting the concentrated flood of units win the game. To avoid a similar outcome in Astrogears, I added a restriction to the building of spawners too close to one another. Also, in continuing with my 'slimming down' mind set, I decided to now only use 3 distinct types of NPC forces. My original intent was to make a sort of Rock Paper Scissors effect from this, which still persists (to a degree) in the map now. When the addition of the Field Engineer's barricade building ability came about, I realized that I needed a specialized way to counter this specific element, and thus I turned one of the three infantry types (the Manufactured War Bests; high attack, high armor, very low HP Ultralisks) into pretty much just a designated barricade and base chewer-upper. I'm still calibrating the balance behind this aspect, even as I speak. As the core map elements started coming together, one thing I had to finally resolve was the issue of player deaths. With Mechnogears, I basically gave players endless chances to come back into the game after dying. The only real way a player could lose was when their team's main building went down. For Astrogears, I thought this kind of leniency might be inappropriate, as it might give players little incentive to worry about personal survival or applying serious effort into strategizing. On the other hand, I didn't want to punish dumb mistakes or newbie players too much, either. Thinking through my options, I eventually decided upon "layers" of death. If the player's Gear died, then they would just be without a means of offense. They could still be useful to their team, but relegated to support-only roles. On the other hand, if the player's main unit (their Gear Master) were to die, should I just say to them that they're just out of luck? I weighed my options, and decided to use a new approach: Allied revives. If a player dies somewhere on the field, it would introduce a teamwork aspect, as another player would have to risk their own Gear Master to go to the fallen player's location to revive them.
While this appeared to be a decent approach, I discovered by accident that the
fallen player's revive unit, a flag, could "stolen" by an enemy and placed
into an inaccessible location. Rather than try to prevent this from
happening, I decided to leave it in on account of it inadvertently added the
extra element of a "permanent" death that I'd originally wanted! Players
on both teams would have to race to a fallen player's flag to determine
whether that player gets to live or die, which in and of itself makes for a
unique in-game "capture the flag" aspect. Unfortunately, later into development (around the Mk I v2 release), I elected to use an auto-revive system instead. This was not necessarily because of any technical reasons. What I was observe ring from people's matches was a relatively high frequency of Gear Master deaths. With the risk of a Gear Master's death bringing the game to a halt for a given player, and because of the relative complexity of the map in general, I ended up having to make a hard choice. I cut the flag revives in favor of accessibility for beginners and smoother gameplay flow in general. Now, players instead incur a 45 second resurrection delay and a 100 mineral penalty for each death. As I was wrapping up the core functionality of the map, I only then finalized my decision to not add the mortar system I'd originally planned for. However, this left me with a rather large gap in the gameplay. Gears, because of the nature of the unit they're represented by (Terran Command Centers), are very slow. And I was stuck with a very large map for players to have them move around in. Without the added element of long-ranged mortars to make the slow speeds and large distances play a role, I now had to make an important decision. Should I find something for the Gears to do to fill in that gap, or simply shrink the map altogether?
It was then I learned how fun it is to shrink a map at the 80% complete stage.
Even if there were other editors that could handle that ability properly
besides SCMDraft 2, without SCMDraft's ability to cut and paste unit, sprites,
AND terrain, I probably would have just stopped working on the map right then
and there. It took me a full week of moving terrain sections, locations,
units, rebuilding the terrain ISOM under them, replacing missing or 'damaged'
parts from the move, and finally realigning everything back to what it was.
Remember kids: THIS is why you finish your planning BEFORE you start your
maps! After that ordeal, I ended up with the reasonably-sized 192x128 map that you see now, but I was still left haunted by the slow Gears. Necessity, being the prostitute mother of all invention, brought about two very fortunate ideas: Gear Teleports and Gear Propulsors. I'd originally intended Gateways to be no more than access points for the team's shop, but in hind sight, I think extending their functionality to allow teleporting added a very powerful element to the gameplay that I didn't expect. I hope players will in time learn to put this ability to good use. As a feature added almost at the very end of my main development (right before beta testing), the Gear Propulsors turned out to be another very useful idea. I've always been annoyed at the fact that I hadn't thought of them sooner, since they were the exact approach I was never able to get to use for Mechnogears that probably would have saved that old map from oblivion (if ever I managed to resolve its lag issues). The idea was simple: Give the players a toggleable unit with decent movement speed. The Gear would be made to 'stick' to that unit wherever it went, and thus be able to compensate for its slow speed. Simple and effective. The last of the map's major gameplay issues issues was now solved!
When my map was finally ready for beta testing, I don't think I was quite prepared for how many issues it ended up having. With me in particular, I have to be careful to avoid the death trap of blissful contentness with the state of my maps, as that in the past been the dominant reason for their relative failure. However, ending up with three solid months of beta testing to work out issues (which as of this writing is only just now beginning to wrap up) tells me I apparently didn't do as good a job at that as I'd thought. At the start of testing, the first problem to up and hit me like a professional boxer without gloves on was the lag! In Mechnogears, there was a similar lag issue that would compound from each additional player in the game. It was partly the reason that map had ended in a failure; multiplayer was unfeasible as a result. I was diligent with Astrogears from the start to try to prevent a similar fate by avoiding all potential lag culprits wherever I could. The main culprits usually come from "spamming" triggers; triggers that run in the background to constantly perform some kind of action (especially ones that create, order, or give units between players). However, Astrogears did not have any of these. Though the lag this time was in fact not as severe as Mechnogears', it was still there. And it was not ignorable. There were only a few points in the development where I almost despaired. The first was when I realized my mortar idea was not to be, leaving me to have to completely redo the map's layout to salvage things. Fortunately, as messy as that process was, it did eventually get resolved. The lag, on the other hand, was a complete mystery. I knew it had something to do with the triggers, but that didn't exactly narrow it down in any meaningful way.
I was then faced with a tough decision. Since I was determined to
NOT release another lag-ridden mess of a map, I would either have to spend
potentially months in a blindfolded struggle to identify the specific cause (if there even
was a specific one), cut off features until things improved, or scrap the map
altogether. Faced with uncertainty in any direction, things weren't
looking too hopeful. I feared that even if I fixed the problem, it might
mean compromising on some important part of the gameplay that would ultimately
diminish the map in general. Considering the map was already about as
'slimmed down' as I thought I could make it (compared to my original plan for
it, at least), I wasn't sure I was ready to take that blow. However, necessity was up to her old profession again, and I did arrive at a possible solution. I remembered that the map's Hyper Triggers (a trick used with maps to increase the number of times triggers are run every second) could be slowed down, in effect lessening the overall load of the triggers. Considering the map had amounted nearly 6k triggers, and that the fastest setting for hyper triggers forces them to be run 12 times every second... you can probably do the math. By slowing the speed down, however, I could reduced that number by half or more. The results were substantial. Up until then, anything past a 2v1 game was almost unplayable. After the change, I could host 2v2 games without even a hiccup. It appeared to work. However, even that simple change to the trigger rate would turn out to open up a bulk-sized can of worms, as all of the map's timed events and sequences, which were dependant upon the 12 per second trigger rate, would get thrown out of alignment. This meant a massive overhaul for all of the map's triggers that were dependant upon the timers (which was more than half of the full 6k). Though the overhaul succeeded, it would later haunt me with numerous issues over the next several betas. I remain a bit annoyed even now at having to have overhauled not just the map's terrain, but also its triggers as well. Oh well.
I've learned by now what I think is the best approach to beta testing from
my experiences with Rush and
Mechnogears. Getting everyone and their
neighbor to do it is not a good option. At least, not all at once.
You're going to want plenty of people, but one good tester who will help you
out consistently is better than 10 regular Joes who won't provide any feedback
whatsoever (though at least they can help pad out your games for lag testing
and other menial uses when they're around). It can be tricky assessing how
helpful people will end up being, though. Sometimes what will happen, in
the case of large maps, is that people will just get curious about the map and
sign up just to see it. Then once they do, you never hear from them again.
Sometimes they'd have technical problems, or simply end up not being physically
available. Or sometimes they'd just lose interest. It happens. Anyway, what I ended up doing for Astrogears was a multi-stage beta testing approach. At the onset, I got a decent number of people around to get things started. As the testing wore on, I turned to my more mainstay testers and some friends to help for the little random tweaks and changes that came up from time to time. Then, towards the end, I started to narrow down the list by skimming off the people who gave me little actual feedback during the testing. I also started pushing for more serious games during test sessions rather than the usual sandbox dinking. I could probably say that this was a mistake, since it was only when my testers started actually trying to play the map that the real bugs and gameplay issues started coming to the surface, leaving me to address them all right at the end. Oh well. Even though I did ask the beta testing to be kept non-public, the fact is that once someone gets a copy of your map, they'll have the same control as you do in who gets to see it. I wasn't too concerned with complete privacy, therefore. My main concern was simply having testers around as needed. More than half the original testers who signed actually did come through, though, which I am real pleased about. I'll be crediting them for their work when I release the map.
All in all, I'm pleased with the way things turned out. I did manage to get a playable map after all, even if its overall accessibility to normal players isn't as good as I'd hoped for. And I did manage to overcome all of the major issues from my previous failure with Mechnogears, which has been quite a substantial personal victory for me. I think I'll learn to make enjoyable maps yet! |