Hi everyone,

I'd like to share with you something I've been working on for the past few months: TournamentDroid!

It started as my final project for a software development course I was doing earlier this year, a C++ application for Windows. Quite satisfied with the result (on top of getting very good marks for my work), I decided to push it further, make the interface fun (if a bit quaint) and release it to the world.

I believe it is now ready to be used by TOs. I've done extensive testing so it should be holding together. Please provide feedback, as I'm still learning about software engineering and I'd love to know what people think of it.

Obviously I'm entering a market lead by Cryodex, which I think is great, and much more versatile than my product. But through conversations with some TOs in France I've discovered that some people would prefer a much simpler interface and don't use Cryodex as a result. So I've tried to build something with simplicity and ease of use in mind.

Go to http://tournamentdroid.16mb.com and download it now!

I've tested it on Windows 7 and Windows 10. I'm planning to make a macOS version, but that will take some time as I want to rewrite it from the ground up in Swift (I'd say a good year or so)...

Please also think about Android version!

Would you consider doing an output for List Juggler?

Would you consider doing an output for List Juggler?

Yes, it is something I was already considering.

It's on my to-do list, when I find the time to explore APIs in Qt and how to connect my code to the Internet

Can you briefly talk about robustness? For example what would happen if players accidentally played the wrong opponent, or handed in the wrong results? Could the software handle the re-pairing, etc?

Is the source code available? Cryodex is open source, while means I can at least check that it works and isn't doing anything naughty, or modify it for a custom event.

Hi!

• Here's an example of a tournament json format that listjuggler expects
• If you want to be fancy and use the REST API, here's the specification
• +1 for open sourcing your code, always good! Here's mine.

Would you consider doing an output for List Juggler?

Yes, it is something I was already considering.

It's on my to-do list, when I find the time to explore APIs in Qt and how to connect my code to the Internet

You actually don't have to -- at minimum you just need to output a .json file that contains the tournament results. Example linked above. The tournament organizer then uploads that file into list juggler manually.

You can use the REST API too if you want to be fancy though :-)

Can you briefly talk about robustness? For example what would happen if players accidentally played the wrong opponent, or handed in the wrong results? Could the software handle the re-pairing, etc?

If players hand in the wrong results, it's possible to change them before generating the new round. Not possible after for now. I believe this can be handled easily enough. I still need to fix a problem when loading a saved tournament (editing table scores for the current round doesn't recalculate players rankings correctly), so it's kind of related. I'll work on both these issues at the same time.

Is the source code available? Cryodex is open source, while means I can at least check that it works and isn't doing anything naughty, or modify it for a custom event.

Would you consider doing an output for List Juggler?

Yes, it is something I was already considering.

It's on my to-do list, when I find the time to explore APIs in Qt and how to connect my code to the Internet

You actually don't have to -- at minimum you just need to output a .json file that contains the tournament results. Example linked above. The tournament organizer then uploads that file into list juggler manually.

You can use the REST API too if you want to be fancy though :-)

Plus I think knowing how to do it is quite important as a developer. I take every opportunity to learn more!

Thanks for the links, that's very helpful!

Do I hear a challenge?!?!?!?!

Good luck with your work. Let me know if you need any help!

Holy crap! GUI work with C++? In the words of Leia, "You're braver than I thought."

If players hand in the wrong results, it's possible to change them before generating the new round. Not possible after for now. I believe this can be handled easily enough. I still need to fix a problem when loading a saved tournament (editing table scores for the current round doesn't recalculate players rankings correctly), so it's kind of related. I'll work on both these issues at the same time.

I can't tell exactly what you're saying, but you probably don't want to re-calculate ranking when you reload. Ranking is the sort of thing a TO might have to change manually, and then the changes won't be persisted across a reload. I would store it in the database.

Apologies if I misunderstood your comment.

If players hand in the wrong results, it's possible to change them before generating the new round. Not possible after for now. I believe this can be handled easily enough. I still need to fix a problem when loading a saved tournament (editing table scores for the current round doesn't recalculate players rankings correctly), so it's kind of related. I'll work on both these issues at the same time.

You probably don't want to re-calculate ranking when you reload.

Ranking is the sort of thing a TO might have to change manually, and then the changes won't be persisted across a reload.

I would store it in the database.

In all the years I've been doing this, I've had one local TO ask about manual modification. If you're going to do it, I think a database is excessive. Just add an MOVOffset value to the player if you need to manually change MOV. If you're trying to manually change anything else then you've made a much bigger mistake.

If players hand in the wrong results, it's possible to change them before generating the new round. Not possible after for now. I believe this can be handled easily enough. I still need to fix a problem when loading a saved tournament (editing table scores for the current round doesn't recalculate players rankings correctly), so it's kind of related. I'll work on both these issues at the same time.

You probably don't want to re-calculate ranking when you reload.

Ranking is the sort of thing a TO might have to change manually, and then the changes won't be persisted across a reload.

I would store it in the database.

In all the years I've been doing this, I've had one local TO ask about manual modification. If you're going to do it, I think a database is excessive. Just add an MOVOffset value to the player if you need to manually change MOV. If you're trying to manually change anything else then you've made a much bigger mistake.

So where is the player data stored, if not in the database? And how do you tell at which round the player was penalised?

Using only a player adjust, you could not regenerate the event from the data.

If players hand in the wrong results, it's possible to change them before generating the new round. Not possible after for now. I believe this can be handled easily enough. I still need to fix a problem when loading a saved tournament (editing table scores for the current round doesn't recalculate players rankings correctly), so it's kind of related. I'll work on both these issues at the same time.

You probably don't want to re-calculate ranking when you reload.

Ranking is the sort of thing a TO might have to change manually, and then the changes won't be persisted across a reload.

I would store it in the database.

In all the years I've been doing this, I've had one local TO ask about manual modification. If you're going to do it, I think a database is excessive. Just add an MOVOffset value to the player if you need to manually change MOV. If you're trying to manually change anything else then you've made a much bigger mistake.

So where is the player data stored, if not in the database? And how do you tell at which round the player was penalised?

Using only a player adjust, you could not regenerate the event from the data.

Hurray thread hijacking!!!

My data is stored in XML. Each player, round, match is a separate XML element. I could add that data in anywhere. I'm not sure how relevant "which round the player was penalized" is, but you could certainly add that as a requirement.

My data is stored in XML. Each player, round, match is a separate XML element. I could add that data in anywhere. I'm not sure how relevant "which round the player was penalized" is, but you could certainly add that as a requirement.

I don't think you're doing anything wrong.

My philosophy is that if I compute a tournament result like this, I will save it. It's just more versatile and robust. It allows manual edits, and it's more able to resist breakage if the pairing system changes in some future version of the rules, it allows tools to process it more easily, etc.

It's debatable what penalties should be associated with (the player, the round, both?) but they're still part of his database (I saw SQL queries in his code). I hope it's sqlite but I didn't check.

Work prevents me from trolling around in his code, but I imagine he's using an on demand database like Derby from what you're saying. They're good, but it's not the way I wanted to go with mine. Each has its pros and cons. I'm excited to get in and give it a look as I haven't done C++ GUI work in nearly a decade.

For the MOV adjustments, it just comes down to what your requirements are. It's not debatable, I just do what I'm told based on what the TO needs. So far, I have not had a request for this functionality.

Visual Studio has gotten pretty gd

Simplicity and ease-of-use being my main focus, I'll go the fancy route: the less effort required by the user the better
Plus I think knowing how to do it is quite important as a developer. I take every opportunity to learn more!

Thanks for the links, that's very helpful!

You are welcome! Please let me know if I can be of further assistance. I don't have a staging/QA server for you to play on, but you could always run juggler locally, the setup is pretty straightforward. Cheers

My data is stored in XML. Each player, round, match is a separate XML element. I could add that data in anywhere. I'm not sure how relevant "which round the player was penalized" is, but you could certainly add that as a requirement.

I don't think you're doing anything wrong.My philosophy is that if I compute a tournament result like this, I will save it. It's just more versatile and robust. It allows manual edits, and it's more able to resist breakage if the pairing system changes in some future version of the rules, it allows tools to process it more easily, etc.It's debatable what penalties should be associated with (the player, the round, both?) but they're still part of his database (I saw SQL queries in his code). I hope it's sqlite but I didn't check.

I am actually using a SQLite database to store my data. It's only really there for backup purposes, as everything you do while running the app is stored in the RAM (It's C++ objects arrays central in that thing!). In the first version of the program, it only saved the tournament name, date and the name of the winner in the database, the whole thing was running in the RAM. I then expanded the database to save every change along the way so that if the app were to suddenly quit, the user could retrieve the tournament data and resume it. I don't know if it's right or wrong to do it that way, but it seemed logical to me at the time.

Killerardvark please feel free to dive in my code, I'd love to hear your thoughts!

