dpoly
New Member
Posts: 16 
|
Post by dpoly on Jan 12, 2017 5:40:29 GMT -8
I've only been studying GDL for a little while and I'm impressed by what can be achieved with such a simple language.
My interest is not so much in AI or competitions as in languages, particularly DSLs, and how they can raise the level of expressiveness in a particular domain. From this point of view I'm interested to understand the limits of GDL, and how it might be improved or extended. Are there games that it cannot handle, or are just too hard to program? Does the low level of the language make a barrier to creating interesting new games?
I'm also interested in whether there is any thought to adding visualisation and/or input features to the language, something like Zillions' ZRF?
[Not sure this is the right forum, but 'General' seems to have a Spam problem of major dimensions.]
|
|
|
|
Post by xenos1984 on Jan 12, 2017 15:15:49 GMT -8
I think it's actually a feature of GDL that it does not contain any visualization, but only rules, at that visualization is kept in external files. This is nice, because you can have several visualizations for one game, without the need to duplicate the rules. Logically, game rules and visualization are distinct.
But IIRC there is no standard visualization format, and there are different formats in use on the Stanford and Dresden servers. A standardized format would definitely be an improvement.
One feature that I kind of miss in GDL is simple integer arithmetics. Granted, it would make rule parsing and propnet creation more complex. But it would simplify game rules, which otherwise replicate parts of integer arithmetics in cumbersome and lengthy tables.
|
|
dpoly
New Member
Posts: 16
|
Post by dpoly on Jan 12, 2017 19:19:34 GMT -8
I think it's actually a feature of GDL that it does not contain any visualization, but only rules, at that visualization is kept in external files. This is nice, because you can have several visualizations for one game, without the need to duplicate the rules. Logically, game rules and visualization are distinct. But IIRC there is no standard visualization format, and there are different formats in use on the Stanford and Dresden servers. A standardized format would definitely be an improvement. Can you point me to anything that describes these differences, or is it just in the source code? Can you point me to a game where this is particularly a problem? Yes, as compared to Datalog, GDL has no general capability to create new data values. For that you need at least a basic type system. Also, some of the games have a lot of boilerplate repetition, which could be alleviated by macros and/or compile-time arithmetic while ultimately generating exactly the same output. I guess the point of my post was to raise the idea of building something on top of GDL, making the language more expressive both for visualisations and writing complex games, while preserving the current advantages. Compiling to GDL, if you like. |
|
|
|
Post by xenos1984 on Jan 12, 2017 23:55:19 GMT -8
|
|
dpoly
New Member
Posts: 16
|
Post by dpoly on Jan 13, 2017 23:44:03 GMT -8
Thanks. That problem on its own could be fixed by a very simple macro, that could generate all those lines mechanically. It could even be done with awk, sed or m4.
I was kind of wondering whether this turns up as a problem in position evaluation. Strong chess (and other) programs typically assign a scale of values to each position, but I guess that isn't a feature of GDL.
|
|
|
|
Post by xenos1984 on Jan 14, 2017 12:24:49 GMT -8
Thanks. That problem on its own could be fixed by a very simple macro, that could generate all those lines mechanically. It could even be done with awk, sed or m4. Yes, I agree. Something like a GDL preprocessor would be nice, that would also allow for C-style #if, #define and #include or something similar, to allow modular rule files. |
|
|
|
Post by alandau on Jan 16, 2017 22:00:19 GMT -8
Some thoughts on GDL in general: Probably the most distinctive feature of GDL is its minimalism. Other aggressively minimalist languages that I'm aware of (like Brainfuck) tend to be heavily imperative; but GDL is both minimalist and fully declarative. (Unlike Prolog, you can always switch the order of conjuncts within a rule without changing their semantic meaning. The only case where the ordering of top-level statements matters is the order of the role sentences.) You can also sort of treat the language at two separate levels; one is the logic for dealing with rules and sentences, and the other is the set of keywords that make that logic apply to games. These are also defined separably in the original GDL specification (section 5 vs. section 6 of logic.stanford.edu/classes/cs227/2012/readings/gdl_spec.pdf). The fact that GDL is so minimal makes it much easier to apply transformations to the GDL and otherwise work with it. It becomes more reasonable to think through all the cases of the different possible language features. (This is amplified by writing transformations that further simplify the language; see the DeORer or VariableConstrainer in GGP-Base, which are often applied prior to further processing.) Another nice feature of GDL is that most of its restrictions that prevent infinite loops or contradictions can be checked statically. (The exception is the requirement that games always terminate.) In terms of flexibility, well, you can simulate a quasi-Turing machine with a tape of finite length, so you can do nearly anything in theory. In practice, you end up restricted by the performance of the engines or interpreters you use. This is why e.g. Superko rules (repetition of a state N times leading to a draw) tend to be dropped; it's not actually that hard to write, but it causes the size of states to balloon dramatically. That's one area where a language feature could improve things, if you allow a way to query history without explicitly copying it into your state. Counting things is also hard (it requires a successor function over the things to be counted), and could benefit from a language feature: alloyggp.blogspot.com/2013/10/arithmetic-in-gdl.htmlI've also had some trouble with certain types of recursion that I'd like to use to express certain rules. This is more a shortcoming of the current set of engines/interpreters than the language definition itself. (See the Atari Go Variant for an example that many gamers struggle with: www.ggp.org/view/tiltyard/games/base/atariGoVariant_7x7/v0/)You may find some other posts on my blog relevant: alloyggp.blogspot.com/ |
|
