Sentinel: Stones of Disruption
Arcade Game by Breaking Walls
for 10 weeks between January and May 2023
Team: 4 game designers, 3 artists
Tools: UE5 | Git | Azure DevOps | Steamworks
Skills: Gameplay design | Technical design | Producing
The goal of the project was to deliver a game within 10 weeks of work for a team of 7 interns. Although this experience could be similar to a student project, this time we had the support of the studio, and the objective was to make a game that was destined to be released, and for which we had to take into account numerous features such as localization, successes, different configurations, keyboard/joystick support, and so on.
This very short timeframe led to a number of design choices in order to get to production as quickly as possible and concentrate on the essentials. So we came up with a game with a roguelite feel, featuring a series of runs through enemy-filled rooms. Between runs, you earn resources that can be used to buy the game's five weapons, eight skills and statistical upgrades. Add efficient enemies to the mix, a few LD elements and that's about it for the time available.
The challenge for us was to create enough replayability by making these elements as interesting as possible. For example, here are the weapons:
Disruptor: a shotgun that encourages hand-to-hand combat, an easy-to-master starting weapon.
Bouncing Betty: a machine gun whose bullets bounce back, increasing damage and inviting you to use the walls.
Kaboom 3000: a mine-laying weapon, which can be detonated after three mines have been laid - powerful but very risky.
Maelstorm: sends shots automatically all around the player, who can recall the projectiles towards themselves like a magnet, increasing their damage and inviting the player to line up between their shots and their targets.
Nova Cannon: a sniper that takes time to charge a straight energy beam that passes through shields.
Each weapon is very unique in the gameplay it offers, with damage and rate values changing drastically as well, giving the impression of playing a different game every time. Coupled with the skills, the intention was to ensure that there were elements to be discovered in the game over several playthroughs.
To understand the design of these weapons, we also need to look at the enemies for a moment. There are many different types we could talk about, but I especially want to take a moment on the enemy we used to call the "jackpot". This was an orb that moved towards the player like the other enemies, but caused an explosion when it was killed. This was at the heart of the game's concept, and added a little salt to the experience. In fact, these enemies are placed in large numbers behind the others. The player's objective is to reach this enemy, kill it and cause a chain of explosions with the other enemies of this type nearby. The gameplay is a kind of brick-breaker, in which you have to place a projectile correctly to achieve devastating results.
And each of its weapons interacts differently with this mechanic, the shotgun inviting you to get close from one side to make it explode, the submachine gun to find the right bounce, the mines to wait for the jackpots to be placed on them, the maelstorm to align the jackpots between the shots and the player, and finally the sniper to succeed in aiming at it by charging the weapon correctly.
Among the design team, we designed the game together and then split up into two for programming, one for LD and one for UX. I was in the programming duo and my main task was to make all the game's enemies and the code surrounding them. I'll mainly be talking about that in this section. The project began with a first prototype that I made between design meetings to evaluate the idea of explosion chains with a brick-breaking feel:
We were fairly confident that the concept had potential and would fit in well with short production runs. But the main perceived problem was a performance risk linked to the number of enemies and the fact that the game is in 3D, and therefore uses skeletal meshes which are likely to be very costly. To gauge the seriousness of this problem, I carried out research throughout the early stages of the project.
After looking at various solutions, we decided to implement vertex animations for the enemies, turning them all into much less expensive static meshes that are animated through their material with vertex displacement textures. To find this solution, I consulted UE5's Matrix Awakens demo, which uses this method, and I started from a utility proposed by kromond on Github, which I slightly improved to make it fit our needs.
This first direction was the most convincing compared to other plugins such as MassEntity, and proved to be sufficient, when combined with other enemy optimizations such as having them spawn in a pool and using squad logic to manage them.
The squad logic was handy for optimizing calculation - the squad calculates for all the enemies in it, rather than each enemy doing so independently - and also helped us with gameplay. In fact, we wanted the jackpot enemies to hide behind the others, so we needed the opponents to maintain a squad formation when they moved. For this, I did some research on the RTS side, notably with this article:
Group Pathfinding & Movement in RTS Style Games by Dru Erridge.
As for the rest, a good part of the work was simply programming the game's dozen or so enemies, which turned out to take less time than expected thanks to good code recycling. All the enemies inherit a basic enemy with the essential code on which I add or override special behaviors as needed. Here's a video of the project in mid-production, highlighting some of the enemies:
My last main task on Sentinel was to manage the project to ensure it ran smoothly. We organized ourselves into 10 one-week sprints, with a sprint review on Friday, followed by a sprint planning to prepare for the week ahead. Complemented by dailys, we had the information we needed to work efficiently without wasting precious time. I would lead these times, reporting the tasks afterwards in Azure DevOps, which we used for this purpose as well as for documenting our project. Unfortunately, I no longer have access to this tool, but I still have some additional spreadsheets that I made at the end of the project:
