Lucas Hellberg Djerf

Favorite games:

1. Path of Exile
2. Dark Souls series
3. League of legends
4. Dragon's Dogma
5. Prey
6.(Recently) Deadlock

About me

Hello! My name is Lucas Hellberg Djerf, and I am a game design student at futuregames, Stockholm and am actively looking for an internship opportunity or junior position.I've been passionate about games ever since I played my first one when I was 3 years old, and after working for a while as a bartender and barista I decided that I wanted to pursue working with my passion in my day to day job.I like many types of games but my favorites are typically deep RPGs or competitive multiplayer games and I'm also a big esports fan!What I love about game design is that it really rewards curiosity and an interest in learning, I truly believe that any experience is relevant for game design.My strengths comes from being wanting and willing to learn anything, allowing me to see games from a holistic viewpoint and use that in my design work.

Game pillars + supporting features

Click image to enlarge

Core game loop

Click image to enlarge

Making discoveries is the main driving force behind the gameplay and player fantasy of being an explorer on a newly discovered planet, so the main progression system is based on discoveries.Most need to be scanned and photographed.registered discoveries are added to the Codex menu where the its picture and information can be viewed.Players have a choice to either name discoveries or keep the default name. This fits the fantasy of being an explorer very well and adds a small way to personalize the experience.The suggested name exists so that it doesn't cause friction for players that are not interested in naming their discoveries.Discoveries are the main contributor to progressing the story and completing quests.

Discovery registration flowchart

Click image to enlarge

Bounceflower quest

Some discoveries are directly tied to gameplay, like bounceflowers giving the player access to throwable bounceflower spawners.The intention is to make exploration more rewarding and further sell the game fantasy.Shops that can have new stock added also adds a credits sink for players.

Quest system features:

Quest structure

Click image to enlarge

Different quests being completed

(Map in journal background is a placeholder taken from Pokemon scarlet)

Objective types include:

Quest progression and completion as well as matching objectives to the correct objective target is handled through a quest manager.Objective targets are attached to actors relevant to quests, they send references to themselves and related objective IDs to the quest manager which matches them with the correct quest.

Quest system architecture

Click image to enlarge

Data tables

Click images to enlarge

Quests and objectives have their own data tables which include:

A component-based interaction system, has multiple interaction types and can be added to any actor.Interaction types include:

NPCs and non-characters can also use these interactions.

Click image to enlarge

The inventory has support for stacking items, as well as removing specific item(s) from the inventory.Each item gets its info from a data table, this includes:

Role - Gameplay + Tech design
Duration - 7 weeks, May 29th -
June 14th 2024
Genre - Horror adventure.
Team size - 4 designers, 4 programmers, 2 artists.
Engine - Unreal engine 5.

• Build download (Itch.io)

This was a group project during my education at futuregames.My primary responsibilities were to prototype mechanics, come up with the gameplay loop and mechanics of the game.I also helped programmers and other designers with scripting, using blueprints.I also assisted with defining and keeping the vision of the game, as well as present the game during our review sessions with industry guests.

Mechanics test 1

The first prototype, testing a static camera, interaction system and lantern

My first task during this project was to prototype a lantern mechanic as well as different camera options.for the camera, we tested a fully static camera that changes angle as the player enters new areas, as well as a standard third person camera.

After testing different cameras, we decided on a "Semi static" camera.It can follow the player along a set path or be set to fully static as we liked the feel of the static camera but wanted a bit more freedom in certain areas of the game.

Third person camera test

Testing a third person perspective as an alternative to the static camera, as well as the post process filter type we wanted for the game

Lantern resource test

Tested a fuel resource for the lantern that drains over time and can be refilled.

I also tested players having to put the lantern down to be able to interact.This could add more tension to situations where the player has to pick it up quickly to flee.Another test was player health draining over time if exposed to the darkness.This was to tie the player's safety to the lantern and to cause tension if forced into darkness.

My first suggestion for gameplay, the lantern is at the core of the game as it is used to deal with both obstacles and the antagonists.During this time, me and the level designer also started discussing how to onboard our mechanics.I like visualizing gameplay like this as it helps me identify unanswered questions by finding gaps between the steps.

First suggestion of gameplay

in this example I had to figure out a way to force the player to turn their lantern on or off depending on the "Enemy" in that level.

Implementing mechanics

I created early versions of the light-based mechanics to use for testing encounters.The shadows (black cube) are gradually dissolved as they are exposed to the light of the players lantern.Meanwhile, the roots (white cube) grow to block the players path if exposed to the lanterns' light.

The first level has a wolf enemy that runs away if the player points a lit lantern at it.The roots are used as a way to force the player to turn off the lantern, for example to pass through an area where a fully grown root would block the player.

Level 1 gameplay demo

A later version of the project where the wolf had been implemented by our programmers.

Baba Yaga demo

Baba patrols between the table, bookshelf, cauldron, and a potion shelf. (Brighter than in-game for demonstration)

Baba Yaga is an enemy that patrols between 4 different stations, 3 of which are playable areas.If the player is in the same area as Baba Yaga and has their lantern lit, Baba Yaga can see and kill the player.This room is very dark but each station has a unique sound that plays while she is there, so the player can listen for where she is.

