I also have trouble seeing what's really needed. Slap on QR code functionality (output and input) on Geordanr's squad builder, and that's basically almost what you need?

He's already on the case.

No need for a header because he's already done the job of filtering the squad information in his long "permanent links". All the QR has to do is play with a "longish" url. It doesn't need to be clever at all with the information of the squad - this will remove the need to constantly extend the QR part of the code - do it once for displaying a URL (which has been done to death everywhere) and it's done. I bet he can do it in 15 minutes tops, most of it spent on searching an easy source.

The issue with using a QR code to provide a link, instead of the squad details directly, is it forces the tournament software to have to be smart enough to go to the squad builder website, and pull the data. And it would have to be compatible with every single squad builder out there, and they all behave differently. And when someone makes a new squad builder, the tournament software now has to go add that new one to the list to be compatible with too....

It's much cleaner to provide the same standard interface that the squad builders need to adhere to, rather than the other way around. You also can't guarantee that the venue will have internet at the event. Generally this shouldn't be an issue, but you don't want to handicap your entire tournament software in situations where the venue does not have WiFi.

All very good points. My goal would not be to trample any work previously done. I know of and use 3 different Squad Builders and 3 different Tournament softwares. All of these have their pluses and minues. Perhaps the title of my thread is a little overpowering as the intention is to find the common link so they may work together. The Cryodex is the most functional software to run events but not the most convenient. As a TO I'd rather not have to lug in my computer and set it up to run an event. There is an app called X-Wing TO for running events but is sometimes buggy and crashes. The last tournament software is web based but has not been updated to MOV and it won't let you drop players mid tournament.

The tournament app would have to have a squad builder built in to make it easier for the software to translate the QR code and allow for last minute registration. By making the app for Android, Apple and web base, you can have the participants build a squad on thier mobile device. This then could just display the code on screen to upload into the app. If a player does not own a smart phone you could always have the option to manually input the squad during registration.

I've been thinking about this over the last few days (ever since Osoroshii brought it to my attention), and I've also come to the conclusion that there shouldn't be The One App; after all, as mentioned we have several squad builders and multiple TO tools. I don't think we need to reinvent those wheels into one larger, all-consuming wheel.

It sounds like we're trying to solve multiple problems here:

• Make it easy to register a player's list at an event
• Create a comprehensive database of matchups and results for MJ to analyze

