• Letter objects can be subtracted but not added.
  
• The minimum value for integer objects is -999, and the maximum value is 999.
  
• You must be holding something to add or subtract, and the result replaces the item being held.
  
• BUMP commands do not require you to be holding anything.
  
• Remember that OUTBOX gets rid of the item being held!
  
• SUB ‘0’ means the number being held minus the number at tile ‘0’. The result replaces the number held. Follow with JUMPN and you have "if object is less than tile 0, jump here!"
  
• Only COPYTO and BUMP commands can modify (write to) a tile.
  
• There are only eleven commands in the whole language!

Once the level is coded, look for ways to optimize your program to meet the size or speed challenges. Usually at least one of the goals can be achieved just by some simple optimizations (see tips below). In some cases, however, a completely different approach may be needed for a certain goal. The size goals are generally much easier to hit than the speed goals. Most of the 36 levels can hit both goals at once with one program. Levels that (as far as I can tell) do not have a single solution for both size and speed are:

• Year 2: Busy Mail Room
  
• Year 19: Countdown
  
• Year 20: Multiplication Workshop
  
• Year 28: Three Sort
  
• Year 38: Digit Exploder

• Reuse code sections whenever possible (ie, using JUMPs).
  
• Look for redundant COPYFROMs and COPYTOs.
  
• Remember that the BUMP commands don't need an object to be picked up first, and end up with that same bumped object in your hands. (It's a free COPYFROM!)

• Some early levels rely on loop unrolling, which is simply repeating the same command or command sequence rather than using JUMP to create a loop. Each JUMP is an extra command that adds to the step count. Many later levels can also be improved by loop unrolling, but there is usually a more elegant solution.
  
• Sometimes the main outer loop of a program can be rearranged to save a JUMP command by having the INBOX in the middle of the loop, right after the final result is placed in the OUTBOX. This only saves a few steps, but can sometimes make the difference between meeting the goal or not. (Year 9 is a good example.)

The below sections have the solutions for each level, for both speed and size. Some have hints if a certain concept or way of thinking about the problem can be key to finding an optimized solution.

However, it is rewarding to solve these yourself, so I'd encourage readers to give each level (or "year") a good try before looking up solutions. The code provided can be simply cut and paste into the game, but even just looking at the code briefly for ideas and then going back to the game is more rewarding than just cutting and pasting. Either way, this guide is for you; use it how you wish!

Have fun!

There is only one (sane) way to do this one! It meets both the size and speed challenges.

Here the JUMP command is introduced. The size challenge should be no problem. For the speed challenge, try not to use the JUMP command as often (or even at all!)

For the size challenge:


For the speed challenge, try handling two or more INBOX->OUTBOX moves in each iteration:

Note that the JUMP instruction can be removed entirely by completely unrolling the loop. The boss man will complain if less than 12 inputs are handled. This results in a command count of 24, and a step count of 20. The inputs cycle through "BOOTSEQUENCE", "LOADPROGRAM", "INITIALIZE", and "AUTOEXEC". The longest of these is 12 letters ("BOOTSEQUENCE").

The floor tiles are our version of memory; in this case, read-only memory, or ROM. This level has the equivalent of a whopping 6 bytes of storage! (Not including our command list.)
Again, there is only one sane way to do this one, which meets both the size and speed challenges.

We can now write to memory (ie, floor tiles) with COPYTO! But there are only three memory locations. Luckily, one tile is all that is needed for some temporary storage. No special optimization should be needed to meet the size or speed challenges.


Note: For those going for the best possible speed, a lower step count can be accomplished by unrolling for all three inbox pairs, giving a score of 18 commands, 18 steps.

This level introduces basic arithmetic using the ADD command. It requires that an item is already placed on the floor to be added with the value of the item in your worker's hands, with the result replacing that value.
Note: A better speed can be accomplished by unrolling for all four inbox pairs, giving a score of 20 commands, 20 steps.

The idea of conditional execution is introduced with the JUMPZ command. The straightforward solution meets both size and speed goals (4 commands, 23 steps).

Notes: A better "legitimate" speed can be accomplished by unrolling for all eight inbox items, giving a size of 24 commands, and taking an average of 19 steps.
Loop unrolling for all inbox items should be the best that can be done, given truly random inputs. It turns out, they are not really random -- there will never be more than two non-zero numbers in a row, the last value is always zero, etc. Given this, one can get away with coding only for a few specific data patterns get a better final speed score. The boss man will complain in some cases, but in the end a final score of 13 commands, 12 steps is allowed (at least that is the best I could do). This is building a program to pass for specific data, however, rather than solve the general problem at hand, and so these types of solutions will not be covered further.

Remember that multiplication just means adding the same number a specified number of times. Both temporary storage (COPYTO) and addition (ADD) are needed.

