Happy New Years, everyone!

A lot has changed for me in the last month, and the new year is feeling pretty great. In December, I left my job of 12 years to join a local Portland game studio (Rose City Game). Along with the new job, I’ve rearranged the home office where I spend nearly 12 hours every day. Unfortunately, all the change along with holidays afforded me little time to focus on Motel Styx. Thankfully, life is starting to settle down and I’m coming back to Motel Styx, so I figured it's a good time to write a dev journal recapping where development is.

Design

The design for this game is complete. It consists of 13 puzzles in three different zones. The puzzles have been designed on paper and reviewed with my partner, Lynne. However, it’s safe to assume the design will change once things get fully implemented. Having the design complete before I get too far into development has been a great way to stay focused on what matters.

Modeling

In October and November I made a good attempt to get all the models for the game built. I’ll have a few to build before I’m done, but I built a great pipeline for creating and importing 3D assets into the game. Here’s are a few that show off the look:

Writing

This game is a narrative puzzle game, so the script is pretty central to the experience. It’s a series of 3 very short stories, and I’ve had a draft of them for 2-3 months now, but there are holes and it’s best for them to go through a couple more drafts. Still, I’m confident in the concept Lynne originally wrote. For now, I’m not delving too deep into writing until after sorting out higher priority items in development.

Development

Development is a big category, but it’s where I feel the most comfortable. With 13 puzzles to build, I’ve been focused on mechanics that are shared between a number of puzzles. That starts with locks and keys.

The Scale Problem

All the models in this game are real-world scale. That's not a common choice in games since real-world objects can be too small or too large to look good from a 1st person camera.  Often you’ll see guns, cars, doors, and keys changed in scale or positioning to accommodate readability.  Still, I want to stick with real-world scale and see where it takes me. My intuition tells me it might benefit the immersion and puzzle design.

But as soon as I got objects into the game, I started seeing issues. The screen shot below shows the player a few feet from a surface with a key on it. The surface is the height of a low bedside table (0.6m). Can you see the key? I’m having trouble and I put it there.

Since finding keys is critical to multiple puzzles, I have to solve this problem. 

I could scale up the key or put all keys in easy to see places. But these solutions could compromise immersion. I could allow players to zoom their view or crouch, but those require more explanation than I’d like. I’d prefer mechanics to be as intuitive as possible. As little explanation as possible.

Then I played Inscryption and saw how flawless the camera felt in that game. Like Myst and other puzzle games from the early 90’s, Inscyption has a series of static camera positions. I'm not going to abandon a free-moving 1st person experience, but seeing that mechanic reminded me that games often communicate to players by limiting what they see/interact with.

With that in mind, I decided to implement a mechanic to allow the player to look closer at game-critical components.

As the player moves around, the reticle becomes an eye when over certain areas. When clicked, the view zooms in on the area. In this new view, the player can look around, but can’t move around. In the gif above, the key is center frame. But the key could be hidden behind something, among a jumble of objects, or in a drawer. What important is the player’s view is controlled by the game when in this closer-look mode.

Lock and Hasp

A few puzzles include padlocks, so I wanted to get the closer-look mechanic to work well with unlocking a padlock. Again, padlocks are smaller than you might expect, so I needed to use this closer-look mode. Here you can see the necessary animation that tells you “nope, it’s still locked”.

The next question I had was: how much detail is needed in the unlock animation? I don’t think players want to sit through 5-15 seconds of pulling the bottom of the lock into view, pulling out a key, inserting the key, turning the key, having the lock pop open, carefully maneuvering the lock off the hasp, putting the lock into hammerspace, opening the hasp, and opening the door. And I didn’t want to spend 5 hours animating all that. So I spent 3 hours making a shader that could dither-fade the lock after it pops open.

It feels smooth, clean, and effective. Additionally, this same shader will now be used for a bunch of different animations. Here it’s used to subtly fade in and fade out the key that opens this briefcase:

These are definitely problems others have solved before. But there’s still satisfaction in the learning and the doing.

Wrapping Up

I think that’s a fair look at where this game is at. I'm sure I'm glossing over a bunch and there are plenty of things I’m not showing to keep them secret.  But I think this log shows that a lot of foundational elements are done and I’m focusing on building mechanics, animations, and interactions that will make up the core game-play.