Robot Odyssey: Won!

Hope you remembered the key, noob.

 

Robot Odyssey's final area, the skyways, opens with a linear sequence of challenges. In fact, the entire area is a linear sequence of challenges.

Hey, it's like that bit from Seinfeld!

Sneaking past a sentry in a wall-hugger bot

This again.

After the second Frogger bit, we emerge at Robotropolis' hottest nightclub - the Disk-O-Tek.

Head in, and you're sent down a forcible ride through the 'W' head of a disk drive and onto a magnetic track-turned dance floor where you'll spin around and around until you exit through the 'R' head. But a robot can grab the doohickey here, which opens a door to a winding path, and a third Frogger crossing, and beyond, the first real puzzle of this level:

The receiver flashes on a 6hz cycle. Off for two, on for two, off for one, on for one, repeat. 001101.

One of the unused chip designs on disk, the "clock," seemed it may be useful here.

Pins 1&2 alternate on and off, every other cycle. Pins 3&4 alternate every three cycles. The other pin pairs alternate on five and seven, which is no use to me for trying to send a 6hz pattern, but pins 1-4 could help.

With carefully timed delays, I might get the pins to output these 6-bit patterns:

1. 010101
   
2. 101010
3. 000111
4. 100011
   

Disregard pin 1. With the logic of (2 XOR (3 OR 4)), we get 001101!

With a bit of trial and error to get the timing right, a circuit outputs this pattern to the antennae:

And we're in!

It's not synced to the receiver, but the correct pattern is enough.

Yet another Frogger sequence, and there's a new challenge:

This doesn't seem too bad. A robot should be able to get past the sentry and touch the button in just three moves - go right, go down, go left. I can easily wire that as a three-state machine advanced by crystal remote control. Once it hits the button, I grab my crystal and dash.

The tricky part is timing.

You know the drill...

...what the?

After another Frogger minigame, you're dumped into an invisible maze! But it's not too bad. I solved it in a few minutes by following the walls - no robot programming required, you can just carry them with you.

Yes, you have to do the Frogger dance again afterward. And then,

This lock puzzle looks enigmatic, but trial and error helps deduce the goal. You can't push the buttons, but your robots can, and it isn't complicated to wire one to go right, hit the button, and return. And you have four robots, one per button.

The starter switch unlocks the four buttons, turning them white. Hitting any in the wrong order re-locks them all, turning them blue again. You also can't hit them too fast; if two buttons are pressed at the same time, they all turn blue. Nor can you hit them too slow; they re-lock if you take too long.

Solving this one isn't complicated, just tedious. The bots all behave the same except that they are wired with incrementally long delay triggers so that they hit the buttons one at a time - this uses most of my allotted logic gates. Trial and error determines the correct order (1-3-2-4, I don't know if this is fixed or variable), and the robots can simply be re-positioned to change the order when needed.

Scanner gets a 15-gate delay trigger. The others' are shorter.

The key goes in the ignition, the starter switch is hit, and hopefully it doesn't explode!

Next room down...

We essentially have a repeat of the minefield puzzle, only now the path is narrower and shorter. But the general solution for the minefield should work here too.

Assigning every other count-to-n states to "wait" won't work without getting into some additional, lag-inducing logic, so I try it with these states:

• Stop
  
• Down
• Right
• Down
• Stop
  
• Left

 

It's difficult to convey with words just how sluggish the handling is, even though all I'm doing is picking up and dropping a crystal a set number of times at certain intervals. It takes me several tries, but I think I get the timing good enough.

Doing this again with Checkers following Scanner's lead took even more tries. The grid is really unforgiving! On top of that, you can't let Checkers accidentally leave the lower room through the south exit, which happened to me an embarrassing number of times..

Down south, the key opens the door to one final challenge.

This looks more complicated than it is. Each robot has to touch two buttons, timed apart just enough so that they're hit in order. Getting the first four is a cinch; you just need two robots to head straight up, with one of them starting just a bit below the other.

Checkers gets 5 and 7, and is wired to begin moving only after Iris sends a signal triggered by reaching the top wall.