I agree about having a common interchange format to describe lists. While my builder has pemalink functionality, it's not compatible with, say, Fab's. The common format would have to feasibly fit in a reasonably-sized QR code for TO software to accept. (At which point, you have to figure out how to load that into a desktop-based TO app, if the desktop doesn't have a webcam.)

Unfortunately I've had a migraine since 7am and so assembling my thoughts on this any more has proven difficult.

Wasn't there was news a while back that FFG was going to be releasing their own squad builder software too?

Wasn't there was news a while back that FFG was going to be releasing their own squad builder software too?

That is the first I've heard of that? They well could release both a software for squad building and running events. It also could never happen.

Iffo sent me some great suggestions. Does anyone have experience with PhoneGap or Xamarin?

Yes, don't use them is my experience. Either go native or responsive, but those are just... well, neither.

That is the first I've heard of that? They well could release both a software for squad building and running events. It also could never happen.

All I ask is that it doesn't require Silverlight to use.

That is the first I've heard of that? They well could release both a software for squad building and running events. It also could never happen.

https://www.youtube.com/watch?v=rnrlBSvzxuU#t=1654

I'd love it!

Also, having some more sorting options for lists would be great.... I have like 200 lists in Geordan's.

The smart-randomizer option in the UK builder is also great for fun games. Wish that was in there too.

Seems like some sort of agreed-to standard for comma separated values (or whatever. It's been a long time since I did the technical side of this sort of thing) would go a long way towards making the various systems play nice with one another.

Basically, the back-end data should be roughly the same for most any squad builder, right? It's just the presentation of that data that differs?

Um, hi, BTW. Politics, sales, and general project management experience standing by. I am _very_ good at getting people to play nice with one another.

That is the first I've heard of that? They well could release both a software for squad building and running events. It also could never happen.

The only time I hear them mention a Squad Building application is the ability to build squads in Mission Control?

The issue with using a QR code to provide a link, instead of the squad details directly, is it forces the tournament software to have to be smart enough to go to the squad builder website, and pull the data. And it would have to be compatible with every single squad builder out there, and they all behave differently. And when someone makes a new squad builder, the tournament software now has to go add that new one to the list to be compatible with too....

That's a worthwhile endeavor.

But, as long as you're at it, wouldn't you want software that can not only read this material, but once the results have been tabulated to upload the results to a central location so that you can get data on what sorts of lists beat other sorts of lists?

Or, if you have names attached to the squads, you can start to develop a ranking system of all players.

Or is that too ambitious and problematic for when the NSA gets its hands on your data? (Well, either the NSA or Google.)

EDIT: worse yet, the Russians. If you are really good at X-Wing, they might figure your sexlife might be bad, and they could automatically send you a bride catalog.

The issue with using a QR code to provide a link, instead of the squad details directly, is it forces the tournament software to have to be smart enough to go to the squad builder website, and pull the data. And it would have to be compatible with every single squad builder out there, and they all behave differently. And when someone makes a new squad builder, the tournament software now has to go add that new one to the list to be compatible with too....

That's a worthwhile endeavor.

But, as long as you're at it, wouldn't you want software that can not only read this material, but once the results have been tabulated to upload the results to a central location so that you can get data on what sorts of lists beat other sorts of lists?

Or, if you have names attached to the squads, you can start to develop a ranking system of all players.

Or is that too ambitious and problematic for when the NSA gets its hands on your data? (Well, either the NSA or Google.)

EDIT: worse yet, the Russians. If you are really good at X-Wing, they might figure your sexlife might be bad, and they could automatically send you a bride catalog.

Yes, collecting the data from the squads is half the point. Right now MajorJuggler goes through great pains to collect the information. Even with all that work we get a slice of the data. We would know what pilots live the longest, who gets killed the most, so on and so on.

I'm not sure about ranking players.

So I was thinking of a way to get the data from a QR code in the tournament software. A QR code can have a max of 4296 characters using an alphanumeric system. Unless I'm wrong you could just start typing the entire list out and have it fit. The app would just have to be able to recognize pilots and upgrades to input the squad. You could even have the players name in the code for the fastest registration ever. Here is a QR code with just a squad as an example:

There if you scan it you'll see it's the Biggs walks the Dogs list Paul played to a world championship.

A couple of hundred bytes is a couple of thousand bits. It should be enough to represent the entire squad config as a bit vector.

EDIT: Nevermind. Ignore this. (Does this forum not allow posts to be deleted?)

I don't usually make up my mind about a squad until I'm at the venue, and pressed for a list by the TO.

This is an extremely important point. Some players will have a list ready, but some will not.

You have to be able to accommodate players that submit their list at the time of registration. At that point it is more difficult to capture the squad details. It'll take at least 60 seconds per player to capture the entire list correctly. I should pull (XwingtoMan) Sean who TO'ed GenCon to get his thought on this. You want to squad details but you don't want it to be disruptive to registration.

The QR code could absolutely be added to any of the squad builders out there. The app would also need it's own squad builder to be self sufficient as player will show up with out a preprinted registration.

Yeah, this would be a starting point. A QR code that contains all the squad details. You can't just do a straight text dump of the squad, since you only have a couple hundred bytes available even using a relatively large QR code. That might not be enough depending on the squad. You would have to use an encoding scheme.

You would also want a header in the QR code that defines what version the encoding is, since it will be continuously getting updated with new pilots and upgrades.

Yeah that's enough space. Just generating a random 500 point squad in void state and cutting-and-pasting the text results in a 900 byte file that compresses with .zip to 550 bytes.

So I was thinking of a way to get the data from a QR code in the tournament software. A QR code can have a max of 4296 characters using an alphanumeric system. Unless I'm wrong you could just start typing the entire list out and have it fit. The app would just have to be able to recognize pilots and upgrades to input the squad. You could even have the players name in the code for the fastest registration ever. Here is a QR code with just a squad as an example:

There if you scan it you'll see it's the Biggs walks the Dogs list Paul played to a world championship.

So once all the players are entered into the tournament here is what a match slip could look like:

This is a very crude version but helps get my point across. The check box is if the ship was destroyed during the match. So we can tell by the slip that the Swarm won(go figure) and had 3 academy pilots left. The TO would have a similar looking section in the app to fill out and the app would figure the rest out. So the results would be this

John Doe match points 0, MOV 57

Jane Doe match points 5, MOV 143

These results would be saved and the data could be analyzed and you could get a very clear picture of the state of X-Wing.

Representing a squad as a bit vector is not unlike how my or Fab's permalinks work. But in order to be common across squad builders there would have to be a single source of truth for mapping a given card to a given identifier, and I don't know if that's realistically feasible.

Instead I was thinking of a deterministic canonical representation of a card: something like converting the English card name to upper case, stripping all non-alphanumerics, and optionally attaching the card type (to differentiate between identically-named cards like Luke). So "Luke Skywalker" the crew card would canonicalize to "LUKESKYWALKER(CREW)". Maybe for convenience we include the points value afterward. Then a given ship with upgrades would be of the form CanonicalPilotName[points]+List[points]+Of[points]+Canonicalized[points]+Upgrades[points], e.g. "LUKESKYWALKER[28]+ENGINEUPGRADE(MODIFICATION)[4]+R2D2(ASTROMECH)[4]".

To guarantee that two identical squads canonicalize identically, ships and upgrades would be sorted.

Admittedly this is pretty verbose, but let's consider how big a given list is going to be. Worst case we're dealing with Epic lists, so we have 300 points to work with. At most you can field 25 12-point ships (I'm ignoring 12 ship restrictions for now), so let's proxy that for the number of cards in play; the longest canonical card name that I could find is STYGIUMPARTICLEACCELERATOR at 26 characters, and the longest card type is MODIFICATION (12 characters). That works out (roughly) to 1000 characters, well within the QR limit.

We'd also want to include a link to a squad builder representation, if possible, so that the TO can quickly inspect it if they have net access.

The QR code would have to use bytes, not alphanumeric, in order to support full Unicode player names as well as URLs. We should still be able to fit in the 2,953 byte limit of the lowest error correction version.

(Optionally we could also store a UUID generated by the squad builder.)

I'm working on a proof of concept at http://codepen.io/geordan/pen/ljLJn -- at some point I'll link in a way to read in my card database and convert a permalink into this format.

Use a red 'X' or perhaps a skull and crossbones icon to denote a destroyed ship. Visually, it will pay off...

We'd also want to include a link to a squad builder representation, if possible, so that the TO can quickly inspect it if they have net access.

I think the Tournament app would need to have a squad builder in it to interpret the information contained in the QRcode. It would be like if I built a squad on Yet Another Squad Builder and printed out my squad I could give the printed sheet to a fan of Voidstate and they could scan it into that squad builder. So when a player brings the printed sheet the QRcode would tell the app how to build the squad in the squad builder in the app. A link to the URL would not be needed. We could then have the Squad Builder in the app have the logic on if the squad is legal for the format being played.

The app would have a set of options when you are first setting up the tournament with the standard tournament rules, like dogfight, epic and so on. you could even crate a custom tournament with fields to limit squad points, named pilots or however you want. This way the App can accommodate and separate the data to tournament type.

Representing a squad as a bit vector is not unlike how my or Fab's permalinks work. But in order to be common across squad builders there would have to be a single source of truth for mapping a given card to a given identifier, and I don't know if that's realistically feasible.

Instead I was thinking of a deterministic canonical representation of a card: something like converting the English card name to upper case, stripping all non-alphanumerics, and optionally attaching the card type (to differentiate between identically-named cards like Luke). So "Luke Skywalker" the crew card would canonicalize to "LUKESKYWALKER(CREW)". Maybe for convenience we include the points value afterward. Then a given ship with upgrades would be of the form CanonicalPilotName[points]+List[points]+Of[points]+Canonicalized[points]+Upgrades[points], e.g. "LUKESKYWALKER[28]+ENGINEUPGRADE(MODIFICATION)[4]+R2D2(ASTROMECH)[4]".

To guarantee that two identical squads canonicalize identically, ships and upgrades would be sorted.

Admittedly this is pretty verbose, but let's consider how big a given list is going to be. Worst case we're dealing with Epic lists, so we have 300 points to work with. At most you can field 25 12-point ships (I'm ignoring 12 ship restrictions for now), so let's proxy that for the number of cards in play; the longest canonical card name that I could find is STYGIUMPARTICLEACCELERATOR at 26 characters, and the longest card type is MODIFICATION (12 characters). That works out (roughly) to 1000 characters, well within the QR limit.

We'd also want to include a link to a squad builder representation, if possible, so that the TO can quickly inspect it if they have net access.

The QR code would have to use bytes, not alphanumeric, in order to support full Unicode player names as well as URLs. We should still be able to fit in the 2,953 byte limit of the lowest error correction version.

(Optionally we could also store a UUID generated by the squad builder.)

I'm working on a proof of concept at http://codepen.io/geordan/pen/ljLJn -- at some point I'll link in a way to read in my card database and convert a permalink into this format.

Some good thoughts in there.

I use a similar notation in the Regionals / Nationals results thread that is unambiguous and doesn't require capitalization. You can have Luke as crew or pilot with the same exact string and it is not ambigious.

[Pilot] + [upgrade] + [upgrade]; [Pilot] + [upgrade] + [upgrade]; [Pilot] + [upgrade] + [upgrade]

I delimit with ; between ships, and + between upgrades. The first line is ALWAYS the pilot. The only potential ambiguity is with R2-D2, who can be both crew and astromech - although right now no ship can have both.

You could save some bytes by not transcribing the entire text for the cards. For example "Red Squadron Pilot" could simply be listed as "Red". I understand that you can make a 100x100 (or larger) QR code, but you want the system to be reliably read by the scanner / app / phone / etc. Decreasing the number of bits increases your signal to noise ratio. Likewise, most or many upgrades could be described in shorthand as well.

You could save some bytes by not transcribing the entire text for the cards. For example "Red Squadron Pilot" could simply be listed as "Red". I understand that you can make a 100x100 (or larger) QR code, but you want the system to be reliably read by the scanner / app / phone / etc. Decreasing the number of bits increases your signal to noise ratio. Likewise, most or many upgrades could be described in shorthand as well.

As I say, just assign each ship an id.

Another way would be to have upgrade type Id's to attempt to keep the numbers to 1 byte.

so EPT is 1 and PTL is 1 and expert handling is 2 so Luke with PTL and wedge with R2 astro and expert handling is:

[1:4]{1:1}[1:3]{1:2,2:1}

This was the original concept idea I had when dealing with the QR code. Simplify each card to a 3 or 4 character code that the app can translate.

Use a red 'X' or perhaps a skull and crossbones icon to denote a destroyed ship. Visually, it will pay off...

That is more of a polish thing. We first must lay the ground work. I've been working of a storyboard to map out the application flow. We will still need a coder to write the code.

The thing about apps is....

Touch screens are rubbish and screen sizes are small on most devices. A piece of tournament organisation software is much better suited to a desktop application in my opinion.

Squad building from a phone is something I think most people will want. I do agree that running an event from a phone could be cumbersome but I would not want to limit the use to just a desktop. Tablets are a fine way to go if the app is built correctly.

If I was encoding a squad "file format" that was future prrof i would just assign each ship and upgrade an id number and make sure that id number format was adhered to in anything producing a squad file.

[1:3]-7;15,[1:4]-9,[1:1]

is Luke with R2D2 and expert handling, Wedge with an R2 Astro, and a rookie.

That's not what "future-proof" means. Who is going to be the curator of the mapping between cards and IDs? What if the venue doesn't have an Internet connection and someone comes in with a squad that has an ID for a ship that just came out, but the software hasn't been updated? This is why I advocate a deterministic transformation from card name and type.

You could save some bytes by not transcribing the entire text for the cards. For example "Red Squadron Pilot" could simply be listed as "Red". I understand that you can make a 100x100 (or larger) QR code, but you want the system to be reliably read by the scanner / app / phone / etc. Decreasing the number of bits increases your signal to noise ratio. Likewise, most or many upgrades could be described in shorthand as well.

But if some card in the future comes out with a similar prefix, you'll get a collision (suppose in Wave 20 they release "Redbeard McShootington" -- "Red" becomes ambiguous). I suppose you could do some light compression by storing the shortcut mapping if there are multiple instances of the same card, e.g. in a 4 Red Squad list, it might be (representing it as JSON here for easier reading):

{
  'mapping': [
    'REDSQUADRONPILOT[23]',
    'FLECHETTETORPEDOES(TORPEDO)[2]'
  ],
  'ships': [
    {
      'pilot': 0
      'upgrades': [1]
    },
    {
      'pilot': 0
      'upgrades': [1]
    },
    {
      'pilot': 0
      'upgrades': [1]
    },
    {
      'pilot': 0
      'upgrades': [1]
    }
  ]
} 

But if some card in the future comes out with a similar prefix, you'll get a collision (suppose in Wave 20 they release "Redbeard McShootington" -- "Red" becomes ambiguous). I suppose you could do some light compression by storing the shortcut mapping if there are multiple instances of the same card, e.g. in a 4 Red Squad list, it might be (representing it as JSON here for easier reading):

Thankfully this is a fairly easy case, always spell out the new card. Although in this case "Redbeard" is different than "Red" anyway. If you had something like "Red Bandito Pilot" then you would need to spell out "Red Bandito".

I think that making the mapping between the encoded name/id/slug and the actual card text be something that people can't bikeshed[1] over is important. If you start allowing things like "Red" then people are going to start arguing over if it should be "Red" or "Red Squad" or "RedSq" or "Red Squadron" or oh dear lord kill me now.

I like the JSON idea, though I would fully embrace the format, and encode the list in JSON, rather than attempting a custom serialization. Using a standard data format makes it easier to parse, and more likely that everyone will produce a compatible serialization. Writing code that converts the JSON to MajorJuggler's text formal would be trivial.

{
    "player": "Eli",
    "cost": 100,
    "faction": "Imperial",
    "list": [
        {
            "cost": 37,
            "pilot": "Bounty Hunter",
            "crew": ["Tactician"],
            "title": ["Slave I"],
            "torpedo": ["Flechette Torpedoes"]
        },
        {
            "cost": 45,
            "pilot": "Colonel Vessery",
            "cannon": ["Heavy Laser Cannon"],
            "elite": ["Outmaneuver"]
        },
        {
            "cost": 18,
            "pilot": "Backstabber",
            "modification": ["Targeting Computer"]
        }
    ],
    "url": "https://geordanr.github.io/xwing/?f=Galactic%20Empire&d=v3!s!40:-1,-1,61,-1:1:-1:U.58;70:56,23,-1:-1:-1:;15::-1:5:"
}

I would:

- Make the top-level "cost" and "list" mandatory; "name" and "url" optional.

- Per ship, make "cost" and "pilot" mandatory

- Ship upgrades are lists per type (to avoid the R2-D2 issue)

- Upgrade types not present are assumed to be empty

- Ordering doesn't matter

1 - http://en.wiktionary.org/wiki/bikeshedding

Redbeard McShootington makes me nervous. I know everyone loves him, but I hope he's not OP in wave 20. I will not have him break down the game!