Re: Gataxx

[Arvind Narayanan <arvindn meenakshi cs iitm ernet in>]

On Thu, Jan 01, 2004 at 11:15:09PM +1030, MattyT wrote:
> On Thu, 2004-01-01 at 17:50, Arvind Narayanan wrote:
> 
> > > This might include games such as Dominoes, Backgammon, Scrabble,
> > > Battleship, more miscellaneous dice games, and so on.
> > Just wanted to mention that gtkboard is generic enough to support
> > most of these.
> 
> I noticed after I sent the last mail that there were some weird "board
> games" in GtkBoard, 
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
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.
> so this doesn't suprise me.  I guess it raises a lot
> of questions however.
I'm open to suggestions :)
> 
> 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).
> 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?

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. The highscores module could
also be readily be made into one. 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.

[snip]
> 
> I presume this is referring to a monolithic application like GtkBoard is
> becoming.  I can see what this might mean, since a simple hierarchy
> won't properly classify games (eg betting games may or may not be card
> games).  I'm not entirely sure what benefit it would give the user
> though.
> 
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.

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.

Cheers,
Arvind
-- 
Its all GNU to me