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.

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:

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!