ID:111613
 


Failing well

Happens to be one of the greatest skills I've come to acquire in my time. It helps me retain a level of class, even when things go horribly wrong for me, helps me to cater to all needs when things are out of my scope and helps me just feel overall better about a situation where in reality, I've kind of duffed it.
But what really is Failing successfully? In order to answer that, we need to take a look at what failing unsuccessfully (Hence known as Crashing and Burning) is, and how to avoid it.


Crashing and Burning

Is the action of completely giving up on something and moving on. Now hold the phone right there, before people start complaining to me and mentioning how 'They can't possibly of failed that badly, if they simply moved on!'. WRONG. Trust me on this, for I am the fail master. A fail is anything you do wrong. Anything you set yourself up for, which ultimately is never achieved. For example:

Paul wants to make Epic Jim's Adventure (Who wouldn't?)
He sets up his Game design, gets a good team in (Himself the programmer of course, because he wants all the glory!)
He decides, players can have multiple save files!
A frustrating week later, he decides that he cannot possibly manage that, leaves it at one save, and continues with the project.

Would anyone say that he didn't fail there? Even if he did persevere, he still ultimately ended up crashing, but did he burn?
Of course he did! Did nobody notice, the moment Paul couldn't do what he wanted he gave up on it. This is rule 101 of avoiding crashing and burning: Compromise!
Let's look back at our friend Paul, and see what he could of done right:

In between 'A frustrating week later' and 'leaves it at one save', we need to make a few ammendments.

First: Paul goes to the forum! Don't feel bad because you're asking (Or searching!) for help, if nobody asked for help, nobody would learn (Even observing, is asking for help in my book).

Second: If the first option crashes and burns, Paul looks at what he's already got, and decides on how he can make small improvements to it, for example (Although I wouldn't recommend this): Change the save system so that it saves on the clients computers, and teach them how they can easily swap out those save files. That would turn a crash amd burn, in a successful failure.

Lastly: Paul made sure his already huge playerbase is happy, people hate it when they don't get planned updates. There's a hundred different things Paul could do, but he decides to stay in the same functional area, and instead designs a whole new login scheme with easy to use loading and new character buttons. Players are happy, and Paul's winning at failing.


If one fails at failing, has one achieved a successful failure?

Interesting philosophical theory there, but in this instance the answer is an outright no. Failing successfully is the foundation of progress, and for me it's completely vital that I utilize it properly whenever I can. Failing successfully isn't only attributed to programming though, you can fail successfully practically anywhere that you find yourself unable to achieve something, a few (fairly random) examples:

I can't scale this wall, but I can paint a picture over it to make it prettier!
I can't beat this boss, but I can learn more about his technique and plan for the next time.
I can't program very good AI, but I can at least make it to the best of my abilities, and make the combat itself intuitive and fun.
I can't X, but I can Y (Where Y is relational to X and beneficial).




So I urge you all, go out now, go and fail, but fail to the best of your abilities. Compromise!
this sucks
FlashRun wrote:
Disregard me I suck cocks


GO BACK TO PROGRAMMING HOBO.

Just because you never fail ;*;
I found it interesting. Should be helpful to others, and a great inspiration as well!
He decides, players can have multiple save files!
A frustrating week later, he decides that he cannot possibly manage that, leaves it at one save, and continues with the project.

As long as the developer continues on with the project I wouldn't call it a complete failure. A lot of people abandon projects for silly reasons (lack of an artist, lack of good game title, etc.) so they don't get to experience the entire development process.

If you quit easily and have never had a project more than 30% complete, your next project probably won't get much past the 30% mark - once you hit that point you start getting into unfamiliar territory and you're bound to run into problems. If you can skip a feature and continue with the project you'll get better experience because you'll get to see more of the development process.

I can't X, but I can Y (Where Y is relational to X and beneficial).

If you can't make X, Y might be a good substitute, but it seems like people often settle for the substitute, Y, without even trying to make X. I don't think your advice is bad, but people on BYOND are quick to compromise. This is especially seen with AI - people can't make AI so the game is called "multiplayer only". I'd change this statement:

I can't program very good AI, but I can make the combat itself intuitive and fun.

To be: I can't program good AI, but I can program bad AI or improve the AI that I have. Maybe the initial attempt at AI is so bad that it doesn't get included in the game, bit it gives you something to work on and improve.
Forum_account wrote:
I'd change this statement:

I can't program very good AI, but I can make the combat itself intuitive and fun.

To be: I can't program good AI, but I can program bad AI or improve the AI that I have. Maybe the initial attempt at AI is so bad that it doesn't get included in the game, bit it gives you something to work on and improve.


That's a very good example of me failing, now to fail well.