Share this project


Share this project

A psychological horror adventure inspired by H. P. Lovecraft and set in a massive, decaying mental institute.
A psychological horror adventure inspired by H.P. Lovecraft and set in a massive, decaying mental institute. Currently in alpha status and being tested by our courageous backers!
A psychological horror adventure inspired by H.P. Lovecraft and set in a massive, decaying mental institute. Currently in alpha status and being tested by our courageous backers!
3,169 backers pledged $119,426 to help bring this project to life.




I only understood you as far as wanting to look.


There is nothing interesting there.


They are sitting expectantly. Maybe you should say something.


I don’t understand that sentence.


[I don’t know the word “stupid.”]


What do you want to say to them?


If you want to scream, please say so.

That was getting too complicated, so I’ll stick to our good old written update format.

Ah, words. I love them, you love them. What would we do without words? We’ve come a long way since the venerable parser in interactive fiction and, even though I mourned its untimely deprecation back in the early 90’s when Legend Entertainment—the company which came up with the absolute best parser system—finally abandoned it, I’ve come to accept the new standard of drastically simplified interfaces. Nowadays players take many things for granted, and how you interact with a game world is one of them—in fact, interfaces are perhaps the most standardized element in the industry today. Admittedly, the less they get on the way, the better it is particularly for a horror game.

We’ve been paying a lot of attention to this in Asylum. The current interface based on your trusty notepad went through several iterations until we settled on its final diegetic incarnation. But we had another issue—as you know, our major roadblock has always been the interaction with the dwellers in Hanwell Mental Institute. It’s crucial for the game and its story that this feels right. Well, I’m happy to say that we’re almost there, and today I’ll tell you the hows and whys.


It’s all about consistency. We went to great lengths to make the environments in Asylum look highly detailed and crystal clear. This monolithic building of horrors has been virtually erected and works great—it’s old news now. However, it’s an advantage that, other than the occasional swinging window pane, or stormy skies, or disgusting swarm of flies circling a chunk of rotten meat, the environments tend to be static. After all, buildings usually stay still most of the time. On the other hand, the characters are organic beings commonly known as humans. And we humans tend to move. A lot.

So it’s been a royal pain to put the quality of characters on the same (or very close) level as the environments. There would’ve been many ways to cop out of this situation, but of course we opted to do it the hard way. I understand now why this type of highly detailed in-game character is usually developed by dozens of people, each with a very specific skill, and with an astronomical budget. Just for one character. This is what we have right now:

 project video thumbnail
Play with

Now this may look interesting, cool even. I know it’s not mind-blowing, but it’s a huge milestone for us. There are several more things we need to do and improve: the animation is still rather stiff and choppy in places. Lenny stares too much and that’s not the idea—he’s a nervous fellow that wants to avoid eye contact. Also, it stills lacks that sort of unique personality a key character should have.

Or maybe he’s already awesome and we’re aiming way high.

This is all especially intimidating once you realize just how many things are happening behind the scenes. Sure, on the surface I just greeted Lenny and simply asked about Hanwell. No big deal, you’ve been doing this in adventures since the day someone put a small leaflet in a mailbox next to a white house. But that small action requires a complete system in place, a carefully exported character with all the corresponding animations along with something called blendshapes for the facial gestures (tons of them, blendshapes everywhere!), plus interactions, events, behaviors, transitions, triggers, and craziness! Mayhem! It’s Hell on Earth, I tell you!

But we still conserve our sanity, or at least enough of it to tell you how it all works. Because there’s another phase of game development that’s rarely discussed yet it’s time-consuming and decisive: research. In software development there’s always a balance between degree of control and speed or ease of use. We tried different approaches to our dialogue system: we had been doing everything from scratch, coding by hand each and every one of the processes that control the character’s behavior: eyes, mouth, gestures, etc. This is mighty useful because we can fine-tune every aspect of his or her behavior, and easily replicate it whenever necessary. However, it quickly became evident that this would take an inordinate amount of time that we no longer have. And it turns out that wasn’t the only issue (because there’s always more issues): even if we completed our highly customized system, then comes the part when we actually have to create the dialogues. Now, if you have simple conversations in mind, that can be a fairly quick process—after all, a common mechanic in games is that you ask a question and the character replies back, meaning that you don’t have to dabble in complicated dialogue trees. But… here comes again… we chose the hard way.

You see, the idea in Asylum is that you don’t ask plain questions but discuss topics. You can talk about something as much as you want until that character doesn’t have anything else to say. However, it could happen that you are discussing something else that enables more feedback about a previous subject. And it could also happen that a character reacts differently to certain subjects when he or she in a specific mood. And it also happens that you if you spend too much time without saying anything, the character loses his or her patience and dismisses you.

Yes, we are officially nuts. But we worked it out.

Enter playMaker. We usually try to rely as little as possible on third-party tools, but playMaker won us over. Briefly, this is an add-on tool for Unity that allows the developer to create something called “finite state machines” or FSMs. The idea is that you define states, actions that govern them, and transitions between them. The above (very) simple screenshot should speak for itself: Lenny says his introduction and then goes to an “idle” state awaiting the player’s input. If the player takes too long, Lenny enters a “timeout” state where he presses the player for more input. The “idle” state is also monitoring the selected topic for discussion.

Imagine doing all that by scripting alone as we were doing with Lua. I love code, but I’m not that crazy. Sometimes you have to draw a line between tinkering and getting things done, and playMaker is an easy way to visualize our character’s behaviors. Without something like it, we’d have to come up with our own graphical tools and we’re not in a position to do that. The interesting thing here is that playMaker is highly customizable, so in reality it’s executing our own hand-coded actions that manipulate the different systems I described before. It’s a good compromise that’s working very well.

The final scheme will be far more complex than what you’re seeing in that screenshot, though: transitions can be global, meaning that asking about any topic could break any state (it’s not wise to place so much responsibility on “idle” anyway). And there’s also the moods—noticed how Lenny’s expression changed twice in that video? Sometimes a mood will last for the duration of a dialogue line, but others will persist for the remainder of the whole dialogue. I know it all sounds like a scary amount of work, but this can be done fairly quickly now that we have all the systems in place.

But wait, there’s even more happening behind the scenes:

That is Unity’s Mecanim, possibly its best feature. It’s a tremendously powerful way to command the animations of a character, attaching them to specific events or behaviors. Based on the video above, this simple system should be self-explanatory, although we still need to add more animations and fine tune all those transitions.

You may be wondering, is all of that worthwhile? You bet! These characters finally feel lifelike, responsive, and they’re a far cry from our initial experiments with pre-rendered graphics. We’re beyond happy with them. I’d have never imagined we’d come this far—and we have to thank you for your patience and support. Soon you’ll be able to have a very interesting conversation with Julia, the first character you meet in the game, in the current alpha build.

Closing time

When there’s good news, there’s always bad news: I don’t want you to panic but we had to close our physical office, and there’s no reason why you don’t need to know. In short, we needed to renew its contract but the proprietor wanted to murder us with the new rent. Blame inflation.

So long, Senscape office! We had a good run.
So long, Senscape office! We had a good run.

It was a good and comfortable spot for us but didn’t make sense to keep it. The whole idea about a second project was precisely to keep the office running with a larger team, but we’re few people now and Asylum is on a stage where it no longer benefits from the dynamics of working together.

Make no mistake, this office was an amazing experience for us: it allowed us to reorganize ourselves, rethink the project, migrate to Unity, complete the entire Hanwell building, finish the intro sequence, characters, and more. It saved us tons of time and we’re working much better now because of it, but the time has come to move on. Looking at the positive side of things, the new circumstances are better for the kind of work I have to do now, which is mostly writing. There are tens of thousands of words already in the script of Asylum (probably as much as Scratches), but I still need to add more dialogues, books and feedback. Me, I prefer quietness and solitude when I write. And perhaps a bottle of Jack Daniels by my side. Yeah, I’m old fashioned.

(actually, I like Old Fashioned’s too)

We do have to thank OKAM Studio, makers of the upcoming and brilliantly looking The Interactive Adventures of Dog Mendonça & Pizza Boy, for taking Pablo with them who, as far as I understand, hasn’t bitten anyone yet. Unfortunately Pablo didn’t have enough room at home, but OKAM came to save the day. And hey, apparently they brought in someone else too…

Josesito is everywhere.
Josesito is everywhere.

In my next update I’ll be telling you a bit about how we “virtualized” us again, this time using tools such as Slack and Trello to keep track of everything that’s happening in the development of Asylum.

From Hanwell to Blackwood

Speaking of Scratches

*pants, pants*

(must… finish… update)

There’s an ongoing community playthrough in Adventure Gamers. The idea is that people play the game together over several days while posting their impressions of the game, and the organizer invited me to participate with my own input. So, over the past few days, I’ve been providing fun facts and interesting trivia about Scratches. Things like…

The very first image we ever did for the game!
The very first image we ever did for the game!
Early blueprints for the Manor...
Early blueprints for the Manor...
... or an early, brighter take on the lake!
... or an early, brighter take on the lake!

And lots, lots more. Feel free to stop by and join the discussion. Or lurk in the shadows, like the kind of horrors that haunted your nightmares in Blackwood Manor. The kind of horrors you’ll also find inside the Hanwell Mental Institute.

Until next time,


Warden's log, April 17, 2015. I realized this is an actual log and I can't write on wood.


For backers only. If you're a backer of this project, please log in to read this post.

Welcome To The Hanwell Mental Institute


For backers only. If you're a backer of this project, please log in to read this post.

Horror In C Minor: A Musical Gift


For backers only. If you're a backer of this project, please log in to read this post.

# Title Of The Update ++ To-do: remember to add a title to the update.


*clears throat*

Hello dear backers, today—

Actually, why did I clear my throat if I’m going to type text anyway? Was it to prepare myself for the daunting task of transforming thoughts into words? Most importantly, why did I transcribe the action of clearing my throat? Was it necessary? Can you know for sure if I truly cleared my throat? Has the throat been cleared if there’s nobody to listen except me? Is anybody reading this? Are you real?

But it’s Friday and I’m not mentally prepared to answer these existential questions. I’m just going to proceed and type stuff in the hope that it will somehow make sense.

Julia: The final cut

Before I get to the meat of the update (I still need to butcher a few more corpses) let me show you some eye-candy. As you know, it’s always been a big concern for us to have realistic and convincing characters. Our previous efforts left a bit to be desired, resulting in robotic or stale animations, and I even dedicated two updates to discussing the difficult process of bringing characters to life. This is precisely one of the reasons why we switched to Unity: to have beautifully animated and responsive people in the game.

Well, over the past few weeks we’ve been focusing on this aspect of the game and we couldn’t be happier with the results. Julia in particular looks amazing, her motions now feeling lifelike and natural. Sure, there’s still room for improvement, but this is as far as we can go with the remaining time and budget for the project. You can see the differences for yourselves in this short clip (without audio):

 project video thumbnail
Play with

Note that Julia is a realtime 3D character being animated by code. In other words, her blinking, speech and gestures are all independent animations controlled by Dagonity. Nifty, eh?

Beyond the limits

But today I wanted to talk about the writing in Asylum. The design document and story have remained untouched since… hell, I don’t know, somewhere around 2009, but the writing evolved over time. The first barebones approach was seen in the interactive teaser released in 2012 in which you clicked an object, got a single response, and that’s all there was to it. This can lead to monotonous feedback when you’re exploring a place because sometimes you go back to previous rooms to look around if you missed something. And there’s two things that annoy me in adventures: first, lack of interactive objects. I love exploring and looking at many things and getting interesting responses every time. Second, repetition. It’s a mood-breaker when you look at something twice and get the same consecutive response; it makes your protagonist feel like a puppet, like you’re reaching the limits of the game, and I want to avoid that at all costs — I want to give you the illusion of infinity, that the game has no boundaries and there’s always something new to discover.

Big words, I know, and unfortunately it’s a complex problem that in a story-driven game demands tons of writing and planning. We tackled this approach in Serena, which was very well received. There was an inordinate amount of feedback for such a small cabin; you could look at the most insignificant item and still get a deep and thoughtful response. Moreover, people could feel how the protagonist’s mood shifted over time and items provoked different reactions as the game progressed. In some ways, Serena was a testing ground for the ideas that we were introducing in Asylum last year. But how complex is this approach? Well… this is how the writing was done in Serena:

“Say, is that the Serena spreadsheet in your pocket, or are you just happy to see me?”
“Say, is that the Serena spreadsheet in your pocket, or are you just happy to see me?”

I’m not the biggest fan of spreadsheets but they’re always handy for organizing data, including game writing. For instance, many translators will request the text of the game on a spreadsheet, which makes sense: the information is neatly organized and you can keep track of progress, changes, add comments, etc. It’s all very useful and neat except for one thing: the actual writing.

Spreadsheets aren’t suitable for creative work. They’re too technical, if you catch my drift. When I’m writing, I like to have a blank page with text on it and that’s it. Over the years I’ve been using many tools to aid me in this task and for a long time my tool of choice was Scrivener. It’s like the Swiss Army knife of writing — there’s simply nothing like it in the industry. Unfortunately, whereas Scrivener is wonderful for blogging, novels, papers, and such, it’s quite cumbersome for game writing. You see, the problem is exporting your data: when you’re writing a novel, you create an eBook or PDF with your text; blog post, you can publish right away. But, game texts are going to end in some intermediate format before they’re shown on screen (in the case of Asylum, that’s JSON) and tools like Scrivener aren’t well prepared for that. This is why spreadsheets are used so often: it’s very easy to import or export data from them. The big shots in the industry use articy:draft but it feels awfully cumbersome to me and it’s better suited for large teams.

Anyway. Spreadsheets. Even though they’re an ugly environment for writing, I tried the same approach in Asylum. It was looking like this:

My screen wasn’t large enough to capture all of it.
My screen wasn’t large enough to capture all of it.
And this (still a fragment).
And this (still a fragment).

That looks… convoluted. But is it necessary? Let me tell you a bit what’s going on internally in the game. Two major things occur story-wise: first, the mood of the protagonist can change. However, as opposed to Serena, where it gradually went from “happy” to “gloomy”, it can go back and forth in Asylum. So sometimes the protagonist will feel cautious, others more courageous, and sometimes he will feel desperate and hopeless. Second, time will advance just like in Scratches since the game takes place over the course of one night. These two variables — mood and time — will trigger different reactions from the protagonist as you explore the asylum and interact with the people dwelling inside.

So here’s how I tried to organize this in spreadsheets: the first table had the texts for interactive objects (feedback). Each row represented an object, such as a piece of newspaper, with up to four different moods and three different responses per mood. That table was over 100 rows high and still barely a third of the game. To compare, Serena had 35 rows for feedback. The other tables contained the thoughts of the protagonist (reactions to locations and circumstances of the story that aren’t triggered by clicking somewhere), and comments about entries in the notepad/inventory, such as tasks and people, which change over time.

Needless to say, it wasn’t very practical. I often found myself scrolling all over the spreadsheets, for example ensuring that a thought was consistent with a related object in a certain location. And again: it’s an ugly environment for writing.

I had to find a better solution.

Back to basics

Yes, there’s something even more basic than spreadsheets, and that’s plain text. The tool that I’m using for the game these days is the same one I’m using right now to write this update:

Now we’re talking!
Now we’re talking!

Ulysses is an elegant and handy software for Mac that makes me revel in ecstasy. It’s lightweight, clean, and focused on plain text. And yet, far from being a glorified file browser, it’s based on a syntax that has completely changed the way I write: Markdown. Basically, Markdown allows you to format text while keeping it readable before converting it to HTML, ePub, PDF, or anything else you like. It’s pure bliss and I consider it absolutely essential for writing — these days I’m not touching rich text with a bloody severed limb.

Of course that working with the texts in Asylum was much easier this way. As you can see in the screenshot above, it’s as simple as setting up a good folder structure and begin working. I used one folder per location (for example, Exterior by day) and then one “sheet” (or text file) per interactive object. Browsing the massive structure of the game is much faster now and way more intuitive than scrolling through an endless spreadsheet. Most importantly: I can focus on the writing for one object at a time without annoying rows and columns all around me.

However, the real trick here is using Markdown for our own needs. I don’t want to get too technical at this point of the update, so I’ll keep it short: exporting texts for the game is even more straightforward now. Combined with the hotspots creator that I discussed last time, creating complex interactive elements in Dagon is just a matter of… writing. Really, we can quickly parse all these Markdown files and convert them to actual code in the game. That feedback about the Hanwell Mental Institute looks like this:

See how there’s a “cautious” state that reflects that particular mood of the character? And note how it changes to “neutral” after you exhaust all the reactions pertaining to the cautious mood? There’s a certain intelligence attached to these objects, and this is a huge feature of Dagon in how it allows developers to create extremely complex behaviors with just a few lines of code.

Remember what I was saying a long time ago, around 1000 words earlier, about the illusion of infinity? Well, keep in mind that we’re doing this for every single object in the game.

*stares intensely at the screen*

Every. Single. Object.

*repeats in slow motion*

eeeeeeeeeeveeeeeryyyyyyyy… siiiiiiiiiiiingleeeeeeeeee… oooooooobjeeeeeecttt…

Coming up

Whew, that was a lengthy one. Hope you enjoyed this glimpse into the inner workings of Asylum and how the writing process has been evolving. There’s more much to say, but the next step is to show you things. We’re almost ready to start testing a demo of the game. As we discussed, this is going to be a gradual release — first we’re going to send it to VIP backers and focus on things such as interface and performance, but eventually every backer will get to play it. The game is looking great. I can’t stress enough how polished and immersive the whole experience is. Also, I’m hoping to have news about a potential release date after the holidays. Speaking of which, we’re working on a small surprise for next week.

That’s about it for now. Stay tuned for more, and have a great weekend!