The Design Creation of E.D. the Databot
When we started to put together our first lesson for Modulo Code, we realized it would need to be a puzzle game with the user moving a character around to clear the stage. We needed to design a character that the user would find it comfortable to interact with. We wanted this character to be alert, curious and aware of its mission on the stage, which could change from stage to stage as the user makes progress through the gameplay. We also wanted the character to look friendly and patient.
Several early sample designs were tried and tested including an ogre, a baby dragon, a rocking doll and even a bouncing little ghost. We finally settled on the idea of a rugged mechanical robot who’s on a mission to explore new planets for human habitat (who knows we may actually need one some day!). The mission calls for a very curious robot, unafraid of what lies ahead and always ready to roll.
We wondered how our robot should move. What form of movement would be efficient, swift and flexible enough to navigate the ups and downs of strange terrains? It wasn’t hard to settle on wheels. The NASA Pathfinder shows us its versatility. With that we had an initial design sketch of robots on wheels as follow.
The single-wheel design reminded us of a unicycle. But to be rugged, the wheel needs to be big enough to navigate through rough uneven rocky ground or even a drop from a certain height. The single wheel is also more agile and makes quick turn possible when applying some torque; a capable unicyclist does that all the time. With that we started to zero in on the single-wheel design.
We thought that it’s incredibly important that an exploratory robot is capable of jumping. We pictured a unicyclist riding around the park in the early hours of the day with a backpack on his back. Wouldn’t that be cool if, instead of a backpack, there is a small jet pack that could propel the robot to jump or even to fly around in short distance? From this design we made only a small change to let the robot bend both of its arms more naturally. That should greatly facilitate its main task of collecting samples!
The only task remained after finalizing the design was to name it. That process turned out to be surprisingly lengthy with many considerations. We thought about how a user would program the robot. If they want the robot to jump, should they type jump or jump() ? Well, the answer should be Neither. because “what jumps?”. In our desire to be as transparent as possible when we present our programming model to our user, the user must be able to specify both the entity and the action that the entity performs. In other word, they must be able to program the robot to do certain thing and so the right way to program it should really be robot.jump()
But there are still two problems with that notion. Firstly, our language of choice Lua supports first-class function as field and provides short-hand operator for object’s method in the form of a colon : operator. In other word, to truly make a method call to an object where the receiving side of the call is able to obtain the calling object as its first parameter, the user needs to instead type robot:jump(), which is short-hand for robot.jump(robot) in Lua. Secondly, typing a 5-letter word like ‘robot’ repeatedly for every single command could be extremely tedious in a relatively longer program. Here’s where good naming comes in handy; we settled on the name E.D., short for “Exploratory Databot”, a name fitting of our interplanetary Indiana Jones who collects geodata on remote alien lands, and there are just 2 letters to type! This brought us to our canonical coding idiom that looks decidedly short and sweet — ed:jump().
