Microbit part one - setting up
15 Jan 2017
Today I started to set up to write some code for my microbit. After initially doing some googling - see here - I found the library for radio is pretty straight forward.
My next step was thinking about how exactly to go about writing for the microbit. Having worked with embedded systems in my day job, I know constrained environments make it difficult to test your implementation, and the setup cost of doing it can take a toll on how long the task takes, so I decided to start by building it for a mac/pytest before porting it to microbit.
Step 1: game fundamentals + testing
At the bottom of this game realistically is just a finite state machine. In real life, there’s 8 states:
- Setup the game
- Have the wolves vote who to kill
- Have the doctor vote who to heal
- Have the seer pick who to ask about
- Transition to day, make announcements
- Have the people vote who to lynch
- Kill whoever has been lynched
- End the game
My first thoughts were “I know, I’ll implement my own state machine”. I then thought of how much that was a dumb and daunting task, and went to find other better implementations and settled on transitions which seemed like what I wanted.
I set up my controller and started with state 1 - setup the game. In this instance the controller’s going to randomly assign everyone a role, so all I needed to do was register how many microbits were playing. For the most part I wanted the radio comms to be completely decoupled from the actual gameplay, so I settled on 3 reasonably testable methods:
- Add a player using a method which puts it onto a queue
- Get the player using a function which gets it from the queue
- Have a blocking method which gets the player, checks it’s not a duplicate and puts it onto the player list.
I went with this approach because:
- It’s reasonably easy to test. I can check add player and get player work by well…adding then getting. The blocking method I parameterised the length for which it blocks before going to the next state, so the test can just set the block to a shorter amount of time than in game.
- I can add the radio bit later and just have the handler call add
- If it’s not possible to do asynchronous stuff with microbit (I strongly suspect it’s not capable) I can replace or else make a child class of the controller and change the get method to a blocking call to check the radio.
A lot of the rest of the game will probably need a similar approach to this as it’s a lot about voting, so I probably won’t go into this much detail with later phases of development.
As far as testing goes my test library of choice right now is pytest because it’s so easy to pick up and keep everything neat and tidy. I highly recommend it.