Getting Started
In WEEK 1 of our micro:bit game design project, I introduced both the platform and the project to my students. These students have seen Python before, but have never seen microcontrollers, or dealt with wireless communication.
I find history to be a VERY important part of teaching technology, so introduced the micro:bit through a history that included microcontrollers since the mid 1970s and the impact of open-source communities on the industry, in more recent years. After a brief conversation on Arduino, Raspberry Pi and the goals of the BBC micro:bit project, we dove into the development process.
I traditionally do a “code along with me” approach when teaching new platforms. For the micro:bit, I started with the default “Hello World,” in order to teach a file-management process, and how to convey code from the browser IDE to the hardware.
After presenting the API and massive tutorial bank available for the device, I led the class through one more project. This code-example uses the most-likely used features of the device, so that they could see a real development process and test a few unknowns about the board. The mini project demonstrates the good and bad of the Display library, along with button input and radio transmission. Users select whether their device will be a sender or receiver, then either send or receive ‘A’ or ‘B’ data based on button presses.
The real value here is understanding the debug cycle. As mentioned previously: If a typo occurs in a conditional statement, the error won’t be reported until the condition is met! This means VERY thorough testing must be used on every code change.
After completion of the tutorial, we got to experiment with having all 10 devices send and receive on the same channel and different channels using the radio.config() function. Next week, we will experiment with range of the radio transmitters vs. power settings.
The Project
The specifications for the project can be found in the Micro:Bit in the game-design classroom : INTRO post.
With the little bit of remaining time, we discussed the potential of mixing known social gaming techniques with the device. Students were initially disappointed that the devices couldn’t “locate” each other in a GPS sense, but I eventually convinced them that human signaling could be an important aspect of the game!
After some time, various students communicated some widely approved ideas, and the group settled on breaking into 3 development teams based on specific game mechanic concepts. I’m very excited to see where these ideas will go, and will report back here as they progress to the deadline. Each group of 3-to-4 students will develop a game that can be played on all 10 micro:bits.
Group A: There initial idea was to create some sort of commerce system where players use the micro:bit to store and trade assets that could be collected or traded to achieve a goal. There was some discussion of using the file-system to store data even when the micro:bits were powered down, making this game playable over multiple sessions or days.
Group B: They want to create a social game where the micro:bits determine a “bad guy,” and the rest of the group have to use clues and communication to determine who it is. This idea has its roots in the party game “assassin,” though I expect a much different as it is developed.
Group C: Will attempt to use the radio system on the micro:bit to develop a sort of cat and mouse game across parts of our campus. This idea will likely need more development after the true range and reliability of the radio are tested. The students will have to sort out a method like “Hot/Warm/Cold” to communicate direction, as only proximity and compass direction are available on the device.
I’ll report back as development begins for the three groups!