Thanks for asking! Coming from a school where teams tend to neglect documentation in the engineering notebook, it was difficult, even strenuous, to learn how to correctly document our progress without relying on the guidance of older members of my team. I understand that you may have a similar experience with newer teams.
To me, this depends a lot on how a team approaches the competition game, especially how they interpret and analyze the game to develop their driver strategies. Having a strategy that is completely distinct from the driver strategies would be difficult since the strategies involved with any given game only have a limited number of potential strategies, and strategies that are the most effective tend to be some of the most popular strategies. For example, the 2023-2024 VRC Game Over Under primarily involves strategies where teams launch triballs from their match load zones and then push them into their opponent’s goal. Although some strategies could involve blocking the launched triball, finding strategies that are wholly unique would be difficult. That being said, there could be more unique approaches to a given game that are not the most popular (or meta) that your team could explore, but ultimately, the strategy your team chooses should be the most effective one, as decided by your team through prototypes, experimentation, and research.
To distinguish your driver strategy from other teams, I think that one area that you could do that in is the depth of your research/inquiry. Within the Engineering Design Process, teams are expected to research, find possible solutions, and choose the best solution for the competition game. If a team considers a multitude of potential options and strategies in the process of deciding on their final driver strategy, then that could show the effort the team has taken concerning their strategy.
Consideration of driver strategies within the engineering notebook typically falls under the “Define” stage of the Engineering Design Process, which falls at the start of the design cycle. I would tend to first consider the game strategy by conducting research before starting the planning and creation of my robot, so these considerations would tend to be at the front of any major design cycle I undergo. The example notebooks I’ll send below generally follow this, putting game strategy considerations at the start of each design process.
Other than what I’ve mentioned already about putting game strategy into consideration at the start of the design process, what I tend to do is to consider the game strategy as goals/functionalities that my robot is trying to accomplish (the “What” and “Why”) and then, through my documentation of robot design and programming, then consider how these goals/functionalities can be accomplished (the “How”). When documenting the creation of mechanisms that address the functionalities that your driver strategy involves, I would reference the game strategy as appropriate (e.g., if one of my driver strategies involves launching Triballs from the match load zone, I would reference Triball launching when I am designing a catapult to achieve this functionality).
In my first year doing VRC (during VRC Tipping Point), I was in a team with several other members who were entirely new to VEX V5 and the VRC competition. Thus, we spent all of our time figuring out how everything worked and making a functional robot based on the design of the sister teams in the organization, neglecting our design notebook in the process since nobody emphasized its importance. By the time we got to our first tournament, we had nothing in our design notebook, even though we had a few thoughts regarding our robot design and strategies. My team didn’t have another opportunity to improve upon our design notebook due to COVID-19 preventing us from attending any other tournaments, so this was quite a shame to me. Since then, I’ve learned to focus somewhat on my documentation and the robot itself since documentation allows me to show the considerations that I put in throughout the design of my robot.
There are a ton of examples that you can find online of other team’s notebooks. The ones that I tend to reference a lot are 3249U’s notebook from last year and 515R’s notebook from last year, and you could also look at the engineering notebook examples in the REC Library.
I hope this (extremely lengthy) reply answers some of your questions!