If you design things correctly you sometimes get functionality such as this for free. I did not set out to provide this strange ability but it would have taken more effort to NOT have it than to have it.hgm wrote:Indeed, this is good strategy. But of course WinBoard supports straightforward time-odds too, even through the GUI menus. What I doubt the usefulness of is playing fixed-depth versus time, or incremental TC vs classical. That just seems to serve no point.Don wrote:It's not a work-around for us and for 99% of the developers it's a must have feature. Since the early days of Doch we have never played even matches against foreign opponents as it's a huge waste of time. Instead we would pick a very strong opponent and give it a time handicap. In this way you spend almost all of your time testing YOUR program, not everyone else's.
We rarely use that feature but we HAVE used it 3 or 4 times to do exploratory experimentation such as to determine which time control style give you the most bang for the buck. Let's say you limited to 5 games per minute and want to get the strongest play possible, which time control do you use? Fischer, move based time controls or fixed depth, fixed nodes, etc. ... ???
So more flexibility is never a bad thing. In general the more professional you are the more flexibility you demand from your tools. For example I am not a graphics artist and I find gimp and corel draw confusing - much preferring simple tools that don't do much but that I can understand. But an expert who knows what he is doing is going to want to use the best tools and will take the time to learn the complexities that add flexibility.
Same principle with Linux command line. It makes you fly in comparison to insisting on graphical tools that dummy things down for you and slow you down at the same time. An expert who knows his way around the command line knows the power it gives.
I try to adhere to the unix principle which is to provide low level tools that have maximum power so that you can assemble them in creative ways. That same principle applies to software design. My tester doesn't rate games for example, that is handled by ordo or bayeselo but we automated with simple scripts. If the tester did it for us we would be locked in to its way of doing things.
WinBoard is actually ideally equiped for implementing such things; afte each move it does "playerClock += TimeQuota(moveNr, tcString)/playerTimeOdds", where tcString can be something like "40/3600:20/900:300+1". Currently both players use the same tcString, built from the conventional -tc, -mps and -inc options, but it would be totally trivial to provide string options -first/secondTC that would overule those, when non-empty, and could then be installed with the engine. So it is not like the work discourages me. I just think it is a bad thing to have. More is not always better, and the 'maximum-flexibility-minimum-usefullness principle' is always looming around the corner.
So the tester itself doesn't do much of anything other than scheduling and playing games and the simplest possible way to provide configuration is to do it by entity. One entity, one set of options and 1 time control etc. I cannot believe that the simplicity of this wouldn't appeal to you. The beauty is that if someone wanted to to provide a version that was dummied down, it would be trivial to do so. IN FACT I do it myself, I sometime write scripts to write configuration files when I'm doing some interesting study that requires a complicated configuration - and I can tell you that it would be much more difficult to do with mouse based interfaces.
I think that xboard has some of these characteristics in common. You can script your tester if you want because it's easy to call it up to play a single game or a set of matches.
I am very interested in looking at cutechess to see if they have embraced this tool concept. From the description it looks very good. Here is the blurb: "Cute Chess is a set of cross-platform tools for working with chess engines."Yes, I know the feeling. Blitz Chess is strongly hypnotic.If I had games being displayed I would want to watch them instead of working
That is pretty contradictory once you remove the misconception that starting your own fork from an open-source solution should imply that you must become maintainer of the main branch. That it worked out for me that way is really an unintended coincidence of circumstances, mainly because WinBoard was really orphaned at the time I needed it, and my general susceptability to requests for help that I can easily satisfy. I would not even have had to open the source if I had just used it only privately. If I would have started from scratch, I would have had to spend years before even having a vey basic GUI, if I could have done it at all. (I had never done any GUI progamming whatsoever at that time.) By starting from WinBoard it took me about 1 week before I could do what I originally intended. (Which was playing with 7 piece types rather than 6.)Because nothing beats a custom solution. It's likely I would need to support some feature nobody else cares about and I have no interest in keeping my changes in sync with other developers. For me it's a tool, a means to an end. I'm not a tool developer except when I have to be.
If that is the case then of course I am interested. By the way, one of the reasons I like xboard is that it can be used like this too.