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


3b76351f96a51c23d38d07c5799f21e0 original
D1de468ddd295464efb30764105be359 original
Dc96413b5f4d0f40b617873d7763d976 original
4624f0dc6660765a7a76f499f2885f84 original
655e1e264a61313806affe2cdf83f6d0 original
A86629b0d6d0955b730cefb83989c18c original
8abe61b060f13ddaf58493fa6f85e516 original
34309e6390c9a35991b5f36de676768d original
211a0fb811555032885253f2cc9f482f original
E357fec014327d80fc636fd1ab9c263a original
33f1fd84394403aace0976381ffb02ac original
Cedb392d07503af1cdf9d79ad25d3043 original

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,


Color enhancement, particles and shaky cams


Hello everyone! We are here another month to show you how things are going in the studio. We spend some time working on the use and application of colors, tints and shades for the characters and scenarios, trying to approach the original concepts made outside Unity. We’ve been experimenting with particle systems too and worked in other technical issues like improving the loading times between stages. Want to take a look?

Level color grading

Since the beginning we wanted to design the different elements that shape the game (scenarios, objects, lighting effects, characters) without color restrictions, avoiding the 8/16-bit retro palettes characteristic of the pixel-art aesthetic.

Certain materials like metal or cardboard use a consistent color pattern on different objects, but our priority was to create every element with its own tones and shades. Although this is not a problem in itself, it is true that all these graphics can be dissonant with each other as they are not affected by the global lighting and refraction of color of the different stages and elements (such as tinted bulbs/glasses, fire, water…). In order to unify the hue range without losing their original colors we applied tonal curves and adjustment layers previously generated in a raster graphics editor.

To import these adjustments on Unity we use an asset called Amplify Color that helps to blend the tones of the scene and obtain an homogenous look for each stage. This extension is really easy to use, the only thing you have to do is generate the hue/saturation/color curve you want in Photoshop and link the image generated with Unity. The results are astounding and it doesn’t even affect the game in terms of performance.

Here are some examples of color grading. As you can see the colors stand out and the color curves manage to give a cohesive look to the different entities that conform the scene.

Color blending options

Leaving the level color grading aside, we needed to develop ad hoc shaders to tint certain zones of the scenarios and objects/characters depending on specific situations. The question is: Why don’t you apply the color grading asset on individual elements? The answer is simple: unfortunately, Amplify Color doesn’t apply this effects to isolated sprites. The extension picks the original adjustments made outside Unity and adds them to the whole scene (in brief: to the game camera), so we can’t obtain adjustment effects on determined spots/elements.

To this effect we managed to integrate Color Fx shaders that are similar to the layer blending options of raster programs like Photoshop or Gimp, considering that we can’t accurately reproduce adjustment effects such as curves or color balance to individual sprites.

On this example you can see the steps made to change the overall lighting of a scene. Each element has a specific shader with a blending mode. The curve adjustment is the last one applied and affects the whole group of layers behind.

The math behind the blend modes

We implemented various typical shaders to apply individually or as layers, this way we can recreate some effects otherwise impossible for us.

Additive: an additive shader does what the name implies, it adds the color passed through, or the color of the layer, to the original color.

If "o" is the original pixel and "c" is the color you’re applying the function will look like this:

f(o,c) = (o.rgb + c.rgb) * o.alpha

Multiply: multiplies the color passed or the one from the layer to the original color:

f(o,c) = (o.rgb * c.rgb) * o.alpha

Tint: this one is more complex, we convert the RGB components of the original color and the color being applied into HSV, then we calculate the resultant RGB like this:

cHSV.brightness = oHSV.brightness * brightnessProperty cHSV.saturation = saturationProperty

o.rgb = ConvertToRGB(cHSV) * blend + o.rgb * (1 - blend)

Where oHSV and cHSV are the original and new color RGB componentes converted to HSV, brightnessProperty and saturationProperty are variables to determine Brightness and Saturation respectively, and blend is a variable between 0 (none) and 1 (full) to control color blending.

