Developing a scorekeeping system for visual tournaments

Packet databases and other quizbowl sites, apps, or software should be discussed here.
Post Reply
User avatar
yeah viv talk nah
Wakka
Posts: 101
Joined: Wed Jun 18, 2014 10:01 am

Developing a scorekeeping system for visual tournaments

Post by yeah viv talk nah »

Motivation

There have been many visual tournaments (e.g. Eyes that Do Not See and BUMPY). Usually, these tournaments are written by adding images to Powerpoint, Google Slides (e.g. JAVA), or another online presentation software (e.g. Eyes XI on OneDrive), with a separate document containing answerlines.

To the best of my knowledge, there is currently no system that "supports" visual (or hybrid written / visual) packets - i.e., no software that incorporates information about the unique format of visual packets. Moderators use basic scoresheet software intended for written packets, and look at the answerline document separately. This is acceptable, but causes a few major problems:
  • Moderators need to keep three documents open at once to run a game, which is inconvenient.
    1. Packet presentation (in full screen mode)
    2. Answerline document
    3. Scoresheet
  • This may cause accidental exposure of answerline content (especially in now-ubiquitous online mirrors).
  • There is currently no way to automatically track and collect buzzpoint data for visual tournaments.
Visual Packet Format

From going through the above sets and other past visual tournaments, each packet is usually written in the following format:
  1. Title and/or packet number (# slides = T)
  2. Blanks to prevent accidental exposure to question content while the presentation is not in full screen mode (# slides = B)
  3. For each question q (# questions = Q):
    • Question header displaying the directive (# slides = 1)
    • Question body containing images (# slides = P), with coloring on each image slide p indicating the point value (e.g. superpower vs. power vs. conversion, plus giveaway)
      • In previous visual sets, P is often constant but sometimes varies in a set range (e.g. from 6-10).
      • The number of superpower slides vs. power slides vs. conversion slides often varies - for example, I found several examples of (very hard) questions being comprised of entirely superpower and power slides before ending on a single giveaway slide (sometimes itself being worth power).
Scorekeeping Infrastructure

I feel it is not worth it (at least for right now) to try to embed the presentation slides into the scorekeeping interface, so I'll ignore that portion of the infrastructure.

From the above discussion, the following information regarding the format should be provided by the set author or moderator or set author:
  • General packet format
    • Q (universally 20 in historical sets, but a hybrid format might use 10 visual and 10 written questions)
    • P (but this can be calculated automatically, as discussed below)
    • For hybrid sets:
      • The above
      • Number of written questions
      • How the visual and written questions are arranged (i.e. should they be arranged consecutively with all visual then all written, or switched back-and-forth between visual and written, or vice-versa for either)
      • Written-specific format details, like what scoring system is being used (e.g. ACF)
  • Packet-specific data, which could be provided for each packet in a JSON (like the one for written packets supported by MODAQ/YAPP), or a CSV
    • Answerlines to each question q
    • A sequence of numbers denoting the point value or type of slide of each slide p within question q
      • E.g., for a question with P = 6:

        Code: Select all

        20, 15, 15, 10, 10, 10
        or

        Code: Select all

        SP, P, P, C, C, G
      • The length of this sequence for each question can be used to automatically calculate its P.
    • For hybrid sets: the above, plus the data file for the written portion
I imagine a simplistic scorekeeping interface that operates similarly to how MODAQ supports written questions. For each visual question, the scorekeeping interface could show the answerline and a clickable sequence of slide numbers from 1 to P, with the point values displayed next to each slide number. Just like how MODAQ lets moderators click on the word on which a player buzzed, moderators could click on the slide number and proceed with scoring. This would allow collection of buzzpoint data for visual tournaments.

Discussion

Developing a scorekeeping interface that supports visual tournaments would be very beneficial, since it would reduce the number of windows moderators need to open from the above 3 to 2 and allow collection of buzzpoint data.

MODAQ already includes some of the features necessary for scoring visual packets (automated individual and team score tracking and all other logistics unaffected by packet format), or very similar features (such as the tracking of written buzzpoints and support for written questions, in the case of hybrid written / visual sets). In fact, I originally submitted this post as a MODAQ issue. However, I underestimated the amount of work necessary to add this functionality to MODAQ.

Development Effort

So, I was wondering if anyone would be interested in either:
  • Forking MODAQ to add support for visual packets, or
  • Developing "from scratch" a scorekeeping interface for visual or hybrid written / visual packets
Personally, I feel that since MODAQ is already so well-designed, it would be best to try the former before falling back to the latter. However, though I do have programming experience in other areas, I am not familiar with web app or TypeScript programming, so would like to reach out for anyone more well-versed to assist in this.

If you are interested, please feel free to reply to this post or send me a message (zubenine[at]gmail[dot]com or that username on Discord).

Note: the main reason I thought about this is because I am writing a hybrid written / visual set, and realized there was a lack of scorekeeping software that could support this (other than using a "vanilla" scoresheet, which is fine, but I feel this is a good occasion for development).
Ani P.
Farragut, UMD, PSU
Post Reply