Tag Archives: process

Seventh episode’s preproduction is now closed!

For the first  week we had this clear idea for the new episode, something we had been thinking in doing for a long time: the whole episode would take place on board of a big screw ship. We liked this setting for several reasons. It was constrained, which is a powerful tool for creativity, and the number of different rooms was quite limited, which would lighten production load in favor of more iteration. There was also the ominous atmosphere of something going wrong in the middle of the sea, the darkness of the engine rooms, the mystery of exploring the depths of the ship… and its name, too: SS Unknown, so the episode could be called The Unknown.

But already in the middle of the season we couldn’t afford an episode so separated from the rest. The idea certainly is juicy for a self-contained story, but it is very difficult to join with the other episodes. As we worked on it, more questions whose answers we didn’t know kept appearing. Where was the ship heading to? What would happen when it got there? How had we got on board? What could be the meaningful contributions to the main arc or to the series’ lore? Because this third episode needs to prepare the players and the story for a satisfactory, thrilling, and terrifying season finale.

Gladly, Enrique had had an alternative idea during this first. After talking about it for a while with José Antonio and me, we all soon realized it could create a really interesting, strange and deep atmosphere. Our heads started boiling with scenes, characters and puzzle elements, fragments of plot and new elements for enriching the lore. This was at the start of the second week, so we took the decision to abandon the previous work and commit to this thrilling new idea!

I know, I wanted like the most an episode of The Last Door set in an enclosed, limited space. Maybe in a future project…

We cannot disclose much yet, because things are still fresh and can (and should) change quite a bit during production, when we see exactly how everything works together. And the last thing we want is to spoil anything. But we can safely tell it will take place in an Irish island, where we will come across a peculiar celebration, and that we will discover a new perspective on the series’ lore, drawing mainly from elements suggested during the fourth episode.

With this new, fertile idea, connections with the rest of the season emerged naturally. From here on, we looked for other people’s work that related somehow with the atmosphere, to use for reference. We always do this, since the beginning of the series: in the first episode they would be Poe’s The Raven and The Black Cat, Maupassant’s The Horla, and the typically Lovecraftian story of the scientific research gone wrong. In the second one there were elements of Lynch’s Inland Empire, Machen’s The Great God Pan, and Poe’s The Telltale Heart, among others. Kubrick’s Eyes Wide Shut, and  Borges’ The Approach to Al-Mu’tasim would be two of the references for the third.

For this episode  –at least at this point — there is a main influence we cannot tell yet, but others are Lovecraft’s The Ceremony and some seductive stories from  Yeat’s The Celtic Twilight, which has been recently re-published in Spain.

This time around we took less time pre-producing the episode, because last time we realized we tend to advance and enhance the experience way more efficiently while building the game. So we are two weeks intro production already: most of the core gameplay of the beta is implemented at this point, as are many of the dialogues. The first backgrounds are ready too, but the game is still lacking content,  enough for another two weeks at least. Then we need to iterate the experience a couple of times, and run the translation-proofreading process, until it is ready for beta testing.

Preproduction of the new episode already started

Pre-production of the new episode already started

After a few days of well-deserved rest, we already got our hands dirty with the development of the new episode. In this new stage, considering our new and promising working pipeline, we’ve set ourselves the goal of mastering the production process.

We want to avoid at all costs unnecessary delays in the development of the new episode, like the ones we suffered during the making of “The Playwright”. We always wanted to achieve a 3 month per episode development cycle, but never before had all the ingredients to achieve it. So this time, a big part of the plan is to walk towards this goal.

Production schedule

The first step was to make a deep analysis of the production process of S02E01, identifying major milestones along the way. Each one of these milestones, is basically defined by the ‘outcome’ expected at that particular point of the development process. First, in pre-production, these ‘outcomes’ would be in form of design documents. Soon after, the main ‘outcome’ would become playable builds of the episode, which deliver a particular set of the expected features.

Once we put together the list of milestones, we hang those in the office’s wall in the form a calendar, placing each one in the expected delivery date. From now, if we miss a date, we’ll know something is going on, and would react sooner, adapting whatever is needed to ensure the project as a whole continues on track.

Image

Wall poster made with post-its, with ‘milestones’ in their expected dates. All these dates are obviously estimations, subject to changes due to production circumstances.

Pre-Production milestones:

  • 7 Nov 2014: Episode Synopsis
  • 22 Nov 2014: List of puzzles, List of scenes, List of scary situations
  • 28 Nov 2014: Map of rooms, Placeholder room’s backgrounds, Second iteration of production lists.
  • 5 Dic 2014: End of pre-production: Screenplay (walkthough) document. Script document. First episode build (#1) (includes all rooms in navigable state, with placeholder backgrounds).

Production milestones:

  • 19 Dic 2014: Build (#2) with first iteration of all puzzles implemented, but still with placeholder art. Must be playable from first to last room.
  • Now come 4 weekly iterations of the episode: planning each Monday, new builds each Friday (builds #3 to #6). Last build (#6) is published as the Episode Beta for Premium users.
  • 23 Jan 2015: Texts for beta are “locked” and sent to reviewers.
  • 30 Jan 2015: Reviewed texts are imported back into the game.
  • 12 Feb 2015: Texts for final version are “locked” and sent to reviewers.
  • 17 Feb 2015: Reviewed final texts are imported back into the game.
  • 20 Feb 2015: Final episode target date. We’d do our best to publish this day, but please note that unexpected events will occur during development 😉

Hope you guys like this insight in our production process, we plan to continue offering you interesting details on how the new episode is being made. Please use the comment section if you want to ask us something, we’ll be happy to answer 😉

cheers.

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)

Image

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:

Image

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:

Image

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 (http://www.chat-mapper.com/), 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:

Image

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 (http://www.antlr.org/), 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: http://autoloot-games.com/?p=110. 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.

Results

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 IndieViddy.com)
– 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” 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.