Lazarus

Lazarus is a project that I and Niklas Olsson have made together as a portfolio piece. For him it is a level and narrative design case. For me, a game and technical design case where I sought to develop and showcase some of my proficiencies as follows:

My goals:

01. Get tech design experience

One main goal for me during this project was to experience working directly with someone who would use my tools and give me feedback that I could use to iterate on my creations as this is something I haven’t had the chance to try out much before.

02. Become more at home in Perforce

To get a good feel for how this iterative workflow could be setup during lockdown times we had to find a way to easily work in the same project. We had both used both SVN and Github with Unreal earlier but this seemed a good opportunity to get more familiar with Perforce as we both had access to it through TGA.

03. Design a gameplay system from ground up

I also set out to design a versatile gameplay system where the player could hopefully feel like a cool hacker hacking their way through the mysterious Prometeo facility and see to it that the system was easy to use for Niklas.

04. Implement the Elevator in a real scenario

This also proved to be a good chance to put my elevator tool in the hands of an actual user and led to some small, but very useful, changes to how it worked.

05. Reworking and repurposing existing scripts

As a part of the vision we had we wanted some features (mantling, crawling and some animations) that could be found in a content pack for Unreal Engine (Advanced Locomotion System). This meant that I would have to go into an extensive collection of interconnected scripts and edit or dismantle them to keep just the parts that would fit our idea.

The goal for the player is to reach this hacking terminal.

The hacking system

My biggest task for this project was to set up the hacking system that let the player interact with different kind of actors and control their behaviours in some way that was adjustable by a level designer.

When I made this mesh for the hacking tool I set out to get a retro-futuristic feel to the tool.

The player would have to be able to see an in-game interface that let them easily understand what they are interacting with and test what the object does when it is hacked. It could be a door that opens, a laser that shuts down, an elevator that moves to a floor; I simply wanted the level designer to have extreme versatility with this system.

A simple example of a level design tool I would make and what the hacking tool can do.

This is a showcase of an in-game security system I set up for Niklas to use. The laser beams will automatically adjust their length to fit where they are placed and if connected to a hacking terminal they can be shut down for a time determined by every instance.

The parent script for all hackables: low on content to make for easy reparenting.

If either I or Niklas made a script that we in hindsight recognized would be nice to be able to hack I never had any problems just childing it to this script. The parent blueprint should just hold the very key features that are the same for all hackables (e.g. delay before hacking and “hack” and “stop hack” with belonging audio) and now that I look at this script I definitely see some things that bloats it.

A shared name would let the hack trigger from the same call as shown here.

Connecting multiple hackables with the same name to the same hacking terminal will make them trigger simultaneously. This means that a level designer easily could combine a door, a particle spawner and an audio trigger to create a bigger event.

All moving objects in this scene are the same type of blueprint, just utilized in different ways.

The system for “Moveables” was yet another step towards creating versatility in the hacking system without getting too complex that it was hard to use. The scene in the above clip simply looks like this:

The red meshes are the respective goals for each “Moveable”.

In the end most scripts made by us were connected to the hacking system and it had proven to be very easy to use in any given situation.

The Alarms Trigger is connected to this button that can be triggered with a click of the mouse.

I also made a simple button that could be placed in a level and connect to any hackables so that all these scripts could be started even without the hacking device. Scripts that we felt would be nice to trigger with a collision had a toggle for that possibility too. For example the “Alarms Trigger” pictured above has a public boolean that sets the collision to trigger on overlap with the player.

This is the script for the handheld hacking device.

A first week version of the Hacking Device.

Other scripts

I also made some other small scripts for use in the game.

A very simplistic checkpoint system I put together.

A simple defeat and checkpoint system. When the “OnDefeat” function was called in the player character the calling actor would have a choice of lines to show on the screen to be more fitting to the way the player's story was ended this time.

Almost out of battery!

I implemented a half-life style flashlight. It would automatically recharge when not turned on but was not usable until fully charged if used until the battery is emptied.

Closing thoughts

For being a product of 4 weeks half-time I am very happy with how the full experience turned out. If given more time I would have added some more finesse to the system that it now lacks to give the puzzles more depth. The system has all the features we planned for but it feels a little unpolished how the system always triggers everything at once and doesn’t allow the player to manually toggle anything back on with the hacking device.

Those little issues aside I must say that I think it is a well functioning system that really serves the game well. I hope to someday put some more work into it and really get to the bottom of creating puzzles with this system in mind.