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.

Robot Odyssey: Control center

 

An ominous security camera greets you as you enter the Robotropolis control center. Every room in this level has one. Their purpose soon becomes apparent, as a computer room on the other side of the complex lets you view all of them, including places you can't get to yet.

 

How pleasantly orthogonal! But there's also a sub-area that neither fits well in the overall map nor obeys grid lines; a maze of ventilation shafts connecting the library and the north chamber.

 

The center of the complex is the MCC, and four buttons accessed through other rooms in each of the quadrants - the ventilation shafts, the force field tunnel, the high voltage room, and a minefield. A floppy disk in the main office, read in the computer room, confirms that the goal of this level is to deactivate the MCC by pressing the four buttons, and other floppy disks give hints on how to accomplish this:

• A disk near the library's venting duct says that "counting chips" can be used to select air tubes.
• A disk in the map anteroom says, as you may have surmised, that the map room walls correspond to the mines in the minefield. Furthermore, only robots may enter the minefield. Robot communication will be needed here.
• A disk in the force field tunnel says that you use robot relays to pass keys along, and to plan ahead for the return.

 

Apart from the disks, the only items found here are two more chips, one in the trash dump, one in the the lobby of the elevator room, which closes as I approach it. A magnet outline here indicates I could hold the doors open with my magnet, and getting a robot to drop it there would be trivial, but I'm pretty sure the game wants me to solve this floor's challenges first.

As for the challenges, the minefield fills me with dread. Clearly the intent is to have one robot solve the maproom maze, and use the antennae to control a second one in the minefield, but there are two major problems - how do I communicate direction with an antennae that can only be turned on and off (oh boy, real-world computer engineering problems!) and how do I account for lag, so that the minefield robot doesn't walk right into the mine that corresponds to a wall that the controller bot bumped into? And after that, do I need to get the minefield bot out?

The ventilation shaft maze looks easier though still non-trivial, especially if I need to get the robot out once he's pressed the button in the MCC. Some trial and error may be needed - there's a fan which I assume will apply leftward velocity to the robot in its path, but I don't know by how much.

The force field tunnel's puzzle isn't yet apparent, but a tunnel bypass tells me that once solved, returning won't be a problem. But the high voltage room looks simple, and more importantly, contains a crystal-charging station. So I go to that one first.

I can't go in here, but my robots can, and I can view the action through the computer room terminal and see that a button-like object moves around randomly. I can't think of a great way to go about catching it intelligently - my button sensor from level 3 isn't calibrated to that particular shape, but pinbot logic gets it eventually.

Hitting the button disables the safety barrier, letting me enter and hit the first switch in the MCC.

Next challenge - the force field tunnel.

The key unlocks the lower tunnel, but only when it's in the right lock. We need to get it to the left side of the tunnel by having robots carry it across the colored force fields, which block you and robots matching their color. Sparky, being painted red, is no use here, since the outer force fields will block him; we need Checkers to carry the key to the middle, drop it, and have Scanner pick it up and deliver it the rest of the way. But then we'll need a way of bringing the key back to the right-side lock so we can leave.

My design plan for Checkers - have him bounce back and forth between the rooms. Force shields don't trigger bumpers, so instead I placed a crystal in the left-side room and used a crystal sensor as the trigger to go right.

The grabber will be toggled on and off by this sensor as well, so that he'll leave it behind, head right, and be able to return and grab it. A useful chip design here, loadable from the disk, will be the RS flipflop, which can act as a one-input, two-output toggleswitch and will save me some effort in wiring up the standard two-input latch-style flipflops to do the same.

Initial tests found it let go of the key too soon, so I added an array of OR gates to delay the release/return.

Not perfect, but maybe good enough?

 

I take Scanner to the other side, and wire him to go right until he grabs the key, and come back.

Good enough!

 

I retrieve the key, unlock the door to the MCC, and hit the second switch here. Now I'm stranded on the left side of the tunnels, but I can get back by rewiring Scanner to relay the key to the center, where Checkers is already programmed to fetch it and bring it back to the lock. This part's a bit tricky, since Scanner has no way of knowing when he's reached the center, but there's a way; grabbing the key triggers a long OR-gate delay chain, after which he lets go of the key and reverses direction.

The minefield and ventilation shafts are next, and I did the ventilation shafts. Robots can enter, you can't, as per usual. The fan is just for show, which uncomplicates things a bit, but the method of counting pipes to enter the correct one suggested by the computer was proving difficult - the count-to-N chip has a lag, and adding more conditional logic (e.g. "go down if you're in state 2 or state 5, advance states if you're in state 1 and bottom bumper is low, or if you're not in state 1 and bottom bumper is high) slows things down so much that the robot completely passes a junction before it decides what direction to take.

But then I realized that there's an easier way. A path through the maze that only requires changing directions twice, both of them in corners, where it doesn't matter if it takes the logic gates a long time to make a decision.