Creating contrast and depth

Throughout the development we noted that in some areas like the laboratories wich have a big set of on screen elements -such as servers, research equipment, tables, monitors and more- were difficult to differentiate the characters from the environment. Also, interactive objects didn’t stand out from decorative ones. To solve this problem we added a gradient shadow in some stages between the interactive and decorative layers. Now players will be able to spot platforms, scalable objects, buttons and hideouts more easily.

Pixel particles

A lot of Paradise Lost elements are volumetric shapes like smoke, fire, water, electricity sparks... When we started the project those effects were made with traditional animation. Seeing the amount of work needed to obtain realistic effects, Carlos proposed to create a particle system that allow us to include particles with a pixel art look, adding dynamic behaviours to this elements and saving development time. This is an example of the particle system added for effects like energy flakes or smoke.

To obtain a pixel art look we imported pixel sprite particles of different shapes, showing jagged columns that follow the same aesthetic of the game. The different parameters allow us to change the density and frequency of the particles emitted by the different objects.

This is a sample of the dynamic particle behavior, attached to a thrown gas bomb:

Shake it

As of late we felt that the damage perceived by Subject W wasn’t too obvious (with tons of elements on screen and a discrete HUD this was a problem in some circumstances), so we worked on a system to show the impacts in a more clearer way. Most games add a tint effect in the borders of the screen, but it looked too annoying and overlapped, so we decided to include a little shake to the cam. We don’t want a dizzy/blurred effect so we added a controller on the editor to regulate the effect if needed.


The issue with loading times was clear since the demo, they were too long for being as frequent as they are. So Carlos tried to find the reasons behind the lenght of the loading screens and how to solve them. The solution was pretty obvious and one of those things that ended up being far more simple than expected.

When the game enters in a loading screen, the screen fades to black, then loads the room, then the audio switches if necessary and lastly the screen fades again to the game. The problem lies in the amount of time spent on fading the screen and switching the audio, it was too long, and it was something we put there, we set the speed for the fading and the switching, so when pumped up the loading screens were cut in more than half the time, leaving the loading almost instant.

We think it’s possible to shorten the time even more with a few tricks Carlos has in mind, is something that we’ll address ASAP.

And that’s all for this month! We’ll keep you updated with more progress in the near future. In the meantime don’t forget to enjoy the wonderful Hyper Light Drifter, one of the big indies out there.

PS: for those who played the game... have you found Subject W already? (・∀・)

Cutscenes, subs and... stairs


Two months of madness

Hi everyone! we were busy as hell since the last update, focused on solving different tech issues and including key features to advance in the game development.

This update will be less “flashy” than others because some things related with animations and designs enter the spoiler terrain. Either way we made some improvements that Carlos will summarize, explaining what’s been done in the coding department during this time. Mainly we’ve made progress in the cutscenes area, which are a key to achieve our vision of Paradise Lost, and we’ve also hit a very hard wall with something that didn’t look that difficult to begin with, stairs. Here we go.

Importing sprites

Until now every sprite we made I imported into Unity manually, I grew tired of this so I made a tool to import these sprites, saving us a lot of time in the process. The importer is very simple and ad hoc, we pass the importer a folder and all the sprites inside this folder are named so the tool knows everything needed to cut them into the correct number of frames, the width and height of these frames is also set on the name. For example the file fall_9_10x10 would be imported as a sprite named fall, cut it into nine frames of ten by ten, but a file named recovery would be imported as a single sprite with that name.

 Additional options let us import the sprites as Advanced Textures and set a Packing Tag shared by all the sprites inside the folder.

Cutscenes and subtitles

In February we bought Cinema Director from the Unity Asset Store, a tool to make cutscenes inside Unity using timelines and actions, with the ability to preview the cutscene outside play mode. At first this sounded amazing, but the asset was made with 3D in mind and 2D was not supported. Thankfully the asset came with the source code, so the first week was spent learning the asset and customizing it for our project, with pretty good results.

