Simon McGregor on Fri, 23 Jul 2010 10:01:24 -0700 (MST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

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


Sorry for post brevity! I'm writing from my mobile.
I think the physical components are as much part of a game as the
logical rules.

>From a formal rules point of view, 30 pieces on a backgammon board are
the same as 30 ropes with different numbers of knots tied in them. But
backgammon is in fact a game played on a board, and a description of
the game as a whole should reflect that.

An automatically generated GUI for a wargame would display the state
of the game components - the spaces on the board, the pieces on those
spaces, the cards in hand, and so on. It doesn't seem that difficult.
Of course, the default appearance would have no individual component
graphics, so every piece would just be a circle with a label (which
you'd mouse over for more details), but adding graphics should be
simple.

As for moves, the large majority of board games have moves which are
related to the physical affordances of the components, so this would
make interface generation easier.

I agree that *good* automated interface design is hard in general, but
adequate design should be feasible in 75% of boardgame cases and the
rest is AI and HCI research, no?

Simon

On 7/23/10, Joel Uckelman <uckelman@xxxxxxxxx> wrote:
> Thus spake Simon McGregor:
>>
>> What do we want our game representation language to do?
>> I'd like the following features: -
>>
>> 1) A playable GUI version of a game can be automatically generated
>> from its description, assuming that the game is composed of standard
>> generic components (e.g. dice, cards, counters, tiles, board, etc.).
>> If the game features some weird component like a card which changes
>> appearance depending on the polarisation of ambient light, it should
>> be possible to write a plugin for it.
>
> I'm hovering between 'orthogonal to a game rep language' and 'not
> possible' on this one. The actual appearance of game components isn't
> relevant to the proper logical relations between them, which is what
> the rules capture. I think it's a good idea to have a standard format
> for storing visual representations of game objects, because then programs
> could use those to map objects in our nascent rules lanuage to their
> visual representations---but I think it's a completely seperate issue
> from representing game rules.
>
> My 'not possible' comment stems from not being sure how 'automatic'
> automatic is. I'm trying to imagine a automatically generated visual
> representation of, well, basically any wargame, and failing at it.
>
> --
> 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