|
|
Post by napstablook on Feb 25, 2016 18:56:35 GMT -8
Hi, I'm in the process of implementing my first general game player. I'm trying to copy FluxPlayer using BasicPlayer as a base, but so far I only have the IDDFS part done. I'm now trying to analyze the description in GDL of a state to see if it accomplishes anything in the goal (for example, in tic tac toe, if I have two out of three boxes marked as O), so I can determine how close to a goal a state is and if it's worth pursuing it. However, I don't see a way to derive the GDL from the tools I have available in BasicPlayer.
Is anyone here familiar with BasicPlayer? Can anyone help me in this?
|
|
|
|
Post by alandau on Feb 25, 2016 23:05:10 GMT -8
Just to confirm, are you talking about the Prolog-based player from this page? www.general-game-playing.de/downloads.htmlIn which case this would be a reasonable source code reference for other people interested: github.com/AlexLandau/fluxplayer-prolog-engine/tree/master/src(I have little experience with Prolog, but I just happen to have been working on this as part of a comparison of the Fluxplayer GDL interpreter's performance with other options.) I know that once the game has been loaded, the GDL rules themselves become part of the Prolog program (with d_ prepended to the sentence names), so that e.g. in game_description.ecl, role just calls d_role, which is replaced by the actual game's set of rules. I see it also has a get_rules relation that is exported. Do either of those help? |
|
|
|
Post by Andrew Rose on Feb 26, 2016 1:27:11 GMT -8
I'm not sure what your aim is here - whether you're trying to reproduce old research, learn a particular language, dip your toe in the GGP world, use GGP as a testbed for some other area of research, create a champion General Game Player or something completely different.
However, if you're planning to write a serious GGP player, I'd definitely recommend starting with the Java ggp-base (https://github.com/ggp-org/ggp-base). It seems to be the most used & most actively maintained by a very considerable margin. Even if that involves learning a new language, you'd still be *much* faster in the long-run because so much of the groundwork is already done for you in that framework.
|
|
|
|
Post by napstablook on Feb 26, 2016 7:22:07 GMT -8
Andrew, thanks for linking the ggp-base, I didn't know it! I might change to it if I don't progress on my current project.
I'm currently using the Java/Prolog version of BasicPlayer (http://palamedes-ide.sourceforge.net/), and I'm just trying to implement it to learn more about general game players.
|
|
|
|
Post by napstablook on Mar 5, 2016 12:51:42 GMT -8
Ok, I am using ggp-base (Java), and I'm still stuck on this part:
"Games which cannot be fully searched require the automatic construction of evaluation functions from formal game specifications. We give the details of a method that uses Fuzzy Logic to determine the degree to which a position satisfies the logical description of a winning position."
From what I understand, what I'm trying to do here is get the GDL sentences that characterize that state and see how close to the goal they are by analyzing the conditions for the goal. But how would I go about doing that? Does anyone have any ideas?
|
|
|
|
Post by alandau on Mar 5, 2016 14:30:37 GMT -8
A few pieces of context here on why this is going to be hard to recreate in GGP-Base: 1) Fluxplayer is relatively unusual among general game players in that it spends a lot of effort on heuristic approaches like the one described there. Most general game players today use simulation-based techniques (in particular Monte Carlo tree search or MCTS) that don't require the construction of heuristics. We're at the point where people are starting to integrate heuristics on top of MCTS, but that's more advanced. 2) From what I've heard, Fluxplayer is also deeply rooted in a "Fluent Calculus" implementation called FLUX. This may make the Fuzzy Logic components of this work relatively easy if you're working in the original code base. 3) GGP-Base generally hides the internals of the game logic from users. (This is perfectly fine for most simulation-based players.) Instead, it uses a "state machine" abstraction where you can e.g. ask what the available moves are for a given MachineState object, then get the next MachineState that would occur if a particular choice of moves per player is made. You can ask for the set of base sentences that define a state, but applying fuzzy logic would require an understanding of the game rules that GGP-Base doesn't really expose. 4) One exception here is the "PropNet" or propositional network. This basically takes a set of game rules and turns it into a graph of logic gates and nodes with special meanings (e.g. "this particular move is legal for this player", or "the game is over"). GGP-Base has code that will do this conversion for you. This is a popular technique for producing faster simulations than a theorem prover can, but it can also be used for game analysis. I have some examples here: alloyggp.blogspot.com/2015/05/implication-deduction-logic-over.htmlSo at least for getting started, you'd have an easier time recreating a MCTS-based player like CadiaPlayer. |
|
