Share this project


Share this project

Play as an alien plant and escape from a scientific facility, full of secrets and dangerous experiments. PC/Mac/Linux/Wii U/Ouya
Play as an alien plant and escape from a scientific facility, full of secrets and dangerous experiments.
Play as an alien plant and escape from a scientific facility, full of secrets and dangerous experiments.
5,953 backers pledged $144,960 to help bring this project to life.

Recent updates


F4f8082b17a68ed250c31d4aebaa90ac original
13b8650e37988a5beb93dffefde18a81 original
99c9f2d9c7d3325b45005136146a0c1f original
948fbb7dd397a763d04e8fd99dc000b3 original
785e079aac094f1442828ee2a973bb4f original
9859b2c82dac3020dc33917a9b9212f4 original
1088790172a81ae58da6a66c6220170a original
5e325e39023a2ce9f40eef5a777ba502 original
Ac9df444003abff15fadb214f6ab93c6 original
0162f4188d7e868b9938b4d626cf20d4 original
596f264608752beb03b0be7cac476b7d original
81d626ab5d068872f5463246c9d0bbc3 original

Shaders, skill improves, menus, gamepad modes


As you know we’ve released the updated demo last month with tons of fixes and gameplay adjustments. Most of the problems were solved for this alpha but a few of them are still on the to do list (we needed to prioritize other tasks in order to complete major milestones).

One of the bigger problems we faced is explained right below:

Color replacement troubles


In addition to the multiple genders + hair styles already designed for each profession of the G.E.R. staff we wanted to include an option to make all characters unique. With the use of a color replacement shader we could create cloth variety and represent racial diversity.

As cool as it sounds it’s relatively difficult to implement this shader and it’s giving us some headaches. Unity2D is based upon Unity3D, as such the Sprites used by the engine are just textures with a particular material so the engine can render them properly (each material is defined by a shader). You can change this material for another one compatible with Sprites/Default, thus applying a different shader to the texture, but you can't have more than one. This means that we need to create a shader that combines all the color corrections and light effects we want to use on a character. This is our main problem as we currently don't know if this is possible with the effects we're using right now or even how to do it.

Let’s see an example: the enemies have one material that allows an alarm to tint these characters with a vivid tint effect. Now, imagine we swap this red tint material to a change-color material so we can recolor all the enemies and give them different looks, when the alarm starts the game should change their material from the change-color one to the red one, but if we do this the red tint would be applied to the base colors of the sprite instead of the recolored ones from the change-color material.





We tried different solutions like the use of imported LUTs applied to a new camera focused exclusively on the characters layer, multiply tints... but no advances were made on this area. Our last resource is the development of the mentioned mega-shader but graphic programming is a whole new field and could take us some time to achieve it.

We have planned other solutions outside the use of shaders if we come to a dead end, like the inclusion of skin colors and different clothes to our current sets of sprites, but this will limit the variety of npc’s so we’ll exhaust all the possibilities before making this move.

Skill changes and development of new menus

Releasing the two demos helped to calibrate the game difficulty and allowed us to see the strengths and weaknesses of the game on multiple levels. One of the most complex tasks of development is the adjustment of the different elements that conform the gameplay structure. Paradise Lost is especially sensitive on this field because the enemies have numerous interactions between them or with their surroundings and also react differently depending on the skill that W is using against them.

The acquiring of new abilities will be a crucial factor to progress on the adventure so we decided to make some changes in order to simplify game mechanics and have a more enjoyable / less frustrating game experience.

Decoy skill

Originally, the decoy was meant to have different levels of progression like most of the skills, but we realized that it was difficult to improve a skill that is focused on two simple tasks: attract the attention of enemies and go through places that Subject W can’t reach.

We came up with different approaches like enhanced durability, use of multiple actions or teleport W to the decoy’s position unlocking the higher level (which causes troubles like ending in “dead zones” or giving the player the possibility to surpass entire levels in a blink) so we decided to keep it simple and change it to a skill without progression, like the double jump.

To do so we mixed the different actions devised by level and balanced them to create a unique mechanic.


In earlier designs the decoy was able to jump in order to reach higher surfaces, but that alerted the enemies and made its use difficult and frustrating, more so if we keep in mind that it has a time restriction. We could preserve the jump action without alerting them, but it’ll look weird to see a spider-like seed jumping near characters and these remaining impassive.

We wanted to maintain the “decoy” element without losing the platforming so certain changes needed to be made. After the inclusion of the new climbing mechanic (holding a button while walking) we decided to extrapolate this concept to the decoy skill and now it has two different actions that do not enter in conflict with each other: it can reach higher elements unnoticed with the climb button and attract enemies with a new explosion button (that can be used in conducts too), eliminating the jump from the equation. This is the result:

