What are your preferences, habits, flaws, techniques when making maps? and tell us about your progress as a map maker. To add more initiating questions: Have you ever recycled triggers and terrain for other maps? What map types are the most satisfying or most tedious to work with? (defense maps against battle arenas with spells) How many of your maps felt sleek/well paced and which were just a random mess of ideas thrown together?

Nowadays I stopped using any form of choosers with "move unit to X location", unless it's units I can hotkey and move instantly by clicking anywhere. I try to recycle as many locations and death counters as I can. I get annoyed when I need to use up to 3 triggers to make just one-purpose cooldown timer with DCs. I have a bad habit of starting with the idea and mechanics of the map and leaving the level design as an afterthought. Nowadays I don't even bother with RPGs unless I have 100% all locations and ideas mapped out.
I end up struggling with the trigger editor and wasting time to copy the same trigger for all players for different locations. I still have an annoyance with the user interface taking up more than 5% of the map's size.

Post has been edited 1 time(s), last time on Oct 21 2018, 11:04 am by FlameViper.

I like to start a project, work on it for about 6 years, then give up with it about 2/3rds complete. But that's just me

I'm about the same as Vrael with less dedication. Cut 6 years to about 6 months for me.

Took Vrael just longer to admit

I have recurring habits when making maps, like always replacing built-in (Brood War) campaigns to place my missions, never distributing them as standalone maps.

I'm also meticulously commenting everything, explicitly splitting trigger sequences and location names depending on them belonging to a part of a mission.

I did recycle quite a few maps from the missions that ended up unused or obsolete for later projects - but I guess I'm really the same as Blizzard (unused missions from Rebel Yell -> Enslavers).

I liked writing AI Scripts, even though the latest advancements have made my knowledge and skills woefully out of date. I'm trying to catch up, though.

When I had an option I tried to keep portrait/sound sets for new heroes consistent. Say, if I wanted a hero to make use of Duke sound set(s) - 4 wht / 4 yes / 5 pss - I tried to give him the Duke portrait set (to be overwritten with something else too). Admittedly it reduced the amount of mess in the datafiles and allowed me to keep track of what went where better, especially because a lot of the time I was running more than one project simultaneously, and at times was getting confused as to what replaced what.

I think the best practice as a mapmaker is to abstract all triggers outside the map itself.
This means you should edit and create triggers in a separate IDE, ideally a programming one like PyCharm, rather than the clunky GUI editor. The other advantage is version controlling your map code. You should keep your triggers in GitHub repository or similar place, and treat it like a real technical project. There is a lack of "respect what comes before" in the community, because mappers do poor jobs of abstracting triggers and sharing them in common formats. For example, I should be able to get the triggers for Desert Strike from a GitHub repo and not need to ask the mapmaker or unprotect the map/extract from the chk, etc.

So for me, these are key to being a good map maker:

1. Write all triggers in external text editor/IDE (use one of the many trigger macro languages). I recommend knowing Python for this.
2. Version control your map's code, ideally using Git.
3. Add comments to all your triggers. You will thank yourself if you ever take a break and try to come back to your project in 6 months.
4. Be sympathetic to your "customers", which in our case is the players and maybe anyone who uses your map for their project.

What I am bad at:

1. Terrain. I'm just not an artist.
2. EUDs. I am a programmer by profession but I really don't grasp hacky low level operations on memory to create new behavior in SC.


This is why I created YATAPI which is a Python API for writing TrigEdit triggers. It's nothing fancy, but it lets you write all the triggers outside the editor. It would solve many of your issues. You would write the same code in one place for your trigger, and then iterate over parallel arrays of players/locations to create triggers for each player/location pair (net same number of triggers, but on your end it's just one trigger macro). There's an example in YATAPI just for that use case.