Water Works
Hammer (Source) // Half-Life 2
Systems, Layout & Flow, Combat
Level Summary
“Water Works” is a single-player level created for Half-Life 2 focusing on Alyx and Gordon leading a raid on a Combine hydroelectric plant on the outskirts of City 17.
The player must their Gravity Gun to manipulate water levels around the facility via a magnetic sheet to control water flow from pipes and vents in an attempt to destroy the Combine’s dam.
This level was completed following rapid iterative development practices. Level parameters include:
5-10 minutes of gameplay
2+ major combat encounters
1+ multi-step puzzles
2-3 enemy types
1-3 weapons
3-5+ significant gameplay areas
Design Goals
Unique Mechanic
Create an original “dynamic” water system that feels like it could exist in Half-Life 2 base game
Verticality
Prioritize meaningful opportunities for vertical traversal that supports rising and lower water levels
Satisfying Level Flow
Guide the players through the level with an “invisible hand”, all oriented towards the dam hero piece
Implementation Details
Unique Mechanic
Inspired by the various physics puzzles around the Half-Life 2 base game, I developed a mechanic that faked a dynamic water system as the player uses their Gravity Gun to add and remove special magnetic sheets from vents. This was a challenge especially because this iteration of the Source engine is BSP-based and does not have dynamic water. I was able to make a reasonably convincing system through some careful scripting, as well as tweaking timings and conveyances such as particle effects and indicator lights until it felt just right. Ultimately, this mechanic was robust, fit my level’s design well, and feels like it could reasonably exist in the Half-Life 2 base game.
Satisfying Level Flow
I wanted to capitalize on the fast-paced & smooth movement offered by the Source engine, and a key part of that was establishing a solid level flow. The level layout required a good amount of iteration up until finally locking just before alpha, but ultimately ended up in a solid place!
Verticality
I really love verticality in all things, and it can be extremely easy for it to be forgotten in video games (I have some great memories of people not looking up in Team Fortress 2!). I focused on verticality from the beginning so that it would be well-integrated into the level, which ultimately led to making the dam hero piece into the final arena of the level, serving as both a “wow” & and gameplay moment. By focusing on verticality, I created some fun moments that enhanced the core level flow while helping the player feel powerful.
Design Process & Iteration
In order to make a Half-Life 2 level, I first had to play Half-Life 2! During pre-production, I played through the base game, analyzed other custom levels, and created some action blocks in order to get a feel for the Hammer editor. Part of this process included deconstructing all systems in HL2, which you can view here!
Once I had a thorough understanding of the game I was designing for, I was ready to dive in! My favourite parts of Half-Life 2 were the various physics puzzles, and I knew I wanted to expand on this in some way. I also love the power of water, and realized the base game touches on water interactions a little bit, but largely does not explore gameplay around these. With these things in mind, I drafted an LDD with the goal of creating a mechanic that uses the Gravity Gun to change water levels.
My first time creating a level of this scope, I definitely had my share of learning experiences along the way; yet, by following rapid iterative practices, I was able to quickly and effectively process stakeholder feedback to make steady improvements throughout development.
One such key iteration was the water mechanic itself. Although my stakeholder agreed the idea held a lot of potential, my proposal ultimately lacked specificity. This slowed me down in the whiteboxing stage: while I thought I had adequately thought through this new mechanic, I quickly discovered I needed to be much clearer in the rules I was defining for this mechanic, and how it actually worked.
A key interaction that changed pretty late in development was an interaction with electricity. In hopes of adding depth to the puzzles, as well as provide an additional challenge for both the player and the Combine forces, I created a system that electrocuted the water if a sparking cable was touching it: player would then have to figure out how to turn off the electricity without getting shocked. However, after lengthy discussions with my mentor, I decided to cut this feature around the “beta” stage of the level. While I was sad to miss out on this potential depth, the water level mechanic still stood on its own, and this ultimately made the level more focused.
Before being cut for scope & focus, an additional interaction with the water was electrocution. This provided an extra challenge & tool for the player, and additional hazards for the Combine
The level flow also changed quite a bit throughout the first half of development. Part of what makes Half-Life 2 feel so good to play is the quick and fluid movement offered by the Source engine, and I wanted to play into that both horizontally and vertically. I tried various configurations of the player entering the level; while the dam was always remained around the same place as the level’s hero piece, I ultimately decided to have the player enter the level with a side view of the dam so they could 1). more easily see the entire level, and 2). see their immediate sub-goal (the sewers) more directly.
Level Layout at Whitebox: an okay start, but very linear & segmented
Final Layout, halfway through development: more natural with better “backtracking with a new perspective”
A final key iteration was how the main “water levels rising and lowering” mechanic was conveyed to the player. While originally designed to be pieces of scrap metal that could be used to block and release water vents, I found through playtesting that players had a much clearer understanding of the mechanic when I created a “magnetic-looking” custom physics object. Combined with red & green lights to help show the state of the turbines, and leading lines connecting the turbines to the dam, players’ understanding of the mechanic vastly improved throughout the beta sprint.
The “Water Blocker” Sheet’s first iteration: non-descript & blends into surroundings
The final implementation: player understanding increased when sheet made to look magnetic, paired with leading lines & indicator lights
Post-Mortem
What Went Well
Application of Feedback
My design changed drastically between the beginning and end of the project – and even quite a bit between each milestone. I think I handled feedback really well – particularly from my stakeholder, but also my playtesters and peers. I trusted them and it guided the level to a much, much better final product than my initial design.
Stakeholder Communication
I did a good job keeping the stakeholder well-informed. We met 1-on-1 every week, which was a great chance to discuss the design with him as it progressed, but I also sent him emails asking questions about significant design changes throughout the process.
Time Dedicated
It’s a bit of a good thing and a bad thing, but I felt like I gave this project the time it deserved and needed. I didn’t shy away from learning Hammer as quickly as possible in the beginning, and that helped me work faster later on – which was definitely needed, as I was overscoped.
What Went Wrong
Scope
As mentioned to the left – I was overscoped. Cutting the electricity supplemental mechanic in the 11th hour may have put me in scope, but I was probably still a bit over. I think the big thing here is that I didn’t want to admit that I was overscoped – I wanted to power through it. I kind of did, but it was not healthy.
Family/Sickness Time Budgeting
I had a family event the weekend before GC, and fell under the weather the week of Thanksgiving, which I was counting on as valuable time to work. I was able to power through some of this, but I definitely lost some critical time here. The lesson here is to budget in that buffer time rather than assuming everything will be perfect or ideal conditions throughout the process.
Being “Hand-Wavey” Early
As discussed with my initial design presentation, I was too “hand-wavey” with my mechanic for far, far too long (though I guess it shouldn’t be hand-wavey at any point). I knew generally how I wanted my mechanic to work but I wasn’t able to nail down the specifics of it until later, which was a major setback. I had a similar problem with the setting, and justifying why the puzzles would exist/how they would function in this setting.
What I Learned
Focus my Scope
I think I have a frequent scope problem. Although I was very reluctant to cut the electricity, I do think it made the level better and helped bring it into focus more. Being overscoped in Hammer was pretty rough – I spent a LOT of time on this project, and still didn’t accomplish everything I wanted to. I think this is the most important thing for me to remember going into Fallout.
Flow is Critical
Although I spent probably longer than I should have on it, I think it was very valuable for me to spend the first couple of milestones really focused on the flow of the level. Once I finally “got it”, it was a frequent positive comment for playtesters, and looking back through the milestones, I think it set the foundation for the rest of the level.
Playtest Often
We already knew this in theory, but this development process really hammered home the importance of playtesting often. There were many times throughout the process where I felt like the level wasn’t presentable – and sometimes it genuinely wasn’t – but I should have pushed through that more. Since Hammer is so robust, it’s also easy to break if you don’t implement it correctly. Having others playtest for me sooner may have caught some of my issues much sooner.
Gallery
