The BBC Micro:bit, which goes on sale this month having already shipped 1 million into UK schools, is a remarkably capable computer and is intended to get you started with coding in a very hands-on way. Its big limitation for games programming is that it only has a 5x5 LED matrix display. What sort of game could you possibly program on that!

Games have always been a great way to get into programming as once you've made your program work there is something to show your friends and family. So the challenge was to find a game that could be scaled down to be workable on the micro:bit's display.

Given that it is the BBC which has pioneered the micro:bit, the inspiration came from the previous generation of BBC computing, the book 21 Games for the BBC Micro, published in the era when the home computer introduced computer programming as a hobby to the generation who went on to become the programmers of the 21st century.

By design, Commando Jump was a very simple game intended to teach BBC Basic programming. It presented the player with a wall that the commando had to climb. The initial jump height was determined by the player's reaction time. After that they could make the commando scramble up the wall by pressing a key as fast as they could. The faster, the higher the commando climbed. If you reached the top of the wall before that time out then at the next level there was a higher wall. If you didn't make it the commando would slide down with a deflated noise.  

The challenge in converting it to the mico:bit was to see how much of this could be implemented in a more restricted environment.

In converting the program to work on the Micro:Bit, I initially chose MicroPython, from among the four editors available on its website, www.microbit.co.uk. This turned out to be interesting and instructive, see Commando Jump Game For The Micro:bit In Python, and made me curious to know whether the same result could be achieved using the Microsoft Blocks Editor.

Blocks For The Programmer

Working in a block editor can be frustrating if you are used to typing code as fast as you possibly can. The Microsoft Blocks editor isn't as bad as you might think when you first start using it. Give it time and you will slowly find that you work out ways of doing things that avoid making a mess of your program as assembled so far by accidentally putting a block in the wrong place.

My advice when you are assembling a complicated set of blocks - a for loop say - is to not try to put it into the whole program until you have assembled it. Use another area of the editor as an assembly area and when you have the block complete move it into place. 

It is also worth pointing out that by right-clicking on a  block you can select duplicate to get another copy that you can use as the basis of an edit. This is very useful for working with a complicated block.

Finally pay special attention to where you place one block within another - you can easily misplace one and discover that your code isn't within the for loop or if statement in which you wanted it.

Limitations

The limitations of the Blocks Editor are quite severe. The biggest problem is that there are no functions or subroutines - which meant I could not adopt the same modular programming approach as in the MicroPython version. There are functions in Touch Develop and this is one way in which it is more powerful than the Blocks Editor. 

It is also worth noting that other block languages, Scratch for example, do have functions - and this is not a failing of the general approach. 

Not having functions is a big problem if you want to teach, or practice, more advanced ideas such as modular top down programming. In this case your only sensible choice is to move to another language as soon as possible. 

There are some other limitations that mean it isn't possible to implement the slightly more sophisticated animation used in the MicroPython version of Commando Jump. Both the blocks editor and Touch Develop, for reasons that aren't clear, do not provide a command that sets an LED at x,y to a particular intensity. You can fade an LED in or out and you can change the brightness of the whole screen, but not a single LED.  All you have is the plot x,y command which turns the LED on and unplot x,y which turns it off. 

You can make use of an LED as a sprite, which does simplify the program. However, you can't mix using sprites with plot and unplot. I suspect it has something to do with the way sprites are implemented as a back buffer. What this means is that if you opt to use sprites you have to use sprites for all objects on the screen - even if they don't move. As you can modify the brightness of a sprite it would be possible to implement the more advanced animation, but for simplicity and to keep the program short in the absence of functions, the simplest version of the game seems preferable.

So in this case Commando Jump is a game where a four-LED wall appears and the single-LED commando moves up one location for every ten presses of the button A. When it gets to the top, the commando sprite is animated horizontally and then down to its final position.