Hello!
My team is working on finalizing our plans for the 2025 kickoff, and we are curious what other teams do for their kickoff events! How do you handle things like mechanism prototyping, game analysis, and determining what kind of mechanisms need to be explored in the prototyping phase.
I’d love to hear all about how your team handles this, even to the level of hourly schedules (if you’d like to share), thanks!
We do a mock kickoff in December to practice the pattern of kickoff day, but some of the main flow is as follows:
Watch the kickoff video in entirety, plus the field intros and actual reveal twice. Discuss observations and points structure
Discuss in smaller groups potential gameplay strategies. Define/estimate how many points an average team will get, how much an elite team will achieve in a match, and the max theoretical (if applicable). Present strategy concepts to rest of team.
Read every section of the rules in full. We split into groups again to take ownership of a rules section then present our findings about unique rules to the team after a thorough review.
Build Figure of Merit Charts to define which strategies maximize gameplay potential — basically we are searching for our ideal gameplay strategy
Write out a materials list for what field elements we plan to build, so I can go buy everything the next day
Define a priority list of the types of elements we plan to prototype (no specific mechanisms, just a priority of gameplay elements we want to investigate first
Build some basic geometries in CAD to understand our robot constraints relative to field element locations and sizes.
Later in the day, download and install all the software released on kickoff day. Also, purchase lists for things we know we need to buy right now before components sell out — maybe game pieces or critical components.
If you notice, we never, ever talk about actual mechanisms to prototype on kickoff day. I specifically discourage this until we have our strategy well thought out. This is “homework” for the second meeting, where the students come in with prototype ideas based on the chosen strategy and priorities.
Gather in the morning with the whole team (some alumni join too sometimes) and watch the entire kickoff stream. As soon as the game is revealed and the manual is released the entire team spends thirty minutes to an hour reading the game manual so when we start proposing prototypes and having other discussions theoretically nobody suggests anything illegal. Following that we set up a “mock field” which is super rough only using cones laid out on the field while we wait for game pieces to arrive (luckily our kickoff center is just down the road) Following that we break for lunch where technically no official discussions are happening but everybody is talking about ideas, prototypes and strategies. Following that we break into several small groups, each one led by a senior or other leadership member and discuss what the “winning strategy” will be. This entails what’s important for our robot to do, what’s going to end up being a waste of time (color wheel in 2020 is the first thing that comes to mind), how we maximize our cycles and other general stuff. Mechanisms or prototype ideas are not discussed in this first round of team discussions. After an hour or so each of the small groups presents a poster they made to the entire team, where we reach a general consensus about what we envision our robot doing, but no possibility is eliminated just yet. Then we break into a second round of small group discussion, this time discussing ideas for mechanisms and prototypes for all kinds of game actions (climbing, scoring anywhere, intake, etc.) and once again after that those groups will present to the whole group. After that design has a pretty good idea of what the robot is supposed to do so then everyone basically leaves except for design and high leadership, and that’s when decisions begin to get made. Above all in that design meeting at the end of the day we outline what we want to get prototyped the next day. That’s how we were able to get working speaker, intake, and amp prototypes by the end of Sunday after kickoff. Sorry if this is confusing I didn’t take any time to proofread this. I’m supposed to be studying for finals but chief delphi got the best of me 
This is from my experience as the former president for my old team. Right after the game reveal, the first thing we did was go through the game manual together as a full team. The goal here was to make sure everyone understood the rules, the scoring, and what the game was really asking for. Once we felt like we had a good handle on that, we started talking about strategy—not what the robot would look like, but what it needed to do. We focused on things like how matches would play out, what the winning alliances might look like, and which tasks were the most valuable for scoring points. This helped us narrow down the key things our robot needed to do, like scoring certain game pieces or climbing in the endgame.
After that, I split the team into smaller groups, each focused on a specific mechanism for the robot—like intake, drivetrain, shooter, or elevator. Every group had a lead, usually someone with experience, who could guide the discussion and keep things moving. I’d float around between the groups, helping them work through their ideas and making sure everything fit together as a whole. For example, if the intake team came up with a design that took up a lot of space, I’d check in with the elevator team to make sure it wouldn’t cause problems for them. My job was basically to make sure the different groups weren’t designing things in silos and that everything would work together in the end.
Each group started by brainstorming ideas and sketching them out. Before they could start prototyping, I made sure they had a clear plan and some basic calculations to back up their ideas. For example, the drivetrain team would estimate speeds and turning capabilities, or the shooter team might figure out how much energy they’d need to launch game pieces a certain distance. We didn’t just jump straight into building; we wanted to make sure our ideas actually made sense before wasting time.
When it came to prototyping, the focus was on speed and simplicity. The groups would build quick mockups to test specific things, like whether an intake could grab game pieces from different angles or whether a launcher could hit a target consistently. These prototypes were super basic—usually made from wood, PVC, or scrap parts—but they gave us the info we needed. We didn’t spend weeks perfecting prototypes; the idea was to test quickly, learn what worked (and what didn’t), and move on.
One thing I wish we’d done differently was use tools like a Pugh matrix to help us compare ideas. Back then, we mostly decided what to build based on discussions and experience, but I think a matrix would’ve helped us make more objective decisions. For example, each group could list out their design options, rate them on things like reliability, ease of building, and scoring potential, and then see which option scored the highest overall. It’s something I’d definitely add if I could go back.
Another thing I’d change is how we collected data during prototyping. At the time, we’d just make observations and notes, but we didn’t formalize it much. If I could redo it, I’d push every group to track real numbers, like how many cycles a mechanism could do in two minutes or how often it failed. Graphing this data would’ve helped us see patterns and make better decisions. For example, if a shooter design was only accurate 50% of the time, that’d be a red flag to go back and improve it—or maybe scrap it entirely.
We also built basic versions of field elements as soon as possible. This let us test our prototypes in real game conditions. For example, the intake team could see how their design worked with obstacles or tight spaces, or the drivetrain team could test turning on field-like surfaces. Running mock cycles with these field elements helped us catch problems early and make adjustments before we were too deep into building.
One thing I always pushed for was reliability. I constantly asked, “Will this mechanism work every single match?” If a design was flashy but prone to breaking or hard to fix, it didn’t make the cut. We focused on making sure the robot could perform its core tasks consistently, because a reliable robot almost always outperforms a robot that’s amazing when it works but unreliable half the time. Once we felt solid about the core mechanisms, then we’d start thinking about extras or ways to push the robot’s performance further.
For a kickoff schedule, a good general format might look like this: start the day by watching the game reveal and immediately diving into the game manual to clarify rules, scoring, and field setup. Spend the late morning analyzing strategies and deciding what roles a competitive robot might play. After a lunch break, shift into brainstorming and splitting into mechanism-based groups to start sketching ideas and running initial calculations. The rest of the day should focus on planning what to prototype and setting priorities for the next session. I wish I could tell you how many hours to spend but I think the only real answer is whatever it takes 
.
By the end of kickoff weekend, every group had a direction and a plan for what to prototype. Looking back, I think we did a solid job, but if I could do it again, I’d add more structure with tools like the Pugh matrix and better data tracking during testing. Those things would’ve made our decisions more objective and taught newer members how to evaluate designs like engineers. Kickoff really sets the tone for the season, and being focused, efficient, and deliberate in those early days makes a huge difference down the line.
Lots of good stuff written on this already.
Now, with a few differences in the rules, things are about to be a little bit different than prior years.
Lots of good stuff in this thread already… so I’ll add something fun. 2491 plans on having the team show up an hour early and make pancakes and get excited.
From what I have seen most teams do fairly similar activities. What I am curious about, how late do other teams operate on kickoff day. Our team usually arrive early before the kickoff stream at 12pm EST. We eat lunch while watching the stream and then work until dinner time (5pm EST) and dismiss everyone for the night. Do other teams tend to work later into the evening on kickoff day or is this a common schedule?
In our 2024 build season OA thread, we shared how we ran our 2024 kickoff. We were pretty pleased with the result and plan to keep the general plan the same this year. The biggest shift last year was:
to be more inclusive in the different ways people solve problems and the different things that they have an interest in. This schedule allowed us to give more flexibility for our members to either focus on brainstorming designs or the overall strategy of the game.
As a larger team, we have enough people to focus on a wide variety of things all at the same time.
We spend our entire kickoff weekend doing very high level analysis of the game. We each read the manual, get really familiar with it, and take time to discuss what we think our best course of action is for the season. Usually by the end of Sunday, we only then start prototyping and designing, but we’ll have decisions made for what we want our bot to accomplish, specialize in, etc.
The teams I have worked with do all the usual stuff already discussed here but one thing my current team does, that is really fun and gives at least a little hint towards what gameplay might look like, is to play human matches. While most of the team reads the rules a few adult volunteers (usually parents) go tape out a basic field in our practice space and find whatever totes or shelves they can stack up to make the scoring locations and find something that can approximate game pieces. Once the team has done a once-over on the rules we take everyone out to “play” the game. It is a fun way to get everyone up and moving for a bit and can give some limited insight about what a match might look like. Particularly useful aspects are things like frequent travel paths and bottle necks on the field. End game actions are usually not particularly accurate in this simulation.
Pancake breakfast.
No that would NOT be a very helpful reply, though it is a good fulfilling meal to share and bond with parents and students and any alums who come by so we like the exercise of it before the season. So we usually watch the game thing, watch it again sometimes, read the manual for dimensions of game elements/game pieces, then get to ideation and krayoncad/scope. KrayonCAD has been what we’ve historically been using to help prototyping designs quickly without having to cad the whole thing. Scope we look for what we can realistically as a smaller team + within constraints of build season. For example, we prioritized speaker and amp over trap, although trap is nice for extra points in endgame, it was more important to do less stuff better than more stuff worse to us. We even elected to go with just speaker after our design came out to just a consistent speaker shot. (Amp wasn’t good until beach blitz offseason).
Friday evening we hop a chartered jet to New Hampshire, spend the night in suites at Manchester’s finest luxury hotel. Our morning starts with a catered champagne brunch before quick heli dash over to Dean’s place for a personal kickoff.
Then I wake up and realize we’re in a classroom with Dunkin’ Donuts like everyone else.
We go to stennis space center and watch the kickoff with a bunch of other teams, It is a lot of fun on the 45min bus ride home. for the last kickoff we just kept passing the note around and squishing it and going " boing boing boing" and then our head mentor screaming “don’t break the dang note!!!”
I’ve tried this with my students before, over 3 separate seasons and with 2 different teams. The students told me it was corny and didn’t like it. Many students refused to take it seriously. Student leads vowed never to do this again. I’m curious why this works well for some teams and not others?
What we have done instead every year since then, is build the field out of Legos (to the best representation we could) and have students emulate robots or drivers, and move their Lego bots around the tabletop field with realistic timing. Others would watch as the gameplay unfolded to make observations.
I would assign certain attributes to teams — unable to do ground pickup, fast but inaccurate shooter, defense only, etc. and that attribute would be applied on the game board.
We learn a few things from this exercise:
It helps if they channel method acting. Make sure to quietly mutter “beep” to yourself throughout the morning to get in the zone.
On my old team the “human robots” were typically people in rolling chairs either being pushed by someone else or propelling themselves.
This worked pretty well and did give everyone a pretty good idea of what would happen.
On 179 we did the human game to simulate 2014 and 2015 but since we couldn’t really simulate 2016 since we could not safely send people over defenses the team decided the strategy team should come up with a way of trying to figure out what would be scores. We slightly overestimated teams by 0.75 game pieces and 0.25 crossings when compared to what each quartile was capable of at Palmetto that year.
After we did that it became tough to convince everyone to go back to rolling around in chairs when we could just visualize everything and use previous stats to get our numbers. Even when we debated bringing it back in 2022 our surviving 2019 freshman said they were against it.
So I think it comes down to if you feel you get more knowledge than cringe from the exercise. If yes than it happens, if no than it doesn’t.
We’re big fans of Why-How-What to help us know what we’re doing. Before winter break, we have a teamwide discussion of Why we’re building a robot, framed within what we want our season goals to be. Once we’ve defined our goals, we discuss How we can reach those goals - on what aspect(s) of the game we need to focus. Only then can we define What we’re going to build - goals drive strategy which drives design.
We’re also really big fans of the Shaker kickoff worksheet which helps us get quickly get our heads wrapped around the game mechanics, critical rules, and potential gameplay strategies. We complete a version of the Shaker Sheet in small groups, come together to discuss, and use the results to create a first-draft priority list.
After the show is over on Saturday we play with the game piece a little and that’s it.
Everybody is charged with reading the rules that evening.
On Sunday we get back together and brainstorm how we are going to play the game. We don’t discus the robot at all.
What is this as a percentage of the average for each quartile? In qualifications the average alliance at Palmetto scored 1.01 low goals and 1.15 high goals. An overestimation of 0.75 game pieces per team on average, or 2.25 game pieces per alliance on average, seems large. In fact, more than double. Am I misunderstanding something?
