Slowly the relational interpretation of Pacman is coming into my grasp. But I have hit a bump. While I have managed to shift the Pacman observations over to relational world, the actions have not moved.
The actions system will likely be scrapped in favour of one both more simple, and one that takes advantage of the relational interpretation of the world. there will be 3 actions: moveTowards(X), moveFrom(X) and keepDirection(). Their meaning is obvious. X can obviously be anything that has a valid integer location. This then excludes things such as ghost centres and ghost density areas.
However, due to this form of action, which can include a free variable, we need to make sure that the variable X is a valid location, and one used in the prerequisite. Using any old location would be silly, although not stupid in other environments with specific goals. This sort of thing opens a whole other can of worms.
Pacman, the environment, is fairly general. Run from the ghosst, and eat all the dots. Not run from a particular ghost or eat a particular dot. Blocks world can also be general, but with the on(a,b) goal, it becomes quite tricky to negotiate using free variables (impossible, from a non-random stand point, I’d say). Because the system I’m developing needs to be able to deal with multiple environments, the Rule formation dynamic needs to be able to take into account these problems. Hence, the moveTowards/From action could create a whole (infinite in some environments) bunch of possible actions.
This reasoning adds further merit to the goal recognition dynamic. By only allowing terms used in the goal and free terms, the action space remains reasonable.
The other problem with free variables transitioning to the action is that the rule becomes more tightly bound than in the previous feature-based Pacman. A variable in a condition in a rule can carry through to the action at the end, making the condition and action generators less useful. They may still prove to be helpful in regeneration, but there are other options towards improving the rules. Using genetic-like mutations on the rules could be an effective way of creating new rules.
I feel like there was another problem to address, but with 35 errors (on first count), I can’t specifically find it.
Well, this may have been it. When generating rules, I need to be careful to make sure the actions are do-able. For instance, if I generate the rule ghostDensity(5) => moveTo(where?). This rule firstly, makes no sense, and secondly, won’t really work. Sure, I suppose the variable in the action could be anywhere, but that is the previously mentioned problem again. I guess this will be solved once I can get the proper coding in for rule generation.