After more testing, I pitched that we should scrap parts of the planned features that didn't improve the experience.One of these was the darkness mechanic as it felt unnecessary as we already force the player to shut their lantern off and on with our light-based mechanics.We also removed having to put the lantern down as without more interactables or the darkness mechanic, we had no need to split up the player and lantern.

Gameplay loop refinement

A first-person dungeon crawler prototype where hurting enemies is required to restore mana and cast spells.This was to encourage aggressive play as mana is also required to heal.The prototype contains:

Duration - 3 weeks. Engine - Unreal 5.

• Build download

Duration - 2 weeks. Engine - Unity.

• Build download

A game prototype where the player's goal is to deliver packages to all of the delivery points and reach the end of the level as quickly as possible.During this project I saw players "break" the game by finding paths I hadn't intended.I supported and encouraged this as making those discoveries as a player is at the very core of these types of games, Only removing some of the more egregious exploits.

A puzzle game prototype where the player can scale objects, and carry small objects.Originally I planned for players to give objects different materials to change their functionality.But as materials don't affect size, I decided to shelve that idea and instead focus on scaling for this prototype.This project reinforced the importance of planning,
as it's easy to jump into an exciting project before necessary questions have been considered.

Duration - 2 weeks. Engine - Unreal 5.

• Build download

Duration - a few days. Engine - Unreal 5.

A prototype for an in-game photo mechanic, imagined for a Pokemon Snap inspired game concept.I learned how to make use of render targets as well as how to export photos from the game onto the user's PC.It was made using blueprints visual scripting in Unreal engine 5.

Role - Tech Design + Product Owner
Duration - 2 weeks pre-production, 4 weeks production, September 16th - October 25th 2024
Genre - Rail shooter.
Team size - 4 designers, 4 programmers.
Engine - Unreal engine 5.

• Build download (Itch.io)

My primary responsibilities were to create a prototype for the game during pre-production, and later to help designers and programmers create features with blueprints.I was also product owner and was responsible for maintaining the vision of the game, presenting it to industry professionals during the greenlight and jury day sessions, along with other managerial tasks.

Rail Shooter Prototype

The rail shooter prototype that I created to get the idea of the game across as well as test how technically doable it was.

I created a game prototype for one of the three options that we came up with. A rail shooter inspired by the Star Fox games.As time was short, I approached the this with my interpretation of rapid prototyping.I made things work as simply and quickly as possible, not focusing on scalability and instead on conveying our vision for the game, creating this prototype in two days.We decided to go forward with this prototype as it was the most technically doable out of our options while still being an interesting concept.

I then documented desired enemy behavior, as they’d be different than many other games.Taking the type of game we were creating as well as our time frame and resources we decided to opt for quite simple enemies.The game also has bullet hell influences which meant for us that we needed some form of pattern spawning system for bosses and opted to also use the same system for regular enemies.

General enemy planning

Plans and desired functionality for basic enemies in the game.

Bosses

Example of one of the boss drafts, this one we didn't have time to implement.

After basic enemies I started collecting ideas for boss functionality.It was nice to have a list for inspiration that could be discussed with the team for brainstorming and identifying potential issues.I also created first drafts for bosses'
functionality. I discussed these a lot with the level designers as we want different themes for the levels which the boss should tie into.

The Octahedron was meant to be the first boss with an aggressive phase, and a vulnerable phase where the player got the opportunity to damage the boss.During concepting, we had more traditional combat. Shooting lasers and missiles while telekinesis was intended as utility.After removing the player’s ability to shoot lasers and giving them telekinesis for combat, the boss no longer required an invulnerable phase. As players need telekinesis objects to deal damage.

Octahedron Boss Planning

The initial plan for the Octahedron boss

Movement improvements

A demonstration of the camera following the players position within a bounding box.

We got feedback that players felt like they were taken on a ride and not controlling a ship through a level.To help with this we made the camera follow the players vertical and horizontal movement until they reach the edges of the movement bounding box as a way of making the player feel more in-control of the ship (later turned Orca).

At the end of week 2 out of 4 of production we added telekinesis as a supportive mechanic to shooting.We got feedback that players enjoyed telekinesis a lot more than the shooting, and also that it was generally hard to aim.We also enjoyed the telekinesis a lot and thought it made our game stand out, so we decided to do a risky pivot and turned telekinesis into our core mechanic.A lock-on system was also implemented to help with aiming, making the gameplay feel a lot more fluid.

Telekinesis instead of shooting

Example of using the telekinesis to combat enemies

For the tutorial, I scripted the sequence of events for the level, handling checks and events for when a tutorial section is completed by the player.As our game has some unconventional mechanics I felt like a playable tutorial was very important for us to be able to have playtests without us having to explain basic mechanics.The tutorial teaches:

Tutorial level

The tutorial level that I made scripts for, handling checks and triggers for player progression

Custom button

Changing the custom button's different attributes.

I created a custom button widget that can easily have its attributes such as audio to play, font style and/or image to display changed.This helped us keep UI theming consistent as any changes made within the button widget itself would apply to all instances, allowing us to create a "Default style" for the button.

I created boss behaviors, handling attack types, and frequency of them by using Unreal's behavior tree system.I circumvented our pattern system's limited amount of pattern shapes by creating an actor with the desired bullet pattern in it, and firing that actor as a single "bullet".This was possible thanks to our programmers setting it up in a way where this bullet pattern system could spawn any actor.

Boss behaviour

The second Octahedron boss version with its behaviour tree during runtime.