The most important changes made to the asset were the inclusion of a MoveTo action to the timeline, which lets us move any 2D entity using our previously built movement components, and the Subtitles action, which writes subtitles on the screen using our DialogueManager. Also MoveTo gives us a good estimation of the time that’s gonna take the entity to reach the set position, even on preview mode, which makes life so much easier.

To give you an idea of what we would be doing to move a character without the addition of the custom MoveTo action, we would have to add an Animation track to animate the entity, an Audio track for the steps, having to synchronize the sound with the animation with the same precision as the code does, and a Translation track to actually move the entity.

How to move a character inside cutscenes with the original asset. As you can see there are too many steps to make a simple cutscene and a velocity curve is needed to reproduce the character’s movement, which is bothersome and not very precise.


How to move a character inside cutscenes with our customized actions. With a pair of clicks the character is moving with the same pace and motions as in-game.


About the subtitles, we wanted to add ones similar to what you can see in the trailer, with only minor changes to improve them, this was easier than expected and now we have a DialogueManager, and the previously mentioned custom action inside Cinema Director to add subtitles to the timeline. Its functionality is very straightforward, first we create an XML with the actors and the lines they say, then we can either run the subtitles by code or setting a new action inside Cinema Director, always specifying duration and the XML path.

On this example both dialogue animations have the same length but the second one needs to show more words. The DialogueManager will write the subtitles at the right speed given a certain duration -we tied speed to duration to properly synchronize dialogue with animations-.

This enhancements give us the possibility to portray a more cinematic look to the scenes, pairing the texts with the length of each animation and avoiding the classic dialogue-skip scheme with breaks, typical of this kind of games.

Stairway to hell

If someone asked me what I thought was going to be really difficult to code, I would never have said slopes. Probably some of you remember the designs made by Enol and posted in the update #32. He designed a stair system based in Subject W’s pivot (wich is wider than the human one) and added perspective to them, giving the feeling of depth necessary to avoid the character standing in the air.

I’ve spent a great part of the last month trying to make them work, and they’re still a little bit clunky. The problem was that the player, Subject W, it’s a not kinematic entity and responds to real physics, this combined with very steep stairs and all the code behind which makes the player move, jump, land properly, pass through platforms and so on, made what looked like a simple task into a nightmare.

It’s not the first time we’ve had problems because something done months ago doesn’t work with something that you never thought would cause issues, these things happen sometimes, but this time we made a really big mistake regarding planification. Whenever I’m working on a certain mechanic or system for the game I try to design it with every feature in mind, and I don’t start another task unless it’s finished. But I didn’t realized we were adding slopes when I made the movement components.

Certain aspects of the movement and the numerous possible collisions needed to be changed to work with slopes because they are a very particular case.

The math behind the slopes is, in theory, simple enough to implement. This first image shows the forces that are applied to Subject W at any moment, obviously if not moving or jumping its velocity is gonna be zero.

 With this information we can deduce that to counteract the gravity the terrain needs to apply a certain friction to the velocity on x of Subject W. This friction is also modified by the normal of the slope in relation to Subject W, because a slope rotated 45 degrees is not the same as one rotated 10 degrees, which is much easier to climb.

In the end the velocity on x for Subject W while on a slope at any given time is:

velocity.x = velocity.x - (hit.normal.x * friction)

And this is the final look of the colliders applied to the stairs:

This wasn’t the only issue to tackle, we also faced the need to design the input around this element, one easy to understand for the player. So far this is the solution that we came up with:

If you walk straight Subject W will obviate the stairs, passing through them.


If you jump in front of a stair flight Subject W will land on it.


Walking, crouching, running and jumping work the same way as they do on the ground.


If you move towards the bottom of the flight floor level the character will continue moving on the ground.


If you stay in a half space landing and want to go up you’ll have to jump.


If you stay in a half space landing and want to go down you simply move the character in that direction.


You can also get down of a stair flight by pressing down+jump.


