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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

2. 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.

3. 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.

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

5. 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.

6. 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.

7. 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.

8. 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.

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

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