Joel Uckelman on Tue, 27 Jul 2010 11:09:34 -0700 (MST) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [game-lang] review of GDL |
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