Well, I wrote a big long post on enemy design, and the only thing anyone noticed was that I lumped skill-based challenges and luck-based challenges into a single challenge type. Caught some flak for that, so I figured I'd explain in more detail why I did that.
Not too long ago, I had them separated - luck and skill, that is. It's patently obvious that they are completely distinct, after all. One is luck, one is skill. You can get better at skill, but you can't get better at luck. So on so on so on.
The problem is that what is patently obvious isn't patently correct, and over time I shifted towards the opinion I hold now, which is that skill and luck are largely interchangeable from a game design standpoint. I don't expect to convince anyone, because it's a patently absurd statement. But I'll give it a shot.
First, to be a little more precise, I don't mean skill in general. I mean physical skill. Precision, reaction speed, spatial awareness. Skills such as tactical analysis, pattern recognition, and math are not really the same category. Those are "information challenges", or whatever term you prefer.
With that in mind, when I design, in my head things move. And they move in specific ways. So if I design a game, I see the fundamental mechanics and imagery boiling or spinning or changing colors as they bounce into each other and lock together. So the framework of a game has a distinct set of characteristics. By paying attention, I can usually produce what seems like more fun play, deeper immersion. Of course, being that I'm just toying around and prototyping, it could also just be wishful thinking.
Either way, the pieces "plunk" together in particular ways. The dynamics of a game, how it moves and spins and changes, is defined by how these pieces fit together. So I think in terms of what each piece of the design adds to the whole.
What I've come to realize is that a mechanic based on luck and a mechanic based on skill both serve the same purpose in this final framework. They both act as a "scattering" agent: they push the player in somewhat unexpected vectors, allowing them to explore the gameplay "terrain" with a quick and interesting feedback loop.
This sets them apart from information challenges, which are a far slower and more deliberate piece that usually forms the "backbone" of the game. The heuristics and thought you use in information dynamics can be very deep and interesting, but they move differently and don't contribute in the same way. The player will tend to "pool" in the valleys of an information challenge, but the velocity he gets from a gamble will often take him up and over various ridges, to new vistas.
They are certainly different from puzzle challenges, which are like little gems in the framework that unfold when you touch them.
The point is that, from a design standpoint, luck and skill serve the same driving role in a game's overall structure. They cause the player to interact with the game's framework in a very similar way. Just because one spins a bit differently from the other is no reason to call them different kinds of things: a penguin is still a bird, even though it can't fly.
They do serve slightly different purposes. Skill challenges can be stacked like a long chain of revolving gears, but doing that with strong luck mechanics will end up grinding itself to pieces. So, in order to use luck mechanics, you need to make sure there's padding between them and the next set of luck interactions, or you lose all agency. That's not as necessary with physical skill, which has a more orderly and agency-filled outgoing vector cloud.
But there's that much deviation within the other kinds of mechanics as well. Mental skill challenges include a variety of types that are just as distinct: memory challenges versus analysis challenges versus spatial challenges versus heuristic challenges... they also have somewhat distinct effects on the game. However, they are all fundamentally the same kind of thing.
That's where I'm coming from: the structure of the game, NOT the player's conscious experience.