And finally, Scanner gets 6 and 8. Finding the precise position to place him so that he hits 6 and 8 interleaving Checkers hitting 5 and 7 is tricky. I also found that Checkers had to be modified a bit to move away from button 7 after hitting it, or else 8 would fail to trigger.

All together now.

With no choice now but to abandon the robots, having served their purposes, I switch them off and take the last teleporter out of Robotropolis.

That's it. That's the ending.

GAB rating: Good

What a cool game! Programming has long been a hobby of mine, and continues to be even as it is also my profession, and Robot Odyssey presents programming in its most fundamental form - circuit design - in a neat, accessible package, and tasks you with innovative and creative challenges from start to finish. Even with its simplified model that runs on an 8-bit, 1Mhz, 48KB machine, so many aspects and challenges of computer engineering are simulated and taught - signal propagation delay and degradation, circuit metastability, clock synchronization, parallel processing, function libraries in the form of chips, even source control in the form of keeping multiple save files. All this is done in the context of a computer adventure game that never feels too much like an abstract toolkit or sandbox. I would have loved this game way back in the days when I was tooling around in BASIC. I dig it now, though I have to wonder what kid in the 10-13 year old demographic that The Learning Company targeted actually beat this game back in the day. This is borderline AP level stuff, and I'm all for that.

It's by no means perfect - the Apple II it was designed for chugs badly as things get complex, and even just moving the cursor around the robots' interiors to design (or unravel) your circuits can become frustrating, let alone fighting both the lag of the computer and the lag of your own circuits simultaneously in the remote-controlled minefield challenges. The game is extremely unforgiving when it comes to leaving objects behind - the key found at the start, for instance, is needed right up until the very end, and you're really screwed if you ever leave it or any other useful object (like the chips, crystals, or crystal sensors) behind, which encourages hoarding a whole bunch of useless objects out of fear that they might be needed at some point, and both clutters up your working space and slows things down even more. The possibility of running out your batteries is a constant stress factor, even if I never came close to letting it happen. The difficulty curve is all over the place, with level 4 a massive spike over 3, and level 5 full of oddball challenges that don't always have anything to do with the core gameplay mechanics.

And in the end, I still felt like there was a lot of untapped potential, even with this engine. With the tools provided, I bet I could simulate a cryptographic machine, build a serial protocol encoder & decoder, make a 4-byte memory chip, maybe even a 6-bit CPU with 2-bit words. Or maybe a wider variety of robots with new and different external components, who could do things like race, play Pong, play hide-and-go-seek, or just have a good old fashioned robot duel. It's a pity that Robot Odyssey II never surfaced to take the concept even further.

Robot Odyssey, for its faults, is still a brilliant concept, in both execution and design, and what's more, a complete package. It's educational, sure, but never feels pedagogic the way so many edutainment games have and still do. Problems - often analogous to real-world ones - present organically, and you puzzle out the means to construct solutions with minimal instruction beyond how to use the base building blocks. I learned things while playing, and never felt condescended to once.

Robot Odyssey: Minefields

 

I've been saving the hardest challenge on this floor for last - not just because it's intimidating, but also because I'm counting on being able to retrieve the minesweeper bot from the MCC once this last puzzle is solved, and not risk having it wander back into the minefield and get blown up while solving another one.

The task - get a robot through the minefield and into the MCC, where it will press the final switch and shut down the master computer. You can't enter the minefield yourself; it must be controlled remotely, and blindly.

The minefield map, which you can enter, marks the location of the mines. A controller bot could be programmed to navigate it and transmit directions to the minesweeper bot, so that both move through their respective mazes in sync, but there are two major problems.

First, the only means of transmitting anything from one bot to another is by wireless antennae signal, which can only be turned on or off. Instructions can only be binary, and we need at least three (right, down, and up). This is, of course, a real-world engineering problem; non-binary information is encoded and transmitted into serial bits all the time. There are some ways this could be solved, none of them easy.

