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.
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.
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.
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.
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.
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 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.
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!