Tales from the Evil Empire

Bertrand Le Roy's blog

News


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff

Archives

August 2006 - Posts

What I understood in The Matrix Trilogy

(this is the translation of a French post I wrote in November 2004)

This is just a personal interpretation. There are others, and it's probably nothing other people didn't think about. For example, Matrix Happening explains the narration more than it tries to give a theory about the meaning of the events in the trilogy but it's a very good read if you understand French.

One thing that should have cought the attention of everyone and hint them that the real story wasn't as simple as the Wachowski would have you believe was the moment in Reloaded when Neo fights a sentinel in the "real world" with only the power of his mind. From this moment on, it becomes inconsistent to believe that the "real world" is just the future of our own. Neo's powers are supposed to come from his mastering the inner workings of the Matrix. How then could he have the same powers in the "real world" except if that world is itself a super-matrix? This is very explicitly confirmed later by the Architect, as well as by the infiltration of the real world by agent Smith (an agent in computers is of course an independant program that is devoted to a specific task and can sometimes propagate like a virus, and if Smith is a virus, Neo is the anti-virus in both worlds). One could also notice that this world is not called "real world" any more, but is now the "machine world". Neo sees the real nature of this world in the third episode under a form that looks very much like the Matrix itself and its trademark Kanji character rain (which was actually one of the things the Wachowskis took from Ghost in the Shell). Only the color changes from the green we've been used to to a flaming yellow that evokes hell. Finally, entities that are clearly defined as programs are now able to go from one world to the other through a train station.

Another clue is the Oracle's ability to foresee the actions of supposedly human beings. In the Matrix, only the machines should behave in a predictible fashion. It should thus be clear from the first episode that Neo is not human. The Architect confirms it in the second episode, Neo is just a program whose function he defined.

I don't hesitate to go further and conclude that there is not a single human being in all three movies, but only programs: all characters have names that indicate more function than personnality (Mouse, Link, Lock, Cypher, Oracle, Architect are all names that have a clear meaning in the computer world).

The keys to understanding Neo's name are given by the Oracle and the Architect. In the first movie, the Oracle tells Neo that he is not "the One". In the second movie, the Architect tells him that he is actually the sixth one to fulfill that function. All you have to do with this information is notice that One and Neo share the same three letters and count the different ways in which you can order three letters and you'll understand exactly what the Oracle and the Architect meant. One was just the first one, not some sort of messiah. Neo is the last one. Between them, the others were Oen, Eon, Eno and Noe. Furthermore, Neo means "new", which is its ultimate function for the Oracle. His previous name was Anderson, which means "the son of the man".

I think the human race has been wiped out during the war and only machines and programs remain. Some fulfill their tasks while perfectly knowing their nature while others believe they're human. The Architect's function is to make the Matrix last, to stabilize it, for example by deporting the perturbing elements to Zion.

The Oracle, according to its name, is the Matrix's database (I guess Sql Server would have been too obvious ;), but her goal seems to create something she can't predict (Neo and the little girl in the third episode?). In other words she's trying to recreate the human nature. Maybe that's what the Matrix was built for, and once again this is confirmed by the name of the Matrix and some troubling images such as spermatozoid-like sentinels penetrating Zion using giant drills... 

The Wachowski brothers have been very litteral about almost everything but what's in plain view is often the most difficult to see.

Will the Wii make you play less (and buy less games)?

Disclaimer: I work for Microsoft and have to admit I'm a big Xbox 360 fanboy so I will not be fully objective on this topic.

Ever since Nintendo has annouced their new controller, I've had very big doubts about betting the console on such a concept. The controller in itself seems to be beautifully executed and more precise than any other previous attempt at a motion-sensing controller, but I fully agree with Peter Molyneux that for most players, the most confortable position to play is lying on the couch with the controller resting on the beer belly. Only the thumbs move, and they do so very little, which enables us to play for extended periods of time (not that we *should* play that long, but we do, and that eventually makes us buy more games). And I call that motion sensing too: the pad is very efficiently detecting very small movements of my thumbs...

