A Non-Violent Immersive Sim

One of the interesting challenges you run into as a game developer is how to simply and clearly describe your game to people who encounter it for the first time. The 10-second hook, or the “elevator pitch.” Sum it up in one sentence. What is your game?

Gone Home is a simulation of exploring an abandoned house to discover the story of the people who lived there.

Like any elevator pitch, your one-sentence description should get people asking more questions. What I’d like do here is answer the question “what does ‘simulation’ mean in Gone Home?” Because the answer to that question drives our entire design philosophy behind the game.

Mechanically, our biggest video game inspirations come from the subgenre of “Immersive Simulations”: Ultima Underworld, System Shock, Thief, Deus Ex, BioShock, the upcoming Dishonored. These are first-person games that emphasize believable gameworlds and player-driven experience. Explore how you want, develop the playstyle you want, inhabit a world that functions in convincing, internally-consistent ways. Immerse yourself in the experience as if you “really are” the character in the game.

These games also all center around combat (or, often, avoiding combat.) Many of the interesting systems and player choices come from how you interact with enemies, and how you customize your own abilities to do so. But there are no enemies in Gone Home; there are no other people at all.

So how does the philosophy of Immersive Simulation apply to a game with no combat? Can a “non-violent Immersive Sim” even exist? For us, it comes down to extracting the specific definition of “simulation” as it applies to the games that inspire us, and applying that to the context of experience we’re presenting in Gone Home.

Because “simulation” in our case is not a literal term. It’s not virtual reality or the Holodeck (or even Jurassic Park Trespasser.) What it means is allowing the player to do whatever their character might logically do within the game’s context, and ensuring that the gameworld reacts in the way you expect. The design challenges in pursuit of this goal involve deciding what to abstract away from literal simulation, and how best to accomplish it.

This all starts from considering the role of the player character. In Gone Home you are a normal person in an abandoned house, trying to figure out what happened to the people who lived there. So what might you want to do in pursuit of that goal? Walk through the house, open doors and drawers and closets and cabinets. Read things. Pick up objects and examine them for clues.

Interesting design questions start to arise at this point. For instance, you want to be able to “read things,” but in the context of the game, what things do we make “readable”? A single-family home tends to contain hundreds of books. Allowing the player to literally read every single one of them would be bad both player-experientially, raising the text noise-to-signal ratio way above acceptable levels, and production-wise, as implementing and maintaining thousands of pages of text just wouldn’t be practical for us.

This is where the idea of abstraction via consistent visual language comes into play.  In Gone Home, you can pick up and examine any book that is lying out on its own, and cannot interact with any book that is jammed into the lineup of a bookshelf.

Quickly an implicit contract is established: any book you see lying out on its own will be relevant to the story and characters, and will be  interactable; anything stuffed into a bookshelf will not be interactable, but also will not be relevant to uncovering the mystery of the house. Abstraction occupies the space where the rules of the game deviate from the rules of the real world; abstracted rules must always be clear and consistent, and help the player to more fluidly inhabit the role of the character they’re playing.

The question of how the player interacts with physics objects gets a little more interesting, and a little more challenging from a systems standpoint. It starts with a similar type of filtering as the book problem: if you’re an explorer trying to figure out what happened in this house, your character wouldn’t need to rearrange the furniture or topple bookshelves. But she might want to pick up smaller objects on tabletops or inside cabinets to look for evidence underneath them, or to pick up specific objects to examine them more closely. To support this player role, we implemented the Physics Examine and Put Back systems.

The Physics Examine system allows the player to grab any small physical object in the game and rotate it to look at it from different angles. This keeps the idea of “examining objects” within the same interactive mode as walking around exploring the house, and puts all physics objects on a level interactive playing field; you can examine a totally mundane pencil the same way you’d examine a matchbook with a portentous note scrawled on it. You don’t get to look at only specific physics objects in high detail “because the designer says so”; you can closely examine any physical object that YOU suspect might be relevant to your experience.

This only got us halfway there, though. What happens when you want to put the object down? At first we only had a system where you toss the object back at the world, turning you into a clumsy vandal by default. Which felt really bad and dumb. The player character in Gone Home might want to pick something up, look at it, then put it back down carefully. But we also wouldn’t want to restrict the player to ONLY be able to pick up objects and put them back where they came from. If the player WANTS to toss stuff everywhere, by all means they should be able to. But it shouldn’t be the only option.

Our initial ideas for design solutions were way too complicated and impractical, entailing a system that would allow the player to place any physics object precisely on any surface, arranging arbitrary objects just so, dynamically detecting valid placements and rotations in realtime, etc. Eventually we realized that this wasn’t supporting the role of the player as investigator, but our own desires as blue sky designers of a literal simulation, which is not what Gone Home is about.

