Showing posts with label school. Show all posts
Showing posts with label school. Show all posts

Monday, November 24, 2014

Learning how to code: Gamecodization - first results

(Usa la lista desplegable de idiomas del menú de la derecha para traducir este artículo.
Artikulu hau euskaratzeko erabili eskumako menuan kokatuta dagoen hizkuntza-zerrenda) --->


This 2014/2015 school year’s first term is about to expire. After approximately 12 lessons of coding (less than 12 hours of work), and one week for project development (homework time) the final results are really awesome, taking into count that:


  1. Students didn’t have any previous knowledge about coding.
  2. They didn’t know anything about game strategies.


As a picture’s worth a thousand words, have a look at this video to see some examples:




Here you have some of my first conclusions about this exciting project called Gamecodization (more at gamecodization.com):

  1. Different levels of students: superb (20%), average (70%), poor (10%).
    1. I divided coding exercises in stages, so all students could catch up eventually.
    2. I had to consider repeating 1 session for the lost ones.

  1. Student types:
    1. Engaged: they know what they’re doing. They use pseudocode wisely. They understand and solve. They want to learn deeper.
    2. Robotic: they translate pseudocode without much understanding. They don’t really know where to place code (inside loops, conditions…).
    3. Lazy: they need to have most of the pieces in place to start understanding things.

  1. Pseudocode:
    1. It’s key to help students in the beginning.
    2. It can be a problem when students just do things robotically, translating from pseudocode to code without further understanding.

  1. Debugging.
    1. Students don’t read compiler’s messages, they prefer to ask the teacher.
    2. There are plenty of problems with variable names due to case sensitiveness.
    3. I instructed my students to use PRINT sparingly to know variables’ states.

  1. Exercise phases: a single exercise can have many stages (increasing complexity). Start really simple and build on them more layers. Examples:
    1. Guess the number. Stages:
      1. Calculate a random number and print it properly (no decimals).
      2. Read a number from the console and print it.
      3. Now compare both numbers, for higher than and lower than.
      4. Loop everything until the win state is reached.
      5. Include other elements: messages, points, leaderboards, preferences.
    2. Avoid long, tedious exercises to avoid students getting stuck.

  1. Homework:
    1. Aside of coding games, basic exercises are of help to clarify some concepts:
      1. Basic operations: use of the console, file I/O.
      2. Arranging of elements.
      3. Dynamic data structures.
      4. Etc.
    2. I gathered my students in groups and gave them flipped resources so they could group in teams at home.

  1. Assessment:
    1. Projects in pairs (in three people groups one of the participants tends not to work as hard as the rest).
      1. Ask for pseudocode and code: the last one could not execute in the last time. And as a teacher you can always check the pseudocode to tutor them better.
      2. Some interesting and easy games to develop.
        1. Escape the maze.
        2. Arkanoid.
        3. Asteroids.
        4. Snake.
        5. Frogger.
        6. Space invaders.
        7. Other of their choice.
    2. Test exam:
      1. This will make them memorize better basic instructions (LET, PRINT…). Otherwise they’ll feel they don’t have to bear anything in mind, and they’ll waste lots of time checking compiler’s help all the time.
      2. Anyway, I made it easy, in the end you want to keep fun in your classes.
    3. Grade: you have three elements for grading.
      1. Theory: test.
      2. Practice: pseudocode and code (if code works well pseudocode shouldn’t grade anymore).
      3. Attitude, interest, behaviour.

  1. Game structure for arcades: for this first stage all the game developed have been based in the following algorithm.
    1. Initialization.
    2. Main loop
      1. Movement.
      2. Laser
      3. Enemies.
      4. Collisions.
      5. Items (keys…).
      6. Win-state check.
    3. End of game
    4. Leaderboard.


The main strategy for teaching coding through games has been:

  1. The idea is not to teach the coding language used (in this case Basic256), but to teach coding basis (sequences, conditions and loops) and strategies to build games.

  1. As lessons went ahead, I maintained a document (a sort of a cheat sheet), so they could know what instructions and concepts had been worked with, so they didn’t need to check the official documentation over and over.

  1. It’s key to start teaching very basic things through a simple game, in this case “Guess the number”.
    1. Print on the text console.
    2. Read a number from the console.
    3. Calculate a random number.
    4. Compare both numbers.
    5. Repeat the operation until the number is guessed.

  1. With the previous game you’ve covered the three structures and some instructions, as PRINT, READ, RAND, LET; WHILE, IF THEN.

  1. The students shouldn’t be breaking their heads trying to figure out complex things. For example, I gave them enough information to calculate a random number, as INT(RAND*10). The same goes for spaceship movement, collisions, point scoring and so on. It’s like giving them basic pieces so they can combine them in different ways to create a wide range of outcomes.

  1. I passed rapidly to graphic based games. Visuals are key for students. For the second exercise we developed a rebounding point:
    1. Concepts of x,y positioning (plot).
    2. Variable for controlling the direction of the point (NE, NW, SE, SW).
    3. Out-of-bounds control, to make the point move properly.

  1. For the third exercise we started developing the Asteroids game (reduced version). In it I introduced the concepts of game structure (main loop), etc. Challenges took the form of:
    1. How to move several elements at the same time: they tried using FORs, popping up the concept of time slicing.
    2. How to set an element’s life-cycle in the main loop (as a laser), also popping the concept of flags.
    3. One of the topmost curious things was the fact that some students had the tendency to include code out of the main loop, revealing they hadn’t understood correctly previous concepts.

  1. Other aspects, as sprite collision, were easier to solve, as basic256 includes several ad-hoc functions. It is so easy to manage you don’t even need arrays to structure your sprites, as you can use expressions like SPRITEPLACE 1, SPRITEX(1)+5, SPRITEY(1) to move the sprite #1 to the right 5 positions.

  1. After finishing the basic version of asteroids we started including other elements: explosions, animations, points, leaderboards...

  1. As a final project my students had the opportunity to choose a game and develop it in groups (check the video).

