Untitled Canvas

For our fifth and final year at Gaming Campus, we were asked to create a compact experience of a game (a "vertical slice"). We were free to pick the type of game we wanted to make, our only restriction was that we had to use Unreal Engine 5.

We were a team of five students in videogame programming. At first, the idea of a visual novel was not preferred, considering the technology we were obligated to use. But gradually, ideas came together to form a relevant project, and one that we are pretty proud of!

The goal of this project was to test our technical knowledge (Unreal, C++) as well as our project management skills. We were five programmers, all in an apprenticeship, not available all the time, and working remotely. School weeks were scarce, so we had to be as efficient as possible.

The story

The player follows the story of Mafuyu and Ena, who found themselves trapped inside a painting while visiting an art gallery. They discover a strange, evolving world inside the painting, as well as an oddly familiar yet mysterious character.

Together, they will have to face many challenges, encounter the inhabitants, and find out the secrets of this strange world in order to escape.

Narration, dialogue and scoring

The most important gameplay aspect resides in a score attributed per-chapter, called "connection points", which influence aspects of the level and the interaction with characters. Although the mechanic is implemented, it has no effect in the demo.

Upon starting a chapter, the player starts with 0 points. From there, they can gain (up to 100) or lose (down to -100) points. There are a few ways that this can happen : either on completing a minigame, or through dialogues presenting choices to the player.

I have personally worked on dialogues, both the UI and the logic. In a narrative game, there was going to be a lot of talking, so we needed a way to intuitively write dialogues and in a flexible manner.
So, using Unreal's asset descriptor system, I created a "dialogue character" and a "dialogue line sequence" asset. Characters simply contain their name, and a map of sprites to show based on emotion. A line sequence is simply an array of dialogue lines (who is speaking? which emotion? what are they saying? etc.), with an optional choice at the end.

How to make the idea work with UE5?

Now, a visual novel running Unreal Engine, that sounds kind of silly, and I agree. But we saw it as a way to enrich the genre rather than sticking to 2D. The main focus remained the narrative aspect, while tense moments would be presented as more dynamic and gameplay-oriented.

The game features minigames, 3D environments, and an explorable isometric view of chapter maps. That way, we could play around with Unreal's rendering capabilities and create appealing scenes that players will want to discover.

The strengths and quirks of UE5

Our demo contains the finished first chapter, as well as three minigames. However, the build is somehow over 700 MiB. That's a bit much for the genre of the game, but that is not the only issue we had to deal with.

We had already used Unreal Engine in a few school projects before this one, and we were aware of the many technical aspects of the engine. One of the strengths of Unreal is its consistency over time. Its technology inherits from its predecessors, and the underlying structure hasn't changed much. However, that is also its greatest weakness.

If you're making any type of game with multiple scenes in Unreal, you'll definitely want to use level streaming, even if not building an open world game. That is because the traditional "Open World" node comes with many side effects, unwanted for any new game. All sound effects (as well as music) are stopped, there is a massive lag spike during loading (which means no loading screen), and of course, any actor you'd want to stick around is nuked from existence.
That last point makes sense, as actors are supposed to be objects within a scene, so a closing scene should drag its contents down with it.

Furthermore, maybe your game has no notion of "gamemodes" or even a controllable character (what UE calls "pawn"). Unreal's gameplay system natively supports spawning a configurable "gamemode actor" and a "pawn actor", as well as a "player controller", and defines their roles and respective relations. There is no real good reason to keep those around, and with level streaming, these are basically ignored anyway.
Instead, we rely on Unreal's "subsystems" framework to create our own engine components tailored to the type of game we want to make.

Technical aspects & choices

Our chapter framework relies on a few permanent subsystems controlling progression, connection points, map objectives, and so on. Upon opening a chapter, three autonomous actors are spawned : a chapter manager, a map character, and an isometric camera. The camera acts as our pawn, and thus receives input from the player. It also manages the orange cursor which indicates the tile we clicked on.

Minigames are also directed by a dedicated manager class, which tracks score and other minigame-specific statistics. The chapter manager remains alive, but deactivated, and is left in an "in minigame" state until the minigame is exited.
Map switching is controlled by the chapter manager, which knows its "chapter map" as well as the minigame maps. Since it is the core gameplay manager during a game and knows all information necessary to load a map at any given time, it was our best candidate.

The core classes of gameplay are managed by C++ classes, which can be extended by blueprint classes later on. The C++ classes only implement the logic which runs the whole game and controls the game loop, while the blueprint classes implement visuals and communication with the UI.
This design makes for a solid game loop, which is very difficult to break and bug out of.