Instead we implemented the Put Back system, whereby any object that has been placed intentionally before your arrival (anything from a desktop picture frame to a bottle of handsoap) can be “put back” in its original location by pointing at its original spot and clicking to place the object. If you look anywhere else while holding the object, you toss it into the world.

So if you want to put back everything you find right where you found it, you’re free to; if you want to grab all the mugs and books and photo frames that are placed around the house and pile them up in a corner, you can do that too. But YOU’ve made that decision, and have the freedom to do so with any object you pick up. We’ve provided authored possibilities to the player, to support inhabiting the role of the player character, but we do not dictate that the player must comply with them.

To us, that is the essence of Immersive Simulation: giving the player all the interactive tools they might desire in the pursuit of inhabiting the player character’s role, without ever saying “you HAVE to play this way, or make this decision, or engage with this content.”

The difference between Gone Home and its inspirations is what role you inhabit: not a gene-spliced assassin or cyborg superagent, but a normal person in an unfantastical, everyday locale. Gone Home is an invitation. Come to this simulated place, explore as much or as little as you want, get as much out of it as you put in. “Playing how you want to” can mean more than choosing to sneak past a guard instead of killing him, or upgrading run speed instead of jump height. It can mean inhabiting a familiar, virtual place “the way you really would if you were there,” engaging with the experience how you want to, if you want to, immersing yourself as deeply as you choose into this particular slice of interactive experience.

We only hope that we can live up to our inspirations.

follow @GoneHomeGame or Like www.facebook.com/gonehomegame for news, updates and peeks behind the scenes of Gone Home.

Posted in Design | 22 Comments

How an Abandoned House in Japan Inspired Gone Home

“I am… merely a curious explorer, who has become entwined in this family tale. … These people mattered and deserve to be remembered.”

One question that I’ve been asked frequently is, “What gave you the idea for Gone Home? Why did you want to make this game?”

There are a lot of practical reasons. Our team’s combined experience drove us to make a first-person exploration game, and our small size required that we reduce scope as much as possible, which is why we decided not to have any characters in our game. But that’s only half of it.

In real life, exploring a completely abandoned place can be a thrilling experience. The feeling of being all alone, surrounded by the past, piecing together a forgotten story. But why pick a house that a family lived in, and not an ancient ruin, or space station, or military complex?

One of our prime inspirations took the form of a long-abandoned family home outside of Tokyo.

The Royal House Haikyo

In Japan, abandoned places (and the practice of exploring them) are called haikyo (廃墟). Last year, I read a fascinating account by Michael Gakuran of the exploration of one haikyo, an abandoned home that’s become known as The Royal Househttp://gakuranman.com/the-royal-house-haikyo/

The house had been abandoned for many years, but had gone undiscovered and remained almost in the same state it was when it was last inhabited. And it was filled with tantalizing and mysterious clues as to who lived there, what happened to them, and why the house had been left to rot.

Family photos filled alcoves and shrines…

In particular, the house seemed to have close ties to a Western man. Had he married into the family?

There were also ties to the British royal family, a posh hotel in Tokyo, and the pearl trade…

As well as some ominous clues as to a falling out with a certain family member…

What struck me above all was the sense of drama and intrigue that emanated from this entirely unpopulated place, stocked only with the remnants of lives once lived there. The disparate hints of these people’s history beg the explorer to dig deeper. What might be fairly mundane events of daily life in the present become a thrilling mystery as they fade into the past.

The house on Arbor Hill

Taking inspiration for Gone Home from The Royal House haikyo presents a number of unique challenges. Much of the investigation of the Royal House haikyo took place over a the course of months, in a variety of locations: the cemetery containing the family’s burial plot, the hotel advertised on the matchbooks, on the internet and in libraries researching the family’s history. Gone Home takes place entirely within one location, the house on Arbor Hill that the player explores over the course of the game. All of the clues, all of the information that the player will rely on to reconstruct the story of what happened there, must be woven into the cabinets, drawers, bookshelves, between the couch cushions and in the hidden compartments of the house itself.

Additionally, in Gone Home we want a sense of urgency and import to the player’s exploration of the house. For it not to be a dead place that’s been devoid of life for years or decades, but a home that has been very recently occupied, as if the family there has just stepped out for the evening. For the player to feel more like Goldilocks in the Three Bears’ house than a tourist in a museum.


In Gone Home, you will enter the house on Arbor Hill with questions in mind: who lives here? Why did they suddenly leave, and where have they gone? And how do I, as an investigator and explorer, fit into all of this?


It’s on us to present you with these mysteries and more, to fill the house with the hints and clues that will draw you all the way through to the story’s conclusion. We’re grateful to Michael and all the other researchers and explorers that worked to unravel the history of the Royal House haikyo, for providing a fascinating example to serve as inspiration and guidance as we continue to build Gone Home.

