Blog

  • XBox: Dragonball Z – Sagas

    Last week, my wife felt bad I was getting my arse kicked (and still am Flash Player Team!!!) by an .ocx problem with Flash and having to write 50 billion commands for work. She got me 2 games, one of which was Dragonball Z: Sagas for XBox. It basically follows the part of the famous TV show I started on while in college; where planet earth is getting attacked by Vegeta and everyone is training to make sure they are powerful enough to stop them.

    The cons. If you hit a level boundary, like a side, your character goes into mega-slow mo and stops. So, if you are running full speed, you stop even if you brush it. I could code collisions better than that mess. The game as hard as nuts fighting bosses, even though I put the diffuculty level to Normal (Easy/Normal/Diffucult). I made it all the way to the 3rd level in one sitting, and got owned by Vegeta. There is no physical way to get through mortar attacks, and plasma blasts that could level a house without going to Google to figure out how to beat him. Also, some of the battles are one on one, not what the cartoon storyline usually had happen. More often than not, it was 5 good guys vs. 1 super bad guy; in the game, they usually show real cartoon shots at the end of the battle to give context.

    The pros. Just… like… the… cartoon. They did a very good job. The levels, the style of look, the characters look; it’s all exact. The sound effects as well as the explosions and screen shake all are that insane, epic, larger than life feeling you get when you follow the cartoon’s storyline. They actually show the bosses’ power levels. They hardly ever did in the cartoons, just gasping, “OMFG, his power level is huge!!!!” but never actually showing the #, nor the scale.

    If I can’t beat Vegeta today, I’m trading it back in since it was used for another game.

    Dragon Ball Z: Sagas

  • Test Flash Remoting Services w/ ARP

    If you are developing service calls, but the back-end (Java, .NET, ColdFusion, etc.) isn’t done yet, you can still be productive by setting up test services. Utilizing what the ServiceLocator in ARP does best, you can point to your test service class instead of the real service, which would be a server gateway.

    Your test service is merely an ActionScript class that has all of the methods that your back-end service would have. So, if you plan on calling “createItem” and passing a string as the only parameter to some Java method on the backend, you merely mirror that in ActionScript.

    You do this for all of your methods. That way, you can continue writing your Commands and Business Delegate server calls as normal with plans to use them as is. When the back-end is ready, you change 2 lines of code in your ServiceLocator from this:

    var CreateItemsService = new TestService("", null, "CreateItemsService", null, null);
    addService("CreateItemsService", CreateItemsService);
    

    to this:

    var CreateItemsService = new Service("http://server.com/gateway", null, "CreateItemsService", null, null);
    addService("CreateItemsService", CreateItemsService);
    

    Notice the only thing that changes is you instantiate a real Flash Remoting Service class (Flex RemoteObject’ish), and put in a real gateway URL.

    That’s it!

    Here’s an example of the TestService.as file. This class extends the mx.remoting.Service class so it operates like a real remoting class. It’ll create Operations, return PendingCalls to server method calls, etc. All you do is make an interval so the method call “waits” 2 seconds before responding so it “feels” like it’s taking some time to talk to the server, where in reality there is no server at all, just ActionScript acting like it.

    Bottom line, to avoid the waterfall effect where a client developer is waiting on a server-side developer before she/he can proceed, this allows you to continue coding without a server, and if the server gets fubarred during development, you can merely toggle this back on to continue testing.

    I reckon this would work in Cairngorm too if you chose to use straight ActionScript instead of RemoteObject tags.

    import mx.remoting.Service;
    import mx.remoting.PendingCall;
    import mx.services.Log;
    import mx.remoting.Connection;
    import mx.rpc.Responder;
    
    class com.company.project.model.testing.TestService
    {
            private var speed:Number = 2 * 1000; // milliseconds
            
            private var createItemID:Number;
            private var createItemPC:PendingCall;
            
            function TestService(gatewayURI:String, logger:Log, serviceName:String, conn:Connection, resp:Responder)
            {
                    super.apply(this, arguments);
            }
            
            public function createItem(itemName:String):PendingCall
            {
                    clearInterval(createItemID);
                    createItemID = setInterval(this, "onCreatedItem", speed);
                    createItemPC = new PendingCall(Service(this), "createItem");
                    return createItemPC;
            }
            
            private function onCreatedItem():Void
            {
                    clearInterval(createItemID);
                    createItemID = null;
                    delete createItemID;
                    
                    createItemPC.onResult(true);
                    createItemPC = null;
                    delete createItemPC;
            }
    }
    
  • Cingular’s HCD Labs

    On my way to a LAN party last night, I stopped by the CHI (Computer Human Interaction) meeting at Cingular Wireless’ Winward location. Her majesty works in Information Architecture there, currently in the HCD group (Human Centered Design) so I managed to chill for an hour. I got a tour of the 4 main rooms they utilize for user testing as well as a good description of their mobile unit.

    The first room had like 7 monitors, all viewing & controlling a computer in the other room. One showed you the desktop as the user saw it as well as seeing everything the user was doing. It had 3 cameras in the user testing room that were on the ceiling, masked to not be noticeable and subtle as to not distract the user. These cameras were controllable from the main room, and you could zoom all the way onto a phone interface.

    The user testing room had 2 microphones with great pickup, and the testers could talk so the user being tested could hear them on a seperate speaker. The actual testing room itself was comfortable, office like, and spacious; you wouldn’t know you were being studied like a lab rat.

    Apparently, the computer in there is not all they use; sometimes they put kioks in there, or actual phones. One of the rooms looked like a mailroom, except instead of mail, there were phones in the slot. Highest it went for Nokia’s was like 6630; 6681 wasn’t anywhere in sight. Japan is so frikin’ ahead of the US.

    The other room was merely for watching with a huge monitor to see what the user was seeing with a small part of the screen showing the user themselves.

    The mobile unit is actually like an RV with 5 computer stations in it. They wire up the sales staff in a store with mics, and put cameras throughout the store that aren’t very noticeable, and watch for a day.

    In the seminar room, they had a few posters showing before and afters; one for a website, and one for a kiosk. They had notes showing what the user said, what was changed based on that feedback, and why. Users’ say the damndest things.

    All in all, insane the amount of work that goes behind user testing, and re-evaluation + multiple iterations of interfaces.

  • Doom the Movie: AOL & UAC?

    Caught the movie last week. The first-person part was pretty cool and accurate. Neat fight moves at the end.

    Her majesty and I noticed the UAC logo looked a lot like AOL!