Re: [game-lang] review of GDL

[Joel Uckelman <uckelman@xxxxxxxxx>]

Thus spake Simon McGregor:
> 
> I'll try a different angle here from yours. Given that we presumably
> want to model arithmetic in our language, are there compelling reasons
> not to model the integers and the reals?

Regarding the reals: I'm struggling to think of any reason for needing more
than the rationals. Actually modeling the irrationals is going to be sort
of complicated, probably involving a lot of extra symbols
 
> From a purely pragmatic point of view, if we restricted ourselves to
> finite models of arithmetic, then whenever we defined a game involving
> numbers we'd presumably have to specify the cardinality of the model.
> This strikes me as both tedious and inelegant.
>

>From a logician's point of view, here's the problem with modeling full
arithmetic: Once you have full arithmetic, you fall prey to incompleteness
and undecidability. These are in some ways worst-case notions. For example,
we might want a decidable language if we're expecting to receive input
from the devil, since the first thing he'll do is give us a set of game
rules which encode the Halting Problem or a Goedel Sentence or some other
such pathological object if we give him enough expressivity to do it.

Now, you might ask whether this actually matters for modeling *games*.
I don't know of any board games which involve determining whether an
aribtary program will halt or doing proof search, so the answer might
just be that it doesn't matter at all---we're not going to use enough
of the expressivity to get us into trouble, but at the same time we
don't want to go through the trouble of coming up with precise boundaries
within which safety is guaranteed, so we don't bother limiting the
expressivity...

I think a bigger problem comes up if you want to use existing tools for
doing model checking or theorem proving, as they might not support the
level of expressivity we're aiming at. Hard to tell at this point,
though.

> Similarly, suppose we modelled miniatures wargames boards as
> hi-resolution grids. Then if we started writing the game, and partway
> through decided that the resolution wasn't fine enough, we'd have to
> go back and change any integer coordinates we'd mentioned. (I can also
> see circumstances where an AI would want to internally re-model the
> integer grids as the continuous fields they are pretending not to be.)

I agreee that would be irritating.
 
> > 3. Turn-taking: [1] defines the game model so that every player moves
> > simultaneously at every choice point, but then provides for turn-taking
> > by letting players other than the turn-taker have a no-op as their only
> > legal move. (See [1, p.7] for an example.)
> 
> This is an unfriendly default case, agreed.
> Incidentally, we are all agreed that we're not (currently) aiming to
> model games with real-time elements (e.g. Snap), right?

I don't know Snap. However, I think you can reduce real-time to turn-based
the same way that you reduce continuous spaces to discrete ones: make the
time quantum small enough.
 
-- 
J.
_______________________________________________
game-lang mailing list
game-lang@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/game-lang