Mining Speed Measurement Methods

Today I’m going to discuss how I measured the mining speed in my previous post, because I didn’t use a stopwatch like some others have.  No, no, these results are far to important to be tainted by human hand eye coordination errors.  What I did, as usual, was to utilize the map editor.  The map editor will allow functions to be triggered when orders are given, such as those given to SCV’s.  Here’s a picture of the map I used:

In this map each of the SCV’s is adjacent to a point, which allows me to assign each of the SCV’s to its own varible, which ultimately makes it possible for me to track which SCV’s are doing what.  The mineral node in the green the circle is the node that I ordered them to mine from.  So after I order the SCV’s to mine, the game will naturally order the SCV’s back and forth from the command center and  the mineral patch.  The map I created has a function that gets triggered every time an SCV uses its harvest ability.  When triggered, the function records which SCV caused the trigger, what “stage” the SCV is in,  and the current mineral count and game time.

The actual event I used in my trigger was “Unit Uses Ability”, and the “Harvest” ability has many stages such as “Approach Resource”, “Wait at Resource”, and “Harvest”.   In my previous experiment, I dumped data to a list box in the UI.  This experiment lead to a lot more data, and so I wanted a way to write the data to a file.  It turns out that it is entirely possibly to do that using “Bank” functionality of the map editor.  Data stored in the bank is written to file after a custom game is saved and closed.  I used the bank to store the data from each event as as comma separated value (csv) row, which was stored as big string in the bank.  After the games is saved I opened the bank file, which on my computer was in “C:\Users\Sean\Documents\StarCraft II\Banks”.  The bank files are stored in XML format, so I just had to get rid of all that formatting, and afterwards I was able to load the data in Excel.  The rest just consisted of finding a fair way to choose a beginning and starting event in that data, calculating the differences in minerals and time, and dividing the two:

\text{Mining Rate } = \frac{\text{Number of Minerals Mined}}{\text{Duration of Mining}}

I still have the map if anyone wants to inspect/and/or use it.  Email sc2math@gmail.com, which I occasionally check.

Also, it was pointed out in a comment, that someone else has done some more testing on the mining speed issue, and I highly recommend checking this post out from the Team Liquid forums if you are interested in the topic: http://www.teamliquid.net/forum/viewmessage.php?topic_id=140055

Posted in Experiment Methods | Tagged , , , , | 1 Comment

How Many SCV’s Per Mineral Node

The fastest way to mine minerals is to put three SCV’s on each mineral patch. Three SCV’s will maximize the percentage of time that the mineral patch is being utilized. Any more than 3 SCV’s will not produce any extra results, unless the mineral patch is far from the command center, as is the case when remote mining. The rest of this post explains why three SCV’s is fastest, and reports the results of an experiment where the mining rates were measured for different numbers of SCV’s.

Only one SCV can harvest a given mineral patch at once. If two SCV’s are sent to mine a mineral patch at once, one of the SCV’s will begin mining, while the other waits for the first to finish. Any time that a mineral patch is not being mined by an SCV, it is not being utilized, which is a wasted opportunity to increase the harvesting rate. For example, when a mineral patch has only one SCV dedicated to it, all of the time the one SCV is travelling to and from the command center is time that another SCV could be mining from the patch. Adding a second and third SCV will ensure that the mineral patch is constantly being utilized. But after adding the third SCV, the mineral patch will be mined constantly, and adding a fourth SCV will not increase the amount of time the patch is being utilized, and therefore will not increase the harvesting rate.

The following relation summarizes the above and is satisfied (evaluates to true) if and only a mineral patch is being constantly utilized:

\text{travel time }\leq (\text{\# of SCV\'s}-1)*(\text{mining time})

On the Steppes of War map, I timed the amount of time it took to mine 200 minerals using one, two, and three SCV’s. The first row in the table below shows the amount of time, in game seconds, it took to mine the minerals. The second and third rows show the mineral mining rates. The last row shows the amount the mining rate increases by adding each SCV.

#SCV’s 1 2 3
Time 329.25 164.625 115.0625
(minerals/second) 0.6074 1.2148 1.7381
(minerals/minute) 36.444 72.888 104.286
Additional (minerals/minute) 36.444 36.444 31.398

The values from the table are not going to be the same for every mineral node, depending on the distance from the command center to the node. Adding the third SCV didn’t produce the same increase in mineral rate as the first and second SCV, but it came close. In the future I’m going to look at the other mineral nodes to see how they compare.

Posted in Game Mechanics | Tagged , , , , , | 3 Comments

Precise Measurent Using Map Editor

In my previous post, in order to get accurate measurements of how far an SCV travels over very small time intervals, I used some of the programming features of the map editor.  This post will not go over the basics of creating a map, but it will give most of the details of the map I created so that the experiment can be reproduced.  There are many YouTube videos that can help with learning how to use the map editor, but I found the following channel particularly useful:  GalaxyEditorTutorial.

The map we will create will allow the player to order an SCV to move between two predefined points by pressing a keyboard key.  The map will also include a timer and a list box, and will be programmed to print the relative position of the SCV into the list box every 0.0625 game seconds.  Here is an overview of the steps needed to create the map:

  1. Create two points with a distance of 4 grids between them.
  2. Create global timer and list box variables.
  3. Create an SCV positioned at the first point, angled toward the second point.
  4. Create a trigger to initialize the timer and list box.
  5. Create a trigger that will order the SCV to move to the second point and will also calculate the distance from the first point every 0.0625 game seconds (one game tick).

The first step is to setup the map with two points with a distance of 4 grids and an SCV at the first point.

Next create global variables for the dialog, list box, and timer.

All new maps start with a Melee Initialization trigger, which contain actions that are not useful for this type of map.  First delete those actions and add the following actions to initialize the global variables.

Finally, the last trigger is activated by the user pressing the 0 key.  This trigger first orders the SCV to move to the second point.  The rest of the actions consist of pairs of wait and print commands.  Each wait command forces the trigger to wait another game tick.  Each print command calculates the distance of the SCV from the first point and adds the value to the list box.

Finally this map can be run by dragging the map file onto the SC2 launcher desktop icon.  After the user presses the 0 button, the distances will be displayed in the list box.

Posted in Experiment Methods | Tagged , , , , | 3 Comments

SCV Acceleration

Below is a graph of the position, velocity, and acceleration of an SCV while it travels from one point to another with a distance of 4 grids between them. The SCV only changes position at every game tick, so the distance traveled function is not continuous and therefore not differentiable.

We can approximate the velocity at game tick i using: v(i)=\frac{d(i)-d(i-1) }{\frac{1}{16}}\frac{\text{grids}}{\text{game seconds}}

Approximate the acceleration at game tick i using: a(i)=\frac{v(i)-v(i-1) }{\frac{1}{16}}\frac{\text{grids}}{(\text{game seconds})^2}

We must also define the boundary values v(0)=0 and a(0)=0 .

The rest of this post covers some of the details of how to perform the calculations using a program such as Matlab/Octave. The distance values were obtained by using the programming features of the map editor to measure the distance of the SCV from its starting point at intervals of one sixteenth of a game second. Here is the code to create a vector with the distance values:

d=[0,
0.0293,
0.0586,
0.0977,
0.1465,
0.2051,
0.2734,
0.3516,
0.4395,
0.5371,
0.6445,
0.7617,
0.8887,
1.0254,
1.1719,
1.3281,
1.4941,
1.6699,
1.8457,
2.0215,
2.1973,
2.3730,
2.5488,
2.7148,
2.8711,
3.0176,
3.1543,
3.2813,
3.3984,
3.5059,
3.6035,
3.6914,
3.7695,
3.8379,
3.8965,
3.9453,
3.9844,
4.0000,
4.0000,
4.0000];

And this code creates the vector of time values at which each of the distances was measured:

t=0.0625*[0:1:39];

Here is the code to calculate the vector and acceleration values:

v=[0;diff(d)/(1/16)];
a=[0;diff(v)/(1/16)];

And the graph can be created using the plot function:

hold on;
plot(t,d)
plot(t,v)
plot(t,a)
hold off;

Posted in Game Mechanics | Tagged , , , , , | 1 Comment

Game Tick

The past week I’ve been exploring the functionality of the Starcraft II editor.  I discovered that the internal game clock operates at an interval of \frac{1}{16} of a game second.  Using the programming features in the map editor it’s possible to create a map that reports the positions of a moving unit.  If the position of a unit is reported at an interval less than \frac{1}{16} of a game second, then some of the positions will be duplicate.  If the positions are reported an interval of \frac{1}{32} game seconds, each position will be reported twice.

Posted in Game Mechanics | Tagged , , | 1 Comment

Game Speeds

StarCraft 2 has five game speed settings that a player can choose from: slower, slow, normal, fast, faster. In my previous post I determined the velocity of an SCV in terms of seconds when playing the game at normal speed.  At normal game speed, one unit of time, which I will refer to as an in game second, corresponds to an actual second. However when moving to different game speeds, that exact correspondence between game time and real time no longer applies.  In order to determine how fast a game second occurs in terms of real life seconds I devised a simple experiment.  I measured the amount of real life time it took a siege tank to traverse 224 grid lengths on each of the different game speeds:

slower slow normal fast faster
real seconds 127.42 169.62 102.10 84.88 72.55
real : game (seconds) 1:0.6 1:0.8 1:1 1:1.2 1:1.4

The first row above shows the actual amount of time it took the siege tank travel the entire distance. The second row shows the number of game seconds in each real second. To see how those numbers are calculated, consider the game speed faster:

\frac{102.10 \text{ real seconds @normal}}{72.55 \text{ real seconds @faster}}\times \frac{1\text{ game second}}{1\text{ real second @normal}} = \frac{1.40 \text{ game seconds}}{1\text{ real second @faster}}

These ratios can be useful to determine how quickly things will happen in fast game mode. For example, we know that an SCV has a full speed velocity of:

\frac{2.8125\text{ grid lengths}}{1\text{ game second}}

To figure out the velocity in terms of real seconds when playing the game at faster, use the following calculation:

\frac{2.8125\text{ grid lengths}}{1\text{ game second}}\times \frac{1.4\text{ game seconds}}{1\text{ real second @faster}} = \frac{3.9375\text{ grid lengths}}{1 \text{ real second @faster}}

Posted in Game Mechanics | Tagged , , | 6 Comments

Units for Unit Velocity

This article is about units of distance and time for in game units such as SCV’s and Marines. Unfortunately, that may be confusing because the word unit is being used for two different purposes in the same sentence. The different in game units in SC2 move at different speeds and that information can be looked up either in the map editor or online, for example at SC2Pod Wiki. Everywhere I looked, the movement speed of an SCV is stated as 2.8125, but the units of measurement are not reported. Without units, that number is meaningless except for comparison with other units. Even if some units such as “feet per second” were given, it still wouldn’t be useful, without some indicator of how far a foot in the game is, such as is provided by a legend in most maps. Another consideration is the fact that there are different game speeds and so we would need to know at which game speed the game seconds correspond to real life seconds.

I opened the map editor to see if it could help me figure this problem out. It turns out that there is an option to display a grid that overlays the map and each of the grid squares has a width and height that corresponds to the unit of length referred to implicitly in the SCV velocity. I also ended up figuring out that the unit of time is one second when playing the game at “normal” speed. I initially guessed and hoped that those would be the units, but I verified it through an experiment.

SCV Experiment Setup

The picture above shows the map I made to test my hypothesis. I had an SCV get a running head start so he would be at full speed by the time he reached the first vertical red line, at which point I started my stop watch. I then stopped my stop watch when he reached the final vertical red line. I added the roads along the vertical red lines, because the grid isn’t displayed outside of the map editor, and I loaded the map into the game by selecting “Test Document” in the drop down menu of the map editor. The amount of time it took the SCV to travel accross 16 grid lengths was 5.79 seconds.

\frac{16 \text{ grid lengths}}{5.79 \text{ seconds on normal speed}}= 2.76 \frac{\text{grid lengths}}{\text{seconds on normal speed}}\approx2.8125\frac{\text{?}}{\text{?}}

Since 2.76 is very close to 2.8125 I assume that I’m correct about my interpretations of the units for distance and time, and that the error of 0.05 is due to the imprecision of my hand eye coordination using the stop watch.

Posted in Game Mechanics | Tagged , | Leave a comment