The first step we took in designing this game was to draw models of our game idea. The following drawings were created the week we came up with our concept and decided on how we were going solve of defined problem. These sketches are quite different from the final product, but still convey the same game idea. Many key components, such as the colored dots, timer, robot, and color sensor were used throughout the entire design process and are still essential to the final game design.
Initial Base Design
Initial Robot Design
CAD Mock-Up of Base
The first prototype was very bare bones. At this point, we had laser cut and painted the terrain pieces as well as laser cut the first iteration of our robot sidewall design. Additionally, we had planned on using two redboards for our game - one for the robot and one that would remain on the base for the LCD screen. Ideally, these two boards would communicate with each other for the entirety of the game. This part of the design wasn't used in our final design because getting two boards to communicate along with all of the other technical elements proved to be quite difficult.
By this point we had also purchased a remote controller that we planned to connect to the robot's redboard so that it could be controlled wirelessly. We determined this to be the best option for our design because the need for wire connections was replaced by wireless connection to the Arduino motors provided by a receiver.
The project dry run was an opportunity for us to present our project to our class and have people play our game in a low stakes setting. The biggest progression made in this iteration of the game was motor control through a wireless remote. The color sensor was calibrated to detect color frequencies, but the point system was not yet set up. At this stage we had two separate code scripts, one for controlling the robot and one for the color sensor. From here, we decided to move forward with using one Arduino Mega that would be placed inside the robot for conciseness and overall efficiency, and this meant that we needed to move the LCD screen to the top of the robot since it would not be able to be placed on the base without power from the Arduino.
We learned a lot from this dry run. As we watched our classmates control the rover, we noticed a couple of things about the rover's movement. First, it was moving very slow and was dragging on the floor. Because this was not our intention, we knew that we needed to increase the motor speed and add some form of wheel at the front of the robot to reduce friction as it moved. Second, we noticed that the robot could not move over our terrain pieces well. This actually became a good thing for us since we hadn't decided how we would keep the players within our main board, so we then made the terrain pieces part of the border that kept players within the designated area.
First rover prototype in operation
Rover prototype with controller
Through a long design process that required us to make adaptions to our build and gameplay, the final design of the game is as shown below. Two separate red boards controlled the main functions of the Rover; one controlled its motor function and the other controlled the color sensor and LCD screen. After multiple trial runs using the game and troubleshooting, we finalized the build. Because of technical issues preventing us from adding the LED lights to the rover, we opted to show the point color on the screen and relay game information that way. And after making certain considerations about the game bounds, we created the borders of the game that would work alongside the terrain to prevent the player from moving beyond the base board. To resolve movement issues that prevented the rover from reversing or turning, we opted for a "glider" leg that glided a smooth piece of plastic behind the 2-wheel drive rover. In the end after painting and decorating, the game was in full operation and was ready to play.
Final build in showcase at the Boston's children museum
To the side is a chart of our timesheet with various categories. After reflecting on both the class and our groups timesheet, it is evident much of the work was done towards the end of the project. Reflecting back on this, trying to begin the sub-projects earlier would have been ideal and better in the long run. What was extremely helpful in our design process was coming up with multiple builds by allowing ourselves to iterate and throw away old ideas for newer ones.