Campo Santo
A small but scrappy video game studio in San Francisco

Shop

Shop

Press

"Like a supergroup of musicians from all the bands you don’t like. And not even the best musicians from those bands."

Rock Paper Shotgun commenter PopeRatzo, February 3, 2014

From the Blog

  1. Drinks? Yep. A quintet of game developers? You betcha. If you’re coming to PAX or are in the greater Seattle, WA area, come join us at Devs & Bevs! 

    Five independent game developers—including us, naturally—are hosting a bar night at the Hard Rock Cafe on Sunday, August 31st from 6:00 to 10:00.

    The lineup for the evening is extraordinary.

    6:00—Fantasia from Harmonix
    6:30—Firewatch from Campo Santo
    7:00—Tharsis from Choice Provisions
    7:30—Below from Capy 
    8:00—MASSIVE CHALICE from Double Fine
    8:30—Costume Quest 2 from Double Fine
    9:00—Gang Beasts from Boneloaf

    And more!

  2. COME SEE FIREWATCH AT PAX PRIME 2014
This is going to be a big PAX for us. For one thing, it’s our first one. But more importantly, it marks the public debut of Firewatch! We’re going to show it off live. This is terrifying.
Join us Saturday, August 30 at 10:30am in the Hedgehog Theatre for a live Firewatch gameplay demonstration, Q&A with the team, and the first screening of our new trailer. If you can’t make it, it’ll be streamed live on Twitch, but we’d love if you came and offered your moral support and heckling.
Here are all the official details:
Making Firewatch: Trailer and a First Look from Campo Santo
Firewatch is a video game being made by Campo Santo, a new ten-person independent team based in San Francisco. It’s a moody, first-person wilderness mystery with lots of dialogue, planned for release in 2015. Join us for the public unveiling of the game, including the first gameplay demonstration as well as the debut of the teaser trailer. Several members of the team will be present to talk through gameplay, respond to questions, and probably accidentally break an NDA or two.
Featuring:
Jake Rodkin, Co-Founder
Sean Vanaman, Co-Founder
Chris Remo, Developer
Jane Ng, Artist
Will Armstrong, Engineer
James Benson, Animator
Most of Campo Santo will be at PAX, so keep your eyes out for:
Nels Anderson, Designer
Olly Moss, Artist
Paolo Surricchio, Engineer

    COME SEE FIREWATCH AT PAX PRIME 2014

    This is going to be a big PAX for us. For one thing, it’s our first one. But more importantly, it marks the public debut of Firewatch! We’re going to show it off live. This is terrifying.

    Join us Saturday, August 30 at 10:30am in the Hedgehog Theatre for a live Firewatch gameplay demonstration, Q&A with the team, and the first screening of our new trailer. If you can’t make it, it’ll be streamed live on Twitch, but we’d love if you came and offered your moral support and heckling.

    Here are all the official details:

    Making Firewatch: Trailer and a First Look from Campo Santo

    Firewatch is a video game being made by Campo Santo, a new ten-person independent team based in San Francisco. It’s a moody, first-person wilderness mystery with lots of dialogue, planned for release in 2015. Join us for the public unveiling of the game, including the first gameplay demonstration as well as the debut of the teaser trailer. Several members of the team will be present to talk through gameplay, respond to questions, and probably accidentally break an NDA or two.

    Featuring:

    • Jake Rodkin, Co-Founder
    • Sean Vanaman, Co-Founder
    • Chris Remo, Developer
    • Jane Ng, Artist
    • Will Armstrong, Engineer
    • James Benson, Animator

    Most of Campo Santo will be at PAX, so keep your eyes out for:

    • Nels Anderson, Designer
    • Olly Moss, Artist
    • Paolo Surricchio, Engineer
  3. It turns out Olly has never actually left his flat, so we dragged him to Yosemite to show him what a real American forest looks like. He brought his camera.

  4. Before After

    BULK REPLACER TOOL

    Time for another short code blog!

    While I was working on some very hairy player stuff one evening, Jane asked if there was a way to swap out every instance of one kind of tree with another kind of tree. After a few moments of looking around in the docs and forums, we determined there was not.

    Since I was stymied by rope physics, I decided to take a brief break and write a quick tool for Jane. It took maybe 10 minutes, and did exactly what it needed to. Wins like that are rare enough I am posting it to the blog.

    Here is the full source for the Bulk Replacer Tool.

    I have written several little utility windows at this point, so I had a decent framework for this. All I had to do was write the algorithm that would handle the replacement.

  5. Hello, I’m James Benson. I’m an animator. I’m going to animate the game “Firewatch.” If you think my animations are bad, you can lobby Campo Santo directly to replace me with a better animator by leaving comments below. I won’t delete them.

    As you can see in the above video, if there is a box that isn’t moving, I can rectify that in around 10 minutes. When I told the people at Campo that I only animate primitive geometric shapes, they thought I was joking, and I didn’t want to correct them b/c I need the money, so right now I’m booked in to animate all the games boxes, but also the main character and everything else.

    If it’s of interest, I worked as animator and designer on the game “Ori and the Blind Forest” and I piggybacked on the success of various Valve properties, exploiting these well-known brands to garner hits. The advertising money lasted a few years but that well has run dry, which is the primary reason I’ve started putting new YouTube videos up.

    Lovely to meet you,

    Let’s talk soon,

    James Nicholas Benson

    P.S. I worked on that Project Milo game where Peter Molyneux constructed a small interactive boy, so you know Firewatch is in safe hands.

    P.P.S. I find It hard to be sincere in a public setting. In truth I am a normal person who is very happy to be working with people I have admired and respected for years. They really are very good-looking.

  6. Feedback is the lifeline that connects the player to a game’s systems. Without good feedback, the player cannot understand how to interact with a game’s world. Inconsistent or inadequate feedback makes a game feel mushy, unresponsive, and unsatisfying to engage with.