Be sure to read the original account of the exploration of The Royal House. It is more than worth your time. http://gakuranman.com/the-royal-house-haikyo/

Follow Gone Home on Twitter and Facebook for more updates like this one.

Posted in Design | 8 Comments

Painting and Process

One way that we consider ourselves lucky is having lots of talented friends who are contributing to Gone Home. From Kate Craig tackling environment art for the game, to Chris Remo composing the game’s music (another blogpost in the making!) to Syd Kalenda stepping up on the community management front, we’re surrounded by really awesome people pitching in to make Gone Home a reality.

Another piece of the puzzle: Emily Carroll, an illustrator, comics artist, and friend of the company, who’s completed an amazing title splash screen for us/desktop wallpaper for you. Check it out!

How did the piece come to be? It was a collaborative process between us and Emily (which consisted of about 5% nudging from us, and 95% Emily taking the idea and running with it.)

It started with a brief: we wanted “the house surrounded by trees, silhouetted on a hill against the dusk light.” We also sent along a really rough drawover based on the layout of the house in the game, over top of an image of an old Victorian that Karla found online.

Emily had played an early version of Gone Home, so she jumped right in with her own distillation of the tone we were going for: “mysterious but also melancholy — something undefinable but bittersweet.” Spot-on.

Based on this, she did a layout sketch to give us an idea of the composition she had in mind.

Often the artist’s first vision of a piece ends up being the way to go, and we could tell Emily had a strong idea for how she wanted to approach this. So we gave the thumbs up, and she went straight to color compositions and variations on the logo.

Deciding on the color approach to take was a balancing act. While Gone Home is a spooky, atmospheric experience, it’s not outright horror. And while mystery and strangeness are key, there are no supernatural elements in the game (magic, ghosts, demons, etc.) Composition 2 felt like it navigated this territory just right: mysterious, intriguing, and just a little ominous, without looking scary or too mystical.

Similarly we settled on options 3 and 4 from the logo sketches. They’re very different, but both communicate a kind of handmade, careful-but-imperfect approach that gives them an intimacy and innocence we liked. We ended up using 3 in the final piece because it just meshed so well with the dusting of stars that Emily worked into her finished painting. Logo 4 will find its way into the game eventually, though.

In the end Emily created an image that we think speaks directly to the feelings that drive Gone Home. We’re using it as the header on our brand new Facebook and Google+ pages (thanks Syd!) and offering it as a desktop wallpaper download here, for your home computer or mobile device. Head on over to the Wallpaper page and try one on for size!

Next time on the Fullbright Company blog: how an abandoned house in Japan has fundamentally influenced our approach to story and design.

Posted in Art, Media | 1 Comment

Cover Bands

Populating the house in Gone Home with period-appropriate ephemera is one of my favorite things to do on this project. Music is important to several of the characters in the story, and therefore there was no choice but to make up some plausibly 90s rock mags.

I’ve made two so far — one based loosely on Spin (by way of Sassy) and one based on a more girl-oriented Option. We bought a passel of old Sassys, which are great reference in myriad ways, and searched up covers of the others. Here are samples of the originals, naturally belonging to those publications:

Spin Magazine Option Magazine

Note the bright, semi-lousy type, the either grainy or super-crisp photography, and the high contrast.

I did a bunch of research, made some layouts, hit up my friends for cool photos of themselves, and produced some pastiche.

Froth Magazine Froth Magazine

Froth – Music and Culture. They started out more underground and overtly feminist (not totally Riot Grrl, but not quite Lilith Fair either), but took it down a notch in an attempt to get more readers. Now they like Beck and Green Day, too.

GROOVE Magazine GROOVE Magazine

GROOVE: more mainstream, but retaining the appearance of a punky DIY aesthetic. They insist on the name of their magazine being reproduced in all caps. Classy enough to do a Kurt Cobain tribute cover (image courtesy Flourecente!), but not classy enough to keep a few other bands off the cover. (Here’s what Spin did: logo in the middle of the forehead.)

We think it’s meaningful to include real band names from the 90s in the covers. They corroborate the graphic design, and bolster the 90s-zeitgeist context. This helps the magazines feel more plausibly like real artifacts from 1995, not from some parallel universe where Johnny Depp never lived. Fair use allows us to use just the names of bands, so long as we don’t use any logos or copyrighted photos — hence why we have fake headliners on nearly all of the covers. (The one real period photo, the one of Kurt Cobain, is under a Creative Commons Attribution license.)

Magazines were so important in the 90s; their presence will help make the game feel like it has people with personalities, engaged by pop culture, in it. There’re definitely more of these in my future, and I’m pretty psyched about ’em.

