Pre-alpha footage and tech issues

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.

bug pixel perfect Paradise Lost First Contact

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.

color curves paradise lost first contact

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.

popup gui paradise lost

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.

entity component paradise lost

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.

entity scheme paradise lost

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.

camera collider paradise lost

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!