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.

Focus on seamless shifting from hands-on work to directing coordinated action.

Background Research


Background research helped me identify a handful of design goals that would distinguish Cinder Ridge from similar games.

  • 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 then identified a handful of design goals that might help distinguish Cinder Ridge from other similar gamesin the life sim / strategy space:

I looked at games where the player can control a large number of characters. Two key paradigms emerged:

  • Indirect Control

    Players issue commands which characters complete autonomously.

  • Coordinated Movement

    Characters move and act together in formation.

Prototyping

How to design a system where players direct a small crew, while also participating directly in the work?


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.

Delegation by Character + Action + Destination

This interface modeled English sentences: "Ask [person] to [perform action] at [location]."

Although this interface was intuitive, testing showed that character selection added meaningless decision-making. Players cared more about what gets done than who does it.

Players wanted to be able to shift between two different mindsets: “I am working with my crew” and “I am directing my crew”

Coordinated Movement

I wanted to explore scenarios where coordinating the movement of multiple characters would be important.

Here, players could create groups of crew members who could then 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.

Players needed to switch seamlessly between precise selection
and quick mass editing

Multi-selection and Coordinated Tasks

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.

However, 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 choose who does what?

Equipment provided an intuitive metaphor 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.

How to eliminate tool selection friction and reduce cognitive overhead?

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.

Selection & Placement


How can players easily tell their crew where and what to work on?

Testing revealed that direct character control was actually
an indirect and cumbersome way to accomplish many player goals.

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 revealed 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?

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.

Switch to cursor based movement and targeting

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.

Reduce tedious multi-selection with intelligent contextual targeting

The system intelligently selects related targets based on the player's initial selection, reducing the tedium of selecting many similar objects.

It uses sphere-casting for nearby discrete objects like trees, and breadth-first search for connected elements like trail networks.

Add rotational control and placement preview for large structures

To place larger structures with precision, players needed rotational control, and a preview of their placement.

A contextual cursor mode increases the distance from the player and displays a preview of the item to be placed.

Orientation is mapped to camera control; the item faces the camera and rotates as players orbit around, enabling direct and intuitive rotational control.

Players wanted to create organized structures with precise angles, so I added snapping functionality with a simple modifier button.

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.

Use snapping to provide consistent, organized construction

Contextual Crew Coordination


How can players fluidly shift between directing and participating in work?

I designed a menu that organized coordination behavior into four “Formations”, but testing revealed players actually wanted to control their level of precision

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.

How can players switch instantly between precision control and mass coordination without breaking workflow?

I reworked existing features into streamlined, context-driven interface with a 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 significant improvements, but testing showed that players had difficulty tracking the complex state of the crew.

Next Steps:

Clearly communicate the state of the crew with a dynamic camera and streamlined, character focused UI.

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.

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.

Scheduling and Automation


How can players scale up their operations without losing the collaborative feeling of hands-on work?

Meaningful Progression

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.

Leadership-Focused Progression

The challenge was to create a progression path which:

  • reflected the themes about leadership and teamwork

  • improved the player's operational capacity

  • maintained the feeling of collaborative work

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.

Assignments enable contextual automated behaviors

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.

How to maintain the significance of direct participation in work as the player progresses toward a larger crew and complex delegation?

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.

Workflow

Building a Trail Section


How does the complete system feel in a real workflow?

Blazing a Trail

Sarah 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

Sarah 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.

Sarah controls the entire crew’s movements directly, and places the log carefully off to the side of the work area.

Planning and Scheduling

Sarah 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, Sarah chooses to work alongside her crew as they build the planned trail.

Result

After two days, a major trail section is complete. Sarah 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."

The cognitive load reduction is significant. Players no longer spend mental energy on crew assignment logistics, instead focusing 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 like "players care more about what gets done than who does it," 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 equipment-based filtering 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.