Theme-Mechanics Seesaw (Part #2)

After last week’s post, a few people (4!) asked for examples of how this works in practice, as well as having some other related questions.

So here are the questions I received, with the best answers I can muster:

Could you provide some examples / experiences that reflect what's in the article that happened when you made some of your games? -Zil, Andy C, Louis K, +1

Subnautica example #1: Adding “Survival” (theme lens)

When we first released Subnautica into Early Access, it wasn’t a Survival game: there was no eating or drinking and players didn’t tag it as such. But I also didn’t know what kind of game it was. I knew it was going to be non-violent and with a focus on exploration and building but I wasn’t sure what core mechanics would be about. I thought it would be “sciencey” and making the planet habitable1. The problem was, we hadn’t figured out how to make that game. It sounds boring even just reading it.

It quickly became a bigger problem because we had to plan our milestones for dozens of developers as well as tell the community about our plans. For the first time, I was working on a game that I actually had no idea what to work on next. A game that people had actually bought. We were also just barely treading water financially so we needed to fix the problem fast.

We noticed a few players asking that we add eating and drinking. I remember one review that said something like “How dare we make a survival game without food and water?”.

They were getting “Survival” game from the theme of crashed spaceship and being alone on an alien underwater planet. Obviously. I’m glad they saw it, even if I didn’t.

The point isn’t that players asked for this, it’s that the theme was begging for it. Our players were just the ones to point it out. We were directionless after approaching the game from a mechanics lens for so long. We immediately added food and water to fit the theme, and that lead to us thinking of survival mechanics. This is the “seesaw” in action.

Adding food and water

So I started pushing on the thematic side of the seesaw, instead of continuing down the mechanics exploration of terraforming and building I had been stuck in for months. The entire genre of the game arose from the theme and this lead to something even bigger - the theme of terror. All of this surprised me, as I had always thought of games largely in terms of mechanics (something I now see other designers doing). I was shocked at how natural it felt and how quickly it unblocked us.

Subnautica Example #2: Adding radiation (mechanics lens)

The opposite happened as well - where changing to a theme mindset helped move gameplay forward.

We were frustrated with players swimming to the Aurora. They start the game, exit the lifepod, see their crashed ship on the horizon and immediately jump into the water and start swimming for it. This entailed holding the W key for about 10 dreadful minutes until they finally got to their destination - a giant pixellated billboard of the ship that was flat when viewed from the side.

Thankfully I couldn’t easily find a flat screenshot from that time

We never expected or wanted players to go there, so we thought a crappy billboard was fine. We just wanted to set the stage that you had crashed. We knew we needed it there to support the feeling of the world, but there was no way we were going to solve it with same toolbox.

Once in mechanics mindset, we immediately thought how we could transform the Aurora from a thematic set-piece to a fully explorable walkable exploration area and placing the Exosuit fragments there.

We also came up with the idea of it leaking radiation - you could still swim to the Aurora, but half-way there you start to hear geiger counter sounds and started to take damage from it. This became a gate that we used to keep you away from the ugly Aurora, until you were situated with the basics - surviving, collecting, exploring and crafting. We also allowed players to repair the Aurora to fix the radiation.

Radiation | Subnautica Wiki | Fandom

These were all gameplay changes that lead directly to a problem we found with the theme.

My point is not that it’s better to approach design from either theme or mechanics - it’s that it’s useful to switch to the other when you’re having problems with one.


How would you approach *not* feeling weighed down by one side? Switching lenses anyway? - Zil

Hmm. While I do think games are at their best when they balance both mechanics and theme, I don’t think I’d be quick to interrupt smooth sailing and progress just to represent the “other side”. Keeping momentum is so important, so I don’t think I’d switch lenses. But I probably wouldn’t consider the game more than decent if I had only explored one side.

Conclusion

I’m not trying to outline a solution, but more of a philosophy. Considerations around theme and mechanics are often opposed. But they are also interdependent and somehow hold the keys to direction solutions within each other.

A conversation with my friend Phiroze led me to believe that this whole idea is very similar to the concept of “polarities”, as he recently learned from this book about “Polarity Management”. I read the book quickly and it seems incredibly helpful for untangling all of this.

The idea as I understand it is that some problems can’t be “solved”. They can only be managed. These problems are really “polarities” that are sets of interdepdent opposites, where the advantages of one often address the deficiencies of the other. Examples might be Competition & Collaboration, Team & Individual, Cost & Quality and perhaps, Theme & Mechanics.

To understand what it means to manage these problems is to see that they exist within a greater system of balance. A system where your problems are inherently unsolvable, but where you can continually shift between polarities to advance a cause. Where changes in one affect the other. Knowing that you’ll never “arrive” and but you’ll always have a path forward.

Continued from Part 1.

Thoughts or questions? Join the discussion on Discord or get in touch.