Tuesday, February 2, 2010

Gnubridge vision statement - draft

Gnubridge has picked up a lot of momentum lately, and so I think it is time to define what it is and what it is going to be over the next few years. In many ways Gnubridge is still very immature, and so its version number is modestly kept below 1.0. This vision statement should help narrow down what it's going to take to make a 1.0 release, by giving the principles by which features should be prioritized or outright rejected. Please help shape this document by giving your input.

Gnubridge is a software program to play contract bridge. It aims to be a player's entry into the world of bridge software. This is accomplished through the following cardinal characteristics:
  • Multiplatform deployment. By using Java and staying platform-agnostic, Gnubridge is available anywhere where Java runs.
  • Gnubridge will be a strong opponent and a strong partner. What's under the hood is more important than the user interface, and enhancements in both bidding and deal playing will be given priority.
  • Simplicity through ease of user experience. It should be ready to go out of the box: no configuration, no questions to answer for the users (like Gnuchess). New options and graphic interface features should be introduced with caution, with original behavior being the default on each upgrade. It is better to support fewer features than to confuse a mainstream user with obscure options and buttons. As a result, Gnubridge should not have many intimidating menus characteristic "rich" interface applications, and advanced options should be hidden far away from the user.
  • Simplicity through deployment. Gnubridge should be distributed and run as a single file (unlike Gnuchess). The project will err on the side of including fewer features rather than making installation and management complicated. Also, no platform-specific installation packages will be supported at this point.
  • Frequent, small, releases. If a piece of functionality provides value to players, it will make a separate release. One or more releases a month should be the norm.
  • No bugs. Bugs will be fixed first. Automated tests will be written to expose bugs.

Gnubridge also has another community it serves - the developers. It should give developers a chance to demonstrate their skills, learn from each other, push the state of the art in game playing algorithms and apply agile development methodology on an open source project. Test driven development, collective code ownership, simplicity of design, and refactoring will be practiced on the project. Automated tools will provide additional feedback on the overall state of code. These will include continuous integration, static analysis, and test coverage.

Here is a brief sketch of what the future looks like.

Version 1.0

Target date: April 1, 2010.
Gameplay to implement most of American Standard convention, as covered in Pavlicek's Bridge basics. Support for doubles and redoubles. Duplicate bridge scoring.
User features: save and load a game. When restarting load a last unfinished game. Replay and rebid a game. Reset score. Force a computer to play before allotted time runs out.
Community: rss feed for Gnubridge updates.
Development: save junit results on CI server. Meet the target code coverage metrics.

Version 2.0

Target date: January 1, 2011.
Gameplay to implement American Standard and most other conventions with options. Bidding to include explanations. Double-dummy solver to include partition search. Double-dummy to include explanation of moves (for analysis mode).
User features: analysis mode allowing user to configure cards in a deal, force that certain cards are played, take back a move, and get computer recommendation.
Community: vote on features, easy feedback, easy debugging.
Development: static analysis tools, produce crap4j metrics, produce Emma plugin metrics, migrate to github, migrate CI to runcoderun.

Version 3.0

Target date: 2012
Network play: play with any number of partners against each other or computer.
Search algorithm no longer knows everyones cards.
Gnubridge enters a tournament against other computer programs.


  1. Am I doing something wrong?
    Every play of a card takes 15 seconds.

  2. It's by design. If you click on the countdown area you can force the computer to move right away.

  3. I'm trying to play on an hp-mini, but the playing screen will not size small enough to see south's hand.

  4. 800x600 minimum resolution. Try setting a larger "virtual" resolution on your machine. We may have a text only interface at some point in the future.

  5. As for updates, may I suggest a multiplayer function, and multithreading in the search algorithm.

  6. It would be really nice to have pluggable or modifiable conventions. Start with a base and add your own conventions, or at a minimum, select which conventions you want your partner to do.

  7. partner bidding is deplorable, especially as to second round preference/choice of player's bid suits

  8. May I say that I am very appreciative that you have started this. Quick suggestion, if I may? A little clickable option to remind the user of the system being played would be nice. I know that it is a work in progress and that you aren't close to having a full convention system programmed. Given that I only pull this up every once in a while, I find myself having to look up which lesson you reached in Pavlicek's Lessons.

    Also, being able to "claim" when the contract is in hand would be a big time saver.

  9. can you play against other people or just against the computer?

  10. It would be nice if one could reset the scores for the game without restarting the program. Like starting a new game of bridge entirely. Also I agree with an above commenter, the parter horribly underbids sometimes.

  11. Keep up the good work. I am not convinced yet you will beat me in 2012. Hope to see you then.

  12. Could it be made so that one can define one;s own bidding system with one's own point count?

    1. if you can only come up with a good generic notation, and we could have users contribute bidding rules. Alas, I can't see what that generic notation would look like.
      If you'd only like to tune existing rules, then we'll make that available once there are enough rules to make for a decent bidding.

    2. This comment has been removed by the author.

  13. I give the following values:

    Opener Responder
    6 А 6

    2 K 4

    2 Q 4

    10 АK 10

    9 АQ 10

    5 KQ 6

    13 АРД 14

    2 J trump 2

    1 each х trump 1
    2 (with 6+ trumps) void 2 (with 4+)
    4 (with 6+ trumps) singleton 4 (with 4+)

    My system opens with 4+ cards in the majors.

    I would love if it should be as flexible as possible in making one's own bid/bidding system.

  14. Any idea when the next version will be available?
    I'm a beginner, and only know computer basics but I love this! Gnubridge is fantastic and easy to use, keep up the great work!

  15. Hard to find time for working on Gnubridge these days... I'd say it's on hold indefinitely until something changes in my schedule or somebody else takes interest.

  16. It is my hope that someone will take an interest in this project and bring it back to life, it's a great opportunity for AI research that has a practical application and a potentially huge set of consumers. Unfortunately finding someone with strong programming skills, bridge skills and plenty of free time isn't going to be easy.

  17. This needs SO much more.
    The bidding is in the dark. You don't know what system is played. I used to play ACOL. No way to find an optimal contract.
    Living with that and playing whatever contract it ends up with - at the end of play you can't see the cards of the deal to contemplate what went wrong.
    You cannot replay the game or analyse the game. You cannot save the game. Or view bidding after starting play.
    I have downloaded source and although software seems very solid I would call it Object Orientation gone Mad.
    Class Ace, Class King ... , Class NoTrump, Class Spades, Class Hearts ...
    And I don't think the DoubleDummySolver works very well but you need hindsight to evaluate and gnubridge doesn't supply that now.

  18. This comment has been removed by the author.