Share this project

Done

Share this project

Done
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

Photos

E9abff3e8dd59eb31018ba085412630f original
7af2f8a9a52d3a90193003977717eaee original
Fa9401251c773cbd4bbd71f85e99da5c original
820e7b109bf9a67d2f10f8b48460cc8c original
31c4d954c80f73c7702dd4345e8404d8 original
9ec7d0522ba9e31e85dfe7bf9610e446 original
7e92e613fad97fb50f7cb1204d3d5a3b original
86476b4bae650ee3422a533eee6e7c56 original
C570b1757b634c166bd90ba7a54f14aa original
39e75b13a08120be23081dd8e69d01c9 original
39e75b13a08120be23081dd8e69d01c9 original
39e75b13a08120be23081dd8e69d01c9 original

Color enhancement, particles and shaky cams

53 likes

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.

Loading

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

43 likes

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.

Subs

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

70 likes

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

Falling

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.

Recovering

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: http://gdcvault.com/play/1022243/Scroll-Back-The-Theory-and

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!

Pre-alpha footage and tech issues

62 likes

Well it took us a little more than expected to make a proper gameplay presentation, but it's finally here:

_

We wanted to show you a sample as close as possible to the final version of PLFC, and for this we had to include elements that we planned to address later like the transition between stages or the inclusion of sound elements.

Graphic issues

You will probably spot some misalignment with the camera or graphic errors like half-pixel lines next to characters and objects, the half-pixel line is a known error and we’re searching for a solution right now.

As you can see, there are only 2 type of characters with no diversity. We already made the rest of skins (as stated in a previous update) but we are working on a system to integrate the sprite sheet of each skin automatically. This system is not yet implemented, but goes along the lines of using the AnimatorOverrideController component to modify the animations given by a mecanim instance.

Another pending task is the use of shaders to tint characters and blend their tones with the backgrounds and the rest of elements. As simple as it sounds the use of curves and visual fx consume resources, and we need to find their correct application.

In addition to this, user interface elements will be added in the next version. When the player walks near an interactive object a pop-up will appear, making easier to recognize interactive object like levers, hideouts, etc.

Many of you have asked for a more technical update, focused on the coding issues of the game, so I’ll let Carlos do the rest. Also, this won’t be a one time thing, you can expect a technical section on following updates.

Building the demo

Hi everyone, I’m Carlos, programmer of Paradise Lost: First Contact, I know it’s been awhile since the last update but we’ve been hard at work to bring you a very exciting one.

On November we decided to build a demo, one large enough so you could see the things we have already done or are almost finished in the game. Unfortunately this build is still too unstable for release, so apart from the video I’ll talk a little bit about how we built this first preview, and maybe get a little technical as you have asked many times before. 

Entities: characters and objects

As you know we’re building this game in Unity and we’re using the Entity-Component design pattern to build the code, because Unity is basically a huge Entity-Component pattern itself, if that makes any sense.

All the characters and objects that are interactive in the game or that posses any logic that reacts to your input or simply are running on the background are classified as entities.

Theses entities are usually built with one main script, which for example in the case of our protagonist Subject W is named SubjectW, this main script usually gives each entity specific logic that only belongs to it. Apart from this script we have several other scripts that are called components, these could be very important aspects of the entity like a movement component or a vision component, and gives the entity different abilities.

 With this pattern it’s easier to build different entities with a few reusable scripts, though many times making these work together has proven trickier than expected.

As I told you before all entities usually have a main script, well both Subject W and the enemies are considered Actors, a subtype of Entity, which are entities with a Finite State Machine (FSM from now on) that in the case of Subject W controls some behaviours and in the case of the enemies is basically the AI. This means that an Actor is very much like a really complicated entity, it needs a main script and a FSM, which is divided in a class that defines the FSM and another class that manage transitions. The main script for these Actors is also divided between the real main script and a script to handle the information received by components related to senses, like vision and hearing, this division was only made to keep things tidy and neat into small classes.

Apart from this all the behaviours used by the Actors are separated objects that run a particular piece of code, of these behaviours only a few of them could be reused on every type of Actor.

I hope this gives you a good idea of the amount of work creating one entity involves. And the more clever this entity is, the larger amount of time needed to complete it.

Now I’ll cover different entities that I consider to be interesting, some of them you may have already seen on previous updates.

Subject W

Subject W hasn’t changed much for this demo, almost everything you see on the video was already done months ago. Basically we have added a few animations, sounds and behaviours, that are not that big to mention.

Enemies: Guards and Scientists

Guards and scientists proved to be more complicated than we initially thought, the amount of interactions of these enemies with the objects and characters that surround them is huge, this interactions result on what we think are very intelligent enemies, but it also means that for every new situation or object added to the game new problems could arise with them if I’m not careful enough.

For this demo though only the scientists gave us problems, they were not as thoroughly tested as the guards were so they needed a few more behaviours added and tweaks made to work properly.

Doors

Transition between different rooms was something inexistent before we began working on the demo, as of now we were working with isolated rooms for prototyping, and was one of the first things to be accomplished. Obviously with the addition of these transitions we needed doors.

There are three types of doors, regular doors that have a physical object that needs to be open, abstract doors that are basically triggers that teleport you to another location and conduct doors that require an animation to pass through. Even though they sound very different all of them use the same main script, and the differences are given by additional objects attached to them.

