The Path Of Proper Map Making A lot of mappers, especially new ones would probably ask this question. How to create a good map? There are a lot of ways to do so. To start with, I will begin with scripting/triggering. The Importance Of Proper Scripting A lot of people (Especially new users), often adopt the motto of "As long as it works". This resulted in a poor scripted maps that often cause players to disconnect or long loading time. Let us take a example, shall we? Respawn Events Time - Every 30.00 seconds of game time Conditions Actions Unit - Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing 0.00 degrees Respawn Events Time - Every 30.00 seconds of game time Conditions Actions Set Respawn = (Center of (Playable map area)) Unit - Create 1 Footman for Player 1 (Red) at Respawn facing 0.00 degrees Custom script: call RemoveLocation (udg_Respawn) From what you see. I assume you would said both of them work the same, and you are right. Both triggers are the same, they spawn 1 footman every 30 seconds for player 1. Although the concept was the same, but there is something that separates both of them. What is that? One was coded at ineffective way (Results into long loading time, disconnect, lag, file size larger and so on) while the other was coded at optimized way (Results into smooth running map with little or no lag at all). The first trigger you had seen works just like the second trigger. Unfortunately, it does not destroy a memory leak which could resulted into a total disaster. That is part of the reason of why a proper scripting is important. To know what is memory leak about, search a tutorial about memory leak. Another tutorial of mine have a brief explaination of what is memory leak about. Click at this link below to read my other tutorial. The Importance of Efficiency in Coding What Should Be Avoid And Why? A lot of mapper doesn't like to receive a negative critism. If your map was well develop, would you receive a negative critism about your map? Definitely you would not receive it. Surely you can said "I don wanna make uber map", but even if you are trying to make a decent map. There is a guidelines to be follow as well. If you doesn't want to follow it, you would never make a decent map even though you are using World Editor for 5,000 years. This is the list of thing you must avoid. 1) Make a map out of boredom This is definitely a NO. When you are making a map out of boredom, it usually turn out to be terrible work as you are making it in such a rush without conducting any test at all. If you make such a map, never release it to map section forum at respectable site where the map would be evaluate based on the standard such as wc3c.net or hiveworkshop.com as you would likely get a harsh critism and make a fool out of yourself. In the end, you would probably flame the user and get banned or negative reputation by the staff. Do you want that to happen? 2) Let the user test it Never ever release your map in hope of the user itself would test it for you. You should test the map by yourself to know what is wrong even if your map was a multiplayer map as you know better since you was the creator. Given a excuse of "This was a multiplayer map" is not a excuse since you could host it yourself at LAN/Internet to try it out. The excuse you given is not to the other, but to yourself. If you really need somebody to test it, you should post a request at forum such as Map Development section at hiveworkshop.com or Map Testing section at wc3c.net to get any volunteer to be map tester. Not posting/upload it to map section that are reserve for complete map to get yourself a map tester as it was simply unprofessional. If you upload bugged/incomplete map at section that are reserve for complete map. You would likely have your map rejected by the staff or probably worst. The user might not download it and play the map ever again after seeing it as a piece of crap. Infact, if the user seen another player host this map at LAN/Internet. The user would probably warn the other not to host it. Do you need people to discourage other from hosting your map? I do not think so. 3) Never start a mega project A lot of mapper especially newbie usually failed in map making. Why? Because they start to make a compleks map without even thinking if they have enough time, skill, dedication and effort to do so. This resulted into project being abandon during half way. Some mapper probably create over 10 map, but none of it finish. Why? I guess I already explain it, did't I? Waste of time and effort, make your finger and brain sore from all those work for partically nothing. Do you want that? 4) Lack of Description/Detail/Information Whenever you are making a map, detail are always important. It could range from item, quest log, ability, structure, upgrade and so on. A indepth description would not only help user, but it would prevent the user from the state of confusion because they do not know what to do. If a user doesn't know what to play and what to do during the gameplay, they would probably quit the game even before they started. If you upload the resources to a site where it require you to wrote a description such as hiveworkshop or wc3c. Writing a decent description not only spare your map from rejection, but could probably attract user from downloading your resources. A example of a map thread with fine description can be seen below. Brotherhood Of Kenji - The Hive Workshop - A Warcraft III Modding Site The Chosen Ones 3.1a - The Hive Workshop - A Warcraft III Modding Site Diablo III Beta v1.11 - The Hive Workshop - A Warcraft III Modding Site As you can see, a good description not only look attractive. But it could also encourage user to download it and helpful in every aspect. It might be tendious to wrote those detail, but the work would paid off. 5) Never accept constructive review A lot of mapper fail to make a good map lies at this part as well. They do not accept constructive critism of what's wrong with their map and often regard it as flamming/trolling. To make it worst, some mapper have the lack of sportsmanship as well. Just because a much experience mapper or user told them of what's wrong with their map, this type of mapper rant their anger out of them simply by downrating their resources or flamming them. This would eventually resulted into people no longer interest of telling the mapper of what's wrong with their map. By doing this, you not only discourage people from download your map. You also lost a biggest asset of all time. To be honest, if you are seeking for map tester to find out what is wrong and a user who appear out of nowhere telling you what's wrong with your map. Ain't you get yourself a free volunteer and free review out of it? Accepting a constructive critism from map tester, but not from user is likely to be contradiction. It not only make yourself look foolish if you did that, it also makes yourself look like a perfect idiot and believe me. Nothing is much more suitable to describe a perfect idiot than this. To outline a difference of constructive critism or not. Here is a example below. As for this, it isn't constructive. So, it was acceptable for you to denied his post. As for this quote above, it was a constructive critism. Not flamming the map or the author of the map. So, take note of what it written and hopefully it would help. If there is something you disagree, try to give reason about it. Learn to have a sportsmanship, never downrated other people resources out of anger or flamming them especially if they give a constructive critism. Thanks them if they give such a review, you would eventually learn how to make a better map faster than a knife cut through a butter. Positive critism is nice to heard and nice to see. But, do they help you in mapping? That is the question you should ask yourself. And if a map was indeed superb, it would definitely earn a positive critism. 6) Protecting a map Protecting a map while you know little to nothing about map editing was a stupid thing to do. First of all, open sources map are easy to be review and also enable a much experience map maker to view the scripting/triggering to point out the flaw of your coding. If you know the flaw of your coding, you would be able to fix it and this would benefict your map in term of efficiency. You might also learn something useful from it. Protecting a map because you do not want your map idea to be stolen is absolute nonsense because of 3 reasons. I) Experience map maker could have easily develop such a map with better concept, better coding and terrain compare to you. II) You lost yourself a free volunteer that help you fix/point the bug of the map coding. II) It was a idea, anybody could have a similiar idea. For example, just because your map idea was Tower Defense; it doesn't mean other people never though of making a Tower Defense map. What Should Be Done? Ok, now this is the list of thing you should do if you wish to make a good map. 1) Planning Always plan what to make. Planning doesn't generally like "Oh, I have a idea. Let's do it". The planning revolve a lot of aspect ranging from the game concept, terrain, custom import, scripting/triggering, file size and many more. You need to take concern of it or else your map would never became a good map. I would take a few example such as file size. When you are making a map, you want it to have lot's of fancy model/icon/skin to make your map goes WOW. But, you need to take care the file size as well especially when it was a multiplayer map. What happen when your file size exceed 4mb (The max size permitted for multiplayer map) due to custom import? Your map would eventually unable to be host, resulted into nobody playing your map at all. Even if your map does not exceed 4mb (Let's said 3.9mb) and your map was a 10 player map. Trying to host it at full house was nearly impossible as the download time could take a hell long time depends on the host and player connection. This resulted into player leaving the room before the game even started. Surely you can said "You are hosting this map with bunch of impatient kids". Believe it or not, nobody going to waste a hell long time to download a map that they know nothing about it (Especially new map). What happen if they do download it only to find out it was terrible? I guess I do not need to explain this part, do I? Planning could take up to a month or probably longer. But once you have a plan, the execution would be quick and smooth. 2) Research Always make a research (Especially scripting/triggering) as you might found something that are useful. For example, you only know how to script/trigger in GUI. One day you make a research and found out it could be code at JASS/VJASS and it was far superior. What happen? Congratulation, you just take another step in developing a much better map. 3) Ask Do not be shy to post a question at forum when you do not know how to resolve a problem regarding your map. But at the same time, make a research before you ask the question as it might already been answer at tutorial. Do not expect user to create the solution for you (Especially in scripting/triggering). Try to make it by yourself first and show your work to the other and they would naturally gives you a better solution. Begging and asking someone else to do it for your would likely get your thread ignore. 4) Testing Always test your map as you know your map better than anybody else. Before you release it, it was recommend you conduct more test. 5) Avoid minor bug Minor bug are usually refer to inproper hotkey, missing dis_btn and so on. Even if your map was a beta stage map, always ensure small problem such as inproper hotkey been fix before the map release. Map such as TD or AOS would give a hell lot's of problem to the user if there is a inproper hotkey. For example, if I want to select hero A at the tavern and the hotkey that shown was A; I press A button only to get a hero B. It not only annoying, but discourage user from playing it. That's all my tutorial at this moment. Hope it could help mapper in developing a much better map in the future. Credit List bounty hunter2 - Fix grammar mistake. Aeroblyctos - Mention a error at the example I show due to exhaustion. Eleandor - Point out a grammar error.