I designed my circuit to do this incrementally, first to travel diagonally up-right, then added the ability to sense being stuck in the upper-right corner and advance to a "go south" state, tested it, and added the ability to sense being stuck in the lower-right corner and advance to a "go southwest" state. When I tested it, the robot made it to the north chamber and MCC, but missed the button, so I added once last state so that it could reverse itself in the MCC and hit the button.

The final design's a bit cluttered, but I expected much worse.

The logic is actually fairly simple:

• Hitting any top-right, bottom-right, or bottom-left corner advances the state.
• State 0: "Go up and right."
• State 1: "Stop going up and right. Go down, and lock it in."
• State 2: "Go left." (don't stop going down)
• State 3: "Go right." (left motion stops, down motion doesn't)
• State 4: "Nothing." (right motion stops, down motion doesn't)

 

 

All that's left now is the minefield. Hope I can get Checkers back once that part is solved!

Robot Odyssey: The suburbs

Robotropolis is a terrible place. Not a minute after arriving via subway escalator, I realized that the streets surrounding the exit were a Lost Woods-type situation where every direction led to an identical set of paths until you take a specific pattern through it, and when you do, what's next is a maze undergoing a raging magnetic storm that kills your batteries.

Nearby, a storm shield component could be collected, and a device that could modify one of my sensors to detect storm clouds. I didn't really see the point of doing that; I could just wire the storm shield component to be permanently on while traveling the maze and disconnect once through it.

 

An extra power crystal is found in the maze, and a conspicuously placed token gets repulsed around in the storm. You can't pick it up, but a robot can.

One passage out of the maze leads to a scene.

A keycard can be fished out of the trash and used to unlock the elevator - I hold onto the keycard, of course. The elevator leads to a '5' chip, and a puzzle.

Like in the subway, this is going to take cooperation, but this time, there's a barrier that only the robots can cross. We're going to need two robots working in coordination. Maybe even three.

Scanner's up/down wiring is easily modified to drop the token when he hits the slot.

Sparky can find his way to the lever as-is, and with a few wiring modifications, can be made to pull on it.

That leaves me with Checkers, who will need to grab the goods, come back, and signal to Sparky that it's okay to let go once he returns.

Sparky's wall-hugging behavior would be useful here, and thankfully, this circuit is already saved on the disk's reverse side, along with a few others.

I load it onto the blank '3' chip and wire Checkers accordingly. The signal will come from a crystal sensor, and the spare crystal is placed one room to the south. Sparky is modified to let go once he gets Checkers' signal.

 

I let 'em go at it, and...

 

...it's a failure. The wall-hugging chip isn't smart enough to get inside the vending machine. Arghhh! The crystal killswitch works fine, at least. I just have to chase down Checkers and disengage his motors before he gets carried away.

I found a simpler design that didn't need the chip, but did need a bit of manual intervention.

• When you're not carrying anything, move up, and move right too if you're touching the roof.
• Once you pick up the ticket, go down and left.
• Hitting the floor sends the signal to Sparky to let go.
  

The one bit of manual control is that Checkers must be started after Sparky opens the vending machine - too soon and Checkers hits the token slot instead of the roof and moves right too early.

Following this little adventure, Scanner is starting to look a little low on energy. I've got two spare crystals, at least, but the only recharging station I've seen is past the point of no return.

One last untaken exit from the stormy maze leads to a residential area - another non-Euclidean maze with a bunch of items scattered around including a '6' chip and a bunch of sensors. And my inventories are looking very cluttered by now.

Skulking around, I see an inaccessible bureau-bo-crat, demanding F-12s like what I just picked up.

 

A room in this area has another puzzle:

Doesn't seem too difficult - just wire a robot to move right until he hits the wall, and then up and left to the switch, and the other bot can get the other one.

One room over,

I can't cross through the force field connecting these rooms, but the robots can. But then what? The map I've been making says the gatekeeper should be one more room over to the right, and up/down don't really go anywhere, but there's a solid wall to the right. And furthermore, this district already doesn't follow a strictly orthogonal grid pattern, so can we really count on my map to be accurate?

I expect the challenge is to get the robot into the center of the room and touch the thing in the middle. The room on the left is identical except for lacking the button, making it a good place to test logic; I just need to substitute another object - either a key or a crystal - if I want to use position sensors.

Using a positional sensor to guide the robot seems like a good idea, but I soon realize a problem; the moment my robot enters the room, the sensor momentarily fires to the left, and if I've wired the robot to move left on that condition, then it leaves the room and gets stuck in a loop.

After some attempts at a logic table-based solution were foiled by race conditions, I instead used a flip-flop to change machine state - the robot goes right until it hits the wall, and only then do we allow the button sensor logic to take any effect.

Right bumper also means "go up."

Almost there. We just need Scanner to move down, so I add some circuitry to let him do that on three conditions - that the flip-flop has flopped, that the button sensor detects it southward, and that he is not currently touching the right wall.

This mess of stuff gets difficult to work with!

Alright!

The door opens to the right, and thankfully, the force field also deactivates. I did not wish to have to reprogram Scanner even further to hand-deliver the F-12 himself.

I hand over the form, and the gatekeeper processes it, confiscates Sparky's shield, and lets me take the teleporter up to the next level - the control center.