Closed widavies closed 2 years ago
Proposed naming scheme:
An (all caps) FRAGMENT is one TEAM in one ALLIANCE of one MATCH in one EVENT that may or may not be in a DISTRICT, but is definitely in a SEASON (2020 competitive season, 2019 preseason, 2020 offseason, etc)
Multiple SAMPLEs (completed FORMs) may be submitted for each FRAGMENT.
What is the difference between a match and a playoff match? Will these be distinct within the system in some way, or just different names for a match?
Naming strategy works great. A FRAGMENT will replace legacy CHECKOUTs. A FRAGMENT contains a series of SAMPLEs. A SAMPLE maps directly to one completed Roblu form (pit, qual, or match). For flexibility, unlimited samples are allowed (of any type), but certain teams may elect to limit this (1 pit, 1 qual, 1 match) or (1 pit, 1 qual, 2 matches), etc either by procedure, or by a configurable limit within event settings. One thing we'll have to consider is merge conflicts.
The reason merge conflicts (or multiple samples rather) matters comes down to analytics. Let's say each match sample contains "METRIC Y". If a user would like to rank teams by how well they performed at "METRIC Y", it's unclear which sample to pull this from (if there are 2 or more). Should we rank the quality of different scouters? Should the most recent sample by used? Should they be averaged together? Can we design analytics to just display both samples for the same data point? During analytics, it would also be relatively easy to filter by scouter or device, which would be one way to handle it. I imagine once we design analytics, we could figure out a lot of really useful ways to present multiple samples and gain additional insight.
Proposed Design V1
Goals:
Notes:
UI Design:
Data structure design:
The fragment manifest must efficiently support querying all fragments with a team id, all fragments with a match id, or a specific fragment for team id and match id.
Some common queries can be achieved as follows:
The advantage of this design is:
What is the difference between a match and a playoff match? Will these be distinct within the system in some way, or just different names for a match?
Playoff matches have additional importance and a different set of logic, scoring, and parameters. One thing we will want to do in the future is provide live predictions for event winners and district championship/worlds qualifying teams. Defining a clear separator between Quals and Playoffs makes this an easier logical task to implement in the future because the matches are so different from each other (even down to what certain game elements are worth).
Should we rank the quality of different scouters? Should the most recent sample by used? Should they be averaged together? Can we design analytics to just display both samples for the same data point?
For V1.0 we only need to take the most recent sample. Soon after that we will need to do some planning to implement the added merge features. I think all of these should be options (and probably even more). Take a look at the Citrus Circuits scouting white paper for more ideas. For data structure design, don't worry about merge conflicts. We can handle those with other logic later down the line. Just make sure fields have a way to tell if they were used or not, and a timestamp for the form.
We may want to think about gathering live analytics throughout the match to see exactly when a scout entered data points. When we get into more advanced data analysis, we may be able to correlate scout entry times with OCR scans of the match videos to more accurately resolve discrepancies from the official scoring. I don't think this needs to be at the front of our minds yet, but it is good to think about.
In the manifests and UI we need to account for displaying and handling unknown data. During a competition we need to fight to grab unknown data as soon as it is available. I think this would be best implemented via a central server backend that polls TBA for all event data, and pushes data to the app. If we are pushing data to the app (rather than pulling) it will save data, reduce load on our servers. I think this would be a Roblu Cloud exclusive feature. On-device auto sync should be handled with user-generated TBA API keys, not Roblu owned ones.
Overall I think this is a good writeup
Adding a few more polishing design details:
full
, in which case the sample contains a completed form. The kind may be started
, in which a user has claimed that they have started working on the fragment for a particular form type. Later, when the user submits a full
sample, the started
object can remain, but will be defunct. This started
tag is useful when "fragments" are up for grabs & users self-opt to complete them. The started
tag is basic a user's claim to complete the fragment.
Design of how data is structed in events.
For a flexible system, the following should be supported:
Make sure to also track who won the event. Team profiles should have links to TBA & team website.