If I have to be in an upright position and wave my arms around to play, I can assure you that I won't play for more than 20 minutes to half an hour. The Wii controller will certainly work beautifully for a tennis game, or a golf game, or a sword fight game, and you can trust Nintendo to be just as creative with that as they've been with the DS touch screen (why we weren't smart enough to do this kind of games on Pocket PCs years ago and why we're still not doing them is beyond me). Still, I prefer to do my sports outside. Video games, for me, will stay in the couch, mostly not moving for hours. That will make me buy more games, a Wii wouldn't.

So when I saw the PS3 controller, after the initial shock - or lack thereof - (motion sensing? no, they didn't? hey, what's the big round button in the middle of the controller?), I thought that they had actually been pretty smart about the whole thing: their controller will be perfectly fine for any game, even though it won't come back when thrown and it will be somewhat less ergonomic for tennis games than the Wii controller. Then again, the tilting pad was tried before, including by Microsoft. I still have a FreeStyle somewhere in my closet and it was excellent at Motocross Madness and racing games in general (because we already tend to move with the pad in this kind of game) but terrible at almost anything else. So is this just Sony going "me too"? You decide.

But wait a minute... Didn't Sony already have a few PS2 games (mainly sports) that were controlled by the player's body movements? Well, yeah, and by a strange coincidence, the kind of games that work with the Eye Toy is exactly what the first batch of Wii games will be. Come to think about it, this is probably the most sensible approach (and it seems to be the XBox team's approach too).

Another powerful idea is that what seems like such an obvious control scheme may not be as efficient as your intuition will tell you. Here's an interesting comparison... When you think about FPSs and how the keyboard+mouse combination is the absolute best control scheme for them (even though the devices themselves were created for something entirely different), it's just mind boggling because it's so non-obvious. You'd think that detecting eye movement for example would work better for aiming in such games. Well, it doesn't. As a recent study showed, it is less efficient by 25% and just less enjoyable in general. Maybe that's because eye movement is widely unconscious whereas the eye-hand coordination is something that works really well in human beings.

I really like the idea that one controller can't be perfect for all games but that the default controller should be versatile enough to be ok for all games. I've owned a force feedback wheel for the PC for years and it just makes racing games much more immersive; I own a big joystick for flight simulation; an arcade stick will be better for Street Fighter and Pac-Man; mouse and keyboard work best for FPSs. In the same way, the camera will provide motion sensing for those games where it makes sense. But all of these games can be played with a regular controller without a problem, it's just that a special optional controller can make the experience better. The Wii controller just seems perfect for a very small number of games and terrible for everything else. In my opinion, it should be an option because it's just not versatile enough.

UPDATE: the reports from the first people to play with the console for extended periods of time are starting to come in, and it seems like the Wii, like a Gyration mouse, does not necessarily require big movements and can be enjoyed for long periods of time. Well done then. What still needs to be determined is how well the controller will work with "ordinary" games.

UPDATE 2: an interesting account of the first reactions of a person who didn't know about the Wii before.

UPDATE 3: Penny Arcade on the Wiimote.

UPDATE 4: I just read Ars Technica's review of the Wii and they have very good things to say about the system. In particular, "I found the nunchuk + Wiimote combination to be incredibly comfortable in long playing sessions. I was able to rest my hands on either side of my legs while playing Zelda, and that wouldn't be possible with a classic controller design" struck a chord with me. Again, I'm ready to be proven wrong and will gladly admit I was wrong. After all, the DS stylus gaming has been dimissed by some as a gimmick when it was introduced, but it has been working absolutely flawlessly. I'm a big fan of the DS (I have both the phat and the light models), it works perfectly for me, my wife and my three year old daughter who is addicted to Nintendogs. It just leaves me wondering why we didn't get games like those on PocketPCs years ago and why they're still nowhere to be found. If the games deliver on the Wii like they did on the DS, I'm sold, I'll get one and I suppose I'll buy Mario and Zelda. Again. And again. I'll try the Wii at fwends' house and make a first hand opinion soon.

UPDATE 5: Joystiq made a *very* interesting (although unscientific) poll of their readership that kinda confirms the title of this post:
http://feeds.joystiq.com/~r/weblogsinc/joystiq/~3/100490271/

I'm not alone! (die, caps lock, die!)

It seems like I'm not alone in my hatred for useless keys.

I mean, who hasn't pressed Caps Lock instead of Tab or Shift? When was the last time you voluntarily used Caps Lock?

Me, I physically extracted the Caps Lock key from my keyboards...

http://capsoff.blogspot.com/

UPDATE: here's a suggestion I sent about a year ago to the Microsoft keyboard team... I didn't even remember sending that and found it by chance today:
"There are a few keys on keyboards that are really still here for historical reasons. Typically, they are the toggle keys that are associated with a status led: caps lock, num lock, ScrLk and the infamous F lock. One of the problem with these keys is that they are next to other keys that are actually very useful and often-hit like Tab or digits. They are very often accidentally hit, which disrupts the flow of typing.
Possible solutions:
- Get rid of the keys or move them to a place where it's difficult to hit them accidentally.
- Give an option to disable these keys.
- Give them a touch feel distinctly different from other keys
- Return to the old behavior of these keys which is that their toggle nature is physically reflected by the distinctive click and persistent depressed state they used to have on typewriters and early computers. This has the advantage of making the status led dispensable, which is great for wireless keyboards. By the way, why is the status led not on the key itself: on my keyboard, it's on the bottom of the keyboard. What's the point of that?
"

Bragging rights

Here's my brain age:

My brain's 20!

And I'm 36 :)

Posted: Aug 10 2006, 10:03 PM by Bertrand Le Roy | with 9 comment(s)
Filed under:
Mixins for Atlas

I've beeen toying with that idea for a while and I thought I would try to get some feedback on it. Mixins are a way to dynamically add members to an existing object. I've built a small function, Type.Mixin, that does that by copying members from the mixin object's prototype to the object that you want to extend. The mixin object is a type (that is, a function) that can't be instantiated (you can ensure that by throwing from the constructor). The members that will extend the target object are defined on the prototype of the mixin.

Here's an example of a mixin object that is specialized at extending strings:

Bleroy.Mixin.StringHtmlExtensions = function() {
    throw new Error("Can't instantiate a mixin.");
}
Bleroy.Mixin.StringHtmlExtensions.prototype = {
    // Don't do this at home, this is a very naive
    // implementation just for demonstration purposes.
    htmlEncode: function() {
        return this
            .replace(/&/g, "&")
            .replace(/\</g, "&lt;")
            .replace(/\>/g, "&gt;")
            .replace(/\"/g, "&quot;");
    },
    htmlDecode: function() {
        return this
            .replace(/&lt;/g, "<")
            .replace(/&gt;/g, ">")
            .replace(/&quot;/g, '"')
            .replace(/&amp;/g, "&");
    }
}
Bleroy.Mixin.StringHtmlExtensions.targetType = String;

You can extend a string with this mixin this way:

var val = new String($("userInput").value);
Type.Mixin(val, Bleroy.Mixin.StringHtmlExtensions);
$("encoded").innerHTML = val.htmlEncode();

Here, we get the value of an input field, apply the mixin and we're ready to use the mixin's methods on the string and set a label's text with the results. Note here that you need to construct the string instance using the String constructor. A string literal won't do because in JavaScript you can't extend objects of the built-in types that were not constructed from the corresponding type's constructor. You need to "box" the literal in order to be able to extend it.

Now, if you want to extend all string instances instead of just one, just pass the String prototype as the object to extend:

Type.Mixin(String.prototype, Bleroy.Mixin.StringHtmlExtensions);
$("decoded").innerHTML = $("userInput").value.htmlDecode();

This is actually analogous to C# 3.0 extender methods. And this time, no need to box the string: once the type itself has been extended, all instances, existing and future, will get the extensions. This looks kind of cool as a way to package a collection of methods but it would still be more direct to just directly extend the string prototype.

Where mixins really shine is when they're not restricted to a single type like above. Here's another mixin that can be applied on any object:

Bleroy.Mixin.Duck = function() {
    throw new Error("Can't instantiate a mixin.");
}
Bleroy.Mixin.Duck.prototype = {
    quack: function() {
        return this.quackSound;
    },
    walk: function() {
        // implement duck walk here.
    }
}
Bleroy.Mixin.Duck.type = Bleroy.Mixin.IDuck;

This one will not only add the methods to the object you apply it to, it will also make it a valid implementation of the IDuck interface. Here's an example of how you can use it to transform a plain JavaScript object (like something you may have got as a JSON expression from a web service for example) into a legitimate implementation of the IDuck interface:

var myDuck = {quackSound: "qwak!"};
Type.Mixin(myDuck, Bleroy.Mixin.Duck);
// using our new duck
if (Bleroy.Mixin.IDuck.isImplementedBy(myDuck)) {
    alert(myDuck.quack());
}

Like above, you can also apply the same treatment to a type instead of just one object:

Bleroy.Mixin.RubberDucky = function() {
    this.quackSound = "skweek!";
}
Bleroy.Mixin.RubberDucky.registerClass('Bleroy.Mixin.RubberDucky');
Type.Mixin(Bleroy.Mixin.RubberDucky.prototype, Bleroy.Mixin.Duck);

One might argue that this is just a fancy way of doing multiple inheritance and we all know what a mess that is. Well, it is. But it's also a nice way to package a canonical implementation for an interface which is actually coupled with the interface type. I really like that it's still interface-based programming.

Now the thing about all this is that it's not exactly necessary. For example, to associate an interface and its implementation to a plain object, you can just write a class that encapsulates the implementation and that takes a plain object as a constructor parameter.

I'd really love to read what you guys think about that. Would you use something like this? Why would you use it over more traditional inheritance techniques?

The full source code can be downloaded here (you need to extract that into a web site with the latest CTP of Atlas installed):
http://weblogs.asp.net/bleroy/attachment/463965.ashx

UPDATE: The prototype library has something very similar to this, Object.extend (thanks to Zach for pointing that out). You can check it out as well as more useful examples of mixins here: http://www.sitepoint.com/article/painless-javascript-prototype

Define undefined

We already knew that JavaScript had some issues with semantics. Here's another funny one. Guess what this code does:

var a; alert(a === undefined);
alert(typeof(a));
alert(typeof(undefined));
alert(typeof(a) === 'undefined');
undefined = {};
alert(a === undefined);
alert(typeof(a));
alert(typeof(undefined));
alert(typeof(a) === 'undefined');
true = false;

You'll get the following values in the alerts: true, "undefined", "undefined", true, false, "undefined", "object", true.

For some strange reason, JavaScript enables you to redefine "undefined". Just in case you're wondering, undefined is not just some variable that happens to be undefined, it is an official primitive value (but not a keyword). If you declare a variable but don't set its value, it gets that undefined value. Now after our silly redefinition of the undefined, typeof(a) is "undefined" but typeof(undefined) is "object", which more or less means that undefined is not undefined. Nice.

So why would anyone in their right minds define undefined? I don't have the beginning of a clue, but that means that strict comparison to undefined is broken (as the code above demonstrates) and that typeof(a) === 'undefined' should be used instead (at least in principle).

This is so much fun! So any other important primitive values we can overwrite just to see what happens? Sure, let's try this:

alert(isNaN(Number.NaN));
Number.NaN = 1;
alert(Number.NaN);
alert(isNaN(Number.NaN));

Curiously enough, JavaScript seems to let you define NaN without throwing, but it actually doesn't do it: the alerts here show true, NaN and true.

From what I can tell, this redefinition of a primitive value seems to be "valid" only for undefined. Null can't be assigned to, neither can true, false or numbers. Too bad, how fun would that have been (in true daily WTF style):

var reallyTrue = true;
true = false;
false = reallyTrue;
if (true) {
  alert("That's it, I'm officially confused");
}
else {
  alert("Errr?!");
}

Thanks to Mike Harder for discovering that gem.

More Posts