Hello,
I have just skimmed the code and I don’t really understand how true/1 and does/2 works.
From what I can understand, you are using the prolog database to store the game state but I don’t see any actual asserts or retracts. How does this work ?
I was wondering why you decided to use the prolog database to store the game state ?
Is it purely by convenience to avoid threading the game state through all predicate ?
Oops, I should mention it goes with some other modules on github.
The asserts are done by functions in prolog-ggp-player/ggp.pl at f91f6ff304c6fcce4c905eeed4be73e82f6dc130 · roblaing/prolog-ggp-player · GitHub
%% update_true(+Game, +State) is det
% needed put true(Proposition) in clausal store
update_true(Game, State) :-
retractall(Game:true(_)),
forall(member(Base, State), assertz(Game:true(Base))).
%% update_does(+Game, +DoesList) is det
% needed to put does(Role, Move) in clausal store
update_does(Game, DoesList) :-
retractall(Game:does(_,_)),
forall(member(does(Role, Move), DoesList), assertz(Game:does(Role, Move))).
The project has turned into a bit of a Frankenstein’s monster stitched together with JSON.
The rules for a slowly growing collection of games are written in SWI-Prolog, while the frontend is written in JavaScript, the middleware in Go communicating with Postgres which in turn asks SWI-Prolog if it doesn’t already have that game state stored.
Luckily I’ve got the Postgres and Go parts done (except for the bugs which inevitably keep popping up), so can focus on translating game rules to Prolog and drawing them with JavaScript which is fun.
I’m a bit sorry, but I don’t see your code for Lines of Action calling update_true/2 or update_does/2 at all ?
You call true/1 and does/1 directly prolog-ggp-player/linesofaction.pl at f91f6ff304c6fcce4c905eeed4be73e82f6dc130 · roblaing/prolog-ggp-player · GitHub, so I’m a bit lost here ^^
The way I’ve implemented Stanford’s General Game Playing framework is to make the rules of various games separate modules from the “General Game Player” which asserts the current state as “true” (a very confusing predicate name, which I’m guessing was an inhouse logical joke).
The best place to look at the details are at the original course’s website http://ggp.stanford.edu/, specifically the introduction
As far as I understand it, Stanford’s General Game Playing project wanted to encourage competition between AI game players by making the rules as obfuscated as possible so as to prevent people simply creating databases of games so the computer player would simply look up the best move in given state, which makes writing chess players fairly easy since there’s a huge amount of freely available historical games between top players to insert into a database.
There are lots of parts to this, and originally my “main” program which then called in the general game player (ggp module) and rules for the specific game was prolog-ggp-player/server.pl at f91f6ff304c6fcce4c905eeed4be73e82f6dc130 · roblaing/prolog-ggp-player · GitHub which received JSON from the website giving the current state and human player’s move, and then responded with the new state after the AI player’s move.
Part of this was translating between JSON and Prolog for which I used a DIY approach prolog-ggp-player/terms_array.pl at f91f6ff304c6fcce4c905eeed4be73e82f6dc130 · roblaing/prolog-ggp-player · GitHub since I couldn’t figure out the provided libraries…
Long story short, to try replicate a whole game player requires besides the rules module, the common functions for Stanford’s Game Description Language etc. I’ve just tried to focus on writing rules of games in Prolog here.