I then expanded the database to save every change along the way so that if the app were to suddenly quit, the user could retrieve the tournament data and resume it. I don't know if it's right or wrong to do it that way, but it seemed logical to me at the time.

I save after almost every click the user makes. Not sure about SQLite, but the time it takes to save an XML file in Java is faster than the user will ever perceive so there's no reason not to save excessively.

Killerardvark please feel free to dive in my code, I'd love to hear your thoughts!

I'll give it a look tonight. Just make sure you follow these few rules and you'll do fine.

1. Follow the rules. If your software doesn't match the tournament rules then you've already failed.

2. Plan for mistakes. Users are the spawn of satan and they'll screw things up. Be able to undo and fix anything!

3. Make updates in the name of easier use, and hide the complicated things. Power users will know how to find them, and the average Joe prolly won't care.

4. Finally, you're software will never be good enough for certain people. Grow a thick skin and shrug them off. This is volunteer work and they're not worth your time.

I am actually using a SQLite database to store my data. It's only really there for backup purposes, as everything you do while running the app is stored in the RAM (It's C++ objects arrays central in that thing!). In the first version of the program, it only saved the tournament name, date and the name of the winner in the database, the whole thing was running in the RAM. I then expanded the database to save every change along the way so that if the app were to suddenly quit, the user could retrieve the tournament data and resume it. I don't know if it's right or wrong to do it that way, but it seemed logical to me at the time.

There's no objective right way, but you've made a sensible choice using standard tools and you can't really be faulted for that.

I save after almost every click the user makes. Not sure about SQLite, but the time it takes to save an XML file in Java is faster than the user will ever perceive so there's no reason not to save excessively.

It's perfectly transparent on my software as well, I felt no difference in performance with or without the database, everything is pretty much instant!

1. Follow the rules. If your software doesn't match the tournament rules then you've already failed.

Obviously that would defeat the purpose of making the software in the first place! Apart from the recently added specifications about players dropping mid-tournament, I believe my code logic and user features follow the rules as accurately as possible. I also need to add the Strength of Schedule (I've kept it aside for now because in the various tournaments I've played in it's never been used or needed in any way. I suspect it could be useful for really big tournaments where scoring could be very tight between players).

As humbling as it would be to have my software used for really big, major tournaments, I don't think it's quite ready for that (v1.0, my first ever desktop program, I certainly don't expect it to be for a while!). I'm already going to be really, really pleased if anyone uses it for their small event!

2. Plan for mistakes. Users are the spawn of satan and they'll screw things up. Be able to undo and fix anything!

I've been working in Apple Stores for the last 8 years, mostly as a trainer for customers ('Creative'). I've seen first hand what they can do, and I'm still very perplexed by some of them !

3. Make updates in the name of easier use, and hide the complicated things. Power users will know how to find them, and the average Joe prolly won't care.

See previous answer

4. Finally, you're software will never be good enough for certain people. Grow a thick skin and shrug them off. This is volunteer work and they're not worth your time.

Haters gonna hate. Again, 8+ years in retail/customer service, I think I know how to handle unfair criticism and not to take things personally (except this time it's my personal work being criticised, but this is the Internet, I know what I'm getting into here ).

There's no objective right way, but you've made a sensible choice using standard tools and you can't really be faulted for that.

Thanks, that's good to know!

I would recommend looking at upgrading things to c# as the next language upgrade. With xamarin you can code for all mobile platforms natively all by writing c#. It's also not that dissimilar to c++ given that it is the descendant of c++ (It's c++ ++; programmers are not very clever at naming things)

I would recommend looking at upgrading things to c# as the next language upgrade. With xamarin you can code for all mobile platforms natively all by writing c#. It's also not that dissimilar to c++ given that it is the descendant of c++ (It's c++ ++; programmers are not very clever at naming things)

I really don't want to get into this but you wouldn't get away with that comment on a programmers forum, and I don't want OP, who claims to be a student, picking up opinion instead of knowledge. I believe you meant to say "alternative to" instead of "upgrade from" given that it's really hard to compare apples to oranges?

Having programmed in many languages including C++ and C#, I would also consider C# an upgrade. So much C ballast has been thrown out and it offers much functionality that is only available in C++ with additional libraries. I think the OP mentioned programming with Qt, which goes a long way towards alleviating the shortcomings of C++.

Agreed that List Juggler outputs would be amazing if they can be implemented.

Also, just a question in general - why do people always want Android versions? I can understand Mac OS as many people have laptops but do people actually run tournaments on Android tablets?