Security cameras

Security cameras were also added for the demo, they are one of the first objects to use Pixel Art Rotation, the asset we released a few months ago.

When I tried to attach the long laser trail you can see in the video, so the player could see where the camera is pointing, I ran into a really big problem, Pixel Art Rotation wasn’t meant to be used on big images because the computational cost of applying pixels to the entire texture in Unity is too big to be efficient. So I decided to create a Pixelated Line Renderer to draw the line on screen with the right pixel size.

Camera movement

The main focus of this issue was to make the camera follow the player.

At first we thought that it will always follow the player position after he passes the horizontal or vertical threshold that glues the camera to the edges of the rooms, but this solution wasn’t enough for two reasons, one, the player moves through animation a lot of times, which means that he’s not actually moving its position, and two, the movement of the camera was jerky sometimes.

To solve the “movement through animation” problem I attached a Box Collider Fitter, which is a script we have shown on a previous update that adapts a 2D box collider to the shape of a sprite without counting transparent pixels, and make the camera follow the center of this collider when these animations happen.

But the problem of the jerky movement persisted, so I decided to avoid following the player if it wasn’t necessary, which meant waiting for the player to move away from the focus of the camera enough so the resulting movement isn’t jarring, and I made the camera move through SmoothDamp, a nice function that comes with Unity that it’s actually advised to use with cameras.

Other neat things

What I’ve told you so far it’s a meaningful part of the game, but there are still lots of things I could talk about and problems I’m facing as we move forward with the game, like for example how to better control the flow of the game, perhaps adding asynchronous operations for some routines or managing persistance between rooms.

There are also other aspects you can see in the demo which aren’t fully done yet and we’re still researching, like the audio, so I think we’ll left these ones for another time.

Bear in mind that everything I’ve talked about could change in the future as we try to improve both design and coding as much as we can.

Thank you for your patience, see you on the next update!

Development state and new project: GOTY

26 likes

As we informed you a week ago we were working extra hours to launch a campaign for a new project and here it is. We think that transparency is key and that's the reason we wanted you to know about this new game since day one... For us is extremely important to keep being crystal clear about all things concerning not only Paradise Lost, but all the stuff we are working on.

The story so far

Taking a look back at last year from the perspective of development, we didn’t stop fantasizing about how things would have been if we had made different choices. 2014 was going to be a major step for us. Our project obtained financing and we were able to devote to full time development and bring PLFC to life. We engaged in a work schedule that filled us and we loved it. Working on what you really like is a luxury, but nobody tells you about the sacrifices you must do to fulfill your dreams.

Communication problems and the lack of a common goal led us to rethink the initial formation of the team and so we lost a friend, colleague and partner. It was a blow, but the worst part was having to let go all the game’s code: A year of development to the trash. All our hopes were suddenly gone and having to watch how an important part of your project dissapears was pretty fucked up. We had to rise above that and continue making the game. We made a promise to all of you, and that’s not gonna change.

With the things learned and the hard work made by our programmer Carlos we were able to improve a lot of features, like AI and certains aspects of gameplay. We even managed to add stuff that we thought impossible like pixel art rotation, which became a featured asset on the Unity store.

This doesn’t mean that everything is done and lot of stuff is yet to be made, plus working so long in a game that had an initial forecast of a single year burned out both Sigrid and I. The frustration of starting all over again is something that is there, like a thorn.

Summer arrived and we felt that more than a good rest we needed an outlet for our creativity, avoiding to get stuck and stay fresh with new concepts, so we started to create GOTY from time to time outside work hours. After a while we realized that this pastime could become something more, so we decided to polish it. The game seemed fun to play and we decided to give it a chance on Kickstarter.

Why now? Because this project is a way to reflect our current experience as game developers and also address from a positive perspective the problems that happen frequently in game development, specially if you are an independent dev. We felt the need to see if we are still sharp with original concepts.

If the project has any success, we’ll promise all of you that it won’t have a negative impact regarding Paradise Lost. As far as GOTY goes, it’s an already-made project. Even with all the setbacks that have happened so far, we’ve given you constant info and material to back our words, and we’ll continue to do so month after month. PLFC is our beloved child and we are working hard on it to give you a playable sneak peak ASAP.

Release date and gameplay material

So far we were contrary to give you a certain release, because we know what is going to happen… give you a date and then have to delay the project, like most of Kickstarters out there. Our first priority is to finish the level editor and send to backers a preview build as soon as possible. From that point will be able to establish a realistic timetable, but expect a year from now.

Well, with all things said we present to you our new project:

GOTY the card game

GOTY is a tabletop game where you can experience the process of making video games, trying to avoid setbacks and bizarre situations like deleting work by mistake, losing a partner, receiving a lawsuit or even survive a flood in the studio.

Besides all of this, you have to create your project by completing the tasks of the different categories that take part of a game. In order to do so you must bring together the best professionals, collecting assets and gathering a set of abilities to take advantage over the rest of players.

If you want to know more about the game and also help us bring it to life, you can check here the Kickstarter campaign. We hope that you like it and don't forget to stay tuned for more info (but next time only Paradise Lost related) ;)

Thanks in advance for your support and understanding!