Nick Crockett


Cinder Ridge


Website 

Overview   Demos   Research

Demos + Artifacts


Character Movement


I wanted a simple system for character movement which captured the feeling of navigating real natural environments like the South Yuba River, hopping on granite boulders.  The game supports swimming and some light platforming. The player can press Y to jump, or can perform a smaller hop by running off a ledge.


A basic stamina system augments these actions. Steep slopes, dense brush, and heavy items slow the player and cause characters to use more stamina to navigate. Stamina consumption is represented with a sweat drop particle effect, as well as bark text from NPCs.


The player can make it easier to get around by building trails and clearing brush. In this clip you can see the player character move between:
  • dense brush on a steep slope
  • a steep slope with no brush
  • a trail cut into the hillside

Placement & Cursor Driven Movement
As we added more features to the game, we realized that in general, players needed to control item placement directly. We settled on having the player actually control a cursor, and having their character follow closely behind. This allowed us to more easily add additional movement and placement modes, like snapping for construction planning, and a preview visualization for installing larger structures like tents.




Carrying Large Tools
Characters can carry larger tools which roll or are dragged on the ground, such as mowers, wagons, and wheelbarrows. Both “pushable” and “pullable” types are supported.

This involved a lot of work with IK system to control hand placement in a variety of situations, and with our character controller to allow NPCs and players to essentially drive vehicles.

There were a few reasons we explored these kinds of tools:
  1. Wagons and similar items make it possible for a single character to carry multiple items (i.e. by stacking items on a wagon)
  2. These tools would incentivize players to carefully plan trails and roads, since these tools are not allowed to travel on steep slopes or rough terrain.
  3. To offer versions of the same tool or action with different drawbacks to complicate player decision making (a hand tool might be easy to carry, but have a smaller battery, for instance)

Early Prototypes
One of the key goals for the project is to examine the relationship between human beings and the landscape. Inspired by games like Death Stranding and Breath of the Wild, as well as the Independence Trail outside Nevada City, CA, I wanted to consider carefully how the human characters physically traverse the landscape.

This clip shows an early test of breath of the wild style climbing mechanics - the player can run and climb on basically anything, and is limited by a stamina bar.

This clip is a later prototype of climbing mechanics. This character has no premade animations other than a neutral crouch pose, all the animation is controlled by the player via IK. The player controls the hands and feet of the character contextually, using only a thumbstick and one button. Which limb reaches out for a hand/foothold depends on which direction the player tilts the joystick - upper left and right quadrants correspond to the upper left and right arms, and the lower left and right correspond to the legs. Movement is constrained by where the character can physically reach with their other 3 limbs planted. I thought later I could possibly add stamina depletion based on the player’s footing.

I liked how this felt a lot, but it didn’t fit with the ‘squad-based’ mechanics of the game. It could become a fun minigame or a future project of it’s own.


NPC Characters



Directing NPCs
The player works together with NPCs to accomplish a variety of tasks. Normally, when the player presses the action button, the first available NPC will attempt to use the selected tool at the position indicated by the player.


Using Tools Together
Depending on what tool is equipped, the player can switch to other group action modes by pressing R2. For instance, when holding the brush cutter, the player can tap R2 direct their crew to form a line. While standing in a line, all characters will use their tools together, together, making it easier to clear large areas of brush.



Multi-Selection
For tools that target gameobjects, the player can hold R2 to select similar objects nearby. NPCs in your party with the correct tool will automatically target those objects.

These behaviors might seem complex, but R2 is the single control for initiating both ‘group action’ modes, and it’s functionality changes contextually based on the selected tool.


Carrying Large Items
The player can work with other NPCs to carry larger items. This feature was a logical (and technical) extension of the wagons shown above. The more characters are holding a large item, the faster they will travel.

Prototypes


This clip shows an early attempt at NPC pathfinding, using a more simplified  system for player movement (without involved climbing).  

This clip shows my first pass at directing NPC characters to act independently of the player. The player is able to direct NPCS to move to different locations with a few different verbs available: walk, hurry, and sneak.

