Doodle jump: microbit python game tutorial

Doodle jump: microbit python game tutorial

This tutorial will talk you through how to write, test, debug and improve the python code for a doodle jump style game on a BBC micro:bit.

Challenging
Warning: this isn’t easy

This microbit python game tutorial is possibly a little too advanced for beginners so have a look at some of the other tutorials if you’re just getting started or jump straight in here if you’re feeling confident.

Doodle jump is a brilliantly simple but infuriatingly addictive game where you have to control a green alien by moving it left and right to jump up to the next platform, as the world falls away beneath it. The original game won an Apple design award and it quickly took the gaming world by storm. You can play it here (it’s likely to be blocked if you’re viewing this tutorial page in school). The challenge of this tutorial is to attempt to scale down the game so it still works on a 5×5 LED screen on the BBC micro:bit whilst still being fun to play.

 

Try it with code
Try the code

Below is a sample of the doodle jump game that we’ll create using this tutorial.

Press Ctrl + Enter to run the code, or click on the run button that appears when you click on the {+} button in the bottom right corner of the code editor.

Press button A to move left and button B to move right.

If you want to test the game on an actual micro:bit, plug it into your computer, run the code and click on Download HEX and save that file onto your micro:bit.

Making computing accessible for all (2/6): Challenging computing lessons

Making computing accessible for all (2/6): Challenging computing lessons

This post is the second of six in a series with ideas and resources on how to make computing lessons engaging and demanding for as many students as possible. Click here for the original post.

Challenging
Ideas and resources for challenging computing lessons

There’s no point making lessons fun just for the sake of it. Ok, maybe it’s acceptable in the odd lesson just before the Christmas holidays, but I’d rather my students left my lessons feeling like they’ve achieved something than leaving just feeling like they’ve enjoyed themselves.

Fun isn’t a dirty word, but it’s not an end in itself: it’s a natural bi-product of lessons with just the right amount of challenge.

Too much challenge and everyone leaves frustrated and demotivated. Too little and boredom is endemic.

Students don’t all have the same capability, pace, independence and resilience, which means setting the level of challenge is almost impossible to get right for everyone. But lessons / projects with a low floor and high ceiling – that start easy but don’t shy away from difficulty – mean that everyone is going to be suitably challenged at some point along the way.

Ideas:

  • Use templates for code / games rather than expecting students to always start with a blank canvas. Unfinished or deliberately broken code is great as it gives students a starting point to work from.

e.g. “There are 3 syntax errors in this code and one logical error for you to debug”

  • Get used to setting short challenges and puzzles – often at the start of the lesson. Start with something easy and get more difficult as your classes get used to problem solving

e.g. “Today’s learning objectives have been encoded with a caesar cipher: decode them and tell me the key: Avkhf dl’yl nvpun av slhyu ovd av bzl spzaz pu wfaovu”

  • Allow your students to choose different difficulty challenges for lesson / homework. Make sure the complexity of the work increases rather than just the quantity for the most able students.

e.g. “Beginners should make an animation on the micro:bit using built-in images like Image.HAPPY and Image.SAD. Anyone up for a challenge should define your own images to use in your animation

Key questions:

Who’s leaving my lesson feeling like a failure? Who’s leaving my lesson without having learnt anything new?

Example activity: Micro:bit animation

The code above simulates a BBC micro:bit to display an animation consisting of two images. There are three challenges of varying difficulty for students to experiment with lists to create their own animations.

 

Making computing accessible for all

Making computing accessible for all

This series of posts aims is aimed at UK secondary school teachers to give some free ideas and resources in order to help make computing lessons engaging and inclusive in order to help attract more and more students to continue with the subject at GCSE and beyond.

When students are choosing their GCSE options they seem to love asking teachers why we chose to teach our subjects.

Often, I can almost see the cogs turning inside some of my students’ heads, weighing up whether they should choose Computing over Art; ticking off the benefits of each subject as they make the first real choice that might affect the rest of their lives.

Whatever they use to make up their mind – who teaches the subject / what their friends are choosing / what they’re good at / what they enjoy – there’s clearly a lot more that we can do to promote Computer Science as a viable, challenging, enjoyable and worthwhile option. The national figures show a pretty poor GCSE uptake of GCSE Computer Science compared to other eBacc subjects and an abysmal uptake by girls. Boys, whilst outnumbering girls at KS4 and beyond, are being outperformed by girls from KS2 onwards. So there’s definitely something not right there that needs addressing.

CAS include
CAS #include. Making computing accessible for all

I’ve been slowly working through the brilliant advice on the CAS #include site about how to ensure that my Computing lessons aren’t just catering for people like me and it strikes me that the way to be inclusive for all also looks and sounds like the way to be engaging and stretching for all. This post aims to share some of the mistakes I’ve made as well as some of the things I’m trying to put right to make sure that all students get the most out of their computing lessons, hopefully also boosting recruitment at KS4 too.

I’ve come up with 6 Cs to use as a checklist for planning engaging and inclusive computing projects: