In the previous tutorial we used the multirun command to run our research in parallel with our buildup. A big advantage is that we need not worry anymore about Pylons (thanks to the farms_timing command) and research in our main code section. We can concentrate on constructing peons (i.e. probes), buildings and units. Thus we get cleaner code. Another command that helps is the goto command.
Previously we had the following code:
...
wait_build 1 pylon
build 1 gateway 80
wait_buildstart 1 gateway
build 2 pylon 80
wait_buildstart 2 pylon
wait_build 1 gateway
train 1 zealot
build 3 gateway 80
wait_build 3 gateway
train 4 zealot
farms_timing
build 9 probe 80
wait_buildstart 9 probe
build 10 probe 80
wait_buildstart 10 probe
build 1 assimilator 80
wait_buildstart 1 assimilator
wait_build 1 pylon
build 2 forge 80
wait_buildstart 2 forge
build 11 probe 80
wait_buildstart 11 probe
...
Now we can replace it with the following piece of code (in our main section) - the new lines are drawn bold (and bigger):
...
goto b_gateway
:a_gateway
farms_timing
build 9 probe 80
wait_buildstart 9 probe
build 10 probe 80
wait_buildstart 10 probe
build 1 assimilator 80
wait_buildstart 1 assimilator
goto b_forge
:a_forge
build 11 probe 80
wait_buildstart 11 probe
...
and two small pieces of code at the end of our file (i.e. after "goto repeatrush"):
; >> GATEWAY SCRIPT PART
:b_gateway
wait_build 1 pylon
build 1 gateway 80
wait_buildstart 1 gateway
build 2 pylon 80
wait_buildstart 2 pylon
wait_build 1 gateway
train 1 zealot
build 3 gateway 80
wait_build 3 gateway
train 4 zealot
goto a_gateway
; >> FORGE SCRIPT PART
:b_forge
wait_build 1 pylon
build 2 forge 80
wait_buildstart 2 forge
goto a_forge
To be honest, this doesn't make our script any more powerful. If you look at it for
a while you'll see it doesn't add anything. It's just the same code, but some of the
code is now located at the end of the file. The main advantage is that you can now
decide to write these small pieces of code first (and make sure they are correct)
and insert them anywhere into the main code section. Inserting them is as much trouble
as writing two lines of code.
First we'll code some script parts that can add some photon cannons, shield batteries and of course a cybernetics core:
; >> PHOTON CANNON 0 SCRIPT PART
:b_cannon0
wait_build 1 forge
build 1 photon_cannon 80
wait_buildstart 1 photon_cannon
build 2 photon_cannon 80
wait_buildstart 2 photon_cannon
goto a_cannon0
; >> SHIELD BATTERY SCRIPT PART
:b_shield
wait_build 1 cybernetics_core
build 1 shield_battery 80
wait_build 1 shield_battery
build 2 shield_battery 80
wait_build 2 shield_battery
goto a_shield
; >> CYBERNETICS CORE SCRIPT PART
:b_cybernetics
wait_build 1 gateway
build 2 cybernetics_core 80
wait_buildstart 2 cybernetics_core
build 4 gateway 80
wait_buildstart 4 gateway
goto a_cybernetics
Just study these parts for a short while, then you'll see there's nothing new here.
The photon cannon part is called "b_cannon0", because there are two
parts: "b_cannon0" and "b_cannon1". We'll get at the 2nd part later.
The 2nd cybernetics core might be a bit overkill, especially early on, but
as you'll see later, this script is aimed at the high resource map Fastest Map Ever.
Besides, upgrading is very important, and having
two cybernetics cores doubles our upgrade capacity.
The next step is to include the code parts for the robotics tree:
; >> ROBOTICS 0 SCRIPT PART
:b_robotics0
wait_build 1 cybernetics_core
build 1 robotics_facility 80
wait_buildstart 1 robotics_facility
wait_build 1 robotics_facility
train 1 shuttle
goto a_robotics0
; >> ROBOTICS 1 SCRIPT PART
:b_robotics1
wait_build 1 robotics_facility
build 1 robotics_support_bay 80
wait_buildstart 1 robotics_support_bay
build 1 observatory 80
wait_buildstart 1 observatory
build 2 robotics_facility 80
wait_buildstart 2 robotics_facility
wait_build 1 robotics_support_bay
train 1 reaver
wait_build 1 observatory
train 1 observer
goto a_robotics1
; >> ROBOTICS 2 SCRIPT PART
:b_robotics2
wait_build 1 robotics_facility
build 4 robotics_facility 80
wait_buildstart 4 robotics_facility
goto a_robotics2
No surprises here. The robotics tree is split up in 3 parts, so we can be more flexible
in chosing our buildup. Perhaps one could leave out the training of a Shuttle, reaver
or Observer to get a faster buildup. Remember though, an advanced unit like the reaver
is always useful, if not for offence, then for defense.
The next 3 script parts are the most important parts of our buildup phase. They represent the fleet, templar and arbiter tree.
; >> FLEET SCRIPT PART
:b_fleet
wait_build 1 cybernetics_core
build 1 stargate 80
wait_buildstart 1 stargate
wait_build 1 stargate
train 1 corsair
build 1 fleet_beacon 80
wait_buildstart 1 fleet_beacon
build 3 stargate 80
wait_buildstart 3 stargate
goto a_fleet
; >> TEMPLAR SCRIPT PART
:b_templar
wait_build 1 cybernetics_core
build 1 citadel_of_adun 80
wait_buildstart 1 citadel_of_adun
wait_build 1 citadel_of_adun
build 1 templar_archives 80
wait_buildstart 1 templar_archives
build 5 gateway 80
wait_buildstart 5 gateway
wait_build 1 templar_archives
train 4 high_templar
goto a_templar
; >> ARBITER SCRIPT PART
:b_arbiter
wait_build 1 stargate
wait_build 1 templar_archives
build 1 arbiter_tribunal 80
wait_buildstart 1 arbiter_tribunal
build 5 stargate 80
wait_buildstart 5 stargate
wait_build 1 arbiter_tribunal
place_guard arbiter 0
train 3 carrier
train 1 arbiter
build 6 stargate 80
wait_buildstart 6 stargate
goto a_arbiter
A big suprise here. We use the place_guard to define a guarding role for our arbiters.
Without this command the game would crash! So make sure you put a line "place_guard arbiter 0"
in every script where you plan to use arbiters (and they should be included in every Protoss script,
because they are really, really powerful). The line should be included before you train the 1st
arbiter. The place_guard command is also often used for high templars, science vessels and queens.
We conclude the set of buildup script parts with the 2nd photon cannon buildup part:
; >> PHOTON CANNON 1 SCRIPT PART
:b_cannon1
wait_build 1 forge
build 3 photon_cannon 80
wait_buildstart 3 photon_cannon
build 4 photon_cannon 80
wait_buildstart 4 photon_cannon
build 5 photon_cannon 80
wait_buildstart 5 photon_cannon
build 6 photon_cannon 80
wait_buildstart 6 photon_cannon
build 7 photon_cannon 80
wait_buildstart 7 photon_cannon
build 8 photon_cannon 80
wait_buildstart 8 photon_cannon
build 9 photon_cannon 80
wait_buildstart 9 photon_cannon
goto a_cannon1
Absolutely straightforward! Easy to create, manage and use, though, personally, I would refrain from using
identifier names ending in numbers too much. It's easy to mistype something like "a_cannon1",
you could end up typing "a_cannon0". Also the choice of "a_" vs "b_" as the only difference
between ending and beginning identifiers, improves the chances of hard to find script errors.
Luckily you won't make the same mistake ;)
In this section we will introduce a piece of code which will help us test our scripts faster. The command that will help us test our scripts is called give_money. It is a command that shouldn't be used in custom scripts, officially, but, officially, we shouldn't be editing the Patch_rt.mpq either. If it helps to test our scripts faster it can't be that bad.
We use the multirun command in combination with an endless loop (goto) and a delay (wait). First we add a line to the start of our script:
; === START ===
build 1 nexus 150
wait_build 1 nexus
build 4 probe 130
wait_build 4 probe
; === MAIN ===
multirun m_myfunding
Then we add a small loop at the end of our script file:
; --- FUNDING MULTIRUN SCRIPT
:m_myfunding
wait 500
give_money
goto m_myfunding
Here you have it. We can change the wait value to 5000 if we want our AI to play fair. Change it to 50 and your AI will never need to harvest anything. The values for testing purposes should be around 250 or 500. Once you have tested the AI enough you can set it back to 1000 or higher. A little warning: the extra gas and money awarded by the "give_money" command is added to any computer controlled player, at least in multiplayer games. The only one who won't be getting extra resources will be you!
The script parts we have created in this section enable us to write a more advanced AI script, one that builds all the way up to the arbiter tribunal. In the long run this will make our AI superior to any other AI out there, that doesn't try to benefit from one of the most powerful units in the game: the arbiter.
Let us proceed to the next page where we will first
write the attack script parts and then finish the script parts with more very important upgrade and tech research.
| Previous | Back to Index | Next |