incompl

Here are my top 3 favorite pieces of box art for console RPGs.

3: Final Fantasy IV DS (North America)

A newcomer.  Why?

The art style of Yoshitaka Amano.  This piece demonstrates one of his signatures: some areas have high complexity, some areas are fairly plain.  I’m not actually sure if he designed this logo, but it is clearly in his style.

Perfect positioning.  A temptation might have been to ignore the ESRB and Square Enix text.  But in this case it was carefully considered.

Black.  Final Fantasy box art is usually light colored or white.  They decided to make this release stand out by making it as sinister as it is sleek.

Great use of foil.  You can’t tell in the picture, but the logo is metallic.  Too many games make poor use of foil in their box art.  Some of them simply make the whole box semi-metallic, only succeeding in making it hard to read.  If you own this game or see the box in the store, take a moment to appreciate how the use of foil is sharp and clean, but matte enough to avoid being distracting.

2: Breath of Fire III

Also dark and simple.  Why?

Realistic fire.  This will really stand out in a rack of games sporting CGI renders.

Use of symmetry.  This is well balanced, but the fact that the vertically-centered line (the sword and the i) are only subtly indicating the center of the image is what takes the cake.

The i.  They ignored the temptation to go bad-ass all the way.  The candle is subtle, thoughtful, and well-executed.  Notice the yellow glow around the candle flame.  That wouldn’t work except against the black of the sword.

This box art falls short though.  The “The Classic Role Playing Game” text is white on light orange on the left side.  This is sloppy.  My guess is that this got tacked on after the real designer’s job was done.

1: Final Fantasy VII (Japan)

Lots of white.  Why?

In Japan, the title could sell this game, given the circumstances.  The designer knew this and decided that this was more than any flashy artwork could do.

The font.  This is the first Final Fantasy cover to use this logo style, to my knowledge, and it has been used ever since.  A brilliant example of how to make a fantasy font look distinguished.

Off-center. The logo isn’t presenting itself as the center of attention, neither in size, nor in position.  It is simply there.

The logo background image.  In this version it isn’t clear that this is a meteor, so it gains meaning as you play.  A fantastic symbol for the game (on several levels) with a stylish fade.

Here is a great way to make your political party look awesome:

Sure, it is an interesting approximation of the American political landscape.  But as a piece of propaganda it is brilliant.  It says “Not only are we the exact opposite of those Bad guys (populist is often replaced by totalitarian or authoritarian) but also we are even further away from them than those other guys.”

As a crazy hippie and professed Libertarian I can’t help but love it.

I’ve started considering explorability a metric of code quality.  Exploribility is how easily a programmer can follow code paths within the program when reading the source code.  Things that adversely effect explorability are often adversely impacting some other quality of the code.  On the other hand, many are perfectly acceptable when used correctly.

Here are some examples:

Side-effects (the reader may have difficulty making the leap from effect to cause, among the other problems with side-effects)

Using string values to control program flow (IDEs can’t easily track them, for example enumerations are better in some cases)

Reflection / “eval”-type functions (Again, your IDE probably can’t track this type of thing)

Line wrapping at bad times (Reduces effectiveness of IDE search functions, for example it can be bad to wrap in the middle of a file path)

Unnecessary String parsing (foo = foo.replace(”fresh”, “funk”) when foo = “icon_funk.gif” is better, again effects usefulness of IDE search functions)

Sometimes explorability comes into conflict with other best-practices (in the previous example, the code may need to abstract away the file extension).  But it is definitely a good ideal to reach towards.

Programming is definitely a skill, but its sub-skills are a little fuzzier.  It is often broken down by language.  You have programmers who are good at Java, or C, or Smalltalk, or Self, or JavaScript, or whatever.  This is useful to know, but it is not the whole picture.

To me, this is like breaking down “people who are good at cars” as people who are good at Mitsubishis, or Fords, or Hondas, or Lamborghinis, or Caterpillars.  In reality, you also need to know who is good at racing, construction, manual transmission, driving in snow, and so on.  Someone who drives Mitsubishis might know how to fix their cup holders, so it is good to know who is good with that make of vehicle, but again, that isn’t the whole picture.

This can cause trouble.  Your average software developer resume doesn’t tell you if the person is good at pointer arithmetic, or higher-order functions, or prototypal OOP, and so on.  You often have to infer it from the language list, and honestly that process is not as fail-proof as it seems.  Many people who know JavaScript don’t even know what prototypal OOP is.  I’m not sure how many people who know C are pointer arithmetic wizards.  You can make an educated guess, but I hate guessing, and I’d do a bad job guessing the specific skills of someone whose primary language is C++, as C++ just involves so much stuff.  I love resumes that go deeper, and appreciate the ones I’ve seen.

We also don’t hear much about the groupings of these sub-skills.  We all know that a fellow who implements operating systems in C and a fellow who develops blog software in Ruby have very, very different skill sets.  But we don’t talk about system skills and implementation skills as much as we talk about system languages and implementation languages.

It is harder to write a resume that says “I am good with higher-order functions and closures” rather one that simply says “I am good with Lisp” and leaves the rest implicit.  But that is the direction I think we should move in.  Far too often I have no idea what kind of programmer is behind a resume until the interview, which can lead to a lot of wasted time.  I’d way rather hear that real programmers can think in pointers than hear that real programmers use C.  And in general, I’d like to have an easier time communicating with people about types of programmers and their various skills.