Penalty & Scoring System [AARD-1895]

[AlexD717]

Objectives

Track penalties, scoring contributions and ranking points. Implement per-robot penalty and score trackers. This system can be expanded upon later including some more advanced point tracking system so just do what seems reasonable for this particular task.

Description

• When spawning robots you can now select what alliance they are on (default red)

This can also be done through the configure assets tab

• During match mode, the game keeps track of how much each individual robot contributed to the score and displays that information at the end of the match

The score for Luna is -15. This can happen either if the robot scores in the opposing alliances goal, or through penalties.

• The simulator now also keeps track of penalties which are displayed with a toast, and also increase the opposing alliances score

• You can now configure a protected area on the field, that the opposing alliance can't enter without receiving a penalty
  • Ex. If a red robot enters a blue alliance protected area, the red robot receives a penalty and the blue alliance gets some points

• You can also configure the panel so that it requires robot contact from the opposing alliance to count as penalty points
  • Ex. In Reefscape (2025) there were areas that you could enter, but it was risky, since it was a protected area and if you touched an opposing robot that would be a penalty.

Testing Done

• Robot alliance can be configured
• Match Mode keeps track of how many points each robot contributed (can be negative)
• Can configure protected areas on the field
• Entering a opposing alliance protected area that doesn't require robot contact gives the opposing alliance points
• Entering a opposing alliance protected area that requires robot contact gives the opposing alliance points, only on collision with one of their robots

JIRA Issue

[ryanzhangofficial]

Looks and feels great! Seems to be a great start for the full system.

[Dhruv-0-Arora]

Conflicts. Is this blocked by the refactor?

[AlexD717]

Conflicts. Is this blocked by the refactor?

The conflicts were primarily due to the Preference Saving Refactor (so that changes are applied instantly). I don't believe that this is blocked by the UI refactor if that is what you are referring to.

[AlexD717]

@Dhruv-0-Arora can you rereview? This has been sitting for over a week with no changes

[rutmanz]

From a rules perspective, there are a few more types than contact-required and contact not required. Some of them are only active in specific phases (auto, endgame), some require that the opponent (robot who is protected and will gain points from the foul) be in the zone (2025 G427, 2024 G422), some require that either robot be in the zone (2024 G423), and some require that the offending robot be in the opponent's zone (2024 G405).

I don't know if/how we want to support all of these cases and if it is in the scope of this PR to do but the current configuration is a little too rigid to support those

[AlexD717]

From a rules perspective, there are a few more types than contact-required and contact not required. Some of them are only active in specific phases (auto, endgame), some require that the opponent (robot who is protected and will gain points from the foul) be in the zone (2025 G427, 2024 G422), some require that either robot be in the zone (2024 G423), and some require that the offending robot be in the opponent's zone (2024 G405).

I don't know if/how we want to support all of these cases and if it is in the scope of this PR to do but the current configuration is a little too rigid to support those

There are a lot of specific rules in FRC and its very challenging to account for all of them. The way I understood this PR was just to make the underling penalty system while also adding a couple penalties to demonstrate functionality. Personally I think that this can be easily expanded. For example, in the configuration panel you could add a multiple select dropdown where you select during what game phase the zone is active. Then in the zone you just check if the current game phase is one of the selected phases and only then count the input. I don't think there is any other way to account for all of these FRC edge case rules without a lot of if statements.

I would add this functionality, but this PR is already over 1,000 lines of code changed and our current dropdown doesn't allow multi-select functionality.

[rutmanz]

in that case I think this lgtm

[BrandonPacewic]

This looks really solid overall - I don’t foresee any issues with the approach taken here. There are a few small tweaks we might consider:

• Improving encapsulation by moving some of the physics logic out of MirabufSceneObject
• Representing endgame as a dedicated enum state for better clarity in match flow

Great work. I’m looking forward to seeing the next steps for this feature. 🎼

Only requested change was a merge conflict concern. Dismissing this review.

[BrandonPacewic]

This feature will continue to be built upon by AARD-1893.