Newsgroups: comp.ai.games,comp.ai,rec.games.bridge
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!ncrgw2.ncr.com!ncrhub6!ncrutr.Utrecht.NCR.COM!news
From: Martin Janssen <Martin.Janssen@ATT.COM>
Subject: Re: How can we encourage AI interest in bridge?
Message-ID: <DKvG6B.FKC@ncrutr.Utrecht.NCR.COM>
Sender: news@ncrutr.Utrecht.NCR.COM
Reply-To: Martin.Janssen@ATT.COM (MARTINJA)
Organization: AT&T WCND Utrecht
X-Newsreader: DiscussIT 2.5.1.3 for MS Windows [AT&T Software Products Division]
References: <4cj3tu$5dr@glitnir.ifi.uio.no>
Date: Mon, 8 Jan 1996 16:51:47 GMT
Lines: 62
Xref: glinda.oz.cs.cmu.edu comp.ai.games:3430 comp.ai:35711


> ==========Jon Haugsand, 1/5/96==========
> 
> > 
> > > with declarer play in isolation.  Maybe the Great Games
> folks would be
> > > interested in making modular versions of their system available, so
> > > that people interested in competing in a computer tournament could
> > > write just a bidder, or just a defender, or an opening
> leader, or what
> > > have you.  The missing functionality could be provided by BB6.
> > 
> > We need standards:
> > 
> > - how the hand is saved in a file
> > - how the auction is saved in a file
> > - maybe ole2? I can see other people climbing in the curtains ;-)
> > - etc etc
> > 
> > Some committee must start this job.
> > From that point modular programming could start.
> 
> We need also some ready made user interfaces, that work on different
> platforms and that do the following:
> 
>  - graphic and ascii
>  - menu-driven and command line driven
>  - tournament mode: play against itself or several kandidate programs
>  - let the user enter one or more of the roles.
>  - feeding the program with already bid and played games from bidding
>    and playing contests (for evaluation)
>  - keep scores and statistics for exchange with others.
>  - Either agreeing on one bidding system and defense system, or making
>    macro language describing bidding and defense conventions.
> -  Standard interface to bidding modules, declarer modules, defense
>    modules (and dummy modules :-)
> 
> In this way, people can work on the difficult parts, making good
> bidding programs and playing programs. Some can work on one problem
> and others can work on others, and thus people can exchange modules
> without trouble (wishful thinking?).
> 
> The point is: The user interface is a lot of work, but is not the
> difficult part and should be reused by several bridge programs.

The real challenge is to define a good strategy for a bridge
playing program. After all, what is a good strategy. Start by
taking as many quick tricks as possible by playing Aces, Kings,
etc., is not the right strategy, as beginners very soon find
out. On the other hand, the purpose of the game is to make as
many tricks as possible. So how do you program this? How do you
evaluate the play so far at any given point in the play? In
other words: what is a good strategy for playing bridge, that
works in all cases?

> --
> Jon Haugsand
>   Dept. of Informatics, Univ. of Oslo, Norway, jonhaug@ifi.uio.no
>   http://www.ifi.uio.no/~jonhaug/, Pho/fax: +47-22852441/+47-22852401
>   Addr: Bredo Stabells v.15, N-0853 OSLO, NORWAY, Phone: +47-22952152