This is the best system we came up with, considering the character movement and the gameplay mechanics already designed and used. We’ve eluded the use of diagonals because they do certain movements in Paradise Lost (if you press down+left Subject W will dock, and adding a new/different feature only for the stairs will be confusing for the player). We are considering to add visual prompts to help players notice the actions that they can make in certain spots of the stairs, but they’ll probably obstruct the designs and look a little bit overloaded. In any case your opinions are more than welcome :)

As you can see development issues can appear anytime, and with a complex game like this with tons of features that involve specific game mechanics is easy to overlook stuff or fall into something that you thought will be made in no time.

In any case we hope that you liked the update and also be of interest to other developers that are having similar issues with their projects. We also appreciate all your comments and opinions on these news.Till the next one!

GUI elements and progress


Here we are with the first 2016 dev report. We practically spend the entire month fixing issues and working on new designs. In gameplay terms, some things were slightly changed -now that we can play with fully-implemented mechanics-, balancing skills, movement sets and behaviors of both Subject W and the enemies.

Besides the tech issues, we wanted to share some designs choices for the GUI, seeing that some of you are curious about the kind of graphics that we use to represent key elements such as the HUD, the skill tree, prompts, etc. Let’s take a look at them and don’t forget to share your opinion, ideas or concerns in the comments, we always listen and learn from all of them :)

Defining an art style

As some of you might recall, we stated from the beginning that User Interface graphics were going to be vector based instead of Pixel Art. We took this decision to have a particular style and create a visual contrast between the game world and the player “tools”.

Our original idea was to conceive a minimalistic design scheme, based on the use of lines and curved forms that resemble organic paths from the nature such as roots, midribs and plant veins.

 HUD design

show Health Points (HP), Energy Points (EP) and the currently selected skill. The HP and EP are represented by the upper and lower leafs respectively. This elements have been changed over time as we experienced different playable situations, trying to find one that was both simple and intuitive.

In the first concepts you can see that the HUD was based on the use of bars. The problem of this kind of HUD is that you need to make a bigger/intrusive design in order to see your status. We wanted to have a simple yet functional game element so we decided that a point system will fit better and give players the possibility to identify the damage inflicted by different enemies/situations and create their own strategies in advance.

For example, if I know that a certain enemy’s attack take away 2 HP, I can put the SHELL skill, exchange HP for EP and avoid being killed.

New skill selection

We showed you in earlier updates the skills wheel that allows Subject W to freeze time and select a certain ability to use. Unfortunately we experienced some functionality problems with this GUI element:

As you can see, the wheel gets cut at the ends of the stages and overlaps with the HUD when the character is inside vents or high grounds.

We came up with this solution, integrating the selection panel into the main HUD and showing the skills available right below the current ability (avoiding overlapping problems with other gameplay elements). Also, when the player is in this mode, the enemies are highlighted so you know their position in advance and determine which ability is better for each situation. It’s still a work in progress, but it will probably remain like this in the final version. Anyway your ideas are welcome too  :)

Skill tree

Players will be able to enhance their abilities thanks to the skill points collected along the getaway. For this feature we designed a tree that reflects the evolution of each skill.

The original concept shows how we visualized the different ramifications emanating from Subject W’s roots. In further versions we’ve simplified the skill tree, coming up with a clearer/understandable version.

In the center of the tree will appear the skill points collected to spend on an already acquired ability. Around the central seed you can see the skills with their ramifications and the leafs that represent the LVL of each ability. The skill points used are shown under the leafs. An info box is displayed at the bottom of the tree, where players can see the action assigned to that level and decide whether to spend points on it or not.

Interaction markers

Some of you are concerned about the inclusion of pop ups and pointers to show interactive areas. First of all, for those that want to have a more hardcore experience, we're going to add an option asking (at the beginning the game) if the player wants visual helpers along the game -If you regret this decision you can change it again inside the game options menu-.
With that said, we designed markers to show interactive objects when Subject W is near them. A button marker has been added above the plant's idle position even if the object is below the plant height, avoiding graphic overlapping of the character with the button. Here are some examples:

