Update: In May 2014, ACBL decided to drop ACBLscore+. Hammond Software (HS) and ACBL were in negotiations to continue work on ACBLscore+. ACBL insisted that as part of any new contract that HS should give up rights under the original contract, including copyright and licensing agreements. ACBL wanted to own all future derivatives works in other industries that HS would create from the underlying code of ACBLscore+, irrespective of who paid for them. Outside counsel for ACBL informed ACBL that without owning the Copyright to ACBLscore+, ACBL would have to drop the project and would not be able to use the software. The terms of the original contract covered copyright and licensing under a typical software contract. ACBL wanted a new contract to include a re-write of the original contract as a “Work-For-Hire” contract, something that was unacceptable. As we could not agree to unilaterally giving up our license, HS declined to sign a new contract. Hammond Software continues to develop ACBLscore+, under the new name of Bridgescore+. See Bridgescore+ web page for more information. The rest of this site remains unchanged from the original project.

This web site provides information about the ACBLscore+ software, the replacement for ACBLscore. The site is intended to help ACBL members know more about the project. Updates to the project will be posted periodically on this site.

This site last updated on November 18, 2013.

We have blocked access to adding comments. We were getting way too much spam (100+ a day).

If you have any comments or suggestions, please post to comments AT acblscoreplus.com.

For any questions about the current version of ACBLscore, please go to the ACBL web site.

This site is written and maintained by the developers of ACBLscore+ in conjunction with the ACBL. Any statements on this site are by the developers of ACBLscore+ and are not necessarily official statements by the ACBL.

In general we want to be as open as possible with this site, but everyone must understand that there is a legal contract between ACBL and the developers of this software so we may not be able to answer every question as openly as we would like. Questions related to ACBL policy should not be posted on this site.

We will do our best to reasonably answer questions posted on this site. Most likely this will be in terms of a periodic (once every 2-4 weeks) mass answer session, so don’t get upset if we take a little while before answering a question. In general a question that is likely to apply to multiple users will get answered first. We will adopt the policy of adding to the FAQs rather than individually replying to each and every question so you may see your question merged with others.

If you have suggestions or ideas for ACBLscore+, please post them on http://ideas.acblscoreplus.com.

Yes, we are bridge players and ACBL members!

We have a Yahoo Groups email list where we will send periodic updates on the project. To join please click on the link and enter your email address. This will save you having to revisit this site for updates.

There will be a presentation on ACBLscore+ at all upcoming NABCs. See the ACBL web site for more details.

