Categories
Programming Tech Trends

Mac OS 3: User Center Design Exemplar

I nearly lost all my data a couple of weeks ago. Actually, I was in no danger at all of losing my data but the terribad UI of Apple’s Time Machine and Time Capsule made me think I did! Apple’s backup solution is like a good looking school yard bully with a hidden inferiority complex.

I used to back up everything manually and it was messy. To be fair Apple seemed to conserve all that backup mess with the Time Capsule wireless base station/terabyte network drive and its slick Time Machine backup application. It just seemed to work: No settings, no maintenance, no hunting for the disk with the 3rd season of Buffy on it.

On the rare occasion when I did need a missing or deleted file Time Machine made it easy, and entertaining, to find (nothing like zooming back in time to give lulz).

One evening last week my MacBook Pro died and upon restart got stuck at the kernel panic screen. I took it Tek Serve in NYC (where they are a million time smarter than Apple’s Genius Bar) and learned that a fresh re-install of Mac OS X was the solution.

To make a long story short, when I connected my revived MacBook Pro to Time Capsule it restored a backup from 4 months ago! That’s a generation in Internet years! Also it took over 12 hours! I was aghast!

With grim determination I started the whole process over and tried to get support from Apple. But nothing helped until I just gave up and accessed Time Machine to confirm it was operational. And lo and behold: There was my data from the previous week. Right up to 30 minutes before the kernel panic attack!