Posted in Art | 3 Comments

Code Judo

Hey everyone,

I’m Johnnemann. As Steve explained in our initial announcement post, I moved up to Portland to help found the Fullbright Company as the programmer of the team. I’ve previously worked on some internal technical stuff at Sony during the PS2 era and the launch of the PS3, and then moved to 2K Marin to help release BioShock for the PS3. I turned to UI, gameplay, and AI programming for BioShock 2 and XCOM, and now here I am, going from a series of very specialized roles to having to remember/learn every aspect of game programming at once, from the fun stuff like player actions to the boring-but-necessary things like configuration screens.

As Steve mentioned, we’re using the Unity engine for our project. This is a bit of a learning experience for all of us, as we’re coming from a professional background in the Unreal Engine.  But so far, as a programmer, it’s turned out to be a wonderful experience: most things are easier than I expect them to be.

However, every once in a while the easiest way to approach a problem isn’t obvious from the beginning.  A few days ago, we realized we had a bug with our doors and drawers that you can see in the video.  They’re using Unity’s physics system to move, in order to allow cool effects like things rolling around inside. Behind the scenes, this effect is achieved with some hinges and springs that move the object along a constrained path, according to the physical forces acting on them. The player, though, is also an entity with a physics presence in the world – specifically an infinitely-strong capsule-shaped presence.  We discovered in playtests that the player’s collision capsule would sometimes interact in unexpected ways with the moving doors and drawers.

Low doors, when opened near the player, would sometimes slide under the edge of the player’s collision capsule and pop the player way up into the air, occasionally even shooting the camera out of the house entirely. The same would occur with bottom drawers. Essentially, it was as though a step had suddenly appeared underneath the player and the system overcompensated for it.

That ain’t so good.

The player could also attempt to walk into an opening door, and being of infinite strength, essentially tear it off the hinge. Sometimes, doors would end up embedded sideways into the wall or ceiling, or stretched in weird and eldritch geometries across the threshold.

That either.

Amusing as these various events could be, we knew we couldn’t ship a game where the player could inadvertently perform origami on a cabinet door. But I was stymied by the lack of options we had for changing physics-related things in the engine – Unity makes it very easy to do most things you’d like, but as a corollary to that, most of the powerful handles are hidden away where they can’t be touched, or at least not easily.  So we went back and forth for a while, trying to come up with something we could do. Make the player’s capsule a cylinder, so that drawers couldn’t force themselves under it? There wasn’t support exposed for that, and it would probably break going up stairs. Make the player have less than infinite mass, so that doors could push the player out of the way? That would involve re-writing all of the boilerplate player-movement code we were using, and could have undesired side-effects on the player’s interaction with the world.

Steve and I talked back and forth about various ideas and solutions, and kept running into the fact that Unity wouldn’t let us get into the guts of the systems, so we couldn’t fix any of the fundamental problems these physical interactions were causing. Finally we just decided to work with Unity, rather than fight it. We discovered some sort of Zen acceptance or fatalism, and we came up with two solutions easily: To prevent doors and drawers acting like sudden stairs under the player, we just changed the player’s step height so that Unity would no longer try to step the player up onto things as high as that.  And then I wrote some fairly simple code to detect when an opening door had hit the player, and stop it moving under physics at that point. Now doors would just lock themselves into place as soon as they couldn’t go any farther, and the player would have to clear the area in order to fully open or close them.  Both of these tasks were very simple in Unity and the door and drawer systems I had already written – so much so that the solution probably took about as much time to implement as all of our previous discussion.

Here’s the very simple result of this (code edited to remove unrelated functionality):

    void OnCollisionEnter(Collision collision)
    {
        if (collision.gameObject == Player)
        {
            FinishSwinging();
            /..../
        }
    }

	void FinishSwinging()
    {
        IsSwinging = false;
        rigidbody.constraints = RigidbodyConstraints.FreezeAll;
        /..../
    }

As a gameplay programmer, I’m often asked by designers and artists to solve problems. One of the most valuable questions I can often ask of either others or myself is “What are we trying to accomplish?”.  It’s all too easy to get sucked into trying to solve what looks to be the root of a problem, or the problem as expressed by a designer, and come up with some over-technical, convoluted solution.  Or to go the other way, and deal only with the surface problem by fixing the easiest-to-see instance and leaving an entire rotten system festering beneath the surface that will inevitably burst out in gangrene when you’re trying to ship.

In a perfect world, you would be able to build a flawlessly precise physics simulation, and be able to support edge cases like a cabinet door that’s one inch tall – but often all you’re really looking for is the most efficient compromise that will prevent the player from being suddenly catapulted into outer space.

Posted in Programming | 3 Comments