Cinder Ridge
Designing Intuitive Crew Control
Role:
Designer/Developer
Team:
3 Engineers, 1 Designer, 1 Concept Artist
Platform:
Game for PC and Console
How do you design squad control that feels like leadership and teamwork, not micromanagement?
Cinder Ridge is a game about forestry in the future, where players lead a small crew to restore and maintain a forest.
To emphasize themes around teamwork and leadership, we wanted the player character to both manage and participate in the work being done - all through an intuitive controller interface.
Through iterative testing, I found players cared more about what gets done than who does it - leading to a contextual, equipment-based filtering system that feels natural and reduces cognitive load.
The final system seamlessly blends direct control with strategic delegation, letting players fluidly shift from hands-on work to team coordination.
Players cared more about what gets done than who does it, and wanted to shift seamlessly from hands-on work to directing coordinated action.
Design Goals
I then identified a handful of design goals that might help distinguish Cinder Ridge from other similar games in the life sim / strategy space:
Leading by Doing
Players should have a sense that they are directing other characters but also participating directly in the work.
Solo Vs Group Effort
Solo work should feel useful and fun, but teamwork should feel even more effective and engaging.
Progression Tied to Relationships
Player progression should be connected to nurturing relationships and becoming a skilled and trusted leader, rather than accruing powers or technology.
I looked at games where the player can control a large number of characters. A few key paradigms emerged:
Indirect Control
Players issue commands which characters complete autonomously.
Coordinated Movement
Characters move and act together in formation.
Beyond Point-and-Click
Targeting consoles meant we couldn't rely on point-and-click conventions from CRPGs and RTS games. We needed elegant controller-based systems for selection and coordination.
Prototyping
How do you design squad control that feels like leadership and teamwork, not micromanagement?
Single-file movement worked because it leveraged familiar real-world behavior
To capture the embodied feeling of hiking and climbing in the mountains, we wanted the game to feature rugged terrain that could be traversed with some light platforming.
Single-file movement worked because it leveraged familiar real-world behavior—people naturally form lines when navigating challenging terrain together.
Players cared more about what gets done than who does it.
This interface modeled English sentences: "Ask [person] to [perform action] at [location]."
Although this interface was intuitive and had an immediate appeal, testing showed that character selection added meaningless decision-making. Players cared more about what gets done than who does it.
Coordinated movement calls for direct player control
In this exploration of coordinated movement, players could group crew members together, and then instruct them to line up to “sweep” an area, moving in unison to scare wildlife out of the brush.
The “line-up” mode felt great, but it was awkward when players wanted to participate directly in these behaviors with their own character.
Seamless switching between precise selection and quick mass editing
For complex tasks like building infrastructure, I explored a system where crew members attempt to copy the player’s actions on nearby targets.
This was a great compromise that allowed the player character to participate directly in the work while making it useful to “scale up” with more crew.
This prototype revealed a lot of complexity around action and target selection—players needed to switch between precise selection and quick mass editing.
Between these prototypes and my design goals, I identified four key design challenges:
Action Selection
How players choose what work to do.
Selection & Placement
How players specify where work happens.
Crew Coordination
How players shift between directing and participating in work.
Automation & Scheduling
How players progress by scaling up their work.
Action Selection
How can players decide who does what?
Equipment provided an intuitive metaphor for filtering actions and targets
Equipment Defines Who Can Do What
Players can configure character equipment from a menu interface.
Choosing Tools, Not Characters
Players quickly select from among tools held by their crew.
Contextual Actions
Each tool has primary and secondary actions that work on specific objects in the environment, limiting user error.
Players can manage their equipment and other items with a compact menu interface
Inventory Related Friction
The tool-based approach worked, but initial implementation created new friction points around inventory management.
Limited Inventory Space
A severely limited inventory cluttered with tools made it cumbersome to perform other key actions like harvesting seeds and cones.
Disruptive Menu Access
Players frequently had to enter menu interfaces to swap items in individual characters' hands, which interrupted the flow of gameplay.
Tool selection produced new friction points around inventory and equipment management.
Next Steps
Replace linear cycling with instant radial selection
Holding R2 / RT should reveal a radial menu where tools can quickly be selected with a flick of the right stick.
This interface removes the friction caused by linearly “cycling” through tools, allowing players to make their selection instantly, with an intitive compound input.
Simplify crew coordination by unifying tool states across all crew members
The entire crew should hold the same tool type; everyone in the party is either holding the active tool, or holding nothing and standing by.
Separate Collectibles & Consumables from Equipment
Tools should be their own category, separate from consumables, collectibles, and other items.
Target Selection & Placement
How can players easily tell their crew where and what to work on?
First Pass: Direct Character Control, Indirect Placement
In my initial implementation, the player controlled their character's position directly, with the character always facing forward in the direction it moved. Selection and placement were handled through a spherical trigger volume positioned in front of the character.
Testing showed that direct control of the character’s position wasn’t relevant to the strategic decisions players wanted to make—what really mattered was precise selection and placement.
The character-focused interface I’d developed was actually an indirect and cumbersome way to specify where an action should be performed.
How can players make selections and placements with greater precision?
Switch to cursor based movement and targeting
I switched to a system where the player directly controls the position of a cursor, and their character follows closely behind.
This allowed much more precise placement and selection by removing the indirection of character positioning, while preserving the sense of embodied movement through the world.
Enable complex planning through cursor-based drawing
Using the cursor system, players can draw construction plans and work areas directly where they're needed.
This allows players to communicate complex intentions that crew members understand as coordinated tasks, moving beyond simple point-and-click targeting.
Enable quick selection of similar targets with intelligent, contextual multi-selection
The system detects discrete objects like trees using a spherical volume, and connected elements like trail networks using breadth-first search.
Optionally, targets can implement their own selection filters, allowing players to select only trees of the same species.
Add feedback and rotation control when placing large structures
Orientation is mapped to camera control; the item faces the camera and rotates as players orbit around, enabling direct and intuitive rotational control.
Allow players to plan with precision with a modifier button that enables snapping on the fly
With snapping enabled, the player's first placement automatically aligns with world-space cardinal directions. Subsequent additions snap relative to the existing structure.
This provides the precision players need for organized construction while keeping the drawing process intuitive and flexible.
Contextual Crew Coordination
How can players seamlessly switch between direct and indirect control of the crew?
Formation Menu
Players needed seamless transitions between two different mindsets—'I am working alongside my crew' versus 'I am directing my crew's work'—without jarring interface changes.
To reduce the number of decisions players had to make, I implemented a menu that organized crew coordination behavior and selection modes into three 'formations.'
Arbitrary Categories vs. Player Intent
Players had to break out of the game world to access formation options that didn't align with how they conceptualized their crew's work.
The formation categories felt arbitrary rather than meaningful to players' actual decision-making process. Players were more concerned with whether they needed precision control or wanted to coordinate their crew on larger tasks.
I reworked existing features into a streamlined, context-driven interface with a quick toggle between Solo and Together modes
Solo allows players to queue up precise actions by assigning the next ready crew member to a specific selection
Together uses smart multi-selection to assign nearby targets to all available crew
Coordinated movement modes activate only when using relevant tools together
These were major improvements, but players still had difficulty understanding the state of the crew
Next Steps:
Clearly communicate the state of the crew with a dynamic camera and streamlined, character focused UI
Closeup
The camera pulls in tight to frame the player character and the first crew member in line.
Optionally, letterboxing could help create a clear visual distinction between the two modes, as well as a more cinematic composition.
Wide Shot
The camera pulls back and frames all crew members holding the active tool.
Centering the Crew
In both cases, the camera is centered at the midpoint of all relevant crew members, rather than just the player character. This would:
Create more dynamic / cinematic visual compositions
Emphsize the feeling of working together.
Make crew member’s facial expressions and state more readable.
Scheduling and Automation
How can players scale up their operations without losing the collaborative feeling of hands-on work?
An early idea for player progression was that players could gradually recruit additional crew members with expertise in different areas.
However, testing revealed diminishing returns beyond about 8 crew members—there are only so many objects and work areas within range of the player, so controlling additional characters doesn’t add as much benefit.
The challenge was to create a progression path which:
Supported themes about leadership and teamwork
Improved the player's operational capacity in meaningful ways
Maintained the feeling of collaborative work and embodied participation
Burnout provides incentives to give crew members rest days
Characters get burnt out if they go too long without a rest day. A weekly calendar interface allows players to manage their crew’s schedules.
Recruiting additional crew then allows players to spread the work out among more people, balancing work related goals with the wellbeing of the crew.
Assignments reduce tedium and shift focus to big-picture strategy
Assignments allow players to delegate complex tasks to groups of characters, freeing them up to consider big-picture strategy.
This provided detailed control while eliminating repetitive micromanagement, but produced tension between scaling up and staying connected to the work.
Schedule assignments with a map interface
A map-based interface expanded on the existing project planning tools, letting players schedule work at specific sites as needed.
These systems did provide compelling ways to manage the crew at a higher level, but diminished the importance and immersive feeling of direct collaboration.
Next Steps:
Encourage direct participation through meaningful collaboration rewards
Participation Rewards
The player character provides buffs to NPCs and builds stronger relationships through direct collaboration, creating meaningful reasons to sometimes join scheduled work.
This approach lets players focus on high-level decisionmaking while making direct participation a meaningful choice rather than a hard requirement.
Building a Trail Section
How does the complete system feel in a real workflow?
Blazing a Trail
The player needs to clear a path for a new trail through dense forest. Shrubs, trees and fallen logs crowd the intended path - exactly the kind of multi-step task that showcases both precision control and collaborative teamwork.
Tree Clearing: Solo to Coordinated Work
Tree Clearing: Solo to Coordinated Work
The player starts alone but quickly gathers her crew when the job proves too big. In solo mode, each press of A sends the next available crew member to fell a selected tree, letting her maintain precision while scaling up the work.
Processing Fallen Log: Contextual Axe Actions
The same axe tool automatically removes branches when targeting the log, then cuts it into smaller sections. The system recognizes the context and provides the right action.
Moving Log Sections: Coordinated Movement
Log pieces are too heavy for one person. Multiple crew members automatically coordinate to lift and carry each section together.
The player controls the entire crew’s movements directly, and places the log carefully off to the side of the work area.
Planning and Scheduling
The player sketches the trail route directly in the world, then schedules tomorrow's brush clearing work before heading home.
Joining the Work
Joining the Work
The next morning, the player chooses to work alongside her crew as they build the planned trail.
Result
After two in-game days, a major trail section is complete. The player seamlessly shifted between hands-on work and strategic coordination as the situation demanded.
Conclusion
Impacts
The final system transforms crew management from a series of explicit decisions into contextual, fluid interactions.
Where the original prototype required players to think "Ask [Character] to perform [Action] at [Target]" - creating decision fatigue around character selection - the equipment-based system lets players think more naturally: "I need to clear these trees" or "This log needs to be moved."
Cognitive load is reduced significantly. Players spend less mental energy on crew assignment logistics, and instead focus on the work itself.
The instant toggle between solo and coordinated modes eliminates the friction of the old formations menu, letting players adapt to changing situations without breaking their workflow.
Most importantly, the system delivers on the core design goal of leadership that feels collaborative rather than managerial. Players naturally shift between working alongside their crew and providing strategic direction, supporting the game's themes around teamwork and leadership through the mechanics themselves.
Design Process Insights
Working as both a designer and developer on this project taught me valuable lessons about balancing design exploration with implementation.
I often found myself jumping straight into implementation details rather than fully exploring the design space. While iterative prototyping with players was crucial for discovering key insights, I could have solved some friction points earlier through cheaper, analog methods.
In hindsight, stepping away from the computer for more whiteboard sessions might have helped me reason through interaction flows before getting caught up in technical constraints. The streamlined equipment selection system, for example, emerged from user testing rather than upfront design thinking - but the core insight about reducing decision fatigue could potentially have been identified through paper prototyping or scenario mapping.
Areas for Further Refinement
While the core crew management system is basically sound, the next phase should focus on individual tool interactions.
I intentionally avoided polishing micro-interactions early on, recognizing these details needed to integrate with the larger crew management framework. Getting the foundational systems right took precedence over perfecting the feel of individual tools.
For instance, the hoe tool levels terrain by a small, constant amount with each strike. For very uneven terrain, this method takes a very long time to finish, creating tedious repetition. A better approach might be to constrain the number of strikes to a fixed range:
flat areas complete in 3 strikes minimum
uneven areas complete in 6 strikes maximum
The key is to make tool use feel consequential, while preserving the increased time cost of working on more difficult terrain.