Friday, September 19, 2014

PLE, personal learning environments

The Internet usually looks like a mare magnum for young students. So many things, so less time... They end up wasting their energy looking for resources, being absorbed in social sites or playing silly games. The solution? Make them curate their own PLE.


Ejemplo_PLE.png Personal Learning Environment, that’s what PLE stands for. And the process of building one is called curation. Everyone has ever done something like this, in fact bookmarking interesting websites for any kind of personal growth is to curate, and that especial folder you keep with several useful links for your work is a sort of a PLE.


Nowadays there are many tools to fabricate a PLE, but if you are going to choose one be sure that it is social media friendly, i.e, that you can share and find others’ works in the Net. I used to use Delicious, but I didn’t find it student-friendly enough, so I decided to change it for Symbaloo. This last one’s main advantage is its ease of use and its board-like interface.


As PLEs deal with many different things (presentations, social networking, documentaries and videos, research, production, publication, citation, collaboration, storage, project management, coding, augmented reality, virtual worlds, gamification, gamecodization...) you can also curate different boards according to the subject you are working about.


Let’s see an example. This is a board I use to teach the concept of PLE to my 13-year-old students. Everything is mixed but visually arranged. As it’s obvious there are hundreds of applications and this is but a mere mini collection.



There are some points to bear in mind about a PLE:


  1. It’s dynamic. A link which used to be valuable can be unuseful all of the sudden. Keep some, discard others.
  2. It’s flexible.
  3. It has to be social: make it be known and know others’.
  4. It’s not only about school: whatever you do you should have your own personalized one.
  5. It’s curated: you have to invest time and effort to make it of good quality.
  6. It’s a magnifying glass to focus on certain aspects of the Internet and avoiding wasting time.
  7. It’s a productivity tool.

Saturday, June 14, 2014

Programming languages for secondary school



CODING: a key for brain development, fun, gamification and gamecodization.




These days plenty of words are being uttered about the importance of computer programming teaching at school.

It is indeed important, but this post goes not about that, but about what choices we have as teachers to conduct it and about my conclusions on what programming languages should be used to teach coding in secondary school.

And these thoughts are mainly based on: 1st, my own experience as a Computer Scientist; 2nd, my experience as a teacher of LOGO; and, 3th, a throughout analysis of several programming languages.

That said, some good features a PL should have are:

  1. An easy syntax, closer to the human language one (pro BASIC, con C).
  2. A loose variable declaration system (pro BASIC, con LOGO).
  3. An IDE (integrated developing environment, so you can have full control of the code, its execution and debugging).
  4. A rapid way to execute the code (avoiding compilations, assembling...).
  5. Lots of resources/libraries.

If you do a quick research on the Internet, you'll find that not many of the recommended languages fulfil those features. Python, Java, even Logo have complex syntaxes and the learning curve could be harsh, not to speak about the bad experience for students.

So, my nominees are:

  1. Scratch: visual, doesn't need any previous programming skills, attractive, shareable, kid-oriented (#3, #4, #5).
  2. Logo: great for geometry and spacial intelligence, similar to robot controlling, but using its full potential can be difficult for the students (#1, #3, #4).
  3. Basic256: really easy to learn language, it even has sprite control functions for game developing (#1, #2, #3, #4).
  4. Visual basic 6: an old but still used language, the concept of “objects” can be worked, real application development, utilization of controls like windows, buttons, textboxes and so (#1, #2, #3, #4, #5).

Now, the next stage should be to decide what concepts should be taught to your students. More on that in the next post.


Note: some interesting books to have a look on.

  1. So you want to learn to program? Basic 256: this is the official book, so nothing is left out.
  2. Help your kids with Computer Coding. Scratch: very visual and easy to follow; the book’s format is absolutely attractive. A-must!
  3. Logo programming language: I wrote this book, so feel free to use it for your lessons, but take in count it’s written in Basque.