I hope that you liked the result  :)
Now I'll leave you with Carlos that will get into detail about gameplay-programming issues.

Demo aftermath

After finishing an stable demo a lot of features were added but were left unpolished, so our priority was to fix all these things before start making progress on other areas. Since then we’ve fixed a lot of problems and I’m going to talk about a few of these, which I think are the most interesting ones.

Fixing broken things


While building the demo we noticed that SubjectW falling from big heights looked really jerky. To fix this we tried changing the animation first, but it didn’t work. Anyway we left the new animation in there because it looked way better.

After this I changed a little bit the camera, thinking that maybe its movement produced the effect, but that didn’t work either.

After wasting a lot of time I finally found the solution, apparently we needed to tweak an option in the Rigidbody2D component called Interpolate, this option when set to Interpolate calculates the next position of the entity based on the current position, making the motion smoother. When we started the game we set this option to None because it interfered with walking and running, so now the option sets itself to Interpolate when jumping or falling.

Passing through doors

In order to detect the ground and other accidents in the scenery we attached a bunch of GameObjects as children to SubjectW, those GameObjects act as key points for those calculations.

While passing through doors these GameObjects ended up in wrong positions, which caused several problems, like clipping through the floor, and eventually made the game unplayable.

Turns out the problem originated from moving these GameObjects in different animations, a method we avoid as much as we can because it’s a pain to maintain. Deactivating SubjectW mid-animation, to reset parameters and set him on the next room, caused the movement in these animations to stop working and retain the last position they had before deactivating the entity.

Now every time a room is loaded SubjectW is moved to a limbo platform where all the proper parameters are reset and then it’s placed in the new room. This may change in the future if I find a better solution.


When SubjectW fell into the ground it used to run an animation for recovering, while this animation was running you couldn’t move at all. After the demo it was clear that, while it was a nice touch, stopping the player completely for such a long time wasn’t a good idea.

Stopping recovery

Recovery while moving

So now we allow the player to move through the recovering, though movement is still halted for a few frames at the beginning to give some weight to the falling and make it more realistic. We also changed the animation, to reflect the ability to move when landing.

The amazing world of cameras in 2D

When talking about side-scrolling 2D games you don’t hear much about cameras and how are they built, at first it seems simple enough, you smooth out the movement of the camera as much as you can and make it follow every single move of the main character until you need the camera to change its location for a cutscene or something similar.

But, like a lot of aspects in game development, the camera is much more complicated than I thought, “smooth and follow” certainly didn’t work for us at the beginning.

To give you a basic idea, these were the obstacles we faced:

  • SubjectW seems to be moving or static for a lot of animations, but in reality it’s the other way around, which caused the camera to be static or moving when you don’t want it.
  • Moving platforms messed with the camera if playing one of the previous animations as well, causing some movements that felt weird and could cause motion sickness. 
  • Moving the camera every single pixel that SubjectW has moved caused small jumps and made the camera stutter too much.

I started searching for proper solutions and to see how other game developers did the cameras on their own games and then I found this video, which saved my life and I strongly recommend if you wanna tackle this issue on your own:

So how do we fixed it?

For the problematic animations I had to do two things. For most of these animations I made the camera follow a secondary collider attached to SubjectW, which is a box collider that fits itself to the shape of the sprite, not counting completely transparent pixels. The rest of these animations needed a helper to take the place of SubjectW when I wanted the camera to stay in one position.

For the stuttering of the camera I made a window of movement, SubjectW must be a predetermined number of pixels away from the center of the camera for the camera to start moving, this way if SubjectW has moved only one or two pixels the camera won’t follow.

As for the moving platforms, they seemed to solve themselves after the previous solutions, so that’s nice for once.


Well, those were some of the things that we've been working on since the last update. Keep tuned for more and don't forget to comment. Bye!