top of page

GRIDHACK: Simple stealth implementation

This was originally a thread posted in November 2022, but I thought I'd turn it into a blog post for prosperity.


Today’s Dev Deep Dive is about Stealth, aka implementing a Security Camera that can detect the player! As I’m still pretty new to game dev, this will probably be more interesting for people who are new to game dev themselves or people outside of it. So let’s begin:


As the main gameplay mechanic in GRIDHACK is hacking, I have to come up with a lot of hackable devices that can also offer exciting gameplay. The security camera is a perfect example of this:

1. It’s familiar to players from games like Metal Gear, Deus Ex, Cyberpunk 2077

2. It’s relatively easy to implement

3. It fits GRIDHACK’s world and gameplay.


By the way, there's now a Steam page for GRIDHACK! Would mean a lot to me if you could wishlist it!


So at its core, a Security Camera is a Finite State Machine, meaning that it has a certain number of states, and it can only ever be in one. I’m not going into more details about state machines, but if you’ve ever encountered a Security Camera in a game, you will quickly understand this. I’m going to list the states here and then explain what they mean:


1. Offline: Self-explanatory, the camera isn't doing anything.


2. Searching: The Camera hasn’t detected the Player but is actively looking for them. This is also usually when the camera does its “patrolling”, moving its view cone back and forth. Typically, the camera starts in this state.


3. Detecting: A grace period where the Player is in the Camera’s view cone and is about to be detected. The longer this is, the easier it is for the player to escape or sneak past.


4. Detected: The camera has fully detected the player. This then might trigger an alarm, guards show up, the mission fails, etc. In GRIDHACK, this works as a “fail state”: A short cutscene plays, and then the Player is set back to a checkpoint.


Now that we’ve established this, we move to the game design part: In order for the Player to navigate around the Security Camera, we as developers need to communicate its state to them. If the player doesn’t know if a Camera is offline or actively searching, they’d get frustrated fast.

My first idea to communicate the camera’s state was via two indicators: the color of the view cone, and the color of a LED light on top of the camera. Additionally, there’ll be more indicators as soon as the camera enters the DETECTING state, as this is the most important one for the player to notice:1. A sound when the camera starts detecting.2. A progress bar appears over the camera that indicates how close the camera is to detecting the player.

Watch the video to see what this looked like. Seeing this, I quickly realized a problem. Can you guess what it is?




If you said “the progress bar is hard to see” you are correct!

In this situation, the Player is usually more focused on their position, especially in relation to the view cone, to see if they are in the “detection zone” or not. In addition, it is possible for the security camera to be completely off-screen, which would make the detection bar completely useless.

So what’s the solution?I realized that the progress bar needed to be moved to the Player character. After all, it’s the Player character that is being detected!

This ensures that it is always in plain sight and the Player can keep their focus where it needs to be.

Watch the video to see how I updated this in GRIDHACK.




Thank you for reading this far! Let me know if you liked this little deep dive, and I might do a few more in the future!

Comments


bottom of page