Dog On Patrol

Quest Details

  • Software: Hammer++, Half-Life 2 Episode 2

  • Development Time: 80 Hours

  • Average Playtime: 15 minutes

  • Design Focus: NPC Scripting, Enemy Combat Systems & Design

Quest Summary

Dog on Patrol is a single-player Half-Life 2 level in which the player helps D.O.G., a pet-like automaton, escape an abandoned shipping and garage center. They are also being hunted down by a sniper in a central tower and must create cover for D.O.G.to find a path out of the abandoned facility.

Design Goals

Recurring Nemesis Type Enemy

Develop a recurring enemy in the level that is always hunting down the player. This will help to create a consistent tension between the player, puzzles, and enemies throughout the level.

Companion AI Interactions

Create unique interactions with ally NPCs where they can help the player progress through the level by interacting with items around them to empower the player.

Interactable Environmental Combat

Design environments with interactive elements that alter how the player navigates the level and deal with combat scenarios. By incorporating the environment into combat scenarios, the player can have a more engaging combat experience.

Recurring Nemesis Type Enemy

In this level, I implemented a unique ‘Sniper‘ enemy that follows the player through the three main sections of the level:

  • By doing so, I created a constant gameplay tension throughout the level for the player.

  • By interacting with the environment, the player can block the sniper’s gaze.

  • D.O.G. will often not complete actions without the player blocking off the sniper first.

Companion AI Interactions

In this level, I programmed a unique ally NPC named D.O.G. to help out the player throughout the level.

  • This means that at certain points throughout the level, D.O.G. will throw items like explosive barrels to the player to help them blow up walls and enemies.

  • I also programmed D.O.G. to require help from the player at times as well.

  • D.O.G. will not move or perform further actions without knowing that he and the player are safe.

  • This unique behavior was all created in the NPC and the level using a combination of triggers and scripts to make D.O.G. feel like he was reacting to the player’s actions throughout the level.

Interactable Environmental Combat

In wanting to create dynamic combat sequences in which the player was able to engage with enemies in unique ways:

  • I created wooden boards all along the walls that could be broken down to crush enemies against the wall.

  • I added lots of physics objects that the player could use to throw at enemies

  • More wooden boards were implemented along the exterior wall facing the sniper to allow the player to create cover from the sniper.

  • Large cranes with breakable rope/hooks were implemented as more useful cover from the sniper.

Postmortem

What Went Well?

  • Planning and working on passes for the scripting and gameplay went well, especially towards the end of development.

  • Working on a lot of custom scripts to get both AI and interactable environmental objects working well taught me a lot about scripting in Hammer Engine and created some impressive gameplay moments.

  • The D.O.G. AI companion was made relatively stable due to a lot of checks that made sure not to interrupt or confuse the AI while it was attempting to complete a task.

    • These checks included making one of the quest objectives to create cover for D.O.G., so he wouldn’t get shot by the sniper, not allowing for more than one explosive barrel to spawn at once at each explosive barrel station, and making all out-of-bounds map sections automatically explode any explosive barrels. These measures guaranteed that the D.O.G. NPC AI would never be confused by combat triggers or multiple, conflicting points of interest.

  • D.O.G.’s interaction with the environment around him made both scripting impactful gameplay moments easier and less buggy.

    • By simplifying D.O.G.’s functions and adding more complexity to the environmental effects, I was able to lower the number of possible points of failure in D.O.G.’s behaviour throughout the level.

    • One example is when D.O.G. throws an explosive barrel at a wall to break it, which only needed a simple target switch from the player to a specific point on the wall to achieve.

What Went Wrong?

  • The aesthetic portion of the level was difficult to get up to the same level as the gameplay. I spent a lot of extra time at the end of development, trying to make the level look better.

  • Conveyance of key gameplay elements and new mechanics could have been executed better, especially with more playtesting.

  • I ran into many issues with the D.O.G. AI companion getting confused when the player lost the explosive barrels or used them in a way that wasn’t accounted for in the scripting.

    • If D.O.G. threw the explosive barrel, but it did not reach the player, D.O.G. would often not be able to register where the explosive barrel had landed and pick it back up again. This led to many different failsafe triggers being coded in so that D.O.G. could recognize when the player wasn’t able to reach the explosive barrel. This still ran into some errors with D.O.G. getting confused, though, so a further preventative measure had to be put into place by just making the fences shorter to guarantee that he would more often than not be able to successfully throw the explosive barrels to the player.

    • This solution still had issues with players being able to potentially bypass D.O.G. by throwing the explosive barrel over the fence themselves. This was remedied by having the sniper blow up the barrels if the player hadn’t created cover for D.O.G. to walk over and throw the player an explosive barrel.

What I Learned.

  • Planning out a more balanced development schedule for working on and planning aesthetic polish for the level throughout development.

  • Doing many more playtests and getting insight from other designers would help alleviate a lot of the issues around trying to solve conveyance.

  • It’s important to have thorough and detailed action blocks when designing for AI companions.

    • Having detailed action blocks would have helped me catch strange edge cases and bugs much earlier in development, and would have influenced how I design a level to optimally showcase an AI companion like D.O.G.

  • I learned that, when dealing with D.O.G.’s AI behavior, it’s important to design around not interrupting D.O.G. during his scripted actions or when he’s idle. Any minor possible disruption will completely shut him down and soft-lock progress for the player.

  • With D.O.G.’s scripting, I also learned that it’s best to keep things as simple as possible in terms of him not receiving a lot of triggers or commands. Rather, it works out a lot better if his scripting and actions affect the environment more than they potentially affect him.

GALLERY