I remember being 6 years old, sitting at my family’s computer , trying my best to use KidPix v1.0 for hours on end. I’d draw little game worlds and characters, and redraw parts to create motion in an imaginary game. The imaginary games were often physics-based; for example, a ball would roll through a maze filled with little traps. We didn’t have a powerful computer at the time, and the idea of spending money on a game console was hilariously out of the question. So I made due with what I had at the time.
The idea of a physics-based game has stuck with me well throughout my childhood. Up until a cancer diagnosis took me out of high school and put me into the hospital, I’d make Rube Goldberg machines out of K’nex pieces that spanned the width and height of my entire childhood room. Physics, I felt, was the ultimate puzzle to solve.
TRIAL BY FIRE
In early 2017, I started learning C# and Unity, for an experimental project within the small agency I co-founded, Vault Labs. It started out a bit rocky, but after trial and error, I quickly realized I wasn’t a half-bad coder. So, I decided to plan out a full game project as a way to build on the momentum and skills gained in that small project. And of course, physics was the first place my mind went when brainstorming.
The first version was rough to say the least. The horrible image above, with the painful lighting effects and blinding orange, was from the first playable version. The best thing going for it was some bouncy physics, mostly thanks to Unity doing the heavy lifting for me. The game had no UI, a crudely designed character, and the jankiest controller for moving around.
Over time, I refined the character controller, did a complete “start from scratch” on the game art, and incorporated lots of feedback from play-tests. It started to feel like a much more organic world that could possibly exist. The lighting got pulled back, the impacts felt more weighty, and proper sound design was implemented.
As new challenges came up to implement, I found myself getting a lot faster at writing C# in Unity. I began making my own internal docs for some of the more complex scripts I was writing, and I became absolutely religious about commenting code. Elements of the game that I thought were impossibly complex became very achievable.
Here’s two examples of early refinements:
Below, left: When you sling Harlow around, the camera will react to your velocity and zoom to give you a better look at things when you’re moving quickly. When you’re stationary, it’ll zoom in a bit closer. This can be set up to react to environments as well, such as if you’re in a narrow corridor - zooming the camera in can help things feel appropriately claustrophobic. Instead of using Unity’s default “Timeline” camera system (which is quite good, don’t get me wrong), I made my own system to get the tight control I desired.
Below, right: When aiming Harlow, his eye will squint proportionally to the power of the jump you’re aiming. Additionally, in this gif, Harlow knocks a sparking wire out of a pool of water, making it temporarily safe to enter. When the wire falls back in, the water is then electrified again, and Harlow short-circuits as a result.
Below, large & bottom-most: Some dangers in the world are sentient. This spider’y large robot is controlled by a dynamic AI and procedurally moves around with no hard-coded animations. The two “attacks” it attempts were instructed to miss by a certain factor relative to Harlow’s position.
The future of harlow
Harlow is very much still in active development, and will be released in 2019. It’s been a labor of love to learn development while producing a game, and I’m excited to put it out in the world. If you want to read more about the game, or want to keep updated, check out the site at playharlow.com