|
Re: Strategy Sub-Team
We’ve only been running the strategy team for the past two years, but it has been immensely helpful so far in letting us know where our decisions are coming from and what our biggest priorities are.
Our strategy team is a small group who practice modeling games in the preseason (I'm happy to say that it’s been getting more popular; as of this offseason we already have 4 underclassmen who have been meeting every week since champs to practice). While the strategy team is at work the first few days of build season, the rest of the team is either reading the rules and brainstorming their own strategies to pitch to the strategy team, handling basic administrative tasks (getting shipping orders in, making supply runs, etc.), or preparing to build field parts.
On our team we've been doing things a little differently; we strictly separate mechanism design and “strategy design”. The strategy team brainstorms, analyzes, and refines sets of game objectives the whole team will later debate. The group does not discuss mechanisms much beyond basic requirements because we want to focus on identifying the best sets of objectives before becoming invested in particular mechanisms that may not meet the best gameplay goals. After we narrow down to the top 3 or so options using mathematic models, the factors that make one strategy a better option than the other cannot be easily weighed (presence of certain partners, mechanism feasibility, etc.); such factors require the full experience of the entire team to effectively judge. After debating the top options as a full team, we hold a blind vote to determine our favored strategy. We then get to focus our prototype building around meeting the top strategy's specific gameplay requirements.
It can also helpful to not just set clear goals, but to also set your design/gampeplay objective priorities in various tiers. When you need to make a tradeoff, these priorities and their tiers should make your defining factors obvious. This is very helpful because when things do go wrong, it’s much easier to pinpoint what factors you were weighing and where your design considerations can be improved for the future (ex. for us this year we made several poor tradeoffs primarily because we kept overestimating weight; weight-based decisions will thus be more carefully made in the future).
|