Finding the Most Fun 15 Seconds of a Karaoke Performance

Karaoke Play of the Game

I designed a system that identifies the most fun 15 seconds of a player or group's performance. Dozens of different moments throughout the song were given different weights based on how entertaining or significant they were, with the highest-scoring segment being replayed at the end of the session.

The system had to respect special edge cases such as when the game is paused, or when one of the singers has a terrible internet connection.

Gameplay under NDA

My "Plan of Approach"

I came up with the following steps to handle this task:

Identify the different motivations the target audience might have for enjoying karaoke.
Reasoning: "Fun" is subjective, so I first needed to understand what different players actually value in a karaoke experience.
Determine which recorded in-game events could realistically represent those motivations.
Reasoning: Once I knew what players found enjoyable, I needed measurable events that could indicate those experiences.
Determine the weights of those events by surveying the target audience.
Reasoning: Not every event contributes equally to the experience, so I used player feedback to determine how much each event should influence the final moment.
Determine how these weights should be combined when calculating the most fun moment.
Reasoning: A single event could not always represent the most enjoyable part of a performance, so the system needed to combine multiple events into one final highlight somehow.
Implement the weighted events and replay the chosen moment at the end of the karaoke session.
Reasoning: This needs to be done to playtest and tune the previous two steps.
Hold playtests and make balancing adjustments.
Reasoning: The initial weights were based on research, but playtesting was necessary to find cases where the system produced unintuitive or uninteresting results.

Research is OP

First Iteration

My first iteration worked pretty different. It measured the following "fun" categories based on earlier desk research and the game's mechanics:

The best part of a song, which was used as a backup if nothing interesting happened.
Audience's favourite, which is when the audience would use the cheer button.
Loudest moment.
Best individual performance.
Worst individual performance.
Best group performance.
Worst group performance.
High performance contrast, which is when two players had a high difference in scores.

The peak of each of these moments were attempted to be calculated throughout the song:

However, this system sucked. As my research had already showed, the target audience likes karaoke for a wide variety of reasons.

This means that if we only looked at the most extreme moment of a song, you wouldn't represent everyones fun properly. The image shows a moment with the "worst individual performance" having the highest weight, but in most cases, a group would want the best individual performance + audience cheered to replay instead.

That's how I ended up with the latest iteration, where multiple identifiers can contribute simultaneously to the highest weighted, most fun 15s of a karaoke session.

You might've noticed the list of identifiable moments to be different, which has the following reasons:

Good and bad performances were combined to simplify the already very complex system, as they both touched on the same type of moments. If a group sings well, "Good performance" will automatically show up with a higher weight considering only the strongest singer's score (which differs for every single line) will end up mattering.
This also removes the possibility for a "High performance contrast", because a group would from now on be considered as a monolith when calculating the score.
The "Best part of a song" would be needlessly complex to calculate. I initially had the idea to calculate the part of a song that was cheered on the most as "the best part of a song", but that would be a lot of data to save when its a category which only ends up mattering when literally nothing was done, but in that case, you might as well not replay anything.

UML

I have also designed and implemented the technical side of the system: