I've been over it many times with people, and I know every programming book on the planet will tell you that swiss-army-knife code is bad, but I still do it. Here's a good example:
I was making a Java program that was supposed to help build text adventure games from easy script files. This project got cancelled for two reasons: one, I realized that Inform is already better suited towards creative writers, and two, if you wanted to make a text game in a readable scripting language, you have options already. That being said, I never got past designing the thing. Because the design just kept getting bigger!
First you were just going to script the thing and it would run in a console. Then I decided on a front end. But to have a front end, I needed some standards, like... during dialog, maybe pop up people's faces when they talk automatically. Hmm, I thought, but what if someone doesn't want to do that? Oh, I know, I'll make a super generic front-end and people can subclass it.
Then... maybe people could just subclass it, build the Java binaries and drop them in a folder for me to automatically pick up and add to a menu. Oh! And while I'm at it, they need to be able to do ANYTHING with their front end, so the game should be able to communicate with it via back-and-forth string communication. Now we're talking! I should have stopped at "I'll make a front-end". And I won't even go into my scripting language and its ability to accept commands out of order (good gravy.)
This is a pitfall of programming. Wanting to please your audience is normal, but its hard to remember that you -are- your audience in this particular industry. In all honesty, I pick up code and don't judge it much at all until it annoys me. I just figure out how to make it do what I want and then I do it, and there's always a way when you have the will. So on my current project - the first open-source phase of a commercial mega-project - I'm going to try and force myself to be stricter. I think I may get something done this way.
0 comments:
Post a Comment