top of page
kratelum_banner_mio4.png

A fast-paced top-town third-person arena shooter

Overview

Kratelum is a 3D fast-paced top-town third-person arena shooter, developed using Unreal Engine 5.

It features adrenaline-filled, skill-based gameplay, centered around using traps and power-ups to eliminate hordes of enemies.

The game is divided into arenas of increasing difficulty.
The player's goal is:

  • to kill all the enemies, which gradually spawn in the arena at an ever-increasing pace;

  • and to achieve the highest score, taking advantage of the score multiplier provided by traps and kill combos.

This was our final and most ambitious academic project. 

  • Team size: 22 (10 designers, 5 concept artists, 4 3D artists and 3 programmer).

    • The large number of designers was the result of splitting the students into two groups because of the limited number of programmers. This, however, led us to achieve a better verticalization in our roles.

​

  • Objective: create a vertical slice of a third-person game using Unreal.

    • This means the game should be polished and feature (but not content) complete.

    • The slice was then presented and played by numerous publishers, during the "Publisher Connect" event.

My role

Gameplay, combat and Tech Designer

Genre

Third-Person action 
arena shooter

Platform

PC
(Unreal)

Dev. Time

6 Months

windows_logo.png
UE-Icon-2023-White.png

Clips from the game

fucile1.png
fucile2_edited.png

What I did

  • I collaborated with the design of the game concept and mechanics.

  • As Tech Designer, I maintained a constant and direct communication with the programmers, explaining and discussing design requirements. 

    • I listened to the designers' and programmers' needs, proposed and evaluated solutions,
      shared technical knowledge, designed tools and solutions to streamline and make more efficient the development process.

  • I prototyped in Blueprint and C++ many of the game mechanics.

    • This enabled us to test early our ideas and identify the ones that really worked.

  • I made a prototype of the first Boss Fight.

    • Completely designed and coded in Blueprint & C++ by me.

    • Even as a prototype, it allowed us to showcase the game's potential.

  • I contributed to the writing of the GDD and I was responsible for organizing and structuring all
    project documents.

  • I implemented the base for game's UI.

  • I collaborated on the game's testing, writing extensive feedback documents.

Prototyping

My approach to Design

I believe that games are designed through playing.
They don't just exist as ideas in our minds, ideas are abstract, intangible;
but games should be actively discovered by playing them.
That's why I follow a hands-on, iterative approach to design, rooted in prototyping and costant playtesting.

Overview

Traps

Objective: prototype a set of Traps that can be activated by shooting a Button. They can damage enemies and/or the player's character.

This prototype was designed and coded quickly, to provide designers with something interactive as soon as possible and proceed through iteration.

In the end, my prototype proved convincing and efficient enough that it ended up in the final build.

Trap and Button

As I often do, I began by creating a base class in C++ that all Traps would then inherit from. The implementation is pretty much empty, as the only important function "ToggleTrap" is to be implemented in BP.

I proceeded by making the interactable Button.

I always make my prototypes as configurable as possible. Here you can not only specify a list of Traps to be activated, but also its delay (during which the player can't activated it again), the duration of his animations, the colors and emissions that defines the pressed status...

Using this base, I proceeded coding a total of 8 different Traps using Blueprint.

This also allowed me to easily add animations via Timelines.

Without going into too much detail, here's a showcase of some of traps, followed by a gallery showing some
of the implementations:

Overview

Boss Fight

Objective: prototype a boss fight, showing what could be done using the core mechanics of the game, while also adding a fresh twist to the game’s rhythm and offering a distinct gameplay experience.

I designed and implemented the boss over roughly six weeks.
I followed a hands-down iterative approach, with the aim to achieve a playable level as fast as possible, so I could use playtest data to refine the prototype.

Final Result
fucile1.png
fucile2_edited.png
Design

I started by designing a minimal version of the boss fight, concentrating on establishing a solid core gameplay loop.

I avoided defining too many details early on, so I could leave space for creative flexibility during the design process.

My design goals and relative solutions:

  • Make something fresh, different, to change the pace of the game →  Here the objective is not to kill hordes of enemies, but to destroy the Boss as quickly as possible.

  • Reuse the core mechanics of the game → Dash, shoot, power-ups, traps were all used.

  • Replayability and puzzle design → I wanted to make the player think and progressively learn the Boss patterns and strategy. The Boss is not easy, its attacks are partially randomic and there are various tricks that can simplify the fight. This encourages a "try, die, repeat" cycle, motivating players to continually learn and improve their skills.

  • Make something simple → Due to production constraints, I was alone, so I had to extract as much fun as possible from simple mechanics.

    • Moreover, a simple design allowed me to itearte more easily and effectively.​

Core idea:​ the player needs to destroy a central structure (the Boss), capable of many different attacks that increase in difficulty as the fight progresses. Many attacks are inspired by bullet hells and require skill, knowledge, and clever use of the game mechanics to overcome.
The Boss is assisted by four Minions that heal it periodically. Destroying them should be a priority.

The Minons became 4 turrets on minecarts, each protected by a shield that makes them immune to attacks. However, during the Boss's healing sequence, the player can shoot nearby explosive barrels to destroy the shields by detonating them close to a Minion.

This mechanic allowed me to introduce a light puzzle element while cleverly reusing an existing system from the main game.

I ended up developing 6 Behaviors for the Boss.

The first four are attacks it can perform, and each one of them increases in difficulty as the Boss’s health decreases.
For a detailed breakdown of each behavior, please see the PDF attached below.

After many iterations, this was the Boss's final Design Document.

Application is no longer available.

Implementation

Firstly, I implemented in C++ the base classes for the Boss, Minions, and Projectiles (that are shot by the Boss).

Starting with C++ insted of BP gave me a more solid and flexible base. 

I started by developing an initial version of the Boss, capable of doing only a single attack, then I developed the Minions and started implementing every behavior I envisioned.

This is the pipeline I followed:

  • Design a Behavior.

  • Prototype a simplified version using BP, to test the idea.

  • Convert and expand the implementation using C++.

    • All Boss behaviors were written in C​++, resulting in cleaner, more efficient, and easier-to-maintain code.

  • Playtest, again and again! 

    • External feedbacks were crucial played a key role in fine-tuning the Boss’s behaviors.​

The Boss is controlled by a Behavior Tree featuring 11 custom Tasks.

This was one of the most complex BT I had ever developed, but I focused heavily on keeping the structure clean, readable, and easy to maintain.

The boss has 4 different attacks. They are all implemented in C++ and are driven by curve tables that scales their difficulty depending on the boss's current HP: when a behavior is called, all the revelevant curves are evaluated depening on the boss's HP, getting all the config values of a behavior as a struct. 

The next attack behavior is choosen randomly using a weighted extraction algorithm that also avoid repeated behaviors.

These are some of the function I wrote for the Boss's behaviors. In total I wrote more that 1200 lines of code.​​​

These functions are far from perfect, but they served as functional implementations. 

One attack I’m especially proud of is called “Corner Lasers”, consisting of laser beams originating from the sides of the arena and parallel to the walls directed towards the centre. This attack is completely configurable as a sequence of single lasers, each one with a direction, speed and delay before the next.
This is controlled through different data tables that defines attacks of increasing difficulty.​​​

bottom of page