Even though Firewatch doesn’t have complicated puzzles or intricate combat, it’s essential for players to understand which objects they can interact with in the game and how. It facilitates them being able to play intentionally and for us to communicate to the player what the possibility space of the game is. And as the HUD is something the player sees a lot, how interactive and polished it is has a big impact on player perception…
[[MORE]]
We wanted to get a HUD with appealing look and feel up and running early in development. Jake created the assets and I integrated them into the game itself. We wanted the UI system to be modular, so its appearance could be modified by Jake without needing many changes to the underlying implementation. We used a visual scripting system and a 3rd party UI package.
In general, I’m wary of visual scripting solutions. I find they are often brittle and make implementing simple features cumbersome and difficult features even more difficult. 
However, as Will wisely counseled, they are good for one thing procedural code is not: implementing state machines. A HUD is basically a bunch of elements responding to other actions executed within the game; it rarely does any execution itself.
We’re using Playmaker, a robust visual scripting package available in the Unity Asset store. It provides a state machine component that can be added to any GameObject, and within it you define states, actions to execute when entering those states, and events that will cause transitions to other states. But the best part about Playmaker is that in addition to be easy to add custom actions, it has a number of custom actions for other popular third-party Unity packages, including the UI package we’re using, NGUI. (Playmaker + NGUI integration is available here)
Under the hood, we have a HUD manager script that receives notifications from all the other relevant player-controlling scripts. It get notified when the player targets a new object, when the pick something up, etc. This HUD manager dispatches events to a root UI object. Rather than having one massive state machine for the entire UI, we gave each HUD element its own simpler Playmaker state machine. So the reticule that expands and contracts is its has its own state machine, the object name that appears beneath it has its own state machine, etc.
The HUD manager dispatches those events to Playmaker, and in turn the Playmaker state transitions execute actions that tell various NGUI tweens to play. In Playmaker, it looks like this:

So with the player targeting the “log” above, the targeting system tells the HUD manager the player has a new target, the HUD manager sends an event to Playmaker, and Playmaker handles that event by transitioning the reticule NGUI element from its “off” state to its “on” state. And as the player is close enough to see the object’s name, another event is dispatched to Playmaker, causing that text element to fade in.
The only challenge here was, while Playmaker allows sending events to specific state machines or broadcasting an event globally to every state machine currently active in the entire scene, it doesn’t seem to provide a way to send events to all the state machines on a single GameObject. Rather than maintain references to each individual state machine and needing to update them each time we add new state machines, I wrote a simple event broadcast component.
public class vgPlaymakerBroadcast : vgMonoBehaviour {

private PlayMakerFSM[] allFSMs;

// Use this for initialization

void Start () 

{

allFSMs = gameObject.GetComponents();

}

public void SendEventToAllFSM(string eventToSend)

{

for (int i = 0; i < allFSMs.Length; i++)

{

allFSMs[i].SendEvent(eventToSend);

}

}

}