%*@:-(

Just before I joined Apple I got some coaching from Bruce Tognizzni (I was designing a set of never-to-be-released apps for Letraset back in 1991). Tog explained that good user centered design doesn’t just hide complexity–it enables the user to navigate it. Time Machine and Time Capsule are bad user centered design according to this definition since they are pretty faces and not much more.

I can’t think of any better example of user centered design than the original Mac OS (version 3) and apps like MacPaint and MacWrite. And since you can’t run it anymore (but you can see screen shots at the Vintage Mac Museum) I decided to bring the Mac OS 3 back to life in flash. Embedded above is version 0.1 of the Mac OS 3 Flash Sim. It don’t do much but I promise to whittle away at it as time permits. I’ll post the source code shortly as well. Right now you can selected the trash can and pull down the apple menu.

It’s funny but the constrained yet expressive capabilities of the original Mac OS are much more like the user experience of the iPhone and iPod Touch then the current Mac OS X. There is something to be said for the power of limitations.

Categories
Programming

Worst Ever Paragraph in a Technical Doc

I’m working on my Flash game framework. Progress, which I admit is slow, requires a good understanding of the Flash CS4 Component model. I embarked on this project a few weeks ago without realizing 3 things:

  1. The CS4 Component Model is very different from the CS3 model.
  2. There is very little good documentation for CS4 Components.
  3. Flash and CS4 Components have become the step children of Flex and it’s entirely different, incompatible component model.

🙁

I’m not sure why the CS3 Component Model had to go. The major change seems to be that CS3 Comps were based on a subclass of MovieClip while CS4 Comps are based on a subclass of Sprite. This change in inheritance has some great technical advantages but even more practical disadvantages.

MovieClip is a heavy weight object with lots of functionality. It’s a great starting point for components because you have all of Flash’s frame-based animation at your command. Sprite is a superclass of MovieClip and hard-coded to a single frame. Sprite is a great idea, since a many elements in a Flash game are static. Using Sprite-based components means less overhead for the Flash engine to grind through. Sprite-based components are less overhead for the programmer too: Since Flash plays any MovieClip by default you don’t need to include frame management code in a CS4 Component.

That’s all good. Here’s the bad:

CS4 Components can not share the same stage with CS3 Components. You have to choose one or the other!

There are 5 less Adobe-authored CS4 Components than CS3. Some of my favorites were not ported to CS4 including Accordion, Tree, and Window. I can still use the original CS3 set of components but not in the same application with CS4 components.

/cry

A quick search of FlashDen lists 236 CS3 components and only 51 CS4 components. This means to me Adobe has been doing a poor job of evangelizing the benefits of CS4 Components or that the benefits aren’t worth the effort. Or, as I suspect, all of the above.

CS4 components can be compiled so that their code is hidden. I hate that. I hope I don’t need to argue the open source model here. But someone at adobe should read the Wikipedia entry. I know developers who want to make money from their Flash components probably demanded this feature. I want to grab these follow capitalists by the shoulders, look them square in the eye, and say “There is a better way!” Look to the Perl community! Look to the Ruby community! Look to the PHP community! None of our brothers and sisters are starving there! Hiding your code leads to a lack of adoption, a lack of quality, and the illusion that you can sit on your butt and no longer have to innovate.

For me, the single biggest problem with the CS4 component model is the scarcity of quality documentation. The books and sites devoted to CS3 components are too numerous to mention. I found only one decent article on Adobe’s DevNet about CS4 Components: Creating ActionScript 3.0 components in Flash by Jeff Kamerer. It’s a very comprehensive article, points out many of the problematic design details that need to be considered when authoring CS4 components, but it’s rambling and needs much editing.

In fact it contains one of the worst paragraphs I’ve ever read in years of reading technical documentation:

You’ll find ActionScript metadata throughout all component code: in ActionScript 2.0 and ActionScript 3.0, in Flash and in Flex. ActionScript metadata comes between square brackets. It has a name that is followed by a list of name/value pairs enclosed in parentheses. For example, here is metadata with the name Inspectable and a single name/value pair, defaultValue/Label: [Inspectable(defaultValue="Label")]

Confusing yes?

What the author means to say (and I don’t blame him, I blame the nameless Adobe technical editor who should have fixed this) is that metadata is enclosed in square brackets and defined by a name and a string value or a list of key/value pairs. The example given is the most confusing part of this paragraph: It would be much clearer if a general example was used like [Name(key="value")]. By using a specific example he makes us hunt for the general hidden in the details. The example uses “defaultValue” as the key and confuses us with the word “value” on the left (the value is on the right). By using the string “Label” for the value the example confuses us with a synonym for a name on the right (the name, or key, goes on the left).

Unless I’m so confused I got it wrong.

Categories
Programming

Always Start with Da Face!

The hardest part of creating a Flash game, after figuring out the idea behind it, is to figure out what it will look like. Once you have those two tasks out of the way the actual coding is easy: The design tells you what to code.

But first -> Inspiration!

Since this game will feature multi-player interaction I’m going to borrow from the greatest of all multi-player games: World of Warcraft. In WoW you get to battle monsters and other players rendered in an epic 3D virtual world. Sweet! In my little game you’ll do the same, only with dots instead of the epic 3D. A lot of WoW-play boils down to a race between DSP (damage per second) and HSP (healing per second). So that’s what my game will do: Let players discover who can keep their little team of dots alive while killing the other guy’s dots.

Like the game the UI will be inspired by Blizzard’s magnum opus as well. On the left will be unit frames that display the health, mana, and experience of your team. On the right will be unit frames that display your opponent’s stats. In the center will be an animated dot-view of the action. Across the bottom will be command frames: Click these guys and you can target and attack bad dots or help your good dots. Lose and you hang your head in humiliation. Win and you gain experience to progress to the next level. Maybe even some loot will drop!

At this point I have a rough idea and a very rough UI design. I like to work it that way. I’ve found it’s a big waste of time to spend hours designing something what will just end up trashed as the concept evolves. It’s time to code…

I’ll need four major classes: An application class to manage everything, A view class to display stuff to the player, a state machine class to track what is happening to who, and a game engine class to control all the action. (This architecture is called Model View Controller (MVC) and is at the heart of almost any well written GUI application.)

I’d like to use a hash map to store the current state of my objects in the game. I don’t really need the efficiency of a hash map. But my ideas are very rough right now and things are going to change. Store keyword-value pairs will make managing change easier than hard coding properties into ActionScript classes. The Adobe documentation suggests I use the Object class to create a fake hash map (associative array) or use the flash.utils.Dictionary class. But I won’t get cool Java-like collection interface convenience functions 🙁

Luckily I found: AS3 Data Structures For Game Developers by Michael Baczynski. Thanks Michael! This library includes Hash Maps, Queues, Trees, and Stacks and more. Hard to believe ActionScript 3.0 doesn’t include them by default.

Categories
Programming

Getting Back Into Flash!

It’s been a couple of years now since I wrote a Flash game. They’re fun and easy to write and don’t take much time. For me the fun is in the design and programming. The result of the process might be a playable game–but I make no promises.

I’ve taken down all my old work, since it was out of date and I barely functioned anymore. That’s the problem with programming: The platforms keep changing. The Flash CS 4 of today is a whole new ballgame and I need to get up to speed quickly so turned to my favorite Flash platform how-to author: Colin Moock. I think I have every book he has written on ActionScript that is published by O’Reilly. Since beginning of the 21st century Mr. Moock has exhibited genius when writing about Flash programming.

Moock’s current Flash programming book is Essential ActionScript 3.0 from 2007 which is old by Internet standards. But I’m a couple of years behind the times and EAS3 got me up to date quickly: Subclass Sprite and Shape not MovieClip, how to use events, how to animate, how load resources, how to redraw the stage intelligently. Nice stuff that is scattered all over Adobe’s support site. Apparently there is more Internet info on Flash and its buddies ActionScript, Flex, MXML, and Air then on the Mac OS X APIs!

One technology I want to use in my game is Moock’s Union Platform. It looks like a quick and elegant way to incorporate multiple users into my game. We talk a lot about the power of social networking and data mining but under all that talk is the power of multi-user applications. I remember years ago when I worked at Apple asking Kurt Piersol what comes next after OpenDoc (the hot technology of 1997) and he said MUDs: Multi-User Dungeons. And I said Huh? Isn’t that a buch of guys fooling around in a fantasy world online? Yep, he replied and smiled mysteriously.

12 years later I get it. Any with Moock’s help I’ll put MUD goodness into my little Flash project 🙂