Pokémon TCG: Sword and Shield—Brilliant Stars

Tournament Software 1.07

bulbasnore said:
I think GreatFox might like your code (Cross-Platform Realbasic).
Click to expand...
Oh... I would very much love to have the VB Project file you used to make it. Like bulbasnore mentioned, I got Realbasic and was recently, "accidentally" upgraded to its Pro version which has Database and Cross-Platform compiling capabilities. It can also transfer and translate VB code into Realbasic since they are basiclly one in the same with a few exceptions.

It would be a lot of help since I'm both developing the software for Mac OS X and learning Realbasic at the same time (eventough I believe I've gotten the hang of it now). It would make things go a lot faster. Maybe we can both work on it together, you developing it for Windows while I port it and fix it up for Mac OS X (especially since both platforms require very drastic and opposing methods; especially when it comes to the GUI).

Let me know what you think.
 
I can't follow too much on the technical side because I don't know too much about programming, but I can agree that the TMS doesn't like any punctuation in the last names. We had a Matthew Lewis and a Matthew Lewis-Thorne. Believe me, it wasn't a pretty sight. We ended up calling one of them Matthew LT. That's the only way the software would accept everyone's name and pair properly.
 
Thanks for the pointers about the dashes and other punctuations that cause problems for TMS. My software doesn't care because I store my files in binary format. When I build the TRN import/export feature into my program tonight, I'll make sure I filter any punctuation problems (I'll probably just replace known punctuation problems with blanks).

I might be interested in putting this product's source out in the open and appoint someone, if not myself, to Config Manage it. I've not done that before, so after I publish tomorrow and if there's still interest, I'll talk more about putting the code on some open source site.

Finally, the code is VB 6.0. I'm not sure if that means anything with regards to using VB DLLs and OCXs. Does anyone know if MS controls how you can distribute VB code that uses their controls?
 
DGL, what do mean by "PUI math?" Are you talking about the tiebreaker? I know the DCI Tiebreaker for Opponent's Win Percentage, and that's what I've implemented, not the TMS Tiebreaker. If you're interested, here's how Reporter calculates the tiebreaker:

- calculate the win percent for each opponent where
-- win_percent = max (1/3, total wins / total games)

- opponent win percent = sum of all win_percent / number of opponents

However, I seem to remember that byes in DCI Reporter are handled differently when calculating the opponent win percentage tiebreaker.

Questions like these would certainly be wonderful open-discussion items if we decide to create an OpenSource forum for developing and maintaining a freeware tournament software program. I'm all for it.
 
Believe me, I'm more than well versed in how Reporter does Op Match Win Percentage. Nobody's sure of how TMS does this. I can't get a definitive answer from anywhere. So if anyone does have any insights as to how TMS does it (it's very different from how Reporter does it), I'd really like to know. Most of the problems highlighted here with TMS (with the exception of Version 1.07) are covered ad nauseum in the TMS guide on TC's website that the wife and I put a few weeks into developing. For those who haven't read it yet, I highly suggest you do.

