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

[Simon McGregor <londonien@xxxxxxxxx>]

On Mon, Jul 26, 2010 at 4:11 PM, Joel Uckelman <uckelman@xxxxxxxxx> wrote:
> 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.

I beg to differ. The component structure of the game isn't just
details about the interface. It's also conceptual information about
how the game is structured.

> 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.

I think if you write it in GDL it will be *exactly* as difficult one
way or the other. I'd also assert confidently that in infinitely many
Turing-complete languages, the first way is easier, and in infinitely
many Turing-complete languages the second way is easier, so that it
makes no sense in general to say that one way or the other makes
things easier from a computational point of view (unless you have a
particular set of languages or machines in mind - perhaps those ones
which human beings find psychologically easier to use?).

I'd also claim that even if the reasons for describing Backgammon in
the ordinary way are to do with writing the rules, they have
implications for the visual representation. The two things (rules and
presentation) are not orthogonal, because they share a factor: the
conceptual structure of the game state.

>> 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.

Saying that the game-state consists of counters on a board is part of
a visual description? Doesn't this imply that either

1) the rules description language should not have access to concepts
like board spaces and counters (and I have to agree with Marc that
these are exactly the sorts of things missing from GDL), or
2) these abstract game concepts should be considered completely
orthogonal to the logically related GUI elements of board spaces and
counters (which seems perverse and redundant to me)

Suppose that I write a generic GUI interface for any game in which:
the state consists entirely of the positions of pieces on a board, the
state of the game is completely observable for all players, and the
allowable moves consist entirely of moving a certain number of pieces
to other positions on the board. There are a lot of games like this,
and a generic interface should be fairly straightforward to write. The
auto-GUI will require the following inputs and no others:

* The topology of the board
* The dimensions in which the pieces can vary (e.g. owner)
* The rules which determine what the consequences of making a move are
on the game-state

This information, which is the minimum information required to present
the game visually to a player, happens to be exactly the information
which describes (a natural way of conceptualising) the game's
state-structure and the game's rules.

Of course, there are choices which can be made about how to present
the board and the pieces, but the implementer of the auto-GUI can just
pick some reasonable generic solutions. For instance, display the
board as a Voronoi diagram and the pieces as counters in the polygons;
if the pieces vary in just one dimension besides position, make them
vary in colour; if two, make them vary in colour and shape; make the
user mouse-over for any additional information.

The only input to my putative auto-GUI program is this state-structure
information (plus the rules). There is no non-rules-relevant "visual
information" which can be separated out and put in a separate file,
unless we allow the rules language to express basic game concepts like
"board made of spaces which can contain pieces" in ways which can't be
automatically recognised as such. Then, yes, the presentation language
will have to contain a construct which says "that bit of rules
language is actually talking about a board which can have pieces on
it".

> 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

For bits of visual description which are genuinely orthogonal to the
rules (e.g. "display text in Spanish", "use this png image for
counters of type A"), I agree 100% that it should be possible to
separate the rules from the icing. I think I'd prefer it if it wasn't
mandatory, because it's easier to write code to strip irrelevant
details from a file than to write tools which allow a programmer to
automatically cross-reference structures and identifiers in separate
files or blocks of text.

> 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
>
_______________________________________________
game-lang mailing list
game-lang@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/game-lang