Also, the decoy is capable of interacting with elements (like Subject W) and move between the floor and the conducts if they have a ventilation grid. This diversifies the gameplay and allows players to create multiple strategies.


Shell skill

New animations have been added to the shell state (like slip and recover) in case players fall from platforms while walking.

We also simplified how the damage is perceived while enhancing the ability under the skill tree menu.


Instead of showing a table for each level representing the multiple types of damage (which is difficult to remember) we decided to keep it simple and reduce by half all damage when players invest skill points on it (progressive damage like gas or fire is reduced on level 2 and direct attacks on level 3).

Spore skill

The spore went through a big facelift in order to make its use more fun and its progression more challenging.

Previous version of this ability had two different functionalities related to the first levels of the skill tree, changing the way that could be used: Level 1 > the spore seed reached half of a room, Level 2 > with the skill button pressed the spore seed reached further.

This idea was a bit lame because the landing was very imprecise and overall annoying to use. Also, the gas animation needed to vary from one level to another in order to reach higher spots. This was related to the third Level that gave the spore the capacity of exploding automatically when touching the floor and avoiding elevation like the previous levels (this force-feeded the players to reach the top level in order to be mildly interesting).



Giving a twist to the spore functionality we created a new mechanic that is resemblant to the Balloon Fight game (do you remember this NES classic?) allowing Subject W to create the spore directly from its head.

New floating animation for the spore


Now the spore floats but it can't maintain itself on the air so the player needs to constantly press the jump button to keep it elevated and navigate through the room with the movement controls (beware! W gets exposed while controlling the spore!).

Using it is more interesting and fun because we can reach higher places and affect enemies like cameras or cambots.

In addition if a character identifies the spore it can blow it up and alert the room, giving us the tools to create more possibilities and challenges.

Host skill

With the host players are able to control scientists and press elements unreachable by Subject W or move them away. Certain characters like guards have the ability to knock out other enemies.

The earlier version of this skill used a dart to hit the enemies and trigger the skill from a safe distance, but it was redesigned to create a more clear progression.

Now, On Level 1 Subject W controls enemies if it touches them.

Level 2 gives the ability to control them at distance throwing a dart and also gives the player the option to knock them out from afar (this interrupts the skill). Level 3 has no time restrictions + gives the possibility to switch between the enemy and Subject W to avoid being seen or create more elaborate strategies.

The decoy, host and spore skills are complex mechanics in which you control different entities and the world reacts in various ways to their actions, we needed to adapt several systems to recognize and work well with more characters than Subject W. Thankfully as this was a planned feature a lot of the work was done on the first iterations of those systems and the implementation was moderately quick and clean.

Skill tree modifications

The skill menu has been modified to adopt these changes and the abilities without progression have been added too.


We removed the skill names and levels to have a cleaner look (these will be represented in the info box) and the shell has been relocated to the right in order to create a pyramid composition: stealthy techniques to the left / ‘offensive’ techniques to the right. Thanks to this we were able to expand the info box, gaining space for the action graphics and showing a more concise explanation of the level with a bulleted text.


The top tabs have been reduced and navigation buttons have been added to the bottom of all sections.

Unification of state bubbles

Now that we are unifying mechanics and concepts we decided to do the same to the state bubbles that represent any kind of damage done to an enemy. We had states of sleeping and knocked out for humans, stand by globes for robots/mechanic enemies, etc., so we realized that all of them served the same purpose: show that an enemy is unconscious. With this in mind we created a new bubble that applies to any KO state:



Gamepad modes:

After changing the climbing mechanic we thought that adding two control options to the gamepad could be a good idea. Taking the Xbox controller as reference:

  • Mode A: run with the X, climb with the Right Trigger
  • Mode B: run with Right Trigger, climb with the X


Most players are probably more familiarized with the old school running (ala Mario Bros) but other players seem to prefer RT running, so we’ll keep both of them selectable in the Options menu.

PS: Development forum

We are still working on the forum in order to implement it on our website (been busy with development issues) and figuring out how to send invitations for the backers, etc. As soon as we have it we’ll contact everyone and post an update announcing it.

Thanks for your support!

Demo 1.1.2 (Windows, Mac) + fixes report


First of all, if you are having trouble receiving the download on your mail inbox put your direction here and the Humble team will send you another link with the demo (It seems that their system has some problems with the mail listing). Now you can choose between Windows or Mac OS X.

