4k Game; Little Missile Command

Keep an eye on gamepoetry.com for an announcement of the winners of the 4k game competition later today. I didn't win the competition, but pleased with my entry anyway.

You'll be able to play the game on gamepoetry.com, or you can play it here.

I'll be posting a write-up about the development process, but my wife just had a baby, so my priorities are elsewhere. :)

4k Madness

The submission deadline for Urbansquall's 4k game competition is right around the corner. Mine is in - I'll post a link to it here in the next few days.

The 4k limitation really keeps you on your toes. It doesn't foster great coding practices, but it does force a lot of creative engineering. Most programmers I know - including me - don't think about our code in terms of minimizing file size. We usually consider the size associated with a framework we're using, or (especially) visual assets. But I don't refine my code with the level of granularity required by a 4k limitation.

And let's face it - there's not much reason to. Bandwidth is less and less of a limitation, and the extra 12 bytes you may generate by declaring a new variable don't mean much of anything in a real world app. Neither does the 100-byte cost you incur from using some utility class.

But the artificial limitation is still worthwhile. It forces you to examine how you code. Even if you'd never pull some of the ridiculous stunts you might when facing a 4k limitation, you're forced to learn at least a couple valuable new approaches. The process refines you.

4k Game Competition

The Fultons alerted me to the fact that Urbansquall is sponsoring a 4k game competition. With a $50 first prize, they're obviously hoping that game developers will be compelled by the thrill of the challenge. Or maybe just ego. But whoever heard of a programmer willing to work tirelessly - and for peanuts! - just to prove himself?

Count me in.

Flash Gets Searched

I'm obviously a few weeks late on this one, but I've been on vacation. (A computer-free, cell-phone-free vacation, I might add. Try it sometime - it's pretty incredible.)

Anyway, Flash is searchable, or at least Google has an algorithm for it. Adobe says in this article:

"Google has already begun to roll out Adobe Flash Player technology incorporated into its search engine."

This page outlines some details from Google's end. At the moment, they're only indexing text within a SWF file - not images or video. But the implications are huge.

I've acknowledged that the most reasonable criticism of Flash is the inability to search the content within it. That's been a huge limitation, and anyone that's trying to build a highly searchable site has avoided Flash for that reason alone. We'll have to see how valuable the search results are that are generated from Google's new algorithm, but that limitation is becoming irrelevant.

What's really huge about this is that the FlashPlayer "plug-in" has made another giant step toward transparency. This is (in part) Google and Yahoo admitting that Flash is a core means of transmitting information over the internet. If GooHoo is expecting to find Flash content, they're expecting end users to have it installed. It's a transparent medium - everyone expects that Flash content is viewable. When it's not, something is wrong. With the typical plug-in, the expectation is the opposite (that it's not installed), and that's even what you plan on.

Maybe you're more skeptical, and you think that this is just Adobe swooping in at the right moment, leveraging the GooHoo/Microsoft conflict to give FlashPlayer a (HUGE) leg up on Silverlight. Maybe Google and Yahoo aren't admitting anything about Flash as a core means of transmitting information. Guess what: it doesn't matter. Motives aside, FlashPlayer gains some huge ground not just as a plug-in, but as a platform.

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.