Epilogue environment backdrop
Epilogue environment foreground
Epilogue logo

Epilogue

Overview

Details

Epilogue is a school arranged group project with the theme being ‘conflict within’. We had a total of 4 weeks to produce this project and the engine we had to use was Unreal Engine 5.2.

The game is a first person rogue shooter where the player fights off hordes of enemies and scavenges for weapon upgrade cards until they have cleared all 5 stages (of grief).

Team

For our team, we had 9 people in total, 3 programmers and 6 designers. Unfortunately this was our last game project for our education and we were not able to have any artists by this point since they were very busy finishing up their education.

Our Project Owner was Oliver Smolka, a design student who was an excellent lead that kept everyone motivated. During our meetings we could tell that he was very passionate about the product and game development in general. He also had a very good eye for detail and really emphasized that we make a fun to play product. I am glad that Oliver was able to be decisive when it came to features and kept us on track to deliver and meet our milestones.

I also got along well with the rest of our team and sometimes we would even end up playing games together after work hours, like Risk of Rain 2. This of course was not mandatory nor planned, but I think it definitely helped us get to know each other more and it was fun. It was something that I had not really experienced much of up until this project, even though I have participated in pretty much all scheduled after work events and various game nights during other projects, it felt more genuine.

Responsibilities

Gameplay Programmer

Early on we were quite indecisive regarding what sort of weapon we want in the game, and I was discussing this with our mentor. My mentor suggested that we should make a systematic weapon solution to let the designers tweak the gun behaviours through Unreal Engine’s details panel.

The rather ambitious gun system I developed has a user interface similar to Unreal Engine’s Input Mapping Context interface, and it lets the designers control the ‘Trigger’ type, ‘Constraint’ type(s) and ‘Spawner’ type. Triggers described how the shooting action should begin, whether that’s shooting once on button press or continuously shooting whilst held down. The Constraints describe conditions to evaluate before firing goes through, such as cooldowns, ammo count or charge time. And the final type, the Spawner, let the designers control if they wanted a burst of bullets in parallel, several bullets in serial or singular bullets to fire if all the other conditions go through.

I worked closely with our PO for the 3C programming of the player movement and iterated over features to see what we should keep and what we could do to make it feel good. We quickly dove into a more Quake-esque feel with the controller as the rapid and responsive movement felt nice to use with an environment that had a bit more altitude. I made sure to use curves to define certain behaviours of the game, such as damage falloff, or the acceleration of the player’s dash ability.

Technical Artist

Early on, we were able to establish that we wanted to have a retro aesthetic to the game, but not restrain ourselves to older generations of hardware. So we went with a 3D environment with pixel art covering the walls, inspired by games such as Compound or Friends vs Friends. Then we decided that we’d be making the art for the game as well, and we’d need adequate tools to do so. I was testing out and looking for software that would meet the needs of our project, and we ultimately landed on using Blockbench, Aseprite and Blender.

Another opportunity I could not pass up on was that Epic had just so happened to release Unreal Engine 5.2, and with it came their Procedural Content Generation system. I took on the responsibility to investigate it and test it to see if it would be a valuable tool for our project, as another fellow programmer was also excited to test it out. I determined that, whilst it was really powerful, it will take time for us to learn about it in-depth, and would require more practice and training for us to put it to good use, so in the end we decided to not include it as part of our workflow.

Another visual aspect I brought up was making use of outlines for the game, and there are a handful of ways to do this. The two more popular approaches to making outlines are using a post processing step, given fragment depth and possibly fragment normals, to compute the differences between neighboring texel values to determine if they are different enough or by taking a mesh and extruding the vertices along their normals. The post processing step in our case wouldn’t give us enough control over what they applied to, and there were more technical difficulties that would have to be addressed if we wanted to pursue that approach. The second outline option seemed a lot more feasible, but then to avoid the hulls breaking apart, we’d have to author outline meshes along with our regular ones, and we passed on doing that too since we were getting pretty happy with the cleaner looking environments either way.

Artist

I helped brainstorm what sort of art direction we wanted for the game, as we quickly landed on a 3D pixel art style we felt like we could pull off ourselves. We took a lot of inspiration from more surreal and abstract environments and media for the game as we wanted to induce a more dream-like feel for the game.

There are a handful of art assets in the game that I made, such as the skybox, damage number font, some UI advice and two additional models we could place down.

Builds

I was responsible for making sure that at the end of each week, we were able to get functional builds, and although I wasn’t very used to debugging Unreal Engine builds, and did have to spend a bit of extra time learning about it, I did end up fixing all issues that cropped up during the building process.