Failure is a great tool for a game designer; it is another way to figure out what we don’t want to do when we’re working on a game. Whatever part of the game design process you fall into, it’s important to be able to recognize, assess, and grow from failure, whether it’s as a programmer, mechanics designer, level designer, or even an artist.
The first thing you have to remember when you’re learning from failure is that you have to know about it. Test early, test often, test everything. Test in as many environments as possible, and as rigorously as possible. If you’re a programmer, give yourself debug tools to intentionally create circumstances that are plausible but that you don’t think will happen. If you’re a traditional game designer, play around with some out-of-bounds experiments. Make sure that everything comes together in one thing. The worst case scenario is that you discover that your game absolutely will not work with a certain functionality or element added. On the other hand, frequent testing means that you can actually find new opportunities and paths that would otherwise be unavailable to you. It also means that you’re less likely to simply run through things the same way by force of habit, though you should still externalize some of your testing either to friends and acquaintances or to a group gathered explicitly for that purpose. If you aren’t looking for failure, you won’t see how you have to improve.
Be quick to accept failure and use it to your benefit. I’ve worked on a few video games as an amateur developer, and one of the things I found most interesting is how I’d make mechanisms for my games on accident; once an error in my platforming code meant that not only did I save myself the effort of, say, writing wall-jump code further down the line, but I also created a skill-based wall-jump mechanism that was quite interesting in theory. Never discount a failure as useless, because everything that goes wrong in game development is something that could be saved for later use; a shader that goes absolutely crazy under the right conditions can be used in a controlled manner later on to create interesting effects if you don’t throw it out.
Of course, the flipside of that coin is that not every failure is productive. Sometimes failure is just a way to learn how not to do something, and while that’s okay you need to be aware of the fact that you can’t recycle everything. That wall-jumping mechanic I mentioned earlier was actually good for me because it was something I was planning to implement later on, but if I had been trying for a more serious platformer feel in my game I would have had serious problems on account of it. Likewise, that shader that goes into polychromatic fits when the lighting is too bright is likely going to look very out of place in a realistic environment.
The second core way to learn from failure is to analyze how and why you failed. If you aren’t skilled enough to know what went wrong, it’s a great time to step back and expand your knowledge and skills before you continue, so that you don’t make the same mistakes again in a later situation. If you can’t figure out a way to fix your mess, you’ll also have a very hard time applying it to a controlled environment later on when you want to use some interesting quirk in an applied setting but wind up just creating memory leaks or an infinitely scaling balance nightmare.
One of the things I first learned when I started writing tabletop games is that the ways that I think, with a great focus on order and steps and scales, doesn’t actually always help. Many of my early attempts at game design were marred by a degree of simplicity and predictability that is one of the things that I consider the great scourge of attempts to create an engaging experience, as I created linear scaling that ballooned out of control and led to some impossible to correct balance and scale issues, completely ruining the narrative of my games on account of shoddy systems design. As I continued my studies in game design, I was able to take a reflective look at how I had gone wrong, looking at probability and narrative and the ways that other games are designed and built to promote their purposes in order to create games that actually felt right, albeit were very simple, and eventually started to develop games that were capable of being enjoyable, such as my prototype for Orchestra over on StoryNexus and my more recent projects such as Ostravia.
Whenever I failed, the thing that I found most helpful was to step back, and try to recreate the exact same thing I had done. That way, I could tell if I had a method-based or execution-based error (i.e. if I’d created something that was never going to work versus if I’d made a typo). Further evolving from this point, I discovered that what really helped me most was to keep a running log and commentary of my work; something that allowed me to really go back and see what I’d done and why so that I could review it later and make improvements without compromising the integrity of my designs.
In short, if you’re a game designer in any medium, you’re going to encounter failure at some point in the process, and you need to know how to direct your progress onward. Be sure that when you fail you know whether you’ve discovered something that could be useful down the road, either in direct execution or in concept, and you go back to correct the things that went wrong in a way that allows you to confirm the exact source of the error, even if that means that you have to do a little more work throughout the development process.