This was implemented with a verb-adverb system. Actions like “Go Here” could take an argument for different adverbs like “quietly” or “quickly”, which the player can toggle through with a modifier key. This still basically exists in the code but I’m not sure how useful it is in most situations other than sneaking up on game.



One of the clearest first gameplay tasks I wanted to prototype was rounding up small game for trapping would, but also potentially for other purposes - tagging, removal of invasive species, creating animal rehab centers, etc.

Jackrabbits (and eventually other small game) run and hide under plants. Dense foliage makes it difficult for the player to track where the rabbits are, although with careful attention you can spot them.


I’m excited about how wildlife interacts with the position of plants, with structures the player can build, and with the NPC characters the player works with. This video shows an early prototype where the player directs NPCs to walk in formation to scare rabbits out of the bushes.



Construction

Cinder Ridge features a robust, modular construction system.  To enhance the natural feeling of the environment, we wanted to avoid obvious grid-based gameplay and aesthetics as much as possible, so construction is placed freeform.

Building a Fence

The player starts by drawing a blueprint plan for the structure they want to build. In this case, they are laying out a fence made of posts and panels.

This creates objects for NPCs to target.

Once the player draws out a plan, they can work together with other characters to place resources. Here you can see stacked posts and rolls of netting must be carried by characters.
I didn’t want to give players infinitely “deep pockets” for carrying unlimited resources, as many role playing games do. Most resources need to be carried one at a time, or by a small group, encouraging the player to bring NPC companions along for logistics. Having even one companion can cut construction time in half.


Then, the player uses the construction tool (a wooden mallet) to actually build the structures they have planned.
The player can use multiselection (described above) to direct NPCs to work on connected construction nodes.

I didn’t want moment-to-moment control of the NPCs to feel too ‘top down’. The construction system is designed so that the player character has to participate in most work, leading by doing.

When given the “Place Resource” action, NPCs will search outward from the node where the player placed theirs for linked construction nodes. Actions are queued up, so if the player picks up and places two posts, the NPCs will also try to pick up and place two posts.

These features combine pathfinding with a queue of tasks. The task assignment system underwent a lot of refactors and revisions over the course of our development to hash out particulars. For now, I’m using the A* Pathfinding Project asset by Aaron Granberg to handle path finding.

Construction Plan Types
There are 3 main categories of construction plans, that we implemented to support a variety of structure types, with variations built on top of these.

Graph Plans
So called because the player builds an undirected graph as they draw the plan.

The player places links and nodes, and every link must have two nodes.



A single graph plan can support multiple recipes. The player can create different fences depending on which materials they add.

This plan is used for a variety of structures, like fences, walls, but even more complex structures like row covers.




Brush Plans
So-called because the player presses and holds a button to continuously brush nodes. One node can be connected to up to four other nodes. Junctions and endpoints are rendered with a larger diamond  for clarity.

These plans are used for curving structures, primarily trails. Previously I had tried a spline based solution with fewer nodes, but this was simpler (both to implement and to actually play with).

Players can use tools to cut trails into the hillside, making the path flatter and easier to walk on. They can also add resources to build stairs and other structures along the trail.



Polygon Plans
This plan type extends Graph Plans, and adds a third element; polygons.
When players complete a valid vertex cycle (including some constraints, such as min/max angles, and a maximum number of verts), the placement tool generates a fill using the vertices.
These plans are used for flat structures like raised platforms, concrete pads, etc. I wrote a few variations on this to support different structure types.

Shown here is a variation for making raised flat foundations for buildings. When a polygon is placed, all vertices are moved to match the height of the highest polygon, preventing the platform from penetrating the ground.



This video shows a very early iteration of the trail planning tool, which uses a spline to produce a curved trail. 


Trees

An important goal is to treat the environment as a dynamic ecosystem, rather than a static background for adventure and exploitation. This early test shows a stand of cedar trees growing over many in-game years, at an excellerated rate. Simple rules govern how and where the trees grow based on shade from nearby tall trees, changing weather, ground cover, and rainfall. I was pleased at how much it resembles a real forest after a few years.


Modular Tree System
Trees grow in vertical sections, which helps forests look more diverse, and creates a lot of opportunities for interactivity.