As for repackaging of the VB core components/runtimes/controls/libraries (unless you're writing your own custom components), it's not a problem. Developers do it all the time. Plus, the core runtimes are available on an MS server for public download. Just make sure that if you're including custom controls/libraries that they're registered correctly (which I think is a big problem with TMS as it doesn't register a library correctly).
 
Last edited:
After working tonight on making my software read/write TMS .trn files, I realized that I originally wrote my software to handle smaller tournaments (max of 128 players, 8 rounds). I originally didn't intend to give this software to anyone else, so I didn't plan ahead to make it handle tournaments larger than what I normally run.

At a later date, I'll modify my software to handle just about any size tournament. Until then feel free to use/change my software.

Rather than provide the URL here on this site, please email or private message me and I'll give you the URL. For those of you who've already done so, I'll email your (or send a private message) when I publish.

Thanks for your interest.

PS. Maybe we should start a tournament software development group and together develope a commercial-grade product that's open and free.
 
:::WARNING:::

I changed my software today to export TMS .trn files and suddenly the auto-pairing algorithm broke. (M

Hold on downloading this until I fix it in the next hour. Sorry about that.




OK, I changed my mind. Rather than email everyone, here's the URL for the directory containing all my source.

www.nancyweb.com/pokemon/ts

For those who only want to install and look at the program, here's the win-zip file. Just download the file, extract it, then run the setup.exe file.

www.nancyweb.com/pokemon/ts/setup.zip

Just a few things.

- I originally never intended to release this program. I currently don't have a help file or manual, so you'll have to hack your way around for now.

- Although my program exports to a TMS .trn file, if the players aren't in the TMS Access player database already, the .trn file can't be read. But, I suppose the file will upload to PUI correctly even if the players aren't in the Access player database (so long as you've registered the POP IDs with POP). I'll try it this weekend for our Prerelease.

- I currently haven't implemented Top X playoffs yet.

- because this was intended for small tournaments, the tournament file limits are:

-- 128 players (64 matches per round)
-- 12 rounds

- The player database however can store as many players as your disk can hold. Eventually, I'll probably make the tournament file limits much bigger.

- Just a quick guide to features of the software:

1. player data can be stored in a separate file (player database - kind of like the DCI local players file) and registered into the tournament by clicking a dropdown button. If you entered a birthdate for that player in the database, his correct age will be calculated based on the system clock when you register him/her.

2. when entering an age manually thru player entry, use the full age in years. The software does the age categories if age-modified option is turned on.

3. printing is done in arial, 10 pitch

4. I developed this program expecting a screen resolution of 1024X768 or higher. You might have to do some scrolling for lower resolutions.

5. The program is very basic right now, so go easy on the critiques. This is NOT DCI Reporter. It's just my homegrown software.

6. the age-modified pairing algorithm tries to adjust situations when a younger player plays any older player with a different score. basically, age takes precedence when scores are different, up to a max score difference of 3 points (or 1 win). Also, the tiebreakers are NOT used to do pairings, only the scores (and ages for age-modified) are used for pairings. See the code for more details. However, you'll see the tiebreaker (opponent win-percent) when viewing/printing the standings.

7. When adding late players, you have the option to give them byes or just add them. In the later situation, they are entered into the tournament with DNPs (Did Not Plays) for the applicable earlier rounds. If you want to pair late players with byes, just add the players and go the the pairing screen to unpair those players from their byes and/or DNPs. Then you can manually pair them. Unlike BYEs, DNPs don't give a player any score points.

8. I've tried to trap many possible user errors, but I'm sure I've missed some alone the way. Feel free to email me with suggestions and critiques.

9. to drop players, just delete them in the player entry window after the tournament has begun. If you try to delete a player whose already dropped, they'll be "undropped." However, the software CAN'T handle players who drop for a round or two and come back to play later. I might add that feature later, but I'm not sure it would be legal to do in a sanctioned tournament.

Have fun.
 
Last edited:
SteveP said:
PS. Maybe we should start a tournament software development group and together develope a commercial-grade product that's open and free.
Click to expand...

That would be great. I liked the sourceforge suggestion.

I'm not a fan of Win32 .dll/ocx as they dont run on other platforms (Mac/Linux/Palm); maybe there is enough horsepower to code this in something else or maybe GreatFox will have success with RB translating it despite the controls. At least having the pairing/scoring algorithms & formats out in the open will enable other ports to be compatible and use the same math.

Anyway, VB or not, I'm supportive of getting the community to host this in an open place and write it. Nice idea and thanks again for sharing your hard work (and the hard work of preparing for sharing your work with others :D as well).
 
bulbasnore said:
That would be great. I liked the sourceforge suggestion.

I'm not a fan of Win32 .dll/ocx as they dont run on other platforms (Mac/Linux/Palm); maybe there is enough horsepower to code this in something else or maybe GreatFox will have success with RB translating it despite the controls. At least having the pairing/scoring algorithms & formats out in the open will enable other ports to be compatible and use the same math.
Click to expand...
I can try testing it in WINE, though I'd prefer something that I can run natively. Consider this a vote for Linux & OSX versions/compatibility.

I'll also second the idea of getting it hosted on SourceForge. It might attract other coders and make it adaptable for other games. DCI Reporter is pretty clunky and hard to work with as well--I'm sure there are lots of TOs looking for an alternative.

regards,
:unknown-b
 
***** OKAY, IT's Fixed. (Stupid Logic Error :mad: ) *****

***** Uploading Now (Stupid 56K modem) *****

will be done uploading in about 20-30 minutes from the time of this post.

Hey, try to get that kind of quick response to fixing a bug from the TMS developers. :p

MAKE SURE you check that you've install version 1.0.1 and not 1.0.0. You know what they say about the initial version of any software program.... :D
 
Last edited:
Regarding standard pairing and scoring algorithms, I'm all for it. I doubt mine should be standard, but I'm for a consortium to set some open standards in this area. No need for those Reporter/TMS developers to keep all the secrets. :)
 
Well... I'll have to download and translate the Project to Realbasic again as soon as its done uploading. Anyways, I did manage to translate the previous version you had up. There seemed to be a little problem converting frmMain.frm. Somthing about a nilObject not being handled.

It seems to convert to RB fairly well. Some objects will have to be redone and lots of recoding will be nessacery, but it looks as though I should be able to get it working on OS X. It'll just take a liitle bit of time and more R&D. Just wish I had more Mac users with more Realbasic knowladge then me to help....
 
Well, I don't know where to go from here. I'm an old-school developer, but extremely interested in this endeavor. The best thing that could come out of this would be for someone to abstract the algorithm. So, to start this off (and maybe move to a more proper forum later), here's a my abstract of how the Age-modified pairing algorithm should work (and how I implemented it):

1. Sort the players randomly.
2. Sort the players first by score (without the tiebreaker), then by age-category.
3. Go down this sorted list and pair successive players, avoiding repeated match-ups.
4. If age-modified is turned on, try to avoid matching players outside their age group if their scores are different. For example, if a 9-year old has 10 points and is matched with a 25-year old who has 9 points, first try to re-match the 9-old with another person in his age-group who has at least 7 points or more, or second to pair him with an 11-14 year old who has 7 or more points.
5. Always try to give the odd-bye to the youngest, least-winning player. A good question is, should this step happen before step 3?

Okay, that's all from this geek.
 
a way is to treat it as an optimisation problem and seperate the weightings applied to each factor in a possible pairing from the search for a minimal cost.

So a very high cost is applied to potential pairings that include players that have already met. A smaller cost is applied if players are from different age groups. A moderate cost to pairs with differing records. Giving a bye to an older player can be given a higher cost that byeing a younger player.

You can then change how pairings are produced by adjusting a set of constants rather than having to write code ;)
 
