Re: [game-lang] a survey of previous work

[Joel Uckelman <uckelman@xxxxxxxxx>]

Thus spake Simon McGregor:
> 
> I feel uneasy about this. I think the point I was trying to make was
> that high-level concepts in gaming, such as cards and board spaces,
> *already* contain implications about how the game is psychologically
> structured (and hence how an interface to it should be constructed).
> 

I still see this as irrelevant for a rules language. A model checker
or AI won't make any use of the information you're encoding about the
game interface, so at best this information won't be used there, but
the program will still have to wade through it.

On the side of the user of the language, having the rules and the
representation together violates separation of concerns. We'd not be
helping out the user at all by permitting him to mix the two.

Hence, I think it's more appropriate to have a second language which
lets you map objects from the rules (& state specification) language
to their visual representations.

>
> Backgammon is a game played on a board of 26 spaces (including the bar
> and home) with 30 pieces which can be moved on those spaces. It could
> also be played on 30 distinct tiles (corresponding to the pieces) each
> accommodating up to 26 counters (corresponding to the spaces).
> 
> From a game-theoretic point of view, these descriptions are
> equivalent. It's only from the player's point of view that they are
> different, because they have radically different cognitive ergonomics.
> From the very moment that you specify that backgammon is a game played
> on a board of 26 spaces with 30 movable pieces (i.e. from the moment
> when you introduce the high-level gaming concepts) you are saying more
> about the game than is relevant to game theory or AI. You are
> introducing details which are part of the abstract description of the
> game's interface for a human player.

There are reasons for describing backgammon in the natural way which
have to do with the input (i.e., writing the rules) instead of the output
(i.e., the visual representation). If you set out to model it they way
that physical backgammon sets are, then you'll (presumably) have a much
easier time writing the rules down and checking them for accuracy than
you will if you choose a strange, yet equivalent, way.

> In other words, if I describe Backgammon in our putative language by
> simply listing the probabilistic game-state consequences of every
> legal move in every possible game-state (where a game-state includes
> what the active player rolls at the start of their turn), a GUI
> designer should have total free reign in how to represent this and
> design the interface. Text strings of ones and zeroes, an audio loop
> of beeps and warbles, a picture of a Backgammon board, whatever.
> 
> On the other hand, if I describe it in terms of counters on a board,
> then I think the GUI designer should be expected to display counters
> on a board. Unless I specify otherwise (which for Backgammon at least
> I might actually want to be able to do because of its highly
> distinctive appearance), the GUI designer should have reasonably free
> reign in how to display the board and the counters, where on the
> screen to do it and so forth.
>
> There are going to be some sensible defaults for display and interface
> design (e.g. regarding how to choose which counters to move and
> where), but they certainly won't be universal (on a small touch screen
> it's likely to be easier to drag a counter directly to the place you
> want it; with a mouse it might be easier to click the counter and then
> its destination; on a mobile phone it will be different again).

I don't disagree with any of this---but it should be part of a visual
description, not a rules or state description.

I think what would satisfy me on this point is that

1) the rules and state descriptions are not mixed in with the visual
description, either by being in different files or in different sections
of the same file, and

2) the rules and state descriptions have no dependencies on the visual
description. I.e., a rules interpreter which isn't going to display a
GUI won't even need to read the visual description.

-- 
J.
_______________________________________________
game-lang mailing list
game-lang@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/game-lang