Friday, April 12, 2013

Code and Design

These two are not the same. Well duh, one's code, and the other one's design. Except that it's not that easy. So let's talk game design.

There's Code, and Then There's Code

When people talk about code in the context of computer stuff, they think about this:
int doSomething() {
   foo;
}
Or whatever your syntax looks like. But code, in this context, can mean everything that tells an engine what to do. RPG Maker event code counts, some engine's script language counts, everything counts.

Look at me, I know Java!

But there are people who think that code's strictly lines of keywords, characters and names that you stick into a compiler/interpreter. Everything else is below them, and they're somehow better because they know a programming language. I once encountered someone like that in an RPG Maker forum where he had presented his game. It was, in fact, coded in Java and looked hideous. He brushed off all criticism on the basis that he knew Java, and therefore his game was better than the others.

No. Even if it was the most beautiful, efficient and maintainable Java code ever, it still looked hideous. That has nothing to do with the framework/engine it's based on.

Also, I'm pretty sure that I know some people who never touched a programming language, but still have a better idea of how programming works than some programmers. Analogy of the day: Just because I don't speak your language, that doesn't mean I'm a bad writer.

Pretty Good Coder, But...

Now let's assume you let go of your programmer hubris. You're just good at whatever you use to code, and you go on to make your game. Since the main screen works, you build, let's say, a menu in beautiful code. You go to a related forum and post a screenshot, or maybe a short video. After an undefined time of F5ing your browser, you get a reply. It's full of how your menu just isn't good. But... but... it's flawless. It doesn't have a single bug. You considered every single thing that could occur.

Then your problem's not the code. It's the design. Design, much like the ability to make good code, transcends platforms. A crappy menu will always be crappy, no matter what it was made with. But still, both have hardly anything to do with each other. Just because you're good at one thing, that doesn't mean you're good at the other.

The Difference

Now, as I said in the beginning, code and design are different, even though they have a few things in common.

Visibility: Unless the player has been in programming long enough to turn into Neo, they will not see the code. Like all background mechanics, as long as the code works, it isn't noticed. The only time the player will actually see the code is when the game glitches up and throws an error message at them. That's another reason why the engine doesn't matter. People are, except for some telling things (e.g. RPG Maker 2000 splash screens) not able to tell what it was made with.
Usability: This has to do with visibility. Both code and design must be best usable for those who are going to work with it. For the code, it's the programmer, but for the design, it's the player. I've noticed that the creators of things are often very defensive of them and dismissive of their mistakes. "It's not a bug, it's a feature" comes to mind.

Design 101

Since this is basically a rant blog, I'll go and rant a bit on things I have encountered in terms of design flaws.

(Anti-)aliasing: Anti-aliasing is smoothing out edges by blurring them a little bit. I'm sure you have all seen it. I'm not definitely for or against it. It just depends on the context. If the rest of the game fits, why not? If you're going for retro and everything else's is in clear pixels, please don't. The reason I'm bringing this up is that anti-aliasing is often used for scaling images and drawing text in engines/frameworks. Either turn it off, or turn it on, but don't do both. If you can't turn it off, work around it. What? Good design requires effort.
Menu additions: This is a thing I keep seeing in RPG Maker games, mostly because the engine already has a UI. If there's one thing I learned, then it's that UIs across the game should be uniformed. They should look and behave the same, and feel like they have always belonged to the engine. Photoshop gradient Times New Roman/Arial is not what they look like.
More clicks than your average download: Again, this is mostly a menu thing, but translates to everything that requires player input. Giant mazes of sub-menus, often with different reactions to the same key, don't make good UIs. Stop trying to be so goddamn fancy and keep your stuff simple. Because, as mentioned above, you're not making these interfaces for your ego, you're making them for your players.

Of course, there's more than that, but these were three I remember seeing quite often.

In General...

Of course, this stuff doesn't just apply to game design. You could probably replace "player" with "user" and have it still make sense. That's how important good design is. I'm not saying that good code isn't, but just because one thing is good, that doesn't mean the other one is too. Rant end.

No comments:

Post a Comment