Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for visual packets (and/or hybrid written / visual packets) #248

Open
ani-per opened this issue Aug 21, 2023 · 4 comments
Open

Support for visual packets (and/or hybrid written / visual packets) #248

ani-per opened this issue Aug 21, 2023 · 4 comments
Labels
wontfix This will not be worked on

Comments

@ani-per
Copy link

ani-per commented Aug 21, 2023

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.

Currently, there is no system that "supports" visual (or hybrid written / visual) packets. Moderators use basic scoresheet software intended for written packets, and look at the answerline document separately. This is acceptable, but causes two major problems:

  • Moderators need to keep three documents open at once to run a game, which may cause accidental exposure of answerline content (especially in now-ubiquitous online tournaments).
    1. Packet presentation (in full screen mode)
    2. Answerline document
    3. Scoresheet
  • There is currently no way to collect buzzpoints or other advanced stats for visual tournaments.

Visual Packet Format

From going through the above sets and other visual tournaments in the past, 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 (# questions = $Q$):
    • Question header displaying the directive (# slides = 1)
    • Question body containing images (# slides = $I$), with labelling via color indicating the point value (e.g. superpower vs. power vs. conversion, plus giveaway)
      • In previous visual sets, $I$ 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).

MODAQ Support

It doesn't seem worth it to try and embed the images into MODAQ. But from my understanding of MODAQ's current features, it should be smooth to add scoring for visual (or hybrid written/visual) packets, by asking the tournament author/moderator to provide the following:

  • General packet format
    1. $Q$ (universally 20 but a hybrid format might use 10 visual and 10 written questions)
    2. $I$ (but this can be calculated automatically, as mentioned below)
    3. For hybrid sets:
      1. The above
      2. Number of written questions
      3. 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)
      4. Written-specific format details like what scoring system is being used - these are all already built-in to MODAQ
  • Packet-specific data, which could be provided for each packet in a JSON (like the one for written packets already supported by MODAQ/YAPP), or a CSV
    1. Answerlines to each question $q$
    2. A sequence of numbers denoting the point value or type of slide of each slide $i$ within question $q$
      1. E.g.: 20, 15, 15, 10, 10, 10 or SP, P, P, C, C, G for a question with $I$ = 6
      2. The length of this sequence for each question can be used to automatically calculate its $I$
    3. For hybrid sets: the above, plus the written question data file - which is similarly also built-in to MODAQ

Then on the MODAQ interface, for each question the question panel could show the answerline and a clickable sequence of slide numbers from 1 to $n_i$, 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 and other advanced stats for visual tournaments.

Conclusion

MODAQ already includes most of the features necessary for scoring visual packets, since it is is actually simpler than scoring written packets. Adding this would be very beneficial for all who enjoy writing and playing visual tournaments, since it would reduce the number of windows moderators need to open from the above 3 to 2 and also allow collection of buzzpoint data.

(Also, the main reason I bring this up is because I am currently almost finished with writing my own hybrid written / visual film set, and I was thinking this would be awesome to use for that, especially since I believe there has not been such a hybrid set before. I am not familiar with web app or TypeScript programming, but I do have some programming experience so would love to help out in accomplishing this.)

@alopezlago
Copy link
Owner

Thanks for the well-written proposal. It's an interesting idea, but it's a lot of work: YAPP would have to understand a new format, and MODAQ would have to include a new scoring flow based on sequences, and the UI would get more complex than it already is. It would probably be better as a separate app that could focus specifically on visual tournaments (and could then include features like showing images).

The other factor is that I have a lot less time to work on MODAQ now than when I first started, and this feature would be fairly large. If you want to fork MODAQ to build a version for visual tournaments, then I encourage you to do so, and I'd be happy to see the result.

@alopezlago alopezlago added the wontfix This will not be worked on label Aug 27, 2023
@ani-per
Copy link
Author

ani-per commented Aug 29, 2023

Thanks Alejandro. Looks like I underestimated the amount of work required, and I didn't know that you were busier now - sorry about that. I will post on the forums to see if anyone would be interested in assisting in either a fork of MODAQ to support this or developing a separate similar program specifically aimed at visual packet support.

@alopezlago
Copy link
Owner

No need to apologize, it'd be great for something like this to be made.

@ani-per
Copy link
Author

ani-per commented Aug 29, 2023

For reference, I've posted a thread on the forums regarding this effort (basically a copy of this ticket).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants