For backers only. If you're a backer of this project, please log in to read this post.
Warden's log, April 17, 2015. I realized this is an actual log and I can't write on wood.
Welcome To The Hanwell Mental Institute
Horror In C Minor: A Musical Gift
# Title Of The Update ++ To-do: remember to add a title to the update.
Click Here To Read This Update
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):
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:
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:
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:
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…
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!
Hola, ¿cómo están? Hoy quería comentarles algo muy interesante, resulta que—
*repeatedly hits head on the desk*
Guten tag, ich bin ein—
*hits head one more time*
Testing, testing… one, two, three… OK, that did the trick. Hello there! I trust you’re all doing great. Today I’m going to talk about a prominent feature in adventure games: hotspots. But first, a little story.
Once upon a time…
This year marked a decade since the second playable teaser of Scratches was released. It supposed a huge leap of technology since the slideshow format of the first one, released in late 2013. The new panoramic rotation system — popularized by Cryo in the mid-90’s — which allowed players to explore the locations of Blackwood Manor in 360 degrees, proved to be very effective and immersive for the game. Although back then it alienated some hardcore fans who still preferred the slideshow format, in the end we all agree that this upgrade in quality made Scratches a much better game — in fact, we’re so happy with panoramic rotation that we’re still using it for Asylum.
Thing is, panoramic rotation brings a whole new challenge to developers: the possibility to rotate the camera in any direction means more stuff you can show, hence more stuff that players will attempt to interact with. The node-based approach brings yet another layer of complexity because it could mean that the same interactive element is seen from two or more nodes. This is a very common occurrence in Asylum, a sprawling game world with big areas that promises plenty of nodes per location. It happens right at the beginning with Julia’s desk in the foyer, which is accessible from six different nodes.
Naturally, players may attempt to look at the desk from any of these nodes and expect to get an interesting response. And of course making the desk interactive in one node but not the others is lazy and a potential mood-breaker. These interactive elements are represented in the game as invisible clickable regions — surely you’ve heard the name before: hotspots.
But allow me to finish my story. We didn’t have sophisticated tools while producing Scratches. Its engine — the venerable Scream — was solid and efficient, but lacked a friendly workflow. There was no easy way to define hotspots: the engine would only accept rectangular regions for interactions. Would you like to know how I defined hotspots in the game?
Manually. Every single one of them. Select the region in IrfanView, then copy-paste the coordinates in a Scream script.
Now let’s take Asylum, a game that is three times as large, which means many more nodes, and a greater interaction density per location. Clearly, we needed the improve the workflow.
3D hotspot, meet 2D graphic
Fast forward to present time. The first major improvement that we introduced was polygonal hotspots, which means that we’re no longer constrained to those rough squared regions. Polygonal hotspots mean that interactive elements can be more accurately drawn in the engine, resulting in a smoother experience for players, but at the same time makes the process even more difficult because you use more vertices — which means that drawing them by hand could literally toast your brain.
Before I tell you what we’re doing now, an important distinction: as a node-based adventure, Asylum’s graphics are pre-rendered. What you see on screen are flat bitmap textures projected on a cube to give the illusion of actual 3D. The hotspots, however, are 3D polygons that are drawn without textures, so the player never gets to see them. We need this to do something called “hit test” — that is, when the player points the camera at an invisible hotspot, the engine detects the interaction and an icon pops up over the corresponding element. So basically the hotspot is a 3D polygon placed over a 2D bitmap. Hang on in there because here comes the good part…
Introducing Spotmatic™ 3000
It all began with a simple question: if we do have 3D graphics before we pre-render them, why not use all that information to produce hyper-accurate hotspots? Even better, how can we improve the process to make it as automatized as possible?
Well, we did the best we could, and it’s a far cry from our previous approach. I think it might be the most sophisticated system conceived for adventure game development. It boils down to selecting objects in 3ds Max and exporting data about them… and truly, that’s all. Check out this screen:
The process is as simple as assigning a color to any object in 3ds Max (the only software we support now, though it should be easy enough to extend this functionality to Maya or Blender). What our Max tool (developed by Pablo) does is export a list of "colored" items along with their names and individual textures with their placement on screen. Then, our Dagon for Unity (aka Dagonity) engine grabs all this data and automatically assigns an interaction to these items, be it feedback from the protagonist or a custom action such as grabbing the item in question. All the mumbo-jumbo happening behind the scenes is a result of Francisco’s wizardry with Unity — essentially, the colored portions of a texture that correspond to interactive objects are vectorized into the 3D hotspots. The most beautiful aspect of this process is that the color of the object remains consistent across the whole location and nodes it contains. See, this is what happens when we define objects for the janitor’s closet:
The interesting thing here is that the programmer never needs to know the color, just that there's an item called "gloves" (for example) with a certain object ID. Similarly, the writer only needs to know that there are gloves in that scene and write a few lines for them. Right now I'm working on a script that will convert a monolithic Excel sheet with all the protagonist’s feedbacks into Dagon's new data storage format based on JSON, similarly to what we did in Serena. Again, the orange gloves can be seen from any angle or node in the janitor’s closet — we don’t need to define several hotspots for it, just tell 3ds Max to draw the gloves with the orange color.
Why is this a big deal? As we discussed, creating hotspots is a cumbersome process, especially with a high interaction density per location (and it's truly HIGH in Asylum). You could spend hours defining interactions for just a single room, but not anymore with this tool — our workflow now is as simple as writing the texts for a location and exporting the interactive items from 3ds Max. Our good friend Dagonity will take care of the rest.
Just think about it: I write a bunch of lines for the darn gloves, Pablo assigns a color to them in 3ds max, and then Francisco loads the exported data into Dagonity. BAM! The gloves are now interactive and have feedback. That’s all there is to it. As usual, all our tools will be open and free to use, and I’m hoping that Spotmatic™ 3000 will be ported to other modeling applications by our ever-growing community. The system works just the same for third-person adventures and you could even ignore 3D altogether and colorize spots with Photoshop or similar. Yup, quite a progress since those golden days with IrfanView and Scratches.
Coming up next… how feedback works in Asylum and why we’re so fixated on interaction.
It will. Oh yes, it will!
In other news, Asylum has made it to popular website for all things spooky Bloody Disgusting's top Indie Horror Games of 2015. I particularly enjoyed what they had to say about it:
“I can’t wait until Asylum finally arrives and I’m able to take it off all of these ‘upcoming games’ lists. It’s been in development for a long time, but recent looks at the current state of the game lead me to believe it isn’t that far off. It’s an ambitious title and one of the few adventure games we have to look forward to right now. I have the feeling the wait will be well worth it.”
I'm really sorry about the excruciating wait, but you know that we're painstakingly working on the game as usual. We did achieve major breakthroughs in the project this year: the novel interface, beautifully animated NPCs, and jaw-dropping, moody visual effects — the kind of stuff that we wanted to include in the game since it was initially conceived. We’re not going to rush things and ruin a long 5-years of hard work, but we are ensuring that Asylum lives up to its promise.
See you soon, and thank you for your patience!