For instance, this allows trees to break into discrete log sections, and allows the player to interact with different pieces of the tree.


Adding additional prefabs and materials to a generated tree allowed us to visualize the state of a tree for the player.
As a tree loses health, it’s leaves die, turn orange, and fall off.
When a tree dies, completely, it decays over time, eventually becoming a clean white snag, and falling over.



We also experimented with other tree types, like this “bush” type for small trees and large shrubs like Manzanita. We never got around to fleshing out these tree types with as many features as the vertically growing conifers.


We also tried a much more complex “branching” type for oaks, madrones, etc, which combined concepts from the vertical/conifer type, and the bush type. With this modular system, it’s possible for every tree to have a unique appearance.

Shade and Moisture
Trees and other plants impact the plants around them. Trees cast shade on the ground and on each other, which impacts the growth of smaller plant species below. Trees also affect water levels in the ground, reducing the rate of surface evaporation.

This visualization shows how the shade system works. Shade is calculated on a low resolution grid, and creates fanlike shapes moving northward from the tree. This reflects how trees cast shade in the northern hemisphere.

Trees can also cast shade on eachother, and shaded parts of a tree will eventually lose their leaves. In aggregate, this means that large stands of trees will create a canopy of green over time, shown below.



Other Effects of Trees
We’ve experimented with other ways that trees can affect their environment, including this early test of having trees drop their leaves on the ground below. The data is represented on the left with different species leaves in different RGB channels.

Plants

Trees and small plants are both batch-rendered using the Nature Renderer plugin.
Smaller plants are rendered using detail meshes with a custom shader we developed. The lifecycle status of plants (if they’re fruiting, flowering, how healthy they are, how large they are, etc) is represented with splat maps that are passed into the shader.

The slideshow below shows two plant species changing over the course of the year.

Factors like shade levels and moisture affect the health of plants, and therefore how quickly they grow, how much they flower, and how much they fruit.

Fire


One way I am interested in complicating mechanics around plant growth and forest management is by simulating aspects of how forest fires spread in real life, including factors like slopes and ladder fuels.


Below is one of my first tests of burning grass on Unity terrain. Instantiating hundreds of flame particle systems got out of hand quickly, and the result is not very visually appealing.


I’ve been experimenting with shader graph to make more interesting looking flames, which are also more performant than a bunch of particle systems. I was also able to encorporate some more handmade crafts into this style of flame, using a simple orange watercolor as the basis of the effect. These flames also look great scaled up, and with small and large flames combined. For larger or more distant objects I can get away with a single large plane rather than many small flame particles.


The final system uses the unity jobs system to process spreading flames, and a single particle system for efficient rendering.





Paper Prototyping


After building a lot of test scenes of the 3rd person game mechanics, I realized I needed to get a handle on the long term progression / strategy of the game. We made a simple paper prototype of an environment broken down into tiles with tons of pieces made with cardboard and POSCA paint markers.


The player moves a bunch of crew tokens around the board, planting trees, building trails, shelters, and other improvements.

After a couple of long playtests, it seemed like the rules might be fun, but the data-heavy nature of the game made it unweildy to play as a single player board game. Each tile has a variety of stats that determine how plants grow, how they burn, how moist the soil is, etc. I found that I spent most of the time playing calculating the effects of weather and updating tiles on the board, so I decided to try switching to a digital 2D prototype.

  • Players can upgrade connecting trails, cut / plant various plant types, and start controlled burns.
  • Some tasks require multiple crew to be on the same tile, others can be done by one person but might take several turns to complete.
  • A “predicted weather” track allows you to plan ahead for bad weather.
  • Depending on conditions and weather, fires start and spread uphill (rightward).
  • Plants grow or wither and die (becoming fast-burning dry fuel) based on water, shade, and ashes left by previous fires)
  • Grass and Shrubs instantly grow to their full size. Shrubs are hardy but don’t offer as much shade as a fully grown tree.
  • Trees start small and vulnerable, but if you can keep them alive for a couple of years they grow tall and cast lots of shade, which improves water retention and reduces fire danger.

For all the complexity, actually playing becomes fairly simple once the player learns some basic rules of thumb.