Re: Gataxx

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

On Fri, Jan 02, 2004 at 01:47:27AM +1030, MattyT wrote:
> 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.
I agree with all this, I was responding to the point that you said some
of the games were "weird".
> 
> 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.
> 
OK. What changes in the UI do you suggest for arcade 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?
If its not a separate process it has to be threads, in which case 
there are the synchronization issues which are surely more difficult
to handle than dangling process issues.

I have to worry about a protocol anyway, when network functionality
is added. Now all I have to do is make the front end interface with
the server instead of with the back end. I think this is how xboard
works, it can talk to gnuchess or to ICS (internet chess server).
> 
> > 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.
I wanted some extra features. Like more than one "score" field,
give arbitrary names to fields, and sort based on more than one
field.
> 
> > 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.
Fine.
> 
> 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.
I'm generating the 3D balls in code at runtime :) 
See http://gtkboard.sourceforge.net/doc/doxygen/aaball_c.html

That's mainly because I'm lousy at graphics design and didn't want
to spend time on it, since gtkboad isn't currently focused at end users.
But it also has a couple of advantages: The same code works at all
grid sizes and whatever be the foreground and background sizes.
> 
> > 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
OK, there is no technical difficulty in doing this kind of thing.
And I'm not averse to the idea in any way. Just honestly trying to
find out how the UIs would/should differ.
> 
> 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.
OK. I'll change the names.
> 
> Also, I'm a little puzzled by your separation of Iagno (Othello) into
> 8x8 and 6x6 versions.  
Again, the focus so far hasn't been on the end user; 6x6 othello is not
a "real" game, its just a "proof of concept" that the "variant" support
is working. The 2 othello variants share the code, and just instantiate
their boards differently.
> 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.
- Go is out, because the regular minimax doesn't work for the Go AI. 
(Incidentally, gtkboard uses depth-first iterative deepening alpha-beta
with transposition tables and a couple of other heuristics.)
- Five in a row: Its there, its called "pentaline", though the standard
name seems to be "free-style gomoku".
- 3D chess: haven't heard of it?
- Tic tac toe: I thought its too simple so I didn't code it.
As for what I intend to include, I haven't done any planning. Typically
if I see a new game and find it interesting then I sit down and code it
in a single session :)

Arvind
-- 
Its all GNU to me