Céu + Arduino
A couple of months ago I acquired an Arduino Uno board  and started working on integrating it with Céu .
In this blog post, I depict a demo game that uses an LCD shield on the Arduino.
In the game, the player controls a “ship” that moves on screen and has to avoid collisions with meteors.
The video shows the game executing:
The game gets faster and more meteors appear on each phase. When the ship hits a meteor, the game restarts.
The outermost loop of the game runs forever and restarts the game on every new phase or on “game over”:
1: loop do 2-12: // CODE 1: set game attributes 13: 14: _map_generate(); 15: _redraw(step, ship, points); 16: await Key; // starting key 17: 18: win = 19-45: // CODE 2: the central loop 46: 47-60: // CODE 3: game over 61: end
We split the remaining code in three blocks (to be expanded further):
- CODE 1: sets (or resets) the game attributes, such as the ship position, speed, and game points
- CODE 2: executes the main logic of the game, such as moving the ship and detecting collisions
- CODE 3: executes the after game code, based on the result of “CODE 2” (win or !win)
Every time the outermost loop is executed (lines 1-61), it resets the game attributes (CODE 1, lines 2-12), generates a new map, and redraws it on screen (lines 14-15).
Then, it waits for a starting key (line 16), and executes the main logic of the game in the central loop (CODE 2, lines 18-45) until the ship reaches the finish line or collides with a meteor. Based on the return status (line 18), the “game over” code (CODE 3, lines 47-60) may display an animation before restarting the game.
The game attributes (CODE 1) change depending on the result of the previous iteration of the outermost loop:
// CODE 1: set game attributes 2: ship = 0; // 1st LCD row 3: if !win then 4: dt = 500; // game speed (500ms/step) 5: step = 0; // current step 6: points = 0; // number of steps alive 7: else 8: step = 0; 9: if dt > 100 then 10: dt = dt - 50; 11: end 12: end
For the first game execution and whenever the ship collides with a meteor, variable `win´ is set to 0 (we omitted global declarations), hence, the attributes are reset to their initial values (lines 4-6). Otherwise, if the player reached the finish line (win=1), then the game gets faster, keeping the current points (lines 8-11).
The central loop of the game (CODE 2) is responsible for moving the ship as time elapses and for checking whether the ship reached the finish line or collided with a meteor:
// CODE 2: the central loop 19: par do 20: loop do 21: await(dt)ms; 22: step = step + 1; 23: _redraw(step, ship, points); 24: 25: if _MAP[ship][step] == '#' then 26: return 0; // a collision 27: end 28: 29: if step == _FINISH then 30: return 1; // finish line 31: end 32: 33: points = points + 1; 34: end 35: with 36: loop do 37: int key = await Key; 38: if key == _KEY_UP then 39: ship = 0; 40: end 41: if key == _KEY_DOWN then 42: ship = 1; 43: end 44: end 45: end;
The central loop is actually split in two other loops in parallel: one to run the game steps (lines 20-34), and the other to handle input from the player (lines 36-44).
The game steps run periodically, depending on the current speed of the game (line 21). For each loop iteration, the step is incremented and the screen is redrawn (lines 22-23).
Then, the ship is checked for collision with meteors (lines 25-27), and with the finish line (lines 29-31).
Céu supports returning from blocks with an assignment, hence, lines 26 and 30 escape the whole par and assign to the `win´ variable in the outer loop (line 18).
The points are incremented before each iteration of the loop (line 33).
To handle input events, we wait for key presses in a loop (line 37) and change the ship position accordingly (lines 39, 42).
Note that there are no possible race conditions on variable `ship´ because the two loops in the par statement react to different events (i.e. wall-clock time and keys).
After returning from the central loop, we run the code for the “game over” behavior, which executes an animation if the ship collided with a meteor:
// CODE 3: game over 47: par/or do 48: await Key; 49: with 50: if !win then 51: loop do 52: await 100ms; 53: _lcd.setCursor(0, ship); 54: _lcd.write(''); 58: end 59: end 60: end
The animation loop (lines 51-58) continuously displays the ship in the two directions, suggesting that it has hit a meteor.
The animation is interrupted when the player presses a key (line 48), proceeding to the game restart.
Finally, we need to generate the key events to the program itself. As we use a third-party push-button component, the default Arduino binding does not provide event handling for it.
We place the whole program in parallel with the input key generator:
0: par do 1-61: // CODE FOR THE GAME 62: with 63: int key = _KEY_NONE; 64: loop do 65: int read1 = _analog2key(_analogRead(0)); 66: await 50ms; 67: int read2 = _analog2key(_analogRead(0)); 68: if read1==read2 && key!=read1 then 69: key = read1; 70: if key != _KEY_NONE then 71: async do 72: emit Key = read1; 73: end 74: end 75: end 76: end 77: end
The code samples data of an analog port with a delay of 50ms to avoid bouncing (lines 65-67).
If two consecutive reads point to the same key and they are different from the previous change (line 68), then we change the key (line 69) and generate a new event (in the case of a key press, lines 70-74).
The `async´ block is mandatory for generating input events to the program.
Arduino is an interesting target platform for Céu, given its memory constraints and lack of a high-level programming alternative.
The demo shows how complementary activities can be written in separate to run in parallel, reducing complexity.
The code does not become polluted with tons of globals for controlling state, easing the code maintenance.
The complete source code is around 170 lines and also includes all C definitions to generate the map, redraw the scene on the LCD, etc.