Interdisciplinary Tensions

During the 5 or so years I spent working at Mattel, I was in a sort of odd place between the creative and programming departments. I was hired into the interactive group - a predominantly creative one - because of some odd circumstances, but most of my work was technical. So I spent a fair amount of time with (and sometimes between) designers and programmers. Both sides thought I was one of them, so I would hear gripes on both sides. Don't get me wrong, Mattel was a great place, and our teams worked together phenomenally. But there's always potential for gripes between the two, and sometimes that potential is realized.

At the end of the day, I'm a programmer. But working between groups makes you realize the very real dependencies. At Mattel we were making games, so it was really emphasized. Programmers usually make ugly games without some serious creative help. Without the programmers, designers have some nice looking screen shots. Both are equally worthless.

The dependencies don't feel as real when you get into application development. There are some really great tools that will allow a programmer to create a working piece of software, but without a good user interface designer (or a programmer that's into both disciplines), you still usually end up with something that feels like a traditional Microsoft app (i.e., not great).

The UI is what makes you look good. A killer app with a bad UI is like driving a Lotus covered in Bondo. It's impressive under the hood apparently, but I've never seen it. And that's the point.

So if you're a programmer, and you haven't bothered, dig into some design theory. It's actually quite interesting, and much less about emotion than what your stereotypes will let you believe. Some good starting points:

• A two-part series by Mauro Marinilli on UI Theory: Part 1 | Part 2
• A classic article on Fitts' Law from Bruce Tognazzini's site
  

Marinilli's first article has a slew of resources at the end as well. If you know of some great ones, please share!

My point is this: I've had a lot of opportunities open up to me because managers or clients have viewed me as "having design ability." I don't consider myself a particularly good designer. But just having some basic awareness, and being able to integrate it in some basic way, works wonders. People become impressed, and sometimes that even gets reflected in your paycheck.

Game Code vs. App Code

Jeff Fulton has written a great article about optimized game code, including some pretty thorough performance tests. He also gives some great historical information about OOP trends in Flash gaming based on his personal experience programming games.

What makes Jeff's article rare is that you don't see a lot of game developers seriously considering and integrating OOP practices. There are performance hits associated with some OOP structures (getter/setters versus public variables, etc.) that turn a lot of game developers off. Someone that's just doing games doesn't always take (or think they have) the time to learn good system architecture.

Application programmers have no excuse. If you're building apps, you aren't concerned about performance hits that will drop your application from 90 to 60 frames per second. You could probably run your app at 30 fps and be just fine.

Applications also have potential for a more elaborate system architecture and an increased likelihood of revisions or updates by other team members. Good OOP code is crucial for those things. The only detraction to strict OOP practices in Flash is performance related and frame rate specific - and apps rarely come close to pushing those limits.

Before I get flamed by game developers, let me qualify that by saying that a good portion of any game should actually be considered application development. Typically a game is actually an application that houses a game engine. (Jeff essentially comes to the same conclusion.)

So really, nobody has an excuse. Game and app devs alike need to know good OOP practices. Gamers just have better excuses (in certain circumstances) for breaking the rules.

Little Bits of Finesse

Sometimes it's the subtle elements that can really make your work stand out. But those finesse elements are often the 2% of a project that require 50% of your time. It seems counter-intuitive (especially when a deadline is looming), but it's those scenarios where you're often best rewarded for putting a little extra into making reusable code. You invest a little up front for long term payoffs.

For example, plenty of games have a scoreboard. It's relatively easy to just populate a text field with the user's score, but if you spend a little extra time to make a more elegant, reusable solution, your game will feel just a bit richer. People that play it may not necessarily notice that your game has a "special" scoreboard. But they'll know something's just better about your game. And if you've encapsulated the functionality well, you may not need to build another scoreboard for a long time.

Here's an example. This isn't all that complex, and the effect is relatively subtle, but it's a bit more interesting than simple text field updates. I also built it for flexibility. A fast-moving game may have a lower tween duration and higher blur distance. A slow-moving game would have just the opposite. Need a 10-digit score? No problem. And altering the font is as simple as changing a library symbol.

My recommendation, if you haven't already: start developing your own class library, and keep it as a formal repository of all the bits and pieces you use all the time. If you find yourself creating something for the bazillionth time, give yourself some extra time to create a solid implementation of that piece. Don't build everything into it, just the essentials. That will give you a core version, a starting place for future implementations. You'll save yourself a ton of time and, if you go a little out of your way, you'll easily add a bit of finesse to future projects.