All posts by Mauricio García

Reducing accessibility barriers on an adventure game

As most of you already know, we are quite proud that “The Last Door” has important in-game accessibility features. To that effect, we counted on the help and experience of AccessAble Games ( in order to design “The Last Door” as much accessible as possible.

The most remarkable functionalities towards accessibility are: the possibility to play with a special font adapted to dyslexia disorder and closed captions.

Since the beginning of the game development, we had clear that we wanted to add accessibility features so that any player could enjoy “The Last Door” experience. Now, each time we undertake a new chapter design from the scratch, accessibility it’s in our mind, on the starting grid.

Some of these features make the game more accessible and include no time limits to read the texts, a simple control (mouse and left-click), no need of speedy or long clicks, etc. In the top of that, and as main features we focused, in the two above-mentioned aspects: audio and texts.

Taking as a starting point that the soundtrack orchestral music and all the sounds and Fx’s present in the game play an essential role in the gaming experience, and that they have been added to support and go with the players’ imagination, a person who is unable to listen those sounds and music is missing a very important part of the game. He or she will live a completely different game experience far away from the one is designed and intended to be so that’s the reason why we added the option to play with closed captions.

In the upper side of the screen, the players will be able to find music and sound descriptions in the exact moment they are being played in the scene. This description can be also shown in the top left of the screen, in the center or in the top right, depending on where the audio is coming from. This feature is almost indispensable at the point of the game where a given puzzle needs to be solved and it’s much easier to figure it out if you are aware of where the sound is coming from.

A screenshot of the game using audio subtitles:


Being a game adventure, “The Last Door” has many texts: the main character thoughts, object and places descriptions, letters, diaries and journals that Devitt comes across with, etc.

The original font is of pixel-art style, following the overall aesthetics of the game but additionally we added an optional font specially designed to people with dyslexia to be easily read not only by these ones but also by other persons with reading problems.

The same screenshot we used before but applying closed captions as well as the font adapted for dyslexics:


In the second chapter of “The Last Door” we tried to expand the accessibility options by increasing the available languages of the game and most importantly, adding a full-screen mode in both episodes (“The Letter” and Memories”). Indeed, this option was a highly demanded feature by our community.

At this point, I would like to show you the usage statistics of the different accessibility options we have implemented so far:

Accessibility options usage is higher than expected. Taking our first 150.000 gameplays as a reference, the percentage of our players who end up the game with the dyslexic font or the closed caption active, is the following one:

  • 12.33% of the game players who end up the game, they do it with closed captioning activated.
  • 13.78% of the game players who end up the game, they do it with the font for dyslexics activated

Besides, “The Last Door” has received many positive feedbacks regarding our accessibility options, we post you hereunder some of them:

“I love that dyslexia-friendly font. This is just amazing for someone like me. I didn’t have to read everything 3 times to understand every little bit of sentence. That is the exact reason why i gave 6/5 to your game. That is also a message to every other developer. If you could implement that type of font to your games.”

“Wow, I haven’t even started playing, and I already have to applaud you for adding accessibility options.”

“Great work on the accessibility options as well. I was glad to see the subtitling wasn’t hastily thrown in at the end, that it included those great atmospheric sounds, and actually indicated direction. Those are little touches that make a huge difference to players that need them.”

Designing a dialog system for Chapter Two

Hi everybody! It’s again my turn to talk about the development of “The Last Door”. As you may remember from my last post (viewtopic.php?f=3&t=27) I am Daniel, one of the TLD programmers so guess what: Programming will be the subject throughout all my posts!!! 😉

Today I will talk about one of the new features displayed in chapter 2 and, from my point of view, one of the most important ones: the dialog system. Following my usual writing structure , I will explain first what is the dialog system, what was the problem we had to face, how we tackled it, what we have done, what we haven’t and finally, which outcome we got.

I am receptive to any doubt, critics or suggestions from you, so just raise your hand and you’ll be happily answered

What is the dialog system?

I think that almost everyone reading this post and who have played beforehand adventure games like “Monkey Island” will understand what I mean. The idea behind this system is give support to dialog trees (although dialogues are not really trees) implementation. That is, when you interact or talk with an NPC, the player can choose which subject he or she want to talk about till the conversation is over. These conversations can help us to obtain more information, go forward in the game and even, depending on our questions and answers, affect the final outcome (be careful with your responses during the game, we could use them in next chapters)


The problem

The first problem and the easiest to notice from the point of view of a player who has played chapter 1, it’s that in the pilot chapter there wasn’t anybody to talk to. So, first thing we needed to do was to implement dialogues within the game but that’s not all, we also required a friendly tool to make the dialogues easy to design and test (chat simulations) for the game designers since the programmers we were too busy as to be loaded with an extra task. And everything was to be done in two or three week at the most. Quite enough, isn’t it?

The workflow we had in mind was the following:


What have we implemented?

At engine level

Starting from the bottom up, we designed a graph data structure which in turn extended and used our actions system. So this way we had again something similar to a BehaviorTree (BT) but Attention! those with a minimal knowledge about graphs will know that a (as its name implies) BT is acyclic, while many of our conversations had cycles. Thus, we needed to push things a little bit more in our actions system. Basically, what we have now is a directed labeled graph consisting of nodes with a destination edge pointing to the next node. Each node has the following structure:


This time, we have separated a bit more the structure (graph) from the data (actions).
Let’s explain a couple of things first:

  • Condition. This is a kind of Action which will check whether the necessary conditions are met to execute the node or not. There are two types of conditions; the “blocking” and the “passthrough”. In the first type, if the condition is not met the dialogue ends. In the second type, what happens is that the internal dialogue logic doesn’t execute, so it automatically goes to its neighbor node/destination.
  • Dialogue actions. Up to the present day, there are 3:
    • Say. An actor says something in the dialogueImage
    • Select Choice. Choose an answer, question or topic (​​destination edge) on which to continue the dialogueImage
    • Jump selector. Given a set of edges, take the destination nodes and check if they meet their condition or in the case they don’t, check if they are not blocking conditions. Choose the first node that meets the constraint. If none satisfies it, use the default destination which is normally the end of the conversation.Image

At tools level

Honestly, most part of our implementation was a Mauricio’s idea. Completely refusing to reinvent the wheel, he introduced me Chat Mapper (, which with its standard commercial licence you can write your own exporters in C#. But not only that, it also allows to insert LUA code portions, providing some extra logic to dialogues.So we finally opted to use the great default power of this tool just to only focus in writing an exporter which could be able to generate us an ActionScript class coming from a finished dialogue in that tool. Well, not just an only class but something like this:


Let’s overview the parts of this exporter:

  • Localization. It generates a localization file with the dialogue texts.
  • LUA Parser. One of my favorite parts, using ANTLR (, We have implemented a parser of the LUA subset supported by ChatMapper so we can “translate” that code to an Abstract Syntax Tree (AST), which by a TreeParser can be used to build our tree of ActionScript actions. Yes, we moved from LUA to ActionScript via C #.Image
  • Animations. In ChatMapper we can indicate just from a file which action tree must be used when a specific sentence it’s said, if that tree doesn’t exist, a new empty one is created by default. If the animations file does not exist either, again it is created by default. Hereunder you’ll find a simple example of an animations file :

    var show_postcard : Vector.<Action> = new <Action>
    new PlayCharacterAnimationAction( "Player", "up_left_hand_ping", true )
    var mery_comes : Vector.<Action> = new <Action>
    new MoveAction( 465, 475, null, NPC_MERY_VINGE, true, false, false ),
    new MoveAction( 650, 475, 1, NPC_MERY_VINGE, true, false, false, false),
    new WaitAction( 500 ),
    new PlayCharacterAnimationAction( “Player”, “up_left_hand_pong”, true ),
    new MoveAction( 465, 475, null, NPC_MERY_VINGE, true, false, false ),
    new MoveAction( 465, 460, null, NPC_MERY_VINGE, false, false, false, true ),
    new PlayCharacterAnimationAction( NPC_MERY_VINGE, “sitting” )

What have we not implemented?

At engine level

We decided not to implement a generic graph data structure mainly because we had a very specific problem, moreover, keeping this in mind, we had the perfect excuse to continue improving our BTs library (as for instance, splitting tree struture from the actions).

We haven’t any debugger/simulator beyond the one of the game itself, so if we already had that one of ChatMapper, we couldn’t afford to spend our scarce time in an unnecessary feature at that moment.

At tools level

First of all, my main idea was to make something like what our friend fellows from Autoloot Games made here: The idea was to try using again Brainiac as a design tool, but the fact of having to make a debugger and an exporter was a time wasting option. In addition, firstly we had to make brainiac support simple cycles easily.


What went well

Again, I think that the most remarkable thing has been to achieve an easy to use tool, allowing us to add dialogues in future chapters.

What went wrong

One of the aspects that we could classify as negative, it’s been the poor optimization performed when saving data dialogues. Everyone who have played through chapter 2, you’ll have noticed that at the beginning of the game you were asked to allow more space storage (we fell short with only 100k ). Although we don’t need that huge requested space (is set by flash) I think that with little common sense we could reduce that space significantly.

Despite of all the simplicities provided by ChatMapper, there is something that it didn’t go as well as we expected. Taking into account the ability to add LUA logic (which for us was a must) to the dialogues, the person importing or translating dialogue texts to the tool needs a minimum of understanding in programming.

Closing comments

Again for reading the whole post here’s your prize. A video I’ve done this morning showing the basics of our exporter.

Planning Chapter 3

The meeting

Last 25th of June, the entire development team we had an internal meeting to assess the first six months of the “The Last Door” project life. The need to undertake this meeting is obvious since we had already reached an important milestone, the turning point where the release of second chapter made the first pilot to become free to play.

From now onwards, it is even more necessary than ever to invest our efforts cleverly, this is the reason why we needed to stop to consider up to now, all that has gone well and bad.

What went well?

Among the things that have gone well, for us one of the most obvious was the quality of the product. Yeah, we are pretty proud of “The Last Door”, it’s a really good game. And the best thing is that we are not the only ones who think it! Many, a really high percentage of players have spent their time to write us (through one channel or another) and praise the game. Thank you all!

One other good thing is all the good reviews and critics we have received from the specialized press and blogosphere. We managed to put “The Last Door” in several blogs and gaming websites and, to top it all, almost everyone loved the game! That’s great, we are in the good track.

Another source of satisfaction for us, it’s the high level of players’ participation in the development of the game. From the beginning, we wanted the development to be interactive and populate each chapter with as many community provided elements as possible. In the first chapter, we had no time leeway enough to implement this goal beyond a regular beta stage(that didn’t last long, and it was exclusively to fix gameplay bugs, texts, etc.). However, for “Memories”, we have done a great effort and we are sincerely happy with the final outcome. For instance, the experience on leaving objects blank for you to be described, really paid out, we’re totally doing more of this in the future!

Furthermore, having two weeks for beta testing, we’ve been able not only to fix bugs, but to perform relevant improvements in gameplay and, regarding the writings, Wow! In the end, we got almost 100% of the texts re-written by you, and best of all, the final result has been an outstanding second chapter, full of charm.

What didn’t go so well?

First of all, we have suffered an appreciable delay in the development of the second chapter. “Memories” was planned (and budgeted) to be executed in two months and it finally took us three months. One month delay may seem not a big issue, but we failed to establish the right development speed since we hoped that we could do it faster that we did it with the first chapter, and not end up being even slower.

This delay was due to two factors. The first one is the fact that the two youngest members of the team (Daniel and Mateo) are studying and they had to attend their courses (assignments, exams, classes, etc.) which precisely finalised during the same period we’ve been creating Chapter 2. Both of them have had to make a superhuman effort to carry both responsibilities forward and at the same time, not affecting the quality of the chapter.

On the other hand, we underestimated production costs for the new gameplay features we wanted the second chapter to have, like: refactoring the engine, support for NPCs and dialogues (including the integration with ChatMapper, a very cool tool to create conversations).

To follow up the thread of things that could have gone better, we honestly hoped to be capable of start offering translations to different languages at the moment chapter 2 released. But, to be honest, in the end there was no way we could achieve that.

Finally, the most important of the inconveniences we faced, it has been that we didn’t raise the funds that we needed to cover all development expenses of the chapter. In fact, we have only reached 50% of the total. Needless to say, this is a serious problem, since this means that all the team members we’ll get paid less than expected, jeopardizing our personal finances and which in the end compromises the sustainability of the project.

In any case, having obtained 50% of the total amount should not be seen as a failure but as a challenge: we have just started to run the way and we still haven’t done everything we should do. We’re not “there” yet. In this sense, the team continues to move forward with the development of the next chapter, with conviction, but we have to work harder in some aspects, especially those related to marketing and communication, to bring The Last Door to as many people as possible and make it profitable.

Making decisions

This in-depth analysis, should be followed by some serious decision making, especially to establish changes and improvements, trying to find a solution to our current weaknesses and at the same time, empower everything that has been done well until now.

First, regarding the scope of Chapter 3, the most important decision we made was to limit the amount of new features that we would incorporate in the new chapter.

The team agreed that the engine has practically everything we need to build the next chapter, and given that the weaknesses of the project are more focused on marketing and communication, it is compulsory that we focus the developing efforts to strengthen these aspects, especially leveraging that the art team will be busy for a few weeks finalizing the script of Chapter 3.

Keeping this in mind, we established the following priorities for this first month of work:

– Script and Art for Chapter 3
– Localization support (Chapters 1 and 2 must be opened to non-English speaking players)
– Hall Of Fame (reward users who donated 25 €)
– Make payment easier by supporting different payment options and not just PayPal.

Other tasks, less heavy but equally necessary at this first stage:

– Game Trailer (as we are no experts with motion graphics, we are counting with the help of a great professional: Mary Kish, from
– Improve our development with more frequent posts and videos about the game creation process.
– Wild release of Chapter (we want “The Letter” to be released by hundreds of free flash games portals, so everyone who likes it could subscribe and donate for the project).
– Implement tools within our website to facilitate sharing The Last Door on social networks.

In summary, our idea is to invest all the programming efforts in tasks that could directly impact the collection of donations, while artists are busy writing the script and designing the next chapter.

The challenge

Given all these analysis on the situation, and and in order to reassess if we are making the right decisions, we have set the goal of reaching the amount of € 6,000 by the end of the month of July. Do you think we would make it?

Pilot Chapter: Fun facts and references (warning: spoilers!)

We thought it would be nice to use this time to discuss the Pilot Chapter argument in detail and explain some of the scenes that you’ve already played. Many of you asked us about the origins of the story, the ideas behind it, which decisions were taken, etc. Here, we will try to answer some of these questions and then you can share your opinions with us too.

H.P. Lovecraft

After taking the responsibility of creating the script, the first thing I decided was to tell a story close enough to our own vision of the horror genre without stepping outside our comfort zone, and at the same time, a story that was appealing to us from a creative point of view. I didn’t want to create an excessive, grandiloquent and complex chapter but a heartfelt and humble story, faithful to the genre’s roots; a sort of respectful entry in the horror game stage. That’s why this first chapter of The Last Door talks and breathes horror classic stories and imagery all around, especially H.P. Lovecraft’s. The simple fact that the lead character finds his way into an old manor and begins to uncover a hidden, horrible truth is a clear reference to this author (and his collaborators), in such works as “The Survivor” or “The Shuttered Room”. It feels like we’re following on his footsteps, or better yet, like he’s holding our hand while we walk through one of his tales.

Edgar Allan Poe

On the other hand, Edgar Allan Poe is also present in the game in many ways and forms, almost as if we are invoking his spirit. See for instance, the cat puzzle and its sorrowful meow leading us to the wall where a secret lies hidden. Anthony’s obsession with the cat is a reminder of the ill-fated protagonist of “The Black Cat” on the account of how he progressively lost his sanity. Is there a better way to round off this reference than using a crow? Indeed, “The Raven” is one of his most popular poems so we thought it would be interesting to make this continuing puzzle a ritual of sorts, using one iconic reference to merge into the next.

The Crows

So, what’s up with the crows? Why are they eating one of their own? What’s the reference here? Well, during the game we find a note in which Anthony tells us how he was feeling the contemptuous and censorious gaze of his relatives, from their pictures. Finally, we learn he couldn’t handle it anymore and he decided to remove and store them in one of the rooms. The crow scene somehow represents Anthony’s feeling of guilt towards his family. Originally, the crow in the backyard was meant to be just a dead crow, but in one of our team meetings an interesting idea came up – using a dying crow creates a feeling of uneasiness and discomfort in the player but it also works on a symbolic level. Like the dying animal, Anthony is the key to many secrets and we must hurry up before it’s too late.

When the crows get inside the gramophone room, you may remember the curtains being drawn and the (not so) subtle aesthetic change of the room. This is a clear reference to movie director David Lynch, a master of creating disturbing atmospheres through colour and light. In The Last Door, the curtains give the room that ominous look – red curtains are an iconic staple in some of Lynch’s movies like “Mulholland Drive” or the TV show “Twin Peaks”.

The Carnival of Venice

You may be wondering where in the hell does that terrible music that Devitt finds in the cellar come from. It’s a special version, arranged by Carlos Viola, of “The Carnival of Venice” by Niccolò Paganini. The real piece is known to create a sort of discomfort and restlessness to the listener so Carlos thought it would be the perfect choice. Paganini’s life history is very interesting too. He was accused of madness and of making pacts with the Devil; he eventually ended up in prison. It was a perfect reference for that particular scene and the overall atmosphere of the game.


The grandfather clock

When our protagonist steps inside the main hall for the first time, he remarks the grandfather clock is the only sound he can hear. This detail may seem trivial but it hides a reference and a tribute to the first point-n-click adventure I ever played, Maniac Mansion. There, when you first enter the mansion, there’s a clock ticking. That sound has stuck with me for years so I couldn’t help but include that reference in The Last Door.

The deer head

When I was thinking about adding some decoration to the house, the comedy “Murder by Death” immediately came to my mind, especially that scene where a group of detectives are having dinner and the eyes of a stuffed dear head on the wall begin to move, the host hiding behind it. Despite being a comedy, when I first watched it I was a little kid and many scenes caused me such impression that it remained in my memory for all these years. I thought it would be funny to include a deer head in the game.


The Mona Lisa (La Gioconda)

Remember that crooked painting in the lower floor corridor? Perhaps some of you noticed it during your playthrough, but it is indeed a pixel version of ‘La Gioconda’. That corridor is decorated with landscape paintings and there are no pictures of Anthony or any of his relatives. However, I wanted the crooked painting to stand out, so I thought of creating a pixelated Mona Lisa. Plus, it was the perfect place to hide the maid’s rosary – behind that mischievous smile there’s gotta be a secret, right?

Barrels in the cellar

That was our little tribute to ‘Amnesia: The Dark Descent’, one of the most terrifying games in recent years. We thought those dark cellar filled with barrels were unforgettable, don’t you think?


And that would be all for now. Don’t hesitate to send us your questions and opinions 🙂
Until next time!

“Pilot Chapter” Post-Mortem (Part 1)

This is my first post in the development blog, so let me introduce myself to all of you. I’m Mauricio, programmer of The Game Kitchen. For The Last Door I’m in charge of website programming and project management. In the following series of articles I will be guiding you through the development of the first chapter, and if everything goes well, will continue to do the same for the following chapters from here on out. Later, I’m planning on sharing with you other aspects as well, such as our business model, statistics and other stuff that I hope would be of your interest and even use.

So without further ado, let’s go!

An exhausting crowdfunding campaign

To pull off a successful crowdfunding campaign, Kickstarter or any other platform, is no easy feat if you’re lacking a certain reputation to precede you. The Game Kitchen is a relatively young team. Back in 2012, we didn’t even break our third year of existence yet, and of those, the first two years was exclusively dedicated to carrying out projects for other studios and companies. We didn’t have a successful project to call our own and, because of that, we didn’t even establish a regular fanbase. All of that makes getting visitors to a crowdfunding campaign really hard.

December of 2012 was one of the most stressful and busiest months in my life. That’s actually not a bad thing, considering the project got funded and hey, it’s just thirty days! But there’s something I didn’t expect, and I think none of the rest of us did either, and that’s the amount of work and stress level involved in just thinking about ways to make the project more visible and attract an audience to Kickstarter.

In our ingenuity we thought that part of the team would be enough to handle the campaign while the others would start working on certain aspects of the game to have them ready once we were up and running (and more importantly, funded). But that wasn’t the case as most of the resources were spent on the campaign, only exception being the creation of the playable prologue. Even though we barely reused any lines of code or assets from it, it turned out to be a good prototype and gave us a real and concrete vision of what we wanted to achieve in the first chapter.

Eventually, the campaign ended up being a moderate success and we were able to breathe easily again for a week or so while charging our batteries during the Christmas holidays (which in Spain last approximately until January 6).

The real work begins

We began the pilot for The Last Door in January 7. Ahead of us was one of the greatest challenges we ever faced: develop the whole game engine, the first chapter of the adventure and also the first version of the website. Everything in a mere 60 days.

On top of that, we ran into an unexpected bump on the road. Our colleague Alejo told us that, due to personal reasons, he wasn’t going to be able to continue in the team. He directed the crowdfunding campaign and also took a primary role in the project’s birth, but sadly we had to separate our ways for the development of the pilot chapter.

Our first step was setting up a rough planning of all the work ahead of us, and the team’s configuration if we wanted to carry it out. Soon, we decided some of the KS rewards and main features of the website would have to wait until the next stage of the development because we didn’t have enough resources to tackle them at the time. Luckily, the episodic, iterative nature of the project gives us a certain freedom: we would focus on the most essential features during this first stage, and then we could continue adding the rest, along with the following chapters.

Where to start?

From the point of view of production, which is an unassigned role that we all share using our collective intelligence, our first decision was to make a first sprint that would last for a little less than a month. We did it like that because we had to build a clear-cut, well-defined basis for every aspect of the game, and we thought it would be convenient for us to have a 30-days schedule where everyone could focus on their task.

The team in charge of the script and general design of the game, formed by our artists Enrique and Mateo, would be creating the main storyline, script and gameplay of the first chapter, all from a basic argument Enrique had going on in his head during December. Obviously, it had to be a script that would somehow “hide” the lack of features that would be entirely missing from the game because of time constraints, such as tree dialogs (that’s why there’s no other character to talk to in the first chapter) or navigation grids.

For the programming team, formed by Javier and Daniel, the top priority was to create the game engine. The coding of the prologue was done rather hastily during the campaign, so it was obvious it needed a deep and thorough analysis and refactorization if we wanted it to hold up a much longer gameplay and the potential inclusion of even more features in the future. Considering the script and design team would need a few weeks before finishing up the story, we decided it would be best to test our newly coded engine features creating a replica of the prologue.

The team in charge of the website, formed by yours truly up to this moment, would create a good basis that supported user profile management: people needed to be able to register, log in, edit basic information and identify themselves as KS backers to access their individual rewards.

Finally, we had to deal with some other production issues during this first stage. On the one hand, we had an ARG going on since the KS campaign and we wanted to keep it alive. Our partner Alejo, even though we knew he wasn’t going to be part of the development of the first chapter, showed a genuine interest in continuing in charge of this experience, one he himself had conceived and created in the first place. So that was settled. On the other hand, we were afraid we wouldn’t be able to satisfy our players’ communication needs for two main reasons, the first being the huge amount of workload ahead of us and second and foremost, no one in the team really has enough command of the English language. So we thought it was imperative to get into the team some sort of “community manager” if we wanted to guarantee a fluid channel of communication with you, without linguistic limitations. So we started the search of the right person for the task.

To be continued…
The next part of this post-mortem will be available next week.