You’re an engineer that has crash landed on a hostile planet. Early on your goal is to harvest stone and wood to build and fuel a smelter where you can start to gather materials. This process starts manual and over-time becomes a giant factory with high-speed trains unloading materials and drones moving them to where it goes. It is a fascinating, yet exhausting game.
This comment, in particular, got some gears turning.
When it comes to city builders and similar games (including Factorio), I’m too easily distracted by the metagame puzzle of wondering about optimal strategies. I can’t play them for long before I end up closing the game itself and pulling up documentation about the game’s rules and internals, and that usually breaks me out of a potentially addictive cycle.
It is how I, unwittingly, play most games. I try to figure out what that is through experimentation or research and then I work towards that meta. I think the process looks something like this:
- Learn basic mechanics
- Study the optimal meta
- Work towards that meta
However, I’ve been thinking a bit more about this process of optimizing for metagames. I think that it, perhaps, is something I’ve been doing outside of gaming.
Take my job as a product designer. One way I try to solve problems is figuring out how other products have solved the problem. What works? What is cumbersome? What tradeoffs were made when designing this solution?
I’ve studied thousands of different software products and am very familiar with common patterns for various features. This leaves me incredibly knowledgeable about what the metagame is for designing filters, or data tables, or CSV imports. If there’s a feature that you’re trying to implement, I can give you a dozen different ways to do it and the tradeoffs you’ll make for implementing a given design.
While optimizing for metagames is incredibly helpful when solving known problems, it is not valuable when solving novel problems. Interestingly, I think that is perhaps my primary weakness as a designer.