Second, these circuits lag, and the more logic gates I add to a critical path, the more it lags. If the controller bot and minesweeper bot are both moving to the right in perfect harmony, and the controller bumps into a wall and transmits a signal, the minesweeper bot will keep going right and blow itself up before it can receive the signal and understand it to mean "stop." This problem seems the thornier one.

Diagram by Notre Dame University

 

In the real world, the problem of sending non-binary data over a single-bit channel is typically solved with a serial protocol, which at the minimum requires a start bit followed by N data bits and M stop bits. A transcoder for octal packets may begin with a brief pulse to signal the start, then over the next 3T milliseconds send up to three more pulses for the binary representation of the octal input, and then no pulses for the next 2T milliseconds. The receiver is woken up from idle state by the pulse and as soon as the pulse ends, listens for pulses over the next 5T milliseconds to read five bits. If the two stop bits match the protocol's stop value, then the three data bits are read in as an octal number. If they don't, then something went wrong and the packet can't be trusted.

I'm sure that this is doable in Robot Odyssey with the tools given, and perhaps the stop bits aren't  necessary. But I quickly gave up the notion of trying to solve the minefield problem this way. In the real world, even with 1980's technology, an 8-bit packet is transmitted in milliseconds. In Robot Odyssey's world, everything operates in 125ms ticks. Each wire added, each gate traversed, each time interval awaited is another eight of a second or more. The whole mechanism, under the most perfectly optimized circumstances, would probably take more than a second to encode, transmit, decode, and act on a 2-bit trinary packet. And that's just no good for this task - the robots would desync badly.

But I had another thought. The control robot doesn't have to solve the maze with logic. I can be there in the maproom with it and guide it with a manual control, such as placing/removing a crystal in proximity of its sensors. A manual binary input can be transmitted to the sweeper bot with minimal lag, and as long as both robots are wired the same, they should move through their respective zones in close synchronicity.

A binary input can be translated into motion directions by cycling through states, which can be accomplished with the "count-to-N" chip. Wiring the sixth pin to its own reset input makes it cyclical, and I decided on the following states:

• Stop
• Right
• Up
• Stop
• Right
• Down

 

I wire up Sparky accordingly:

 

A test run to see if I can guide Sparky through the map room quickly reveals a problem. Even with this simple wiring scheme, Sparky lags! This isn't necessarily a showstopping problem - I can expect both Sparky and Scanner to lag together, but it does mean I have to time the input to trigger state advancement all the more carefully. Finessing the actual keyboard inputs to manage Sparky's state, even as the Apple II itself chugs along at 4-5 frames per second (and polls the keyboard as often) is no picnic, especially when I need to move the crystal from one room to another and quickly drop it to change Sparky's state.

I try a different state cycle:

• Stop
• Right
• Stop
• Up
• Stop
• Down

 

 

This navigates the maze less efficiently, but it's a bit easier to work with, as Sparky stops moving with every other state change, giving me a chance to rest and calculate my next move. Nevertheless, it takes me several tries to get through a successful test run that doesn't do worse than lightly brush the walls.

Time for the real test. I wire up Scanner with another count-to-n chip, driven by Sparky's antennae to switch states, and place him right by the minefield entrance. I return to Sparky and begin guiding him through exceedingly carefully, as I had before. The absence of any kaboom sound as I do this gives me some confidence.

Sparky's halfway through.

Checking on Scanner via computer room monitor

Made it through!

Scanner didn't quite hit the button, but no big deal - just have to use the crystal-sensor remote one last time.

And the level is all but solved. Checkers and Scanner are free, a fourth robot is released - I'll name her Iris, and the master computer is deactivated. Way to go!

Iris's batteries are super dead, so I recharge them with a crystal, and recharge the crystal from the charging station in the high voltage room below. Scanner's running low too, but I just let all of the robots run until they drain completely so I can recharge them. It takes a good 25 minutes for them all to run dry, but you can't recharge a battery until it's empty.

In the level's exit, the elevator room, the doors no longer close, and the magnet in the corner doesn't react to mine, so now I'm not even sure what the point of the magnet is. For now, I save and take the one-way teleporter to the final area of Robotropolis - the skyways.