Re: Gataxx

[MattyT <mattyt-spam tpg com au>]

On Fri, 2004-01-02 at 00:14, Arvind Narayanan wrote:

> Well, the "board" in gtkboard is a mathematical board, referring to
> the abstraction of of a grid of pixmaps; this need not correspond to
> the notion of a board in meatspace! These "abstract board games" are

Well that's kind of the point here - abstractions should be appropriate
for their level.  That is to say, "abstract" boards should be presented
together as a library, and "meatspace" boards should be presented
together as an application.  I think that the classification of games
into applications should be based on what makes sense to the user, not
the programmer.

You can even fit many card games into the abstract board metaphor if you
want, but I don't think that it would be a good idea to put it into the
same application.

> going to have similar code, regardless of how they look in the real
> world. Most games in gtkboard are in fact abstract board games. Games
> like plot4 and tower of Hanoi are programmed very "naturally" in gtkboard.

This sounds great, as a library.  You can see my other post that I was
very much looking at this kind of thing.

> > Firstly, what is to gain by throwing lots of different types of game
> > into one monolithic program? 
> Could you explain what do you mean monolithic? Please note that adding
> a new game does not add complexity to the core of the program. In fact
> gtkboard can dynamically load the game as a plugin (currently only 
> available as a command line switch). It would be easy to modify it so
> that all games are plugins by default and a game is loaded into memory
> on demand (without chaning the user experience).

I just mean that everything is going into the one application.

There are clearly benefits in saving disk space, for having one UI, but
that's not a valid reason if the separate games are considered logically
different.

Having plugins isn't really relevant either, because what I'm really
interested in here is the user interface issue of having one or multiple
applications.

> > Would we not be better served by having:
> > - one program for each type of game
> > - one or more libraries if needed
> > - consistent design/UI, perhaps enforced/assisted by the libraries
> Could you give some examples of what you have in mind? As I mentioned,
> all the games look the same type to me, so please tell me how you
> would classify them. Also, is there any particular game in gtkboard
> which you feel is incongruent with the current UI?

Well, I should say I haven't actually played the games yet.  However,
from what I can see on your web page, Pacman and Tetris stand out as
weird, I think because of the real-time aspect, which makes them arcade
games, not board games.

Furthermore something like Hanoi just doesn't look like a board.  You
probably could put a grid there, but that doesn't mean you should.

> As for libraries, yes certainly. The backend, for instance, runs 
> as a separate process in gtkboard, and all communication is through
> pipes, so if I clean up the protocol and write up the specification
> the backend would become a library.

Back end separation makes an application far easier to maintain, every
significant application should be.  But why would you have a separate
process, and have to worry about a protocol, and dangling processes, and
the like?  Are you saying you won't have one if you have a library?

> The highscores module could also be readily be made into one.

I think there's already a high scores module in libgnome that
gnome-games uses.

> Then there's the game logic library
> that I'm just starting on: it would have functions to do things like:
> "iterate over all the neighbors of this square". It has the potential
> to reduce the size of the code for many games from a couple of hundred
> to just a few tens :) So it would also be a library.

This is good, see my other post.  You can share multi-player code,
loading/saving games, undoing functionality, and various other stuff
besides the actual board.

One of the things I wanted is to take all the different piece graphics
from the gnome-games board games and make the same options available for
all games.  This is primarily applicable for games with one type of
piece or pieces that are different colourings of one graphic.  GNect and
SameGnome have some pretty nice pieces, GLines not so nice.

It doesn't look like you're doing this on your screenshots, (Plot4
versus Othello) but they might well be from separate versions or
separate graphic sets.

> Addressing the point about monolithicity again, I must point out that 
> the meta game "Zillions of Games" (www.zillions-of-games.com) for MS-windows
> has been quite successful using this approach, with several hundred games,
> although their UI design is far from stellar.

Which is probably successful despite its monolithicity, not because of
it.  Anyone would like something that has a lot of games, but that
doesn't mean it's designed right.  And users have got used to suboptimal
user interfaces.

I have a box that claims to have about 200 physical games in it, by
reusing boards and pieces, but it's done to save money and space, it's
not necessarily logical.

That being said, there is something else to say about looking at where
the final destination is with all games present and how they might be
classified.

It's seems to me that the following apps might make rudimentary sense:

Arcade Games
Board Games
Puzzles (Misc)
Word Games

I'm not saying here you should unbundle your games into separate
downloads, merely into separate applications.  It is probably more
attractive in a bundle, and that's what gnome-games does too.

If the decision here with gnome-games is to put all these "board" games
together, then I would think the decision would be to put *ALL* the
gnome-games together.

> In gtkboard, currently almost the only change in the UI depending
> on type of game is that highscores is not valid for two player games
> and Human-or-Machine-players is not valid for single player games.
> But I feel these are better handled by graying out those menu items
> when they are not needed rather than having two different UIs.

Well, this would really depend on what classifications are possible.  If
there are multiple independent classifications each determining whether
various menu items are present, you would still need to disable some if
you did split up the application on one of the classifications.

But I'm not saying either that you need to have different source for
each app, the actual building of the application window and its menus
could well be a library thing too.

A couple of further notes on your game naming, you might want to think
about making your names into alternatives, ie Checkers/Draughts,
Antichess/Suicide, and so on.  The first could probably be localised
instead of slashed, I'm not sure about the second.

Also I'm pretty sure both Tetris and Othello are trademarked by
companies, and they could well get upset.

Also, I'm a little puzzled by your separation of Iagno (Othello) into
8x8 and 6x6 versions.  It has always seemed to me that the user should
be able to configure the sizes of boards.  I don't see what's wrong with
a 12x12 board, for Iagno, Draughts, Ataxx, Four-In-A-Row, or whatever. 
There are games where this doesn't make sense (ie chess), but they're
the exception, not the rule.

Also, you don't have a list of what you're intending on including, but I
see games missing like Go, Five-In-A-Row, 3D Chess and Noughts &
Crosses/Tic Tac Toe.

-- 
         Matthew Tuck: Software Developer & All-Round Nice Guy        
 My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award
1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic
         Emperor 1998 Released From Smith Psychiatric Hospital