Viscerate
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.
My Roles
Lead Programmer, Tech Designer
Team Size
16
Engine
Unreal Engine
Timespan
7 Weeks
The Concept
We wanted to make a first-person shooter game with full modularity when it comes to building your own playstyle. The player earns "modules" from killing enemies that can be slotted into a Tetris-style inventory. Each module has unique abilities and properties, so the player can forge their own runs every time. The game is a roguelite with permanent meta upgrades and a final boss to be beaten to finish every run.
I was the lead programmer for the project working on prototyping and implementing systems for the game. My main focus for this project was designing and managing the systems of the game, as well as implementing the grid inventory system for the game. As the game would need multiple systems working in tandem with each other, I thought it was important to make all the programmers work closely together and communicate to ensure that all of the systems were designed in a flexible way for scalability and easier implementation.
Modules were originally called "Status Effect" and were meant to be used for everything from damage to status effects like burn over time, armor piercing damage, etc. The idea was that if an effect has no duration, it is instant and ticks only once (like normal gun damage) whereas ones with a duration can be effects like fire which burn over time.
I did not work on the code for the modules themselves, only the design behind them. Modules were designed to be applied to practically anything with a health system, meaning theoretically enemies could also have them for challenge rooms, or turrets could be considered stationary enemies and also have them. The system is therefore very scalable.
My main feature as a programmer was the grid-based inventory system. We wanted a Tetris style inventory system akin to games like Sulfur or Escape from Tarkov. To add extra strategy to the game, the upgrades during the run are all grid based and require the player to balance and manage their inventory to fit as many upgrades as possible.
To solve the issue of the player running out of inventory space and having nothing to do with new upgrades, I came up with the idea of feeding unwanted modules to the gun itself to expand its grid capacity and boost its stats. This makes every new upgrade you pick up meaningful, either toward your combos and build, or toward stats and making space for other modules.
I originally wanted the level loading system to be retroactive, whenever you beat a room and choose a door it would branch out and continue the map in that direction. After testing and for performance purposes, I decided to instead fake the system by just loading in singular levels and unloading the previous one whenever the player clears a room.
The main issue caused by this was persistence. In hindsight, I should have used a persistent level and placed the player in there, but the way that I implemented it now was that the player is recreated upon loading into new levels. Any time you unload a level, it stores the player's data in the game instance and when it loads the new one, the data is streamed back into the player. It fills its purpose but can definitely be improved!
Since I was already working on the Inventory system, I decided to also take on the role of implementing the rest of the widgets in the game. This included the tooltips for picking up items, the player HUD and other menus. For most of my designer-facing code (including the widget stuff) I used a lot of BlueprintImplementable and BlueprintCallable functions so that things could more easily be modified by designers on the fly without needing a programmer to go in and do it.
Overall, I am happy with this project as my first real game made in Unreal Engine. Something I would do differently is researching more into how widgets and such work before I started working on the inventory system. It was more advanced than I expected to make a grid-based inventory system, which meant it took up most of my time during this project. On one hand it was a core component of the game, but we also probably could have reworked things and scaled down to adjust for the scope of the game, but in the end it worked out.