Of course, shortly after we implemented this, Unity announced they will be adding a new native UI system in Unity 4.6. But hopefully, since we set up the HUD to be modular, we can simply change the Playmaker actions from targeting NGUI components to targeting the native Unity UI components instead.
Hopefully that’s been at least somewhat useful! One of the most pleasantly surprising things about working with Unity is how often you can find an asset store package like Playmaker that saves a mountain of time not needing to re-implement known needs like simple state machines. Instead it allows you to just focus on using those packages to make the game look, feel and play better.

    Feedback is the lifeline that connects the player to a game’s systems. Without good feedback, the player cannot understand how to interact with a game’s world. Inconsistent or inadequate feedback makes a game feel mushy, unresponsive, and unsatisfying to engage with.

    Even though Firewatch doesn’t have complicated puzzles or intricate combat, it’s essential for players to understand which objects they can interact with in the game and how. It facilitates them being able to play intentionally and for us to communicate to the player what the possibility space of the game is. And as the HUD is something the player sees a lot, how interactive and polished it is has a big impact on player perception…

  7. Hello again. Olly here. Hi.

    I’m told that it has been too long since the last art blog was posted. So here I am, posting some art in a blog.

    These are some early sketches and colour thumbnails for environments you may see in the final game. Not pictured: Ice level. Lava level. Warp zone.

  8. Enjoy your Fourth of July and this small update!

    Enjoy your Fourth of July and this small update!

  9. Hello everyone,
You don’t know me, but you might have played one of the games I worked on. Even if you did, it might be difficult to explain what I did on it…
Did you notice how the lighting was smooth across surfaces without artifacts? Have you noticed that the character shows damage exactly where it was hit along the correct direction the enemy was slashing? Yes?
Well, then I have a few more: Did your game ever crash? Did any textures pop in close to the camera? Were you surprised by how complicated the complicated world in front of you looked and what the developers did to render it?
Hi, I’m Paolo. I am a graphics and core engine programmer. I am the director behind the curtains who makes sure all the silicon available in the box you are playing the game on is used. I am the guy that can talk about “physically based rendering,” or “memory compression techniques,” and I need to know that, for a computer, ((a * b) * c) is not necessarily equal to (a * (b * c)) (and yes, I know that multiplication is commutable, I am talking about this). I am the guy who spends his time on profilers, trying to understand how to lay down your data in such a way that artists and designers don’t have to worry about it, but your machine is not screaming cache misses every 3 cycles.
No more than a couple of months ago, I saw Campo Santo was looking for a graphics programmer. Interesting. I knew Jake, Sean and Chris from their podcast and the games they worked on. I thought I would give them a call, just ‘cause. The call ended up being a two-hour discussion about the game, what they needed, and how to achieve it.Things like: We need to take Olly’s art and make it look awesome in 3D.
No pressure.
It sounded extremely interesting. A cool game developed by some of the coolest people from the industry? A few weeks later, I decided to pack my room and move up to San Francisco. Now I am here. Let’s see what comes next. More on that soon.
—Paolo

    Hello everyone,

    You don’t know me, but you might have played one of the games I worked on. Even if you did, it might be difficult to explain what I did on it…

    Did you notice how the lighting was smooth across surfaces without artifacts? Have you noticed that the character shows damage exactly where it was hit along the correct direction the enemy was slashing? Yes?

    Well, then I have a few more: Did your game ever crash? Did any textures pop in close to the camera? Were you surprised by how complicated the complicated world in front of you looked and what the developers did to render it?

    Hi, I’m Paolo. I am a graphics and core engine programmer. I am the director behind the curtains who makes sure all the silicon available in the box you are playing the game on is used. I am the guy that can talk about “physically based rendering,” or “memory compression techniques,” and I need to know that, for a computer, ((a * b) * c) is not necessarily equal to (a * (b * c)) (and yes, I know that multiplication is commutable, I am talking about this). I am the guy who spends his time on profilers, trying to understand how to lay down your data in such a way that artists and designers don’t have to worry about it, but your machine is not screaming cache misses every 3 cycles.

    No more than a couple of months ago, I saw Campo Santo was looking for a graphics programmer. Interesting. I knew Jake, Sean and Chris from their podcast and the games they worked on. I thought I would give them a call, just ‘cause. The call ended up being a two-hour discussion about the game, what they needed, and how to achieve it.
    Things like: We need to take Olly’s art and make it look awesome in 3D.

    No pressure.

    It sounded extremely interesting. A cool game developed by some of the coolest people from the industry? A few weeks later, I decided to pack my room and move up to San Francisco. Now I am here. Let’s see what comes next. More on that soon.

    —Paolo