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