Nope, You’re Not Playing this Game

Sure, Modulo Code is a puzzle game. At least that’s what we say. But it’s also a coding game, which means you’ve got to write code to “play” the game instead of using your mouse, keyboard or game controller to do so. When you click the play button to run your code–the code that controls the robot–do you think you’re playing the game or actually changing it? Are you the player or the programmer?

To answer these questions, let’s look at what a scene of Modulo Code is made of and how it’s built. Clicking at the rightmost “flash” button in the toolbar reveals the debug buttons and the status pane on the lower half of the coding screen.

Our sample scene, the “Moving Around” scene shows two programs running side-by-side. The first program is called main.lua. As the name implies, this is the main program of this scene. The indicator icon next to the program’s name shows a locked box sign indicating that the file is locked for change. This is reasonable because the main program contains the game rule of the scene, so it should not be allowed to change. We’ll look into the detail of the main program more deeply in the next post.

The second program is called mod.lua or the user’s program. This is the program whose code is written by the user. The user’s code controls the robot’s movement in order to solve the puzzle in the scene.

When the scene first starts, the main program runs. Along with many other important set-up tasks, it sets up the scene and places the robot. Once the scene is fully initialized and ready for the user’s program, the coding screen opens up a code editor for the user to write their code in the mod.lua source code file.

Unlike the main program, the user’s program does not run until the user clicks the round bright green button with the play icon on it, or the Debug program button on the debug toolbar. It sends the commands the user writes to the robot and causes it to move accordingly. If the robot movement causes the status of the scene to change, such as moving past an energy field above the marker, the scene keeps the changes until all the conditions required by the scene are completely satisfied, at which point the game ends.

While your code is moving the robot, it’s also changing the state of the scene and the game you’re playing. If you think about it, you’re not merely taking action to change the state of the game, you’re actually updating the game’s code in real time, making you both the player and the programmer of the game at the same time. Cool, eh?