Note: A better speed can be accomplished by unrolling for all four inbox pairs, giving a score of 20 commands, 20 steps.

Here we just want to do the opposite of year 7 -- keep only the zeros. It should be pretty straightforward; however, the "straightforward" solution below meets the size goal but fails the speed goal (5 commands, 25 steps).




Loop unrolling can be done at the expense of a larger program size. Instead, in levels that use conditional jumps (like this one), we can often rearrange the main loop to decrease the overall number of JUMP commands executed. This is done by coding so that the output of the result (i.e., OUTBOX) is immediately followed by the next input (INBOX), allowing the JUMP normally at the end of the program to be skipped. When this is done, the first instruction will typically be a jump to the "middle" of the problem, where the input (INBOX) is.

Here is virtually the same solution from above, but with the main loop rearranged:


It still has the same number of JUMP commands, but the first one is only executed once for the entire program run. For the zero case, the loop now runs with only three steps rather than four.

Note: Again, some loop unrolling can be used to find a slightly faster solution (18 commands, 21 steps).

The goal here is to multiply by 8. This could be done with a bunch of ADDs, but recall that 8 is, of course, 2*2*2. This means a sequence of doubling might just get to the desired result faster.

Note: A better speed can be accomplished by unrolling for all four inbox pairs, giving a score of 32 commands, 32 steps.

Just remember that both inputs need to be stored, since you need both a-b and b-a.

Note: Again, a slightly better speed can be accomplished by unrolling for all four inbox pairs, giving a size of 36 commands, and a speed of 36 steps.

a * 40 = (a * 8 * 5)

Multiply by eight as done in year 10, then multiply that as needed to get to x40 using ADDs.

Note: A better speed can be accomplished by unrolling for all four inputs, giving a score of 52 commands, and 52 steps.

If a-b=0, then a=b.

If stuck on the speed challenge at 28 steps, try to rearrange the main loop such that INBOX follows OUTBOX, with no JUMP in between them (see level 9).
Note: A slightly better speed can be accomplished by unrolling the input code, giving a size of 14 commands, and a speed of 25 steps.

If a < b, then a-b < 0.

After a subtraction, the original value held can be restored by ADDing the same value back.







Rearrange the main loop to get a better step count:

a - a - a = -a

One way to make a negative number positive is to subtract that same number from it twice. One can also subtract from 0, but since a zero value is not readily available for this task, this method would take more commands just to generate the zero.

With that in mind, this approach using SUB meets the size challenge.




Rearrange the loop to get a better step count and meet both goals:

Three conditionals (JUMPNs) are needed to cover all four sign possibilities (++, +-, -+, and --).

Note: Code comments are designated by '--'! The code can still be pasted directely into the game. No editing required!

Here the BUMP+ (BUMPUP) and BUMP- (BUMPDN) commands are introduced. The nice thing about them is that they do not require anything to be in hand before use.







For speed, rather than checking for a negative each time through, create two separate loops. One loop will count up (for the negative numbers), the other will count down:

















The main loop can also be rearranged to improve the step count a bit:

The basic idea is to ADD the value from one input the number of times specified by the other input:

This has small enough code size but needs to be sped up. We can rearrange the main loop as has been done before, but that only gets the score to 15 commands, 163 steps. It is more effective to preload the result value to the first input value rather than zero, which saves one iteration of the loop for each multiplication. This can be done without increasing size, keeping the command count at 15 and improving step count to 135.



Finally, a couple other things can be done to improve the speed score (at the expense of size): First, handle zero as the first input value directly (17 commands, 111 steps), and second, always use the smaller number as the counter (since a x b is the same as b x a, and since we are adding, we will have fewer ADD operations if the smaller number is used as the counter). Here is the final program:






























A bit of size reduction can be done by removing duplicate COPYTO commands (lines 20 and 28) and adjusting the loop accordingly (Commands: 27/15 Steps 99/109)

If faster code is desired, a different tactic can also be used. We can unroll the countdown loop such that each copied iteration jumps to a different place. Thus we can use one of the multiplicands to control where the program jumps in order to ADD the specified number of times. We end up executing the same number of ADDs and BUMPDNs as in the previous version, but hardly any JUMPs. Note that this method assumes that we will only use single digit numbers as inputs. (The previous version does not make that assumption.)




































Finally, rearrange the loop to save a few more cycles:

This one is pretty straightforward:








Rearrange the loop for a slight speed up:
Note: A better speed can be accomplished by unrolling the core loop, giving a score of 30 commands, 60 steps.

A straightforward approach to this is to keep two tiles storing the last two values in the sequence, add, then update the tiles with both the new result and the previous result. Repeat as necessary until the output value is greater than the input tile. To meet the goals, output the first value before the loop starts.














