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 ;)
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.
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 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.
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.
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.
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:
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:
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.
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.
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 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.
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,