Title: report: teaching to code a PocketCode game in 4 hours Date: 2016-08-18 08:28 Tags: report, learning, education, teaching, fsfe, codeweek Status: draft Googleadsense: True Slug: 20160630_pocketcodeworkshop Summary: a fully playable PocketCode app was created by an student of my courses in exactly 4 hours Shortlink: Hashtag: #spielendprogrammieren
During a programming course at spielend-programmieren a student of mine, Benjamin Kaut coded his first ever android app uing PocketCode in exactly 4 hours. The course was originally planned to focus on coding with Python but PocketCode turned out to be very popular.
Benjamin had seen Scratch once but had no real coding experience with visual programming languages. As i timed the Pocket-Code Sessions very exact, i can report that the whole app was coded (and teached) in 4 hours, split over 3 days.
I focused more on the “how to” because the “why” was already teached when coding with Python. I think that others can repeat the process possibly much faster. Benjamin used a Samsung Galaxy S6 Android smartphone to code. His app is optimized to make use of the 4k resolution. I still have to wrap my head around the fact that my students tiny smartphone has more screen resolution than my big pc monitor.
Here is what a description of the code, broken down into 4 parts. Please note that the parts are not equally long, the duration of each part depends on the skill and previous knowledge of the student.
* Download and install [PocketCode](http://www.catrobat.org/intro/) and [Pocket Paint](https://play.google.com/store/apps/details?id=org.catrobat.paintroid&hl=de) on the Android Smartphone of the student, using Google Play Store * create a new game, select "vertical" when asked for smartphone orientation * create a new background object using the smartphone camera * create a new opject (sprite), using PocketPaint. * Give this new object the name "player" * code script for "player" object: * [control] when program is started: * [movement] set position to 0,0 * [movement] set set size to 60% * [control] repeat * [control] if abs( inclination_x ) > 5: * [movement] change x by (inclination_x * -1) * [control] if abs( inclination_y ) > 5: * [movement] change y by (inclination_y * -1) * test the game: tilting the smartphone should move the player
* improve the game so that the player can not "leave" the screen. For that you need to know your screen resolution. Those can be displayed while running the game, clicking the "back" button of the smartphone once and clicking on the "axis" icon that become visible at the bootom of the screen. I assume here the screen resolution is x:1440 and y:2560 * inside the script of the "player" object, add this code into the reapeat loop: * [control] if x_position < -720: [movement] set x_position to -720 * [control] if x_position > 720: [movement] set x_position to 720 * [control] if y_position < -1280: [movement] set y_position to -1280 * [control] if y_position > 1280: [movement] set y_position to 1280 * test the game: player can no longer leave the screen
* create additional backgrounds: for start/help, credit screen and "game over" screen. * rename the background pictures into "play", "start", "credit", "gameover" * create two buttons as new (sprite) objects: one "start" button and one "credit" button. Name them "start" and "credit". The buttons should be not bigger than 10% of the background picture * edit the script of the "start" button: * [control] when program is started: * [movement] set postion to ( choose a good position ) * [look] make visible * [control] when object is clicked (touched): * [control] send message "game start" * edit the script of the "credits" button: * [control] when program is started: * [movement] set position to ( choose a good position ) * [look] make visible * [control] when object is clicked (touched): * [control] send message "credits" * [look] hide * edit the script of the background: * [control] when program is started: * [look] show "start" * [control] when i recive message "credits": * [look] show "credits" * [control] wait 3 seconds * [look] show "start" * inside the script of the player sprite, create to new entries for global variables. Do this right after "when program is started": * [data] set value of "lifes" to 100 * [data] set value of "points" to 0 * [data] display both values at the top edge of the screen * also inside the script of the player sprite, inside the repeat loop, create those two entries to update global variables * [data] set value of "player_x" to x-position (of object) * [data] set value of "player_y" to y-position (of object) * create a new object, called "hunter", using Pocket Paint. While painting, make sure the sprite is pointing with it's nose to the right side * create script for hunter sprite: * [control] when program is started * [look] set sitze to 60% * [look] set position to 0, -500 (depending on smartphone resolution) * [control] repeat * [control] if random( 1, 100) < 5: * [movement] glide 1 seconds to "player_x", "player_y" (change the value for "seconds" to change the difficulty of the game) * else * [movement] point to "player" * below this script, add another script for the hunter sprite: * [control] when program is started * [control] if abs(x-position (of object) - "player_x") < 50: * [control] if abs(y-position (of object) - "player_y") < 50: * [control] send message to all: "player_hit"
Samsung S6 (Amazon Partner Net Link)
My report after holding an 4-hour coding workhsop using the free/libre and open source (FLOSS) Android apps PocketCode and Pocket Paint for smartphones in a public school in Vienna, followed by 3 days of 3-hour-courses using PocketCode in my own summer school.
While i made several shorter (one hour) coding workshops in public schools using the “PocketCode”, i never before made such a long workshop. I teamed up with media educator and digital artist Christoph Kaindel and we teached together a class of around 20 young 12-year-old students at Neue Mittelschule Sechshauserstraße in Vienna, Austria. The goal of the workshop was to increase the number of CodeWeek EU activities during the year and to gain experience with FLOSS tools for education, as promoted by the Free Software Foundation Europe/Austria.
The NMSi Sechshauserstraße school is more specialized into computer teaching than other schools, but the class of our workshop did not had any coding experience.
In a pre-conference before the workshop with the class teacher (and professional singer!) Daniela Haas, it was decided to focus the coding workshop on those devices the students already own: Android smartphones. As a backup plan, should the smartphones not work, we had the option to move the whole workshop into the schools computer lab and use Scratch.
We learned that the school is equipped with a set of tablet computers, but the tablets (Microsoft Surface) are running a version of Windows and at the time of the workshop, the PocketCode App was only available for Android devices. As the whole PocketCode App is free/libre open source software, versions of PocketCode for Apple and Windows will hopefully created sooner or later by interested coders.
Also in the pre-conference before the workshop, Daniela Haas told us that the class visited the local firefighters station and it was decided that the workshop should be centered around creating a game/app around this topic.
Christop Kaindel discovered that on the PocketCode homepage is not only learning material for teachers but also example games and tutorials, and he was able -without changing a line of code- to convert the game “saving Alice” into a firefighter version by just replacing the sprites and the background.
He also learned that it is possible to connect (some) smartphones to a video projector (beamer).
At the beginning of the workshop, we had to overcome some technical problems with the smartphone-to-beamer connection:
Unfortunately for us, while Christoph's smartphone was able to connect to the beamer in the classroom, his smartphone could not run PocketCode stable enough. His tablet and my smartphone (both could run PocketCode flawless) were unable to connect to the beamer.
Finally, we found a student with a smartphone that could connect to the beamer as well as running PocketCode, so we seated her next to the video projector.
To my pleasant surprise, every student had already installed the PocketCode as well as the Pocket Paint app on their smartphone, save for the few Iphone users. I borrowed my smartphone to one student so that nearly every student had his own coding device. A nasty surprise became apparent as soon as we tried to start with our workshop: As the students come originally from a lot of different countries, their smartphone settings reflected those primary languages, leading to much confusion. While we showed the coding bricks in German language, some kids had to translate on-the-fly into their (smartphones) native language.
Lucky for us, two teachers were present (history teacher Reinhard Marsch was participating in the workshop like a student) so we had a total of 4 adults for 20 students and could assist with translation and other problems in near-realtime.
While i personally prefer to teach coding (especially the programming commands like “if”, “loop” etc.) in English language, the decision to hold the entire workshop in German language was made at the pre-conference, reflecting on the very diverse linguistic backgrounds of the class. For example, i learned that one energetic student was born in Kosovo, translocated to Macedonia , later translocated to Italy and finally arrived in Austria (learning German). His “normal” english school lessons, typically the first foreing language teached for an Austrian kid, are actually his fifth language, at age 12.
The game concept was to control the movement of firefigthers holding a safety sheet by tilting the smartphone left/right. The firefighters should catch people jumping from a burning building. The game concept is as old as the "game and watch" game "fire" from 1980.
I began with explaining (at the blackboard) what a safety sheet is as the kids had not seen such a device at their visit in the fire station.
By restricting the “artwork” to a line (the safety sheet) and a box (the burning house), both hand-drawn with Pocket Paint, i was able to show the necessary coding (of the safety sheet movement by tilting) in the space of around one hour. We then made a break (ignoring the shools standard sheduled breaks) and moved the whole class into the sport room. The idea was that the each student let his friends make three pictures of himself with their smartphone camera:
Of course, the last picture was the most popular among the photographers, quickly named “stirb!” (die!). The jumping (on a mattress) was more popular with the boys and the girls stayed absent for a very long time, before finally some girls also made “jumping” pictures of themselves.
Thanks to the “Pocket Paint” app, it was easy for my colleague Christoph Kaindl to show the students how to make the background of a picture transparent.
Naturally, not every student had the same level of “finger-painting” skill with Pocket Paint using his smartphone. Some unlucky students run into a bug were the smartphone/ refuses to save the edited picture, making the deleted background black instead transparent. The bug was not reproducible, but it happened some times on different smartphones.
Students with less interest on photo-editing used easy-to-draw stick figures instead, with much detail and red color given to the “splash” picture.
Some talented students replaced the background of the painted house with an actual photo of a house and even found pictures of realistic flames to add to the backgrounds, thanks to Pocket Paints “import a picture” (into another picture) feature.
After the sport room break, we continued with coding the guys jumping from the burning building. One minor problem by teaching PocketCode on very diverse smartphones is that the screen resolution (x-axis, y-axis) of every device is different. However, the students did a very good job on adapting the code (we limited the left-right movement of the safety sheet) to the limits of their own device and to their personal taste.
code -> test-> modify cycle become apparent in the student's behavior, without much prompting to do so from the instructors. The students made good use of the always visible “play” button of PocketCode to test out their games. The rapid switching between paying attention (or catching up) to the instructions, coding, fine-tuning and experimenting worked very well for the majority of students; better than i exspected. It was very helpful to have not one but several adults present to provide help for students trailing behind because of dissenting smartphone language settings or because of wrongly moved code blocks.
(please note the the coding was done with PocketCode app using coding blocks and is written here in pseudo-code resembling python
Most students, after having coded the left screen limit for the safety-sheet:
if x-position < -200: set x-position to -200
Could produce the correct coding for the right screen limit “in their mind”, without seeing or hearing it from an instructor:
if x-position > 200: set x-position to 200
The students also quickly pointed out that the control for firefighters was counter-intuitive: if tilting the smartphone to the left, the firefighters moved to the right:
The code was:
if abs( x-position ) < 10: move x-position by "inclination-x"
I corrected the code quickly into:
move x-position by "inclination-x" * -1
The students again pointed out loudly that the movement was now correct (tilting left made the sheet move to the left) but “far too fast”.
At this point i decided to let the 12-year olds do a bit mathematical thinking of their own and asked the audience for proposals of how to make the movement slower. The first answer was to replace the “-1” by “-2”. We did, but the result was that the sheet moved even more faster. Having the class (math) teacher, Daniela Haas, present i transferred the teaching to her. She engaged the whole class mentally, trying to lead them to come up with the correct answer ( -0.5). However, even with me Christoph Kaindl, the history teacher and the math teacher each trying to “provoke” the class into coming up with the correct answer the students proposed answers like “+2” but not the correct one.
While significantly lowering the oxigen level of the room by thinking hard, some students finally guessed “0.5” and tryed it out. At this point the math teacher had already sayed the correct answer (“-0.5”, but not everyone was paying attention) and most students preferred to orient themselve at their peers instead of doing their own research. After “getting” that 0.5 was a workable number the students were able to flip the sign to “-0.5” on their own.
I reflected that spontanious mathematical insight is never easy to inflict into a bunch of children distracted by their smartphones, especially on a hot day just before the summer vacations. On the other hand, by quickly editing the coding blocks and experimenting with different numbers, even if just guessing, the children had the tools for learning in their own hands. No praising teacher is necessary if the code works.
The biggest problem from a teaching point-of-view was the concept that in PocketCode, an object (the falling figure) can have several different skins (photos): in our game, the “before”, “jump” and “splash” skin. Because we tried to explain this concept first verbally by talking about it (instead of only showing it via the video projector step-by-step), many students did not get it right and made 3 different objects instead of one object with 3 different skins.
After some help from the always busy adults finally every student had one correct “jumper” sprite with three different skins. I noted that this very same mistake (one object with “costumes” instead of several objects) also happens if i do workshops using Scratch.
Another thing that was difficult for me while teaching PocketCode (this also shows up when teaching Scratch) was that i had to force myself mentally not to code too procedural: there is no break command in PocketCode to exit a loop.
Instead, the correct way is to have at max one loop per code block group, and it is possible to have several code block groups with one loop for one and the same object running in parallel.
The workshop ended after 4 hours with a playable game (movable firefighters, several randomly falling down jumpers, score counter). Some of the students made use of the photos taken in the sport room, while others sticked to the stick figures. Due to limit of time i was not able to try out Pocket-Code's in-buildt physic engine. A follow-up workshop was sheduled for autumn, and the students dismissed us with a round of applause.
The workshop attracted several adult visitors, among others the school head teacher, Helene Swaton from Vienna's teacher academy and Meral Akin-Hecke, Digital Champion Austria as well as CodeWeek EU Austria.
My impression was that the PocketCode / PocketPaint apps can be a valuable asset for teachers of all directions due to the fact that most students in Austria already have an Android smartphone. It will however take a lot of willing teachers and workshops until using a smartphone during class for coding will be a tool as common as using an pocket calculator for doing math.
I was suprised by the eagerness of the class teacher, Daniela Haas, to finish the game (“let's do this feature also!”) and delighted to hear her observation that students who usually show only limited interest in math participated very activly in the workshop and did come up with their own mathematical insights while coding.
Each week during the school vacations, i provide with my company spielend-programmieren week-long summer courses for (game)programming. Each course is 3 hours each day, for 5 days.
I continued to experiment with PocketCode and PocketCode during first summer course in July for 3 days before switching over to Python. The setting was different to the pulic school workshop: I had only 4 students, no beamer, no helpers and all students were equally interested and highly motivated in learning to code (i charge money for my courses).
I needed one 3-hour block to teach the same firefighter game as in the school workshop, including time to go outside and take photos of the students as well as of buildings (the flames were to be hand-painted as there was, most inconviently, no burning building in sight and i was hesistant to provide one).
On the second day, i improved the game by adding a real gravity and acceleration (using variables, not the the physic module) for the jumping guys. My students were unwilling to delete the “constant gliding down” guy so we ended up drawing the non-accelarting guy a parachute and finally randomizing before each new jump if the parachute (gliding) or free fall (accelerating) mode is used.
After the first hour of the second day (4th hour), the students were already pursuing their own game ideas with PocketCode. One student experimented with the in-buildt physic engine and on the third day we all coded together a 2-player ball game using the PocketGame physic features.
I hade some troubles getting the in-buildt collision detection code blocks to work like i want: it seems to only work well in combination with the physic module. Hopefully the equivalent of the “touching” command in Scratch will make it's way into PocketCode.
All in all, i was very pleased with the physic coding options of PocketCode, as it makes coding gravity (in all directions!), mass, impulse, collision and friction really smooth.
My biggest personal wish as a teacher and PC user is to use PocketCode on my PC, typing on my keyboard, without the need of swiping with my big fingers on my tiny smartphone (or installing an emulator), but i guess that is what other, PC-based, visual programming languates like Scratch or Beetleblocks are made for.
My students had fun using PocketCode and one already reported of teaching PocketCode to his friends. I will certainly use it especially for students new to coding and i am sure it is a great tool for every teacher, independet of the teached topic.