We couldn’t export a Linux build so far (it’s not so easy as preparing a Mac version and we need to make additional changes to the core structure of the game) so our apologies for the Linux backers :(   we’ll keep you informed about any progress in this matter.

These are some of the things that we changed / fixed for this version:

  • The save state is fixed. Once the player dies Subject W will rebirth in the previous garden the Continue option will be highlighted by default if you have a save state
  • Pressing Intro/Start during the game will ask if you want to return to the main menu  
  • Pressing Intro/Start during a cutscene will ask if you want to skip it
  • The ESC key is mapped like the Intro key
  • The game will launch with the default resolution of your Screen (Res. options will be included in the final version with a windowed mode too)
  • Now the player is able to climb-descend if keeps the D key (keyboard)/RT (controller) pressed while walking. We’ll probably add different modes of configuration for players that prefer to run with the RT and climb with the X button
  • The graphic prompt that represents a climbable surface has a wider range (players can identify them from the distance)
  • Subject W makes a wider jump and it’s easier to move between surfaces without falling from the corners (with this quick fix platforming is less annoying but we’ll keep working on this mechanic)
  • The difficulty curve is more balanced. From the beginning players will have the possibility to interact with their environment on less stressful situations
  • Multiple rooms have been adjusted to the new mechanics
  • The doors keep opened while you enter from another room (you don’t have to see the opening animation twice)
  • The scientists looking at the back show a new state bubble with a clock, representing that they are distracted and you can advance unnoticed
  • Some bugs of the map have been solved (all closed doors are represented with a red wall) and now the save gardens are highlighted on green
  • All the lower hideouts are unified. To use them Subject W needs to be in a crouched position
  • Fixed the pixel art rotation bug of the guards shooting
  • Irvine grenades make more damage
  • The game works on Windows 32 bits 

Problems that we are still working on and might appear while playing:

  • The Mac version shows white bands (or a rectangle) if your screen resolution is not proportional to the original resolution of the game (480x270). The final version will show black borders instead of white ones.
  • Sometimes the character gets stuck inside elevators. We didn’t manage to find this bug in our tests but you can avoid it exiting to the main menu (or the game) and continuing from your last save / launching the game again. This will fix the bug permanently.

If you experience technical issues or have concerns about anything leave a comment below or send us a private message and we'll look into it.

Demo arrival!


Hello backers! Long time since our last update. Some of you asked preoccupied in the comments or by PM if there was some kind of problem with the development, specially since we are inclined to post updates regularly. This time we took the decision of debugging the core structure as much as we can to avoid delaying any longer the release of a playable sample. Maybe the lack of news wasn’t the best of ideas, but we wanted to give you something at once instead of post another “wait a little longer for a sneak peak”.

To all of you sorry for this course of action, we’ll write periodically further on.  

Downloading the demo

You will find a mail in your inbox with a download link containing an entire Chapter of Paradise Lost. If you have a Gmail account and it doesn’t appear in the main inbox check the promotions tab. Lot of things that you will experience are on the making and not completely finished, so there’s room for improvement. All the feedback received by your side is more than welcome.

Pending stuff

There are certain things that we’d love to include in the current alpha, but we didn’t want to spend more time polishing (it’s hard to stop at some point) and give you a playable sample while completing other basic tasks of the general development. We’ll think about releasing an updated beta demo with more content and improves in the future.

Talking about new features, We don’t want to get too much carried away with things that will be included in the final version (specially if some of them are intrinsically linked to core mechanics and will be like go to hell and back to change them). In any case some improves should be:

  • Different skins for male and female (they are already done outside Unity but we changed the system used earlier in development for a more solid one).
  • Different color skins (shaders have a high computational cost and we are still trying to find the most efficient solution to implement tonal ranges. For example, some of you may experience performance issues with the red alarms of the stages > that’s because of the use of shaders).
  • Allow Subject W to hide crouched in low hideouts such as paper bins, boxes, trolleys or flower pots. It seems a little bit confuse to stay crouched to use drawers / trapdoors and you have to stand to hide on the first ones.
  • Leave the door open on the room that you are entering.
  • Enemies able to interrupt Subject W while using a vending machine.
  • A new bubble state for scientist that are focused working and can’t hear Subject W. Bubbles of “talking state” for characters on cutscenes (in the air).
  • Possibility to skip cutscenes by pressing start.
  • Advance dialogues by pressing the action key/button (this one could be very difficult to include due the cutscene and subtitle systems that are already used + the need to change the pace of certains cutscenes, but we’ll try to add it).
  • Load automatically in the last garden after dying, without going to the main menu. 
  • Expanded options menu when pressing start (the demo only show the playable controls).
  • Show distinctive rooms on the map such as save gardens, elevators and undergrounds with specific colors and letters.
  • A legend next to the map.

+ the solving of fixes such as:

  • Receiving the first impact when you are pulled out of a hideout.
  • If Subject W dies by the hand of a reinforcement guard while exiting a room the player can turn invincible (until you exit and load the game again).
  • State bubble maladjustments.
  • Sudden pixel displacements between states of enemies.
  • Represent all closed doors on the map (you can experience a bug that show some of them open).

One issue that we identified during our tests was that the noise made by closed hideouts could be a huge pain (this is because it reveals the position of W and leaves the player very exposed). We’ll try to change it if people think that it’s an annoying feature.


Starting the next year we’ll add the forum section to our main site and send invitations to the backers so we can have a specific spot to chat, comment and write down all the feedback that you want. In any case we’ll be listening to every comment posted on this update or the main comments section as well.

Hope you’ll enjoy the demonstration and keep an open mind about the result, some things might change in the final version of the game.

Happy holidays to everyone and thanks for your support!

PS: If some of you have trouble receiving the humble mail or other problems please notify us by private message on Kickstarter. 

PS2: The demo was developed for Windows version (for the moment).

Level editor, map and new goodies


Greetings backers! Here we are another month to share with you the latest progress of Paradise Lost. We are hard at work with different assignments, establishing unmovable milestones with most of the pending tasks and trying not to overlap our labors, but sometimes we have to spend some extra days polishing functionalities that could save us extra time in the future.

On the art side we were working on animations for cutscenes and some bosses. The last addition to the boss roster has been designed hand in hand with one of our top tier backers, and together we came up with some challenging ideas for this particular confrontation.

The code department (aka Carlos by himself) was focused on finishing the final bits to the level editor and the map, elements that are intrinsically related. Considering that we were deep in these tasks we’ll take the opportunity to share with you the peculiar and complex process of level making.

Designing the levels

To planify all the possibilities of a stage and have an overall look of entire chapters we create the gameplay situations in a vector designed grid before assembling the graphic elements on Unity. The grid is almost proportional to the different pixel art components, and only the main interactive elements are represented with simple vector squares. This way we can focus on the basic gameplay structure without aesthetic distractions.


These are some of the characters drawn inside the grid. The black triangle in front of the NPC means that it can see the player. Red triangle means that it’s looking at the back, so we can pass through staying unnoticed.



Commonly used elements like desks, buttons, trapdoors, etc. are portrayed with the minimum expression of pixels, in a way that they’re easy to recognize and edit. The objects with a blue triangle serve as hideouts (unless the graphic is red, which means that they are locked, acting like a sound trap).


Stage pieces such as doors, vents and vertical lasers are represented too. Background features like glasses and levers give more variety to the stages and add another layer of interaction for the enemies.

Building a gameplay situation

Here are some examples of different stages designed with this method:




The dotted lines with arrows represent an NPC’s routine. The oval mean that a robot turns its face in the middle of a routine to intercept the player. The bubble squares show that two NPCs stop in a certain position to talk and temporarily block Subject W’s advance through the room. 

This is the overall design of half a chapter.

Now that we took on the creative process, let’s see how to translate this design into the game engine.

Level editor

The Level Editor was one of the most important features missing from PLFC, we began working on it almost a year ago, before the video demo came out in december, but we stopped for that demo and just recently resumed our work on it.

The first version of the Level Editor was a standalone application, you could create rooms, move them, group them by zones, edit a room and in theory edit every aspect of every room. This proved to be a bad idea, we were basically trying to reproduce what Unity does but outside of Unity and with some variations and perks added to the mix, so you can imagine how much work that would’ve been.

First version of the PLFC editor

On top of all of this you have to bear in mind that Unity does provide a way to adapt its editor and create new windows and applications, so we scrapped the standalone idea and realized that it was better to “adapt” Unity to our problem rather than recreating the whole Unity Editor. The things that were crucial to add to the Unity Editor so we could have our own Level tool were:

  • Ability to create zones and rooms.
  • Proper room movement on grid.
  • Every entity added to a room must be registered on the room.
  • Ability to generate a map.
  • Save and load the world.

This is what the editor looks like now

The biggest challenge of the new editor was room movement, we had to take control away from Unity during certain situations like while doing a drag-and-drop to the scene or selecting the rooms and moving them, all of this while having to properly manage how every room prefab was instantiated and set on the scene. We faced many problems like the drag-and-drop not working sometimes or dirty flags not being fired causing prefabs to not be saved while exiting the scene, but in the end we got it.

Another really difficult aspect of the editor was generating a map, but we’re going to talk about it on a following section.

Anyway, the amazing thing is that all of these features (and a few more added to help Enol and Sigrid design the levels later on) were finished in just seven days, to give you some perspective the previous version took us a month and it wasn’t even close to being finished. Sometimes rethinking a design choice and throwing away part of your code is worth it. Having almost a full year of added experience also helps.

Exporting background sprites to Unity

On a previous update we told you about our work pipeline with sprites and how we created a Sprite Importer to read large amounts of images and import them with the right parameters into Unity, well we’ve added yet another piece to the machinery.


While the animations are being made with Aseprite, the stage elements are designed with another graphics editor where we can add shadows, gradients and tonal effects (such as color curves). We are also able to categorize the assets in folders preserving all the edition capabilities. Another advantage of keeping all the assets of a level inside one file is that they can be exported with a single click, using an option that exports all folders with a “.png” suffix.

Assigning colors to the different elements of the hierarchy help identify things faster

To keep track of everything once the assets are being imported on Unity, we categorize the sprites following the prefix of the layer where they shall be placed (for example: interactive, decorative, background…).

We’ve also managed to create an script to export all sprites in a folder with an even width and height to the image editing tool we use, remember that the size of any image needs to be always even or power of two to be pixel perfect, that way all of the background pieces can be immediately imported to Unity and placed inside the pixel grid without problems.

The map

What is a Metroidvania without one of these? In Paradise Lost the map is an important gameplay element, not only to have a reference of the player’s situation but to know the location of locked doors, save stages and shortcuts.

Final version of the map will be slightly bigger so players can have a better look of the room details.

Working on the map iconography

Our main goal for the map was to design an intuitive legend that didn’t require descriptions of the rooms so players are be able to easily identify their position and where they need to go.


  • The circle animation is related to the current location of Subject W in the facility. 
  • Unclosed walls mean that the area is bigger than a single square / room.
  • Green rooms are gardens to save the progress and charge the character’s life and energy.
  • Dotted lines mean shortcut, so when you exit a room in the direction of one of these you’ll appear in the room connected to the other side of the dotted line.
  • Straight lines represent a shortcut between elevator stages.
  • Orange background = room temporarily disabled due to story events.
  • Red squares between two stages means that you didn’t access the adjacent area to a visited room (either because you don’t have the necessary skill to unlock that door or a story event didn't unfold yet).

Some game maps like the one from Metroid choose to represent the next objective of the game. Instead of that, we decided that the player will need to explore the facility searching those red locks and identifying the kind of skill or puzzle that needs to be resolved to advance in the adventure.

The technical development of the map

To avoid having to create maps by hand or editing the map every time a room has been moved or deleted on the Level Editor we planned a map generator, its function is to read the state of the Level Editor and create a serialized file that will be read by the game when starting a new game.

The algorithm is pretty simple, in theory, it just reads every room on the scene and draws the room according to its doors and exits, the main problem was that “door” is kind of an abstract concept on PLFC, there are physical doors, ventilation doors, spaces that serve as doors, and on top of that physical doors can be closed and conducts as well but they don’t have to be closed per se, an object could be there blocking your way into the room or other external hazards might be in front of these exits. All of this had to be represented on the map, and to add insult to injury the rooms can change during gameplay and the map has to respond accordingly.

With all of this in mind and to have the map running we needed to first implement and improve our persistence management and modify the way certain bits of information about the doors are saved. Right now we still need to finish some aspects of the map but above you can see that it’s already running.

Elevator rooms

Elevators are a key feature of the level design, and were one of the main tasks that needed to be finished in order to have all the different kind of rooms represented in the map.

At the beginning we only used the cargo bays as vertical connections between floors, but now we added more variety, designing different transportation elements that fit better depending on its surroundings. It also gives us the possibility to include wider vertical rooms with more than two access and create an expanding set of situations with the enemies.

This elements are classified depending on its use and location inside a stage, and are represented as follow:



Moving platforms on which we can walk normally and interact with the elements inside them, like characters or objects, hideouts and more. They connect storage areas and research departments with different aesthetics or gameplay purposes (think of them as the CD corridors of Castlevania SOTN).



The main elevators are inside the corridors that connect the laboratories of each floor. Every corridor with an elevator has a glass panel that represent the part of the facility connected to the current area and its position on the map. The visited areas are already represented on the player’s UI, but in this corridors you can have an idea of the levels that you haven’t visited yet.

This rooms can have enemies patrolling the area or traps, so you must keep an eye on these to avoid getting caught before the elevator arrives.

Stage lifts


These kinematic platforms connect different floors inside a single room. To go unnoticed the player must be aware of the enemy routines on each floor. They have an open structure, so players can jump out of them if they want or need to.

Small additions

In our classic habit of “we can’t stop adding stuff” here are new things that we included heading the alpha demo:

Bins as hideouts


Lots of corridors have vending machines with bins by its side, but they weren’t planned as hideouts. The mid-hideout behaviour was already made, so we designed bigger bins with a garbage-falling animation when W interacts with them.

Corridors facelift

Corridors are a constant in the facility, and the ones that we have from the beginning presented an excessive blue saturation with a boring industrial look (plus the plant didn’t stand out too much on them).


Now they show a lighter palette and a warmer color curve that match with the different aesthetics and adds a unique look too. The orange stripes and details represent the corporate identity of G.E.R. and the new lettering highlight the type of rooms adjacent to the corridor.

Background details


To add more variety to the rooms we designed different drawings for the whiteboards that vary from one research zone to another. This ones are from the engineering and technology area. Some of them show the barely erased schemes made before the current drawing, adding a little bit of realism.



Now, models of the current G.E.R. projects and schemes of the robots that we can see working on the facility are hanged by some of the walls.

Representation of skill use in the HUD


We came up with the idea of showing the time use of a skill inside the HUD’s circle instead of a bar above the character. Now we can have a clearer view of the time left for the ability to end, avoiding to put extra elements that intercede with the game’s world.

Changes concerning the current cutscene editor

As we told you in the previous update, we realized that making the cutscenes with our current scene editor is a big pain in the @$$ (can’t control the timeline while previewing the scene in real time) so we are deciding to either readapt our current editor to include more practical tools or change it and port a bit of the code to another one that is more 2D friendly. As of now we were extra busy importing assets and finishing the main editor, so this will delay the alpha demo for a bit :(

We wanted to openly expose this problem because working twice in some of the scenes (so you can have a demo ASAP) and then readapt or fully re-do them on the new system will be a considerable lost of time in the foreseeable future. We’ll keep you informed about any progress on this matter (and more things to come).

As always, thanks for your constant support and understanding ;)

PS: Starr Mazer DSP


Our fellow devs at Imagos Softworks and Playism just launched Starr Mazer: DSP on Steam Early Access, a SHUMP roguelike prequel to the main Starr Mazer adventure. It’s looking great so you’ll probably want to check it out.


As some of you might recall we’ll be doing a crossover with them. Can’t wait to see Subject W running around a point-and-click SHUMP adventure!

See you in the next update!

Boss design, improved interfaces, animation videos and more


First of all, our humble apologies for not doing an update last month, we’ve been working full speed to finish some key elements and give you an alpha ASAP. Henceforth we’ll need to be extra focused to try and fulfill milestones, so if an update takes more than one month to be posted don’t freak out (at least we’ll keep the current pace to show relevant progress concerning the development).

As of late lot of things have been fixed and polished, but mainly we were working on AI behaviors for bosses and designed new animations for cutscenes (something that takes a lot of time but is essential to tell the story the way we wanted to). Hope you find interesting some of the stuff that we bring you here and, maybe, be useful to other devs that came after us ;)

Enhanced behaviors

Although we have the standard mechanics closed and running we polished a little bit their performance, adding more realism to certain situations and giving another layer of interaction between the NPCs and Subject W.

Damage during states

Subject W was the first character created for the game (in fact it was the first thing we did) and because of that some things were deemed as not possible at the time or we didn’t think about implementing them.

One of those things was not receiving damage during certain states, like climbing, descending or getting up, out of fear of breaking Subject W and not being able to know its real position as most of these actions are only animations and the player only moves after the last frame. But this gave too much power to the player in determined occasions, so it was necessary to change it.

The solution lay in the helper collider that all characters have and serves to delimit their sprites. Thanks to this collider the enemies can now detect Subject W while doing those actions and we can reposition the player to the center of the collider.

Enemies turning

Managing characters turning around in 2D can be a pain, every character except Subject W needs a turning animation to look smooth an realistic. For example while the entity is reproducing the animation it isn’t really turning, we turn the entity by changing his local scale just after the animation is finished.

This meant that if the enemy is turning to face you it won’t see you until the animation is done, or the other way around, the enemy is turning and already on the last frames of the animation facing the other way and you appear behind him making him react in the opposite direction he seemed to be facing.

We didn’t like the results so we reprogrammed the turning behaviours to check the time of the animations.

Now if the character's eyes (and only the eyes) turn around before the rest of the body and the character sees something and has to react to it, the rest of the body will follow and turn around when exiting the behaviour.

Patrol Component

Patrol Component manage patrols for characters, the component stores the points of the patrol and gives the next point to go to, but it was too simple it only stored two points and there wasn’t much room for improvement.

The new Patrol Component manages an unspecified amount of points that are passed as a sequence, making patrols much more interesting, and gives the next point in the sequence unless certain conditions are met.

Now you’ll see enemies with routines that are not so easy to follow (though enemies following only two points are still a thing, specially at the beginning of the game).

Designing a Boss

With most of the enemy behaviors already designed we were able to start developing of the final bosses of Paradise Lost (an important pillar of the game). Designing these characters is no easy task because their actions and routines differ from the ones of the regular enemies, leading to ad-hoc mechanics that need tons of planning and testing. One of the things that we learned through the boss-building process was the need of reorganizing new ideas and adapt them to already established mechanics (as far as possible), finding the biggest amount of variations that a single design can provide to future routines without falling into repetition. The first boss, Irvine, was the keystone to develop the rest of final enemies that we’ll face on Paradise Lost.

Making Irvine

Irvine was not a complicated character in terms of coding behaviours, maybe because we are already used to making complicated patterns for the common enemies, but nonetheless it presented some challenges.

Irvine’s grenade belt

Irvine carries with him a belt full of grenades, obviously he plans on using them, possibly killing you in the process. The grenades were difficult to make, they consist of a dynamic collider, one that it’s affected by physics, a sprite, rotating thanks to Pixel Art Rotation (self-promotion (⁄ ⁄•⁄ω⁄•⁄ ⁄)), and a particle system for recreating the gas that we’ve showed you on the previous update.

The first problem is very obvious, synchronizing those three elements and obtain a realistic effects.To do so the rotation of the sprite needs to be synched with the rotation of the real physical object, and then the particle system has to fire at the right moment and react to the movement of the grenade, which thankfully is an option inside the Unity editor. 

Progressive damage

The gas of the grenade causes damage over time to Subject W, that means that while Subject W is inside the area of effect it will receive damage, and we wanted to change how the damage over time worked, as it was already implemented for the gas of the guard’s grenade.

Basically if you’re inside the area your life will go down and as soon as you move away your hit points will regenerate until they fill the current hit point. 

Laser sight

Considering that Irvine is a sniper we wanted to emphasize his use of a long-range weapon. At first we tried to make a laser sight with a straight red line, but it wasn’t working, the line didn't rotate in sync with the rifle and the results were awful (plus the red line crossing the entire room was very annoying) so we decided to put a small red line with a circle at the end, appearing on top of the player to simulate the laser sight.

Dialogues for animations

In another update we talked about subtitles for the cinematics, and we wanted Irvine to talk on certain routines. This was already possible, you could start a dialogue at any time and set its speed, but we wanted to control the pace even more, reading lines at the same moment the character is doing certain actions.

We solved this by assigning an ID to every line on the XML we use to store the dialogue, then instead of reading the whole dialogue we open the reader and fade to the name of the current speaker, read the ID, or IDs, we need, changing the duration for each line if necessary and then closing the reader and fading out the text from the screen.

New HUD elements and User Interface prompts

Little news in this front. The designs showed in the GUI elements update remain intact but we added a few usability improvements:

Skill name

Some of you told us that the skill name must be shown when you expand the skill menu and not only when the ability is selected, so you can identify faster the one that is active inside the circle.

This is the old functionality. As you can see the name is highlighted only when the ability has been chosen.

The problem that we faced adding the skill’s name was its position on the bar. More leafs will be generated so putting the text to their right will look completely out of context. The remaining option was to put the skill name below the HUD circle, tinted with a color in the range of the glowing skill to represent the highlighted ability.

To obtain an aligned composition of all this elements, we applied a vertical pattern with the same size of the circle, maintaining an equidistant space between elements. Now this is how it looks when you choose a skill:

Damage stroke

When Subject W loses a VP point an outline appears in front of the HUD’s leaf, enhancing the damage effect. It’s not a game changer but helps to spot the lost VP easily.

Noise wave

Testing the game we realised that if you are not hearing the game or can’t/won’t play with a controller it could be difficult to state when are you making noises, and it’s crucial for the player to have at least a visual clue pointing out that you can be spotted by enemies.

Because of this we added a wave that expands from the HUD’s origin any time we are generating a disturbing noise.

This GUI element can help players with auditive problems, making the game understandable without sound. This kind of enhancements make the game accessible for a wider audience and allow people with disabilities to enjoy the game experience too.

Interaction markers

The interactive prompts shown when Subject W approaches an object were already made, but we decided to improve them by adding a circle to the (A) key and displacing it below the plant (or above if you're inside a vent).

Previous design problems

With this change we can follow a standard for the majority of situations, avoiding maladjustments and visual conflicts like having the button too far from the character when it’s crouched or inside the aforementioned vent, overlapping the graphic with the player or simply because it doesn’t stand out above the background.

In addition, when you reach an object that can be used but you are not on it’s level of interaction (like a trapdoor) the prompt will appear with an alpha blend, going full color when you are at the same level.

Previously we automatically forced the player to a crouch or idle stand to interact with the object regardless of it’s previous position, so the state of the plant didn’t matter at all. Now the transition between a crouch and idle state is more relevant and players will need to plan carefully their strategy to proceed through a room, identifying which objects are interactive at their level.

Quick note about prompts: we know that some of you don’t like helpers at all, but keep in mind that you will be able to disable them in the options menu.

In-game timers

In the first prototypes of Paradise Lost the Time Attack situations displayed the time left to escape from/resolve a situation with a vector text in front of all the graphic elements.

During the development we decided to avoid extra GUI elements aside the HUD and interactive prompts and subs, so following this decision we readapted this situations to integrate specific counters inside monitors, screens and info panels distributed around the rooms.

Animating Pixelated fonts

To show theses timers and clues at pixel art level we needed to create handmade fonts that could be easy to implement and change if needed.

We soon realized that we couldn’t create easily a vector font with the style needed so every letter had to be its own sprite. A dictionary store the different connections between text characters and those sprites so we could write whatever we wanted instead of putting each message by hand.

Enhanced animations and new designs

Some of you might be worried each time we talk about changes in animations but keep calm, most of them were slightly changed to have a detailed explanation on a scene or to give extra tips about a playable situation :)

Escaping from the jar

In other updates we shown the new container where Subject W has been held. We came a long way since the first concept, and now the jar is bigger allowing us to represent a clearer and more detailed breakout.


Following the design rules that we talked about in the timers and fonts section, Now the countdown for the first Time Attack is represented on Subject W’s status monitor. We applied our new font hierarchy for different sizes and redesigned the interface to avoid the confusing graphics of the old screen.

Scientific studies

One of the main scenes of the first chapter is focused on the analysis of W’s camouflage ability, with an in-depth conversation that explains how the refraction of light and chromatophore cells worked on authentic species. These are some frames of the info that will be displayed during the dialogue.

Proceed with caution

The mines have been improved with a new laser stroke that prevents players to jump above them.

Some of the mines can be deactivated, so you must calculate the exact moment to disarm it and pass through.

Step by step animations

Now that we jumped right into the assembly of scenes, some new animations for key characters needed to be made. We took this opportunity to record some videos of the process so you can see how we work with Aseprite. They take some time but you can switch to high speed in the Youtube video options.

Subject W breaks glass:



Ash stoops looking at the background:




Ash gives orders to capture W:




An angry Ash stomps:




Ash refuses help:



Ash angry to idle transition:




Acid leaning on desk, doubting:



Acid denying with the head:



 Electro with crossed arms exposes his point of view:



 Electro turns head when someone leaves the room:



Irvine receives a call on his earpiece:



Ok, everything is cool but where am I going to play the game?

As of late some of you commented on the KS posts and sent us messages asking for a release window. We’re not going to lie, the game is taking more than expected and it’s far from done. It could take this year and a little more to have it (partly for the scope and ambition of the project and also because we had to face huge problems that appeared through development). That's without counting the redo of code from scratch a year and half ago.

Sometimes it’s really frustrating because we are working so damn hard to give you the experience you backed for, but is taking too long to deliver that we feel the let down in some of you. We don’t want to be the next failed KS project and, as long as we can survive with what we have, we’ll strive to make this game. Hopefully it comes out as good as we had envisioned 3 years ago (how time flies!) and you’ll be able to forgive us for all the troubles and delays.

Demo Most of the things that you can see on this update will be included in the alpha that we’ll send to all the Kickstarter backers. I don’t want to get my fingers burnt on this issue with a date, but we plan to make an update with it this summer. Before the alpha release we’ll probably change from our current cutscene editor to a new one that is optimized for 2D animations and real-time preview (this is a key factor that could help us save hundreds of hours of work and gain more precision when building new scenes). In the short term it may take some time -readapting certain parts of code to it- but If everything works fine it could be a big step forward (in any case, if we experienced problems porting our content after a while we’ll return to the old editor).

Thanks in advance for your support,