Click to join ACBLscore+ Announcements Email List

  25 Responses to “Home”

  1. The Japanese have a method of getting scores directly to the players within 1 miute or so of the game finishing, included immediate printouts.. You should look into it

  2. Ever since our club adopted the Bridgemate scoring devices, our club’s software has provided a list of the contracts at each table as well as the scores on the recap sheets. I do not know whether this was something our club did on its own, or something that is now part of the standard ACBLScore. So my suggestions will be somewhat dependant on what the status of this is.

    1. If the contracts are not a standard part of an ACBLScore recap sheet, they need to be made part of that recap. When reviewing results, the score by itself is of little use, particularly for defeated contracts. If the contract was made, it is frequently possible to guess what the contract was, but a “+50″ or “-100″ is meaningless if the contract is unknown.

    2. Our club’s software presents these contracts in a totally obtuse format that is very difficult to read. Long ago I wrote a program to read these recap files and re-print them in a more readable format. So if this is part of standard ACBLScore then please change it. What we need is simply one more line on the recap to give the actual “result” in addition to the score, i.e. “+450″ as it now reads, and then on the line right below, something like “4HE5″ for 4 hearts by east, making 5. And please present the result as a simple text file, as the old ACBLScore did, not the HTML garbage that our club’s current software puts out.

    3. The old ACBLScore had a huge variety of formats for the header at the top of the recap sheet. These multiple formats served no purpose, and even though it was club policy to print all recaps using a single set of options, most club directors were unable to figure out how to do this, so the result was the header format changed randomly from game to game. Since I have written my own program to further analyze my results, this was an incredible pain. Ever since our club implemented the Bridgemates, and the software to print the contracts, this has gone away, and all headers are now standardized. Again, I don’t know if this standardization applies to all of ACBLScore or just our club’s software. So, if it is not already present, please adopt a single standardized header format, instead of allowing a zillion options.

    4. Rounding Errors (this is a biggie). ACBLScore rounds off matchpoint results inappropriately when a board has been played 1 (or more) fewer times than standard. Of course the matchpoints only need to be printed to 2 decimal places as is done, but DO NOT use these rounded results to compute each player’s total. I have played in several games where the winners actually tied, but due to inappropriate roundoffs one player was shown at 0.01 or 0.02 matchpoints ahead of the other and, instead of awarding each player the number of masterpoints appropriate for a tie, one was deemed the winner, and the other deemed to be 2′nd place.

    5. Corrected Results. When a result is corrected after transmission by the Bridgemate, our club’s software allows the director to simply change the score, without changing the result. So you will frequently see such nonsense as 4HE with a score of +170. This one is easy to figure out; obviously the results was entered incorrectly as 4 hearts by east, making 4, and then later on someone realized it was actually 2 or 3 hearts, making 4. But what in the world happened when the contract is given as 4HE and the score is +100? Well, I guess N/S sacrificed, but at what contract? The solution is easy; do not allow the director to change the score; require that the entire result be changed. One of the purposes of the Bridgemates is that no one should be entering in any score, because it is all too easy to mess up the vulnerability and enter something incorrect. So when a score needs to be changed, the director should reenter the entire result (4 spades N, doubled down 1) and ACBLScore should compute +100 or +200 E/W as appropriate.

    6. E/W Bridgemate verification. This may be separate from ACBLScore; I am not sure, but it still needs to be fixed. When the Bridgemate result is presented to E/W for verification, the score is always shown from the perspective of the declarer. This is bad; the score should be shown from the perspective of E/W, sice they are doing the checking. If the result was 4 hearts N down 1, the score presented to E/W should be “+50″, not “-50″. Now, it is all too easy for north to enter the declarer direction wrong and E/W not to notice.

    7. (minor point) Get rid of that “-” for 1/2 matchpoint. Use “2.5″, rather than “2-”. This is totally confusing, especially to newcomers. Better still, would be to simply double all matchpoints (2 for a win and 1 for a tie), to eliminate these annoying fractions. Of course you will still need decimal matchpoints as in #4, above, but this doesn’t occur much of the time.

    • Various questions added to the FAQ.

    • That “html crap” is text, and there are plenty of tools that will easily strip out the html code from the rest of it.

      • The problem (for ACBL) and those that strip out the results is that if ACBL changes anything then it can have unknown consequences.
        I have spoken to about 4-5 different companies/people that strip the data from the HTML and it’s not easy or pretty.
        An XML interface is much the better way to go (HTML is an implementation of XML).
        With an XML interface it will be much easier for all involved.

  3. I think it is very unfortunate that the source code will not be open source. You would get to a much higher quality level much more quickly with a community to help. ACBL does not make its money by selling this software.

  4. A nice feature for club games would be the option for a second monitor, always active, updated with each score entered, either by director or by bridge mate, to present the Leaders of the event.

    This is especially nice @ the end of the game, which would allow the players to ‘see’ their standing without ‘hovering’ over the director. Perhaps an option could be to have it active in the last round only or after there are a majority of the results entered to provide realistic information.

    We all have access to large tv’s which make great monitors and for very readable text.

    Also, our club would be proud to be a test site when the program is useable.


    • Can’t give specifics, but we are looking at lots of options regarding second monitors/other forms of output etc. Some of it is software driven, some can be hardware driven (e.g. your OS supports a second screen). The current ACBLscore is a single application, the new ACBLscore+ will have the concept of multiple screens. The output of results is a ‘big’ issue for players and directors. It is something that the ACBL is looking at (in addition to the work for ACBLscore+). We have to do something that works at both a local club, but also the big nationals/regionals (e.g. 30+ brackets in a KO event, > 150 teams in a single Swiss event) etc.

  5. XML is a dinosaur of a data interchange format: see, e.g. this article.

    Aside from using a modern data interchange format, there should be an effort to create a standard format for the data itself (independent of the XML issue) so that the results data can be packaged usefully for upload to the Horn Lake OR other servers. This standard should be a bridge community effort, not an ACBL-solo effort.

    In fact, aside from duplicating existing ACBLScore functionality, the most important functionality of the new program may be its ability to efficiently transfer the data to other servers. So, for example, Randy Corn mentioned the instantaneous updating of results data in Japan. This feature is important and computationally easy provided that metadata incorporates a unique id that entails multiple versions of game results to accommodate updating of results.

    I agree with Paul’s comments about open source. In particular, the scoring and matchpoint calculations SHOULD be open source. The current plan of mixing open and closed source with a variety of languages is a design “yellow flag.”

    • I understand the different data format issues.
      I agree with you regarding data transfer and the intent.
      We are going with XML for the near future, for a variety of reasons.

  6. For matchpoint scoring, please drop the actual matchpoints and only show percentage for each board.
    Actual matchpoints was obviously easier when scoring was manual. Now percentages is nothing for a computer. You no longer need to know what a top was to understand the score. Everything will be consistent.

    • Partially agree.
      To make the transition simple and smooth for all involved (players, TDs etc.), it is likely that the first release of ACBLscore+ will have the ability to generate the results in a similar format as current.
      Not to say that there will not be more advanced formats available, but a smooth transition for 160,000+ members is also important.

      Our ingrained culture is the match point.

      • I do listen… am getting lots of input on this from many.
        I will now push to have the percentage score added to the default output.
        It does have lots of advantages for newer players.
        And us older players too.
        To ease transition, we will also include matchpoints for the foreseeable future, but I can see a time that the matchpoint score will get dropped.

  7. Please do NOT drop display of match points from results. I want to know how I did in comparison with others by match points. Percentages are only an alternative display of the real data, match points. If I am 2 percent behind the one who scored higher than me, I don’t know if that is one match point or five without doing extra mental gymnastics. I teach new folks that though knowing your percentage is nice, it is really match points that produce those “precise” percentages. If you know you missed the next placing by one match point it helps you put in perspective the importance of the overtrick you missed, or whatever.

  8. This is certainly a minor inconvenience but when a club member has already been assigned to a playing pair they should never be shown as a possible player for another pair.

  9. One other item that might be considered. For clubs that do not use Bridge Mate or Bridge Pad it would be nice to be able to enter the contract and result into ACBL Score if one was so inclined.

  10. Question, will you be developing an App at the same time so that I can use ACBLScore on my new IPad Mini.

    • No plans for a specific App for the iPhone/Android however you will be able to access ACBLscore+ from your iPad/iPhone using the Web Browser and be able to enter scores etc. etc. from it.

  11. Will you be doing anything about the ACBLScore user documentation? New users and new club managers become visibly frustrated when trying to use the current documentation to do anything without a current user standing over their shoulders to help. Task orientation and step-by-step instructions have been old hat in the user doc world for years, and that would make a huge difference.

    • Yes. Don’t know the specifics yet. There are lot of people who are ‘trained’ in the current way of doing things.
      We will probably do some A/B type testing to find out how people will use the system.