A faster step count can be achieved by unrolling the loop a bit so we don't need to swap around the tiles each time to track the latest and next-to-latest values in the sequence. This method is much quicker, but no longer meets the size goal.

As the numbers are read in, check whether each one is the smallest value seen so far. If so, store it as the new minimum. If not, just skip to the next input. The minimum value can be initialized with the first input.












Rearranging the main loop gives a slight speed up:

The remainder of a division is essentially all that is needed, and this is fairly easy to do. Subtract off the divisor repeatedly until the number is negative. Add back the value and you have your remainder (modulo) value!








Rearranging the main loop:

This one is straightforward. Use BUMP- and ADD in a loop.










Rearranging the loop, and removing a redundant COPYTO improves both size and speed:

This one is similar to year 24, but the number of subtracts needs to be counted.












Rearranging the loop to save a few steps:

This one is tedious. Coding for size, perform a sort by swapping the values when they are not in order, and repeat.






























To code for speed, one way is to use a bunch of conditional logic to figure out which of the six possible input orders we have, then output for that order.

This task introduces the idea of indirect addressing, which allows us to use items as pointers. Year 28 (Three Sort) would have been easier with pointers!

This builds on the last level, adding the idea of incrementing a pointer to point to the next location in memory (or on the floor, as is the case here!).

Storing the strings starting at tile 1 rather than tile 0 helps with detecting the string terminator and handling null strings.

Note: Your boss will accept a program that fails for a null string (since it is not a part of the test data set). Such a program could reduce the step count to 118 (or better?), but would be incorrect!

Use a tile as an index pointer to the "inventory", and another tile as a counter for the requested item. Remember, letters can be subtracted to test for equality.
















Rearranging the main loop again saves some steps:

This is similar to the last level. Just interate through the vowels, checking if they match the input letter.












We can also rearrange the main loop on this one for a small improvement:

All items must be checked for duplicates and then stored (if no duplicate found) as they are read from the inbox. For meeting the speed challenge goal, the first item cannot have a duplicate, so it can be directly copied without checking.

Copy the first word into memory, then compare to the second word one letter at a time as it is read from the inbox. Once there is a difference, just finish writing out the correct word -- either from memory or from the inbox.


Here's the same program, but with (slightly) more meaningful labels. Yes, it can still be pasted directly!

It's a linked list! Just output the first item, then bump and use that next item as a pointer to the next list object. Repeat until a negative value is encountered.

The most straight-forward way is to divide by 100, then divide the remainder by 10, then use the remainder for the ones value. However, watch out for leading zeros -- they should not be output and tracking that can be tricky.
































For meeting the speed challenge, unrolling with unique jumps for each value can be used. It is tedious but it works.

The basic idea here is to divide and use both the result and the remainder to get the proper coordinates. Reviewing years 24 and 26 should help.











We can also rearrange the main loop on this one for a small improvement:

The word 'prime' makes this sound harder than it really is. One method which produces a decent code size is to simply test all numbers (regardless of whether they are prime) from 2 to the input value (ie, check if they are factors of the number). It will have a fairly long execution time, however:
























Speed can be improved if we only check for prime factors (as the program name implied), but this is at the expense of code size, since they need to be specified in the code:

One solution to the problem is a selection sort. This can be written pretty easily within the desired size, but speed is a problem. (My implementation was 27 commands, 801 steps.)

A better solution is to think of the problem in a different way: simply find the minimum value, output it, and repeat. So rather than sorting everything in place, we iterate through the items, find the smallest value, output it, and then replace the item just output with last value on the list. Thus the list grows shorter with each iteration. This is much simpler, and much faster to execute as well.

Reach level 5.

Reach level 15.

Reach level 18.

Reach level 27.

Reach level 33.

Reach the last level.

Optimize all levels on the green path for size and speed.

Optimize all levels on the blue path for size and speed.

Optimize all levels on the orange path for size and speed.

Ask all bosses to tell you more.

Get this in early levels by just padding your solution with jumps to the next line.

The speed solution for year 2 (in this guide) triggers this one. Or just throw in a bunch of jumps as above.

This can be done easily in any level once you have the ADD or SUB commands. ADD numbers in an infinite loop. Achievement triggers when it attempts to exceed the 999 limit (or, alternatively, subtract until it tries to go below -999).

This one needs indirect accessing, so it cannot be achieved until floor 29 or higher is reached. Use indirect access on a tile that is negative or larger than the floor size.

This is for a solution that fails for certain inputs. Get this on purpose by trying to make a program that handles the inputs given specifically. The easiest way to get it is in year 2; unroll the loop for the precise number of items in the inbox.

Beat all levels of the game.