Dungeon Of Apostasy

Creating a vertical slice of a game with a small team of students from different majors, which in our case consisted of 7 people total (5 artists and 2 programmers), with a time limit of 3 months.

Before we jump into the project, I will first introduce the team:

Machias Boschman: our resident animator. He was in charge of creating the great animations in our game.
Sarah Platteau: all-round artist, but did some of the work on prop art and UI concepting. She also helped improving the lighting in the game.
Odo Struyve: As environment artist, he created most of the models used in the game and was also in charge of the level design.
Arlette Bessems: created most of the materials you can see in the game, and helped out where needed with the models for the environment.
Evy Westelinck: our main character artist for the main character and enemies found in the game. She also did most of the UI design.
Bram Vernimmen: programmer, whom I worked very closely with to program everything the game needs to tick. Bram was mainly in charge of the Inventory and items, character AI and interfacing with the animations. I mainly focused on creating the c++ elements for UI, the battle system, and the item throwing mechanic we had.
Noah Bots: composed the amazing music you can hear in our game. He was part of our team through a collaboration with the Royal Conservatoire of Antwerp. We are very grateful for his contributions!

This project was made in context of the group project subject in our school's curriculum, with the goal to put students from different majors together to simulate working conditions.
We had the opportunity to pitch our own project in front of the supervisors before the start of the semester, so we got to work during the summer brainstorming ideas. After a couple of weeks, we had a rudimentary prototype ready to present the jury.

Despite the criticism that our project was too large in scope, we got greenlit to start the project on the condition we shrink the scope to a more manageable level for the time we have.
The semester started, so we worked on the project 4 days a week from 8h30 in the morning till 17h00 in the afternoon.
During that time we would go through the different sprints a game normally goes through, with each stage having a time limit of a few weeks.

Prototype sprint: 3 weeks
Production sprint 1: 3 weeks
Production sprint 2: 3 weeks
Polish sprint: 2 weeks

During the prototype sprint, the goal was to clear up anything that was uncertain. If it was unclear if something was fun, it needed to be tested. This was also the phase where the production pipeline was written down.
Both production sprints had as goal to actually create the game, but as opposed to the prototype sprint, everything had to be neat and coherent as to not clutter the project with unnecessary things.
At the start of the polish sprint, there is a feature freeze, which means no new mechanics or features can be added, though it was allowed to fix bugs with existing ones should the need arise.
The main goal was to make everything about the game feel a lot nicer to play. This could range from creating UI transitions to making things clearer for the player.

During our brainstorm, we came up with the idea to create a dungeon crawler where you would need to strategically plan out your next move. Failing to do so might result in your death.
For this, we based ourselves on the brutal game that is Fear & Hunger.

We also went with the approach of a static camera, which would reinforce the feeling of dread that there might be an unseen threat outside of the view of the camera.

For some of the mechanics, we needed a luck-based system, but creating that would go a bit against the idea of the strategic planning.
The solution was giving the player a degree of control over the luck mechanics in the form of Tarot cards. A set of 5 randomly drawn cards would appear whenever a luck-based event happened.
The player would then have the ability to pick out a card that they believe fits most with their current strategy. Those luck-based events are also not mandatory outside of battle, so the player can decide to skip it.
Battles are one of the ways to get around enemies. The battles are turn-based based on the current stats of the character.
A battle is a dangerous endeavor, as it can easily end in your death if you are not careful.
Throughout the map, there are several items and chests. Not all items will help you and will actively harm you if you make the wrong decision.
In short, we wanted to create a game where the player would not feel safe, no matter what strategy they come up with.

The code for this project is mostly written in Unreal c++. Only the parts of the code that need to directly interface with UI and animations are done in blueprint.
Both Bram and myself had not done much in Unreal c++, so it took up some time to learn how to work with the specifics of the engine. Once we got up to speed, we started working on the several aspects of the game.
In order to make sure we were on the same wavelength, we regulary communicated with each other to keep the code as clear as possible and the structure as clean as possible. This included daily code reviews of about half an hour.
I mainly worked on the battle system, one of the code mechanics of our game, the UI elements that needed to be written in c++ and the throwing mechanic. Each having their own unique difficulties.
Because of how the battle system needed to work, every aspect of it needed to be event based. Other than that, the battle system consisted of 3 main elements:

The player turn: the player can pick several options to attack, defend, or flee. Each of the options had to flawlessly interact with the system and not cause softlocks.
The enemy turn: during each of the enemy turns, the battle system lets the enemy decided what should happen with the player. This to ensure we could implement a range of different attacks for the enemies.
The turn predictor: at the top of the screen, you can see the expected order of turns. The turns are decided by the player stats, so the player needs to have a visual element to be able to properly strategize their next move.

As the game also supports controller, we decided to implement a radial menu for the inventory. However, each item in the inventory carries a different weight to it, and the player has a limited amount of space.

This meant that there needed to be a variable amount of item slots in the radial menu. Figuring out how to do this in code was much more difficult than anticipated, especially because we had to keep controller support in mind.

There were several issues with keep the focus on the correct UI elements that took a while to fully fix.

Lastly, the throwing mechanic. The idea was that the player received an aiming reticle that moved around on screen, but at first that reticle acted very erratic, causing all sorts of weird bugs.
Actually throwing the item was not easy to implement either, as the item did not always cooperate, usually due to a mistake on my part.

In the end, we managed to get a nice endresult despite the difficulties, so it was definitely worth the effort!

I consider this project one of the greatest I have worked on so far. The feeling of passion we all shared in our group for this was amazing project.
Our supervisors could be hard on us for some decisions we made, mainly scope and priorities, but as a result we all learned how to get better in those things. We always tried to take difficulties and setbacks in stride and worked around it to the best of our abilities.
I can say I personally learned a lot during the project, such as better time management, but also how to use Unreal Engine and other software in a better and more efficient way.
It was great to see how the different majors came together as cogs in a well-oiled machine!

Dungeon Of Apostasy

Goal

The Team

Introduction

The Game

The Code

Conclusion