Gameplay video of the custom engine version

Cabinet of Curiosities is a dungeon crawler set in a mysterious library full of strange artifacts. Defeat monsters and find upgrades to complete the level.

This game was built with a custom engine. The designers on the team also had a parallel UE4 project because the custom engine didn't have enough design tools for them to effectively experiment with mechanics and level design otherwise.

I exclusively worked on the custom engine version of this game.

Based on player feedback, we ran into the problem of the player and enemies being hard to keep track of when they're behind walls.

The designers proposed to make walls translucent when the player or enemies are behind them, but because our renderer was deferred, this was out of scope to implement.

We also thought we could use lower models for walls facing the camera, but the dungeon generation would become too complex, which made this out of scope as well.

Then I used the image on the right to propose an idea where we render the silhouette of the player and enemies when they're behind walls. This would be very simple to implement since it's just using a shader that renders a solid color and an inverted depth function, so it was within the scope of this block.

We decided to go with the approach I proposed and I implemented it.

Silhouette rendering in the final product

The visual artists on the team wanted to be able to do simple color grading to enhance the visuals of the game. I implemented this feature based on this article, the only difference being that the version of OpenGL we were using did support 3D textures, which made the process simpler.

It simply uses a 3D lookup table to replace the colors that appear on the screen. This works by using a 3D texture that would have its colors match up with the coordinates of every pixel, so the pixel at (0, 0, 0) also has RGB(0, 0, 0) and the pixel at (0.5, 0, 0.8) also has RGB(0.5, 0, 0.8). The table can then be sampled by simply using the input color as a coordinate. Then that lookup texture gets modified by color effects in an image editor together with a screenshot of the game, which makes all colors in the table reflect those changes. When the edited lookup table is used, all the color effects applied in the image editor are now applied to the entire game.

This approach comes with some limitations, especially the fact that it only supports effects that affect pixels independently. You can't use an effect where the color of a pixel depends on the colors around it for example. This was enough for our purposes though, and it was easy enough to implement to fit our small scope.

I communicated how to use the color grading feature to the artists by writing this quick guide for them.

The visual artists on the team wanted to be able to add some simple fog to enhance the visual of the game.

This wasn't difficult to implement at all, and it even used a config file we set up so that the artists could change the values themselves after playing around with them in the in-game debug menu.

As a contingency in case we couldn't finish features like animation or particles in time, I implemented a simple color multiplier for all meshes that could be used to convey things like damage or status effects.

It didn't end up being used for anything, but it was easy to implement and a good contingency.

To add the illusion of depth and to match our concept art, I implemented a multi-layer parallax scrolling background.

This filled up a lot of empty space on the screen and it's a big part of the visuals of the game.

This is another example of how I worked a lot with the visual artists on the team to make the custom engine version of the game look better.

One of the level design elements that I implemented is the exploding barrels. They are quite simple, they explode when they're hit by a projectile.

The projectile can be from a player or an enemy and it will also damage both enemies and players. This makes them both useful and dangerous to the player.

This wasn't all that difficult to implement, most of the challenge was with tying it into other systems. I had to tie them in with dungeon generation to make them spawn with the right model and I had to make sure a sound and particle effect was added too, while all those systems were still new and mostly untested.

There were a few interactables planned for the game, but due to our limited scope, we had to cut all but two of them. I implemented an ECS system for interactables but made the interaction itself polymorphic.

This way, the ECS could be used to generalize the pop-up text behavior and to find the closest interactable efficiently, while the interaction was slightly slower but more flexible. The interaction itself didn't need to be that fast anyway, since it only potentially happens once every time the player presses the button for it.

One of the main level design elements of the game was the spike traps that would raise up and damage anything on them after being walked on.

These could be used by the player to damage enemies if they were to line up the enemy to walk on the trap right after the player.

I used C++ templates to write a list of component types that could be damaged by the spikes, it contained the player component and the enemy component to reuse the same code for both of them.