You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
Packet presentation (in full screen mode)
Answerline document
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:
Title and/or packet number (# slides = $T$)
Blanks to prevent accidental exposure to question content while the presentation is not in full screen mode (# slides = $B$)
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
$Q$ (universally 20 but a hybrid format might use 10 visual and 10 written questions)
$I$ (but this can be calculated automatically, as mentioned 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 - 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
Answerlines to each question $q$
A sequence of numbers denoting the point value or type of slide of each slide $i$ within question $q$
E.g.: 20, 15, 15, 10, 10, 10 or SP, P, P, C, C, G for a question with $I$ = 6
The length of this sequence for each question can be used to automatically calculate its $I$
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.)
The text was updated successfully, but these errors were encountered:
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.
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.
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:
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:
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:
20, 15, 15, 10, 10, 10
orSP, P, P, C, C, G
for a question withThen 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.)
The text was updated successfully, but these errors were encountered: