Try the wrong way first

This is counter-intuitive. Many times you have more than one possible solution for a certain problem. One solution has a greater chance of working, say 80%. The other has a lower chance, say 20%. Sam tells that, sometimes, going to for a solution that intuitively has a low chance can lead to unexpected grounds and that is a good thing. Sometimes the unexpected is a positive outcome. Development is an iterative process after all, isn't it? There is always some room to make mistakes and that's what Sam is telling. Mark Rosewater shares a similar view in which both say that to not take any risks is a bigger threat than to allow yourself to take risks.

I have a mathematics wiki and one of my personal beliefs is that the way mathematics is taught at school and college is wrong. The mistake is that people are conditioned to believe that the wrong answers have no value, while mathematics strives to be right at all times. People are taught that they have to focus on what is right, because wrong calculations are wrong and should be discarded. That leaves people with half answers because when a solution is wrong there is never room to question it. Why is it wrong? Most of the time the answer given is "because it is wrong". When a company makes a game and it doesn't work, there has to be a better answer than "because the players didn't buy it". I've read dozens of articles that the folks at Wizards published about making magic cards and over time you start to notice that there is one piece of truth that is deeply rooted in reality. Mistakes are mistakes because they happened in the first place. A mistake cannot exist if it never occurs. How can you know if something is right or wrong if you never try it?

What Sam discussed about trying the wrong way first is rooted in cognitive bias. There is something in everyone's brains that, when people have two different choices to make, the safer choice always takes precedence over the other. I don't have knowledge about that, except that cognitive bias is one of the things that explains why people take risks or not. Why are people more prone to do this or that under this or that condition. I could say that if a company is going to make a game, which game is more likely to be made: option A, a game for a genre that is growing fast and attracting more and more players; or option B, a game for a genre that is being forgotten, with very few players playing it? For almost all sane reasons that one could think of, option A would be the primary choice. While option B would be the bad one.

Can that related to level design? Yes. Imagine that you are good at making realistic levels based on cities, office buildings, subway systems, farms, old villages, etc. You aren't good at making abstract levels based on fantasy realms or another dimensions. If you were to start a project right now, which one you'd be more likely to choose? Probably the safer one, realistic. Because you are comfortable with it. Stretching this a bit, imagine that somebody wants to challenge himself or herself. Pushing its own boundaries to the absolute limits. Some people want to challenge themselves and get out of their comfort zone. In extreme cases this can be dangerous, as in the case of people who are constantly putting themselves under life threatening or risky situations. In other cases it can be somebody who is striving to be original and is always betting on unsafe options, such as always trying to build levels which he or she is unable to accomplish due to the lack of skills. Unfortunately I can't provide advice here on what to do in such cases.

I'd say that the more experienced you are, the better you are at making judgments. Sam is not telling that people should always try the wrong way first. No, he isn't stating this as a rule. He is talking about the value that is often missed in never trying things that aren't the safest ones. To always stick to the safe bets has a hidden risk. That's his lesson.

Change is good... and frightening

One of things that shocked Sam the most was how a set could begin in a state and after the developmental process it went through, end up in a completely different state compared to where it began. The design team produced a set of cards and handed it to the development team to finish the job by adjusting costs, tweaking numbers and so on. He tells that there is a threshold between changing the set too much and too little. The development team certainly cannot reject everything and change all the cards and they also cannot accept everything as it is because the final product is not ready yet. He tells that the beauty of the whole process is how something that you loved in a set can, one month later, be called out as the worst of the set. It's an awkward feeling as he puts it. Ultimately, the players aren't going to know how much sweat, tears, joy, anger, rage, etc the developers went through before the set hits the stores.

From what I read about game design it's the very same process. Sometimes the game reaches the stores and is highly praised, but the players have no idea of how much it has changed since its inception. Mark Rosewater in his lessons tells that often you need to cut out things from your project. That something can be great, wonderful, but it has to serve a purpose in the set's context and if it doesn't. Cut it out. The same thing applies to level design. I understand the part that Sam discusses about being attached to the things that you are working on. If you are deeply attached to a level, or a game for that matter, you really care about it. Letting it go is not easy but sometimes we have to learn to let it go. You are building an awesome level and investing huge amounts of energy into it. Abandoning it because it doesn't fit into the game or theme can feel devastating.

This certainly relates to some metaphors regarding "to renew" or "to refresh". Sam began his lessons discussing the importance of the process to reach the ultimate goal of making the best possible game. Yes, to renew, to refresh, to abandon old things in favour of new things, that is a process in itself.