On another note, since this is originally an MID based Windows app, I'll also have to completely remake the GUI to comply with Apple's Aqua Guidelines. So you can expect an entirely different single window GUI for the Mac OS X version.

Oh boy, its going to take lots of work to get this to work on OS X, but at least if a lot further along than anything I had beforehand. :)
 
Last edited:
Good luck GreatFox. Yah, VB code can look quite spaghetti, trying to separate the visual components and events from the underlying functionality. Plus, I didn't really use a Data Access engine, so the data is coded as record structures and arrays. Sorry, I didn't really build this program from the ground up with cross-platform, modularity, or maintenance in mind.

NoPoke, thanks for the weighted-cost idea. Actually, the most difficult part of the pairing algorithm is the re-trace code. That is, how do you re-trace and unpair already-paired matches when you get near the end and can't pair the remaining players without creating re-matches. I basically used a depth-search strategy without recursion (VB is NOT good for deep-level recursion). Regarding weight-costing, it doesn't work well if there are absolute requirements such as re-matches aren't allowed. Although I allow re-matches to be forced manually, my auto-pairing algorithm doesn't allow such. Nevertheless, I suppose you could implement threshold limits and set the weight-costs beyond those limits to force certain executable paths.
 
Last edited:
I'd use recursion.. but you are right the stack grows horribly. In the dark recesses of my mind I'm sure I came across a proof that any recursive programme can be expressd in a non-recursive form. I remember aving to construct my own large stcks in the dim past just to get around the old 64k page limit that many early compilers imposed on DOSers like myself.


Yes you do apply a very heavy cost to already completed matches. You don't have to apply limits as long as the overall costs are kept in check. (All of this stuff comes from an interest in Chess programmes during my time at University). SInce an exhaustive search is often impractical the problem of optimisaation becomes one of establishing an arbitrarily good solution rather than a best possible solution. I suspect that when reporter becomes blocked in its pairing algorithm it randomly changes a pairing and tries again. There are many points in the pairing processs when two equal or nearly equal pairs could be constructed.



I'll print out your pairing code and see if I can add anything constructive rather than the more academic stuff above ;)
 
This would be best if written in c++ but I'm not doing the work so I'll shut up about that now.

as far as pairings go, I think you'd solve alot of problems by creating a dynamic ordered linked list devided by ages. any odds in an age group could get matched with lowest in upper and upper in the next lowest. and a simple sub to up pair people that have already played before

that is.
linklist round
round.player1->round.player2->round.player3->round.player4
first step is to check if the list is even or odd, if odd, assign a buy, going by youngest first, then score, then match win %,
once thats done, start at the highest ranked player on the list, and pair that person with the next on the list, those two are then added to the pairings and removed from the linked list, and then so on down the road. if they've played before, then it skips down to the next closest.
this would let the linked list really do all the work and avoid any having to figure out big bad pairing methods. a side effect is it would remove any artificial limits on player and tournament size.
mainly all that would be needed is a simple database of the players, and a few lame if's in there to decide who goes on the list where.

my two cents.

-CattDreams

ps. good job on taking initative stevep! much better than my lazy butt
 
You must log in or register to reply here.
Back
Top