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

[Simon McGregor <londonien@xxxxxxxxx>]

On Sat, Jul 24, 2010 at 5:38 PM, Marc Lanctot <lanctot@xxxxxxxxxxx> wrote:
> On 07/24/2010 06:07 AM, Simon McGregor wrote:
>
>> I'd like to suggest that we adopt different terms for (at least) two
>> meanings of "game":
>> 1) the abstract structure of the game as it would be defined in
>> mathematical game theory
>> 2) the overall structure of the game as it presents itself
>> experientially, including its component organisation and appearance
>>
>> I suppose it boils down to what we want the language to represent. We
>> can represent the rules in a purely formal way, and separate that
>> more-or-less completely from the GUI. My preference would be for a
>> language which includes both the rules (in a "gameplay description
>> language"?) and the elements relevant to the GUI and appearance (in a
>> "game presentation description language"?).
>> The reason I put question marks over the separation is that (board)
>> games are usually made from standard components (e.g. cards, spaces,
>> dice, counters) which affect both the cognitive ergonomics (including
>> appearance) of the game and the logical relations which the components
>> can have to one another.
>>
>> It would seem a bit perverse to me to have a language which spells out
>> that the game logic involves a randomly permutable list of (hidden
>> side, public side) pairs, and independently specifies how this list in
>> the GUI can be represented by a deck of cards.
>>
>> Does that make sense?
>
> I think so. If you're saying that you want the language to include some
> high-level notions that are standard in gaming (a hand of cards, a board,
> what it means to be adjacent on that board, what a "suit" is, what a "color"
> is, etc.) then I agree 100% -- that's exactly what GDL is missing.. and
> they're opposed to adding these because they want the general game programs
> to figure this out from their low-level descriptions.
>
> What I prefer to keep separate from the language are specifications for how
> these GUI elements are presented to the user. IMHO, anybody implementing a
> program to interpret the game rules should have complete freedom over how
> they graphically represent the game.

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

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.

In fact, even describing the game-state of Backgammon as a function
from {1..30} to {1..26} (which allows either of the representations I
describe above) is a cognitive abstraction which goes beyond the
game-theoretic. From the most general game-theoretic point of view,
Backgammon is a game played on isolated game states (which might as
well be called s_1, s_2, ...). The game-state of Backgammon can be
represented as a binary string (arguably, in computer Backgammon
programs, that's "all it is") and the rules simply as the list of
reachable next game-states from every legal game-state for every
possible dice roll.

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 guess another way of saying it is that I don't think the
representation language should uniquely specify the GUI, but I do
think that
a) it ought to contain enough information to allow the automatic
construction of a playable GUI version of the game, and
b) I don't actually think that boardgame-level abstractions can be
incorporated into the language at all without involving some
presentational implications (probably enough to fulfil a) already)

Does that make any more sense now?

> I think we do want to define "game" closer to the 1) from above.. at least
> that's the impression I got. Except we want succinct and expressive
> representation.

Not me, I want something which at least allows the option for both 1)
and 2). Partly because that's what I want as a hobbyist, and partly
because I'm unconvinced that the two things are completely separable
for boardgame-level concepts.

Here's a reasonably succinct and expressive notation for 1): represent
the rules of a game by a program in some Turing-complete language -
for succinctness, let's say APL - which takes a game-state (including
a meta-variable indicating whose move it is and some meta-information
about what parts of the state are visible to whom) and returns a list
of possible moves along with the probability distributions on
successive game-states associated with each move. This is clearly the
most general representation for game-theoretic games which are
playable on (or by) a computer.

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