RoboMiner Mechanics

In this section the mechanics of the RoboMiner Robots are explained.

Ore Container

The Ore Container is the part of the Robot that stores the ore mined. The size of the container limits the maximum amount of ore stored, but is also a big influence to the weight and size of the Robot.

Every ore container is aware of the different types of ore stored inside it. Also, it is able to dump the ore it contains, either one specific type of ore or all of it.

Use robot.oreStored and robot.oreStoredA / robot.oreStoredB / robot.oreStoredC to read how much ore is in the container (total or per type). Use dumpA() / dumpB() / dumpC() to dump one type, or dump() for all of it.

Depot

The depot is a personal ore bank for each ore type, separate from the robot's ore container and from your wallet on the account page. Capacity starts at 0 for every ore type and is raised by achievement steps that award a depot maximum (shown on the Achievements page).

During a rally, dump() / dumpA() / dumpB() / dumpC() at your spawn corner fills the depot up to the unlocked capacity for that ore type. Any overflow is placed on the ground under the robot, the same as a normal dump. Away from spawn, dump() always puts ore on the ground — the depot is not used.

At the end of the rally, ore still in the container and ore already in the depot are added together for your mining result and score.

On the rally replay, a translucent square in your player color marks the spawn corner where depot dumps land, and the player card shows depot fill next to cargo when capacity is unlocked.

Mining Unit

The Mining Unit is the part of the Robot that is put to work when executing the mine() command. Unlike the Ore Container it is not aware of the different types of ore.

Mostly, one cycle of mining won't be enough to mine all the ore from one square. The amount of ore mined in one cycle is limited by two factors:

• The Mining Units Mining capacity. In one cycle, the mining unit can never mine more ore then its Mining Capacity.
• The amount of ore at the current location. In one cycle, the mining unit can never mine more then half the ore available at the current location, rounded up.

Besides the Mining Capacity there also is a large variation in power consumption and weight between the different mining units.

Battery

The Battery is what powers the Robot during the mining session. Besides that, the Battery is also the part responsible for the recharge periods between mining sessions.

Every part on the Robot, except the Battery itself, consumes power during a mining session. The power consumption is constant, parts that aren't active at the moment consume the same amount of power as active ones.

Add the power consumption of every part attached to the robot and divide the Battery Capacity by the result to calculate the maximum number of mining cycles the Robot can be active. This result is also visible on the Robots page.

The recharge time is even simpler, it is shown directly in the Shop. Recharge times can vary widely between different batteries, especially for the more advanced once.

Memory Module

The Memory Module stores the Robot program currently active for the Robot. The Memory size determines the maximum number of low-level instructions it can contain.

To calculate the number of low-level instructions of a program simply save it on the Edit code page. Assuming your code is compilable, it will show you the Compiled size on the bottom of the page. This Compiled size is the amount of low-level instructions.

There are two ways to upload new code to the Memory Module.

First, on the Robots page you can attach a Source code to the Robot. When you click on the Apply button on the bottom of the page, the code is uploaded to the Memory Module. If the Robot is mining at that point of time, this upload will be delayed until the end of the current mining session.

Secondly, when you're on the Edit code page and click on the Save button, the program will be uploaded to the Memory Module when the following conditions are met:

• The program is compilable.
• The Source code is linked to the Robot.
• The Compiled size is equal to or smaller then the Memory Modules capacity.
• The Robot is not mining at the time the Save button is pressed.

When one or more of these conditions are not met, use the first method to upload the code, if desired.

The Power consumption slightly increases with the Memory size of the Memory Module. So it is advisable to use the smallest Memory Module that can contain your compiled code.

CPU

The CPU is probably the most complicated part of the Robot. Besides a slight variation in Power consumption, it has one important property: The CPU speed.

In order to understand this property, it is important to know the difference between CPU actions and Physical actions of your Robot.

Physical actions are the actions that move your Robot or the ore in some kind of way. So move() is a physical action, as is rotate(), mine() and dump().

CPU actions are flow control, calculations, variable assignment, time(), and robot property reads (including robot.oreStored*). They do not change the robot pose or cargo by themselves.

Scanning is special. scan() starts a scanner job and counts as initiating work (it returns the scanner's scan time in CPU cycles). The scan then completes after that many CPU cycles (passive countdown on other CPU work, or while oreDistance() / oreType() wait). oreDistance() and oreType() do not return while a scan is still running: they wait until the full scan countdown finishes, which can span multiple mining cycles at your CPU speed. Budget CPU speed with scanTime in mind when you scan often.

The Physical actions are also called Cycles. When a mining area has a maximum number of mining cycles of 150, there are at most 150 physical actions possible in one mining session in that area.

A portion of the timeline of a mining session with a 4 i/c can be represented as followed:

There are two important rules concerning this timeline:

1. When the CPU starts a Physical action, no more CPU actions are processed during that cycle.
2. When the CPU doesn't start a Physical action itself before the end of the cycle, the default Physical action 'Wait' is started.

When the CPU starts a mine() operation as the second CPU action, the timeline will look like this:

And when the CPU is busy with non-physical actions until the 7th CPU action, the timeline will look like this:

In order to mine efficiently, it is important that the Robot program and CPU match each others capabilities. It is useless to have a 72 i/c CPU for the default 'move(1); mine();' program. And a highly advanced but complex program requiring on average 120 CPU actions between Physical actions won't get a Robot very far with a 4 i/c CPU on a 150 Mining cycles mining area.

To check your CPU performance, you can see the Mining results page. When you click on the '+' of a mining session, you'll see a list of Actions. These are the Physical actions performed by your Robot during that session.

If the Wait actions are above 20%, you might consider buying a better CPU or creating a more efficient program.

Scanning and ore heaps

Ore is placed in round heaps. Different ore types can overlap: a small high-value heap often sits inside a larger lower-value one.

scan() reports the nearest cell that still has any ore, along a ray from the robot's position and orientation when the scan started. It does not skip lower-value ore to find type 1 further along the same ray. If you are standing on a cell that has ore, oreDistance() is 0 and oreType() describes that cell (when several types share a cell, the richer type wins).

mine() digs the cell under the robot center and pulls every ore type present there into the container, up to mining speed and free cargo space. dumpB() drops only medium ore; dumpC() drops low; dump() dumps everything. See the Depot section for how dump behaves at your spawn corner.

That combination is why nested heaps surprise players: you may scan type 1, mine a mixed cell, fill cargo with unwanted ore, and keep seeing type 1 underfoot while mine() returns 0 because the container is full. Dump the types you do not want to keep, or move off the cell before scanning again. See Programming tips for nested-heap patterns.

Engine

The Engine is responsible for moving the Robot around. Stronger Engines can move and rotate faster. The Strength of the engine is split into three parts: Forward power, backward power and rotate power.

The other important factor for speed is weight. Every Robot part has a weight value. When you add up the weight values of all the Robot parts, you end up with the total weight of the Robot.

The Robots page will tell you the current maximum speeds of the Robot, again split into the three parts. The speed is the maximum distance the Robot can travel or rotate in one cycle.

When a move() or rotate() command is given which exceeds the speed of the Robot, the action is divided into two or more parts. The first cycle(s), the Robot will move at the maximum speed for the full duration of those cycles. In the last cycle, the Robot will still move at its maximum speed but only during the first part of the cycle.

Assume the Robot has a forward speed of 1.2 and a move(1.8) is executed. With a 4 i/c CPU, the timeline will look like this:

A collision cancels the move or rotate from the moment the collision occurs. So, when a collision occurs at one half of the move(1.2) cycle, the Robot has moved a distance of 0.6 and the second move(0.6) will not be executed.