ROGUELITE STEALTH
Captive is a roguelite stealth and puzzle solver game. In this game you are alone in a factory type environment and you have to escape from various by connecting hot and cold generators in the room. However, be careful, as you switch a generator the environment changes depending on the type of generator. Soon, you would start encountering guards who are guarding around in the area and you would have to escape from the room stealthily. This game is still in its demo phase but I plan to create a lot of puzzles and tricky stealth encounters. This game was created in the Level Up Circle: Beginner Jam#1. This game is heavily inspired from Talos Principal and Inside
Tech Stack
- Game Engine – Unity
- Prog Patterns – Event Driven, FSM
- 3D Design Tool – Blender
- Other Assets – Asset Store
- Music – Garage Band
Event Driven Architecture
From the beginning of the implementation I wanted to develop mechanics via Event driven Architecture. The primary reason for that to have a consistent puzzle rules and also have an easier time to create puzzles by creating elements and then just dragging and dropping the elements onto my level scene. The base idea in event driven architecture is every action you do throws out an event in the world and the elements in the world would listen to it and do their own thing. This also makes the code robust as well as extensible as I can remove buttons, lava, doors from the level and nothing would break as there is no reference management needed ( like in singleton method). However, this was not always useful as when dealing with a multilayered level (1 after another) I am changing properties of elements (lava, door etc.) even on other levels which is no bueno. So, for some exceptional cases I have to add a wrapper to protect overarching level design. However, overall the Event Driven Architecture has been very useful and made it very easy for me to create different type of puzzles.
A Dangerous State Machine
I wanted to make sure that the enemy AI feels familiar with a lot of different type of stealth and still give an opportunity to open up a lot of interaction of the enemy with the puzzles laid out in the room. As of now the enemy consists of 4 states – Idle, Patrol, Chase, Kill. All these states are only activated when interacting with player and this in itself opens up a lot of opportunity of level design. In the current showcase, the only part to be concerned about is to not get killed by the enemy. However, since the state machine is extensible, I am hoping to add more states which can interact with the environment ( like drown, die etc.) which the player has to figure out how to achieve that state for the enemy. I am planning to come with some form of final boss though who would have a lot more mechanics and interaction as opposed to these guarding robots. That is driving me to use behavior tree for boss fight instead of state machines. Stay tuned for more updates on this.
Enemy Field of Vision
Wen working on field of vision, I thought how hard it could be to create one. Specially in the Game Jam time when I finished the enemy AI first and left field of vision for next day. Boy, was I wrong. Field of vision can be challenging if you want to add an interactive element to it. My initial idea was to create a shape collider and make action happen based onTrigger events. However, this creates a problem that first you can’t add more box colliders in the enemy or behaviors could interplay which can be problematic which reduces extensibility of the enemy functions ( in future if I want to add a way to hurt enemy, it would be difficult). Second, the FOV collider will go past the walls and obstacles which reduces the game design area for adding obstacles in the level for the player to hide from the enemy. So I implemented a physics Raycast solution. It is slightly computationally expensive than trigger collider but is definitely the best for the gameplay I want. I send 5 rays out from the enemy guard creating the shape of FOV with radius and distance I want him to be able to see. The rays when collided with walls, obstacles etc. can detect how far they went and the script automatically renders them to that distance. This creates the illusion of rays being blocked by obstacles ( Look on the GIF at the right). It took me quite a while to get this right ( about 3 hours, which is a lot for a gamejam). Of course, rest was easy as if the rays detect the player tag game object then they will transition the enemy guard into its respective required state.
