Let us focus on the inner core of the software, which is a so called virtual machine interpreter. That is a module which takes a self-created program and executes it step by step. The interesting feature is, that the VM can stopped and the “Karel the robot” program doesn’t halt. It’s some kind of box in a box. Perhaps we should go a step backward.
A game-engine is known from implementing a computergame. A game engine takes a command from the player, for example “jump” and updates the internal state of the game. That means, the game engine reacts to the command with adjusting the absolute coordinates of the player and it also redraw the player sprite on the screen. What a game engine can’t do is executing longer programs. So there is a difference between a game-engine and a virtual machine. A virtual machine can be seen as fullblown interpreter. It takes a command, but it can parse a complete sequence of commands too. The VM has an instruction pointer, a datastack and a returnstack. The last one is needed for jumps in the program.
“Karel the robot” doesn’t only provide a game engine, but a sophisticated Virtual machine interpreter. This makes the software unique. Between a VM and an Artificial Intelligence is a difference. A VM needs a program, while an Artificial Intelligence can run by it’s own. Or to speak more directly: the program which is feed into the VM is the Artificial Intelligence. That means, if the user of “Karel the robot” has written a sophisticated control program he has created an AI. He can start the program in the interpreter and the robot will move on the screen. And the user’s created program can fail too. That means, if the program doesn’t make sense, the robot will not reach the goal in the maze. The question is now: how does look the program which control “Karel the robot”?
This is not answered by the project. Figuring it out has to with learning something about Artificial Intelligence. If somebody is able to deliver a program to solve a task, he has understood what Artificial Intelligence is. And that makes “Karel the robot” an interesting game.
While reading through the literature, i’ve found many promising techniques to create a program which controls “Karel”. The first one is manually coding. That means, the programmer types in some commands, and observers the result. Then he modifies the code until the robot is doing what he should. But there are many other alternatives to create new programs for example: AI planning, hierarchical reinforcement learning, genetic programming or partial order planning. The list is endless. A general technique in developing working code for “Karel the robot” is to focus on the vocabulary list. That means to read carefully through the existing commands and invent new one which are powerful. If a list of words is available it is much easier to put them into a working program, either manually or by automatic planning. In contrast, if the grammar consists only of lowlevel actions like “moveleft, moveup, movedown, moveright”. It’s harder to create ontop of these words a powerful program.
What I want to explain is, that the user has to invent his own “Karel the robot” mini-language. He takes the predefined grammar and extends it with new action commands. In the figure, the default grammar is shown in a graph structure. In contains of action and sensor words. Sometimes, the grammar is called an API (Application programming interface) because it provides a library of functions. But the term API is focused on the implementation in sourcecode, the literature calls it a graph grammar because it defines a language. The words in the language can be used together to solve problem. They can put in a program and are extended by default words like if, for, while and goto. Like i mentioned above, the amount of words in the grammar is equal how powerful the grammar is. A more complex grammar is equal to more advanced programming.