Dungeon of Apostasy

The Goal

Finishing a vertical slice of an idea we came up with.

Challenges

Coming up with an idea that can fit in the scope of 3 months.
Working in Unreal Engine with mainly C++.
Not going insane.

We were only allowed to start with 5 team members. But with some much needed luck, Odo and Arlette were allowed to join us!
Without them, this project would've been a nightmare to complete. It would've been possible that the project got scrapped within the first 2 weeks.
We also named our group "Cellar Dwellers", just for fun.

In total, we had 11 weeks to finish this project.
The weeks were spent as follows:

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

The goal of this course was to simulate a real working lifestyle.
Thus, we had to work like a real 9-5 job; starting at 8:30 am and ending at 5:00 pm. For 4 days in the week.

Brainstorming

This project was a suggestion by us students. This meant that we had to sit together during the summer break and prepare a project proposal.
This was done with the core 5 members of our team. And I had to present it before the course started.
Our project got approved. However, what we proposed was totally out of scope. So our first task was to rethink everything we had written down.

Our initial draft was so out of scope that it surprised us that we were allowed to start.
In this draft, we had said that we would implement a lot of playable characters. All placed at different levels in the dungeon.
Some of these characters could even be recruited and help you on your journey!
Including a lot of different enemies, different endings, a crafting system, and much more, these things were cut.
This was definitely for the better, it wouldn't have been possible otherwise.

There are obviously enemies walking through the dungeon. When the player encounters one of them, a battle will start.
The combat is turn-based, allowing the player to strategize.

In some places, you can find items. These items can be used inside or outside of battle.
Outside of battle, they can also be thrown.
Be careful, because not every item will help you.

Prototyping

We had 3 weeks to test out all of our core mechanics separately and in the end together. First to see if they function on their own, later if they work together.
While the artists did prototypes to check out shaders, lighting, plausible environments, level design, and more, us programmers worked a bit different.

Instead of creating 1 Unreal Engine project to create all these mechanics in, we created separate projects for each mechanic.
This way, the projects were less cluttered, and we wouldn't be interfering with the code from the other developer.
It might sound counterintuitive, because we have to work in the same project later on, but the process now is totally different to later.
At the beginning of these prototyped mechanics, we didn't fully know what the scope had to be for that mechanic, how it would work, how it could work with other mechanics.
It was crucial to test these out on their own, and after we prototyped everything, we could make a planning of every mechanic and how it should be integrated in the final project.

In the end, I made prototypes for the tarot card system, enemy AI movement options, the inventory, and saving the game.
We ended up never using the save game, as the scope of our project got reduced that much, resulting in the game being beatable in ~10 minutes.
Jonathan made prototypes for the battle system, the camera system, and the throwing of items.

When all these mechanics were prototyped, we created a new project and reimplemented these mechanics to make sure they worked together.
During this phase, we did all the programming in Blueprints, to ensure this went by fast. We did not encounter any problems with this.

After binding the events, I would test to make sure everything is being triggered correctly, and the animation state machine flowed correctly.
This way, Machias didn't have to worry about the implementation, and could focus on creating amazing animations.

The Code

Because of the size of this project, the version control system being used, and the project technically being owned by DAE, the source code of this project is not public.
If you do want to learn more, feel free to ask questions about what and how we made this game!

The core of our game was divided. Jonathan and I had separate mechanics to implement, however we discussed in advance how we should structure and code them.
This was done to make sure all mechanics could work together without having to redo a lot of the code.
We made sure to recreate the same mechanics that we prototyped earlier.

Instead of doing these mechanics in Blueprint, we did them in C++ this time.
All core gameplay logic was done in C++, after which Blueprints were created to bind certain events correctly. Such as sounds, animations,...
A lot of UI logic for the inventory was also done in C++. This was a task for Jonathan. While other UI logic was usually just done in Blueprint.

The switch to C++ did take me some time to get used to, as I had practically no experience with this yet.
Jonathan was a good sport about this, and made sure to guide me in the places I lacked knowledge.
After a couple days of tinkering with C++, I was fully capable of carrying out my own tasks with great execution.

As his feel for the project was so passionate, and his thoughts on the music were spot on, we wanted to give him as much freedom as possible.
Anything he composed was instantly a hit with our team, and we couldn't be more grateful.

In the end, he composed 4 pieces of music for us. The main menu, a combat theme, a dungeon theme, and a boss battle theme.
You can listen to these pieces in the embed above, and please check out his YouTube channel where he posts all his music.

Since I knew the project was difficult to work on, because of the scope we set, I had to keep everyone in the group happy.
To do so, I made sure to surprise everyone with treats and sweets. On certain holidays, I would provide candy, chocolate or cake.
Even after being shut down by our supervisors, this helped to keep moral high, and all I wanted was to see everyone smiling at the end.

These 3 months of development, are probably the happiest months of my education.
All because I could just develop away, laugh together with the group, and play some games during breaks.
Everyone was trying to help the others during this process, all without too much complication.

I can only wish for future game projects to turn out the same.

Dubbed the "Arlette Strat", this is a glitch that happened when our artist Arlette killed the final boss outside of battle.
This was theoretically possible, but the chance was so low, that I forgot to implement any checks for this.
So when she killed the boss, it would still chase her down, while lying dead on the ground.

While fiddling with the movement and when to disable/enable this, we ran into a small problem.
When the player exits the battle, movement gets enabled.
However, this also happened when the player died during that battle.
Effectively playing the death animation, while the player could "walk" around.

Did you know that a slab of rotting meat can float?
Me neither, but we made sure it could!
While Jonathan was implementing the throwing mechanic, he disabled the gravity on the items and forgot to enable it again.
This meant that after throwing, the meat just started to move around, depending of the current velocity.

If this gif doesn't scream "me", I don't know what will.
While I was testing possible movement patterns for the enemy rats, I wanted them to move sporadically, as rats do.
What I did for this movement, was picking a random possible position nearby, and move to that position.
What I didn't account for, was to wait until the movement was completed.

The results of this being; every tick, a new destination gets picked, and the AI tries to move there.
Constantly facing the destination in rapid succession, gives this result, and we all loved it.

A modern invention in Medieval Times; the "Roomba Rat".
While Machias was adding his animations to the game, he always tested these.
At times, he would forget to uncheck a variable in the state machine, and push his changes.
This resulted in the rats playing their death animation, while they still had the ability to move around.

While we were still prototyping, our animator Machias wanted to learn how to implement an IK-system for his animations.
Even while following tutorials, not everything went always right.
Resulting in the crotch of the character being pushed up, like a scene from Popeye.
Or a character jiggling his bones around while moving.

There is no problem with this gif at all, yet didn't know where else to put it.
This gif shows the progression we made every week with the first chamber.
I like progression gifs, so for that reason, I made one!