VISCERATE
Details
Unreal Engine
7 weeks
Roguelite FPS
16 Team Members
Roles:
Lead Programmer
Gameplay Programmer
UI Programmer
Systems Designer
Introduction
"Viscerate is a fast-paced action shooter blending roguelite elements with strategic combat and modular upgrades. Designed for intermediate to hardcore FPS players, the game delivers an intense combat experience where every run is a fresh challenge. Players craft and customize powerful builds with different weapon evolutions and over 40 unique upgrade modules, ensuring high replayability and tactical freedom."
Designing the systems
As the lead programmer, the first thing I did was discuss the systems of the game with the designers. We knew from the start that this game was going to be a tech heavy project so I wanted to make sure that everyone was on the same page and that systems would require minimal reworks later on.
After clearing things up with the designers, I sat down the programmers and we designed the systems of the game, including how the world should generate, how the upgrades should work and the inventory system.
Worldgen
Initially I had designed the worldgen to generate each room retroactively as the player progressed past certain keypoints, but to improve performance we instead opted for a Hades-inspired approach where each portal at the end of a room just loads in the new level.
I coded the foundation for the worldgen to have a basis, a functional prototype, and then handed over continued development to another programmer who wanted some guidance to ease his way into Unreal Engine. This way the foundation was there for him to improve on and ask for help from me.
Inventory
At the same time as handing over the worldgen to the other programmer, I also took on the job of working on the inventory system as well. The inventory system in the game is grid-based, meaning the modules each take up different amounts of space.
This proved to be a bigger challenge than we initially anticipated, meaning I had to return to the drawing board multiple times and discuss with the designers how we should proceed and what changes would need to be made. We kept continuous communication between disciplines to ensure that we retained the vision across the game and that development could flow easily.
Upgrades
The biggest system was the upgrades. Every item you pick up is placed in an inventory grid system, and have abilities with conditions. These conditions can be "On Reload", "On Equip", "On Deal Damage", "On Move", et cetera. They then do things such as modifying the stats of the player, of the enemies, dealing damage to either, and so on.
This meant that we were in need of a solid foundation for a system that would be scalable and robust enough that we wouldn't need to rework it multiple times later down the line.
We settled for modules coming with "modifiers". These modifiers are added to a list on the player for "x" duration, removing themselves whenever the duration ends or conditions are no longer met. I figured it would be best if all things in the game followed the same pattern in this case; all sharing the same stats systems and having the ability to receive modules and modifiers.
A benefit of this is both that we could easily make more enemies, including things like turrets. Just create an enemy with 0 movement speed and you have a stationary enemy. They would also be able to equip modules the same way as the player would, meaning we could easily scale up difficulty by applying modules to any enemies.
Cross-Discipline
I made sure to implement blueprint events rather than C++ wherever applicable for Designers to more easily be able to hook into the logic of the code and perform their own things. I also set up a "Sector Database" Data Asset containing all levels and what order they should appear in.
Shortcomings
One of the main things that drained time from the project was making the inventory system work. None of us had ever done a system like that before, and it required down-scaling and a lot of work and bug-fixing before it was finally shippable. If I were to go back in time I would plan and research better ahead for that part of the game, so that I could have aided more in other areas of the game once I had finished it.
