1. Information Ensure you've read the Crash Course thread before you start with missions. Simply choose a mission topic and try to solve it, and when done, or things need to be discussed make a thread about it. 2. Missions Universal Readme The "Universal" topic covers some general content that might be used in most type of games and is always useful to know. 1. Order Tracking Submitter: IcemanBo Order When a unit is supposed to do something it receives a certain order, which always has a specified order id. Some order ids have a string equivalent, like order id 851983 equals order string "attack", though not all order ids have a string equivalent. Preparation Preplace some units on map, like builders, magic units, etc. Part 1 Create a trigger that should detect any order a unit does, and print the unit's name and the issued order id on screen. Part 2 Now it should also print the order's equivalent string or the name of issued object id being ordered (in same line). For example 851983 should also print "attack", and 'hbar' should also print "Barracks", so the user can easily see which order is behind the id. Conclusion Such order tracking can be very useful to analyse mechanics, or to understand what is going on in case something doesn't work as expected. 2. Wanderer Submitter: IcemanBo Preparation Preplaced units are not allowed. Global variabels other than the hashtable are not allowed. Hashtable must be used. Timer must be used. Part 1 Create a gryphon rider at center of the map. The gryphon must receive a move order to a random location. The random location is defined to have a random distance between 500 and 1500 and to have a random angle towards the gryphon. (so basicly the location is a random point in a circular range of 500-1500 from the gryphon) Part 2 Now when receiving the move order to the random location, then the tileset at target location should turn to snow, 'Nsnw'. When reaching the target location point, then the tileset should become the original tileset again, and the unit should repeat the procedure, receiving a new order, tile becomes snow, etc... again and again. 3. Unit Spawn Submitter: IcemanBo The goal of this mission is to create 4 bases which spawn units that fight against the enemy. Preparation Preplaced units are not allowed. Part 1 Create 20 random creeps on map initialization with random level at location 0/0 for player Neutral Hostile. (The Enemy) Player 1-4 must be set as allies. Part 2 Create 4 barracks, one for each player, player 1-4 respectivly. The barracks represent the base for each player. The barracks must be located so they form a square around the enemy location 0/0. Their distance to 0/0 must be 3000. Part 3 Each 2.5 seconds a footman, or a rifleman (randomly) must be created at each living base and receive an attack order towards the enemy location (0/0). In case the base is dead/destroyed, the periodic creation must not continue for this certain base. Part 4 The periodic calls to create units at the barracks must stop once there's no enemy alive anymore. Furthermore a message "You won!" must be printed on screen for all players, and all alive footmen and riflemen must be exploded on death. 4. Dummy Unit Submitter: IcemanBo Dummy A dummy unit is a tool that is used as medium for certain goals like casting spells, or attaching visible effects. The dummy itself doesn't have any impact on the gameplay other than it's explicitly strived goal - like for example it mustn't have any collision enabled and can't be killed or attacked by other units. Preparation Object Editor data is required to be used, and probably an import model, too. Maybe helpful: Single Target Spell for Multiple Units Part 1 Create a Tauren Chieftain at the center of the map. When Player Red presses the 'Esc' button (Skip Cinematic) a dummy unit must cast "Shockwave" into the direction of the Tauren Chieftain. Part 2 Now, enhance the trigger so the dummy unit casts 8 shockwaves into circular directions (all around the Tauren) when pressing the 'Esc' button. Only one dummy unit is allowed to be used to cast those 8 shockwaves. Part 3 Take the concept from before, but instead of one dummy casting 8 shockwaves, you now create 8 dummy units that look like a shockwave. Those dummy units must mimic the shockwave movement, and travel 1000 (distance) in their specific direction. Their speed is not so relevant, but should be more or less equal the speed of a normal shockwave. Part 4 Enhance the code of "Part 3" and now also damage all enemy units that collide with the shockwaves (dummy units). The amount is 100 damage per second. Items Readme The following two missions are about item management. The focus lies on stacking and splitting items, but they also bring and require some general knowledge that will help also for other item related questions. 5. Item Stack Submitter: IcemanBo Item Stack Item stacking is the process of merging two chargeable items of the same item type. The charges of one item gets adopted to the other item. Preparation For some part "Order Tracking" mission might become useful. Preplace some stackable items like healing, or mana potions, some non-stackable items, and one hero unit on the map. Part 1 Create a trigger that prints the name and charges of an item when picked up, example "Healing Potion ", where "Healing Potion" might be the item's name and "1" it's current charge. When the item is not chargeable, then only the item's name without charges must be displayed. Part 2 Now enhance the trigger that it makes a check if the unit already has an item of same type in current inventory (in case it's stackable). If true, then the new picked up item must be stacked with found item, and the displaying message must make it clear that the item was not normaly picked up, but stacked. For example: "Healing Potion [+1]", where the "+" implies that only the item charge was added. Part 3 Add a maximum capacity of "3" for item stacking, which means that one item never stacks higher than "3". Part 4 When moving one stackable item at the slot of an other stackable item, they they must be stacked (if allowed due to max capacity). 6. Item Split Submitter: IcemanBo Item Split Item splitting is the process of deviding one chargeable item into two items of the origin item type. The charges of the newly created item equals the charges that get substracted from the original item. Preparation The "Item Stack" mission triggers are required to exist. The "Order Tracking" mission might become useful, too. Preplace some stackable items like healing, or mana potions, some non-stackable items, and one hero unit on the map. Part 1 Create a trigger that runs when the unit moves a stackable item on it's own slot. In case the charges are bigger than "1", then the item must be splitted by amount of "1". Part 2 Enhance the trigger that if the unit does have an other stackable item of the same item type in current inventory, then the split should be stacked with it (if allowed due to max capacity). Slide, Slider, Slide Readme Here are a few missions around a conrete genre, a sliding game. Use following template map for solving missions, it contains new terrain, and 2 already created object data units. <Download Me> A sliding map is a map where units are sliding (continually moving) over certain terrain types, usually ice, without the possibility to stop. The sliding behaviour is defined by speed, which is normaly constant, and the sliding direction, which is defined by orders (mouse clicks). The goal is to navigate the slider through the map and to reach the finish without dying. Start is defined by Player Red's start location. Finish is defined by the "Finish" unit placed on the map. (it looks like a circle) 7. Slider Submitter: IcemanBo Dialog A dialog is basicly a selection menu where the user has the choice to press a button. We will use such a dialog to create a slider selection system. Preparation Preplaced units are not allowed. Hashtable needs to be used for the dialog system. Part 1 Create a dialog for all players as soon as possible with title "Choose A Car". In the dialog there must be two buttons, "Tank" and "Bike", which should create the respective unit (see object editor) for the clicking player at the start location. The clicking player must automaticaly select the slider, and his cam must be moved instantly to his slider's position. Part 2 When the slider is created we want to esnure that he has no pathing map enabled, so sliders don't block each other. Furthermore we want to apply a little trick so the slider gets "untargetable" with right click, wich results that we can not accidently misclick on an other slider, if we only wanted to right-click on terrain. (clicking on other sliders is in no way useful in here) Tip: Search for this trick, there are several threads with this information, but attention, the slider must be still selectable! 8. Sliding Submitter: IcemanBo Sliding Sliding is the process of continually moving a unit via triggers. Here, we define different sliding behaviour, depending on the current terrain type. Preparation Hashtable must be used. If nothing is defined, the terrain type should not be slideable, and just do nothing by itself, aka it will result in normal walkable terrain. Part 1 On "Northrend - Ice", "Icerown Glacier - Dark Ice" and "Underground - Lava" a slider will slide with speed of "400" per second in the direction of his facing. On "Northrend - Snow" a slider will instantly die. Tip: A periodic check needs to be used to determine the current terrain type at the slider's location. And the sliding should look fluent, which means that simply moving a unit with "400" offset each second is not enough. : ) Part 2 The slider's normal movement must be/get disabled while he is sliding, but activated when it's on terrain which does nothing. 9. Steering Submitter: IcemanBo Sterring Sterring defines the slider's turning behaviour while sliding. Part 1 On "Northrend - Ice" the slider must be able to turn normaly. On "Icerown Glacier - Dark Ice" the slider's steering must be disabled, that means that trying to turn will lead to no effect. On "Underground - Lava" the slider's steering will be reversed, which means the slider will turn in exactly the opposite direction, where the player clicked at. Tip: The order which we need to filter to allow/manipulate a slider's turns is the "smart" point order. 10. Death Submitter: IcemanBo Part 1 When a slider dies, a death message with the player's name must show up. Furthermore he must be revived automaticaly after 3 seconds at the start location, the respective player's cam must be insnatly moved there, and the revived unit must be selected for the player. 11. Finish Submitter: IcemanBo Finish The slider's goal is to reach the finish. Preparation Preplaced units, the finish (already existent) should be used. Part 1 Ensure that the finish is not clickable, not killable, and doesn't have any collision enabled during the game. When a slider comes in range of "90" towards the finish, a winning message should be printed and all neutral hostile units must be removed from map. Data Structures Readme First to say, this will not be about pure learning 20 types of data structures, but it will mainly focus on just giving the possibility to structure and to keep track of your data with one or two methods you can use. Data strcucture is a tool to organize wanted data in the explicit way you need to use it properly and/or effectively. Example, unit groups, array, and hashtable can be seen as dats structures, but it's not at all limited to it - you can and will write often your own custom data strucutres. With the years I personaly changed my view about data structures multiple times, and I think now that it's at first pretty important to think of exactly what for or if a new explicit data structure is needed at all. All missions we made before one could solve without making new or complex data structure, but simple array or hashtable (attaching) could be used. Yes, you pretty much always can create high structures like doubly linked lists if you want, but you often won't need it. You often have singular data pieces that need to be tracked on, but only if it makes sense to logicaly bind such single data pieces to each other, only then you actually need a new data structure. Else for example often just single timers and hashtable might be used for tracking the single data pieces. So for example if I want have functions that go through all my running spell instances and stops/manipulates them etc, then all data pieces share some same logics, and then it makes sense to use a data strucutre, so I can keep track of all the data together instead of refering to each single one in a timer callback. But when all data pieces have nothing in common, then I don't necessarily need to put them all into an extra data structure, as it easily may result in logical overheard. 12. Dynamic Indexing Submitter: IcemanBo Dynamic indexing is a data structure method that allows efficient looping through all your instances with not too much of work. In GUI it is's a very popular approach to achieve MUI state for a code, but in JASS it's not always used as primary data structure, depending on the use case. It's still important to understand. Firstly, find out about dynamic indexing -- this is a must have read tutorial about it: Visualize: Dynamic Indexing When applying dynamic indexing, you will end up having one data array which holds all your instances, and the highest instance index will always equal the amount of registered instances. (Meaning that there's no gap in the array, too.) Though, due of the nature of the de-indexing process of dynamic indexing the elements in the array might get mixed up after some removal of Elements. This order change might bring logical errors into gameplay, as it can happen that instances that were registered logicaly after an other instance might operate at first now. When usually "b" acts after "a", now, after some de-index process "b" might come before "a" and so act first, too. But there are still many cases where the instances don't and even can't influence each other, and then dynamic indexing can make sense as instance tracking method. So basically potentially always when the order of registered instances does not matter. Also, especially the direct access to the data array can be very useful, as it gives you power to refer to the data structure as a whole. -- The user can easily reference the maximum amount of elements, and can even get a random element out of the data structure with simply randomozing an index from 0 to max-index. Think of one example where it may make sense to use dynamic indexing, so where the logical order in which the loops access the instances does not matter for the gameplay. It may be a very simple code sample, but it should work properly. Please share your example in a thread. 13. Linked List Submitter: IcemanBo There are multiple type of lists, but we wanna look at only one specific one, the double linked list. The double linked list has fairly good insertion and fairly good deletion performance, but requires more structure data than for example a single linked list. That is because each element has 2 pointer elements that do nothing but organizing the structure, "prev" - and "next" element. Find out and understand what a double linked list actually is and try to understand how it works. Here are two examples you should have read (but you will find more): [Trigger] - Why dynamic indexing is flawed and people should use linked list instead Double linked lists? When you understood the principle of a double linked list you will understand that it uses the power of "prev" and "next" links to not randomly mix up the order of elements like dynamic indexing does it for example. So, what's registered after an element will always stay after the element, and won't be accidently moved in front of it, when some data gets deleated, for example. But with a double linked list you lack of a simple random data access, as you only can access your data sequential through a loop, and you also don't necessarily have a counter for the amount of elements. Think of one example where it makes sense to implement a doubly linked list instead of dynamic indexing - so where you think it's logicaly important not to change the order of registered instances. It may be a very simple code sample, but it should work properly. Please share your example in a thread. Tip: You don't have to create a full double linked list structure with imba functionality like adding a node before and after any other node, but the principle of doubly linked elements should be clear and work properly.