Tales from the Evil Empire

Bertrand Le Roy's blog


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff


November 2007 - Posts

How to build the best fake music instrument set for Guitar Hero and Rock Band

Here's how to build an instrument set with two guitars/basses, a drum set and a mike that will work for Guitar Hero and Rock Band.

The first thing you need to know is that the Rock Band Fender Stratocaster guitar sucks. Here's why:

  • The fret buttons and strum bar are way too soft.
  • It's generally unresponsive and imprecise: it will miss notes that you definitely hit right.
  • Star power / overdrive is difficult to trigger when sitting.
  • You don't need the additional 5 fret buttons and effects switch.
  • The strum bar has a kind of cylindrical tip that will hurt your thumb.
  • I's not wireless.
  • It doesn't work in Guitar Hero.

Of course, there are things to like about it. It's been modeled after one of the most aesthetically pleasing real guitars, I like that it feels heavier and is silent, the start and back buttons are big, nice and accessible, which makes it easy to trigger star power without tilting the guitar. But it just doesn't click (pun intended) and the fact that it doesn't work with Guitar Hero is just not acceptable.

The problem is that if you want Rock Band, you'll have to wait until early 2008 to be able to find the components separately and avoid the bundled guitar.

The guitar that you want is Guitar Hero III's Les Paul. This thing feels even greater than Guitar Hero II's X-plorer, looks great and is wireless. It can't be found separately currently so if you need two that may be a problem. As a second guitar, though, the Guitar Hero II X-plorer is just fine.

As for the mike, apparently any USB mike will work so there's no need to get the Rock Band branded one.

So here's the set:

This will cost you a total of $340.96 with three games and two guitars that work in all of them. Not cheap. One thing to notice is that buying the full Rock Band set might look more interesting as it's only about $15 more and you get an additional guitar and a USB hub. That may make some sense if you don't have an old USB hub that you could re-use hanging around somewhere in the house, but the guitar itself will be pretty useless and I don't like to buy stuff that I'm not going to use.

Posted: Nov 29 2007, 04:44 PM by Bertrand Le Roy | with 6 comment(s) |
Filed under:
Does JavaScript need method overloading?

John Resig of Mozilla and jQuery fame has a very interesting post about method overloading in JavsScript. In a nutshell, he proposes a utility function that gives a relatively simple way of overloading a method. The different versions are distinguished by the number of arguments (not their types). Another way of seeing it is that he factors out into a single place code that would usually be at the start of the method. Go check it out, it's a really interesting use of closures. I'll wait until you're done.


OK, so that's pretty clever. But there are a few things that are wrong with that in my (probably not so) humble opinion.

  • There is one additional level of indirection for each new overload. If the overload you're calling was the last added, you only have one additional call, but if you have, say, five overloads, the first one will have a stack trace that's five levels deeper than necessary. This makes it more painful to debug (of course all those additional functions will appear anonymous in the stack) and hurts performance. One of the commenters on John's post has a workaround but it requires that all overloads for a given method be defined in one single place (which may be all right). That one's probably not that bad.
  • Any use of the arguments pseudo-array severely hurts performance.
  • It's a lot more difficult to tool and to reflect on. IDEs, even if they have JavaScript IntelliSense, will have no clue what the signature(s) of that method is without additional metadata. If you get a reference to one of those methods, you can't determine its signature. Its length will always be zero. You can't toString it either as this will get you the addMethod code instead of the code of the method.

This last point is by far the most important. IntelliSense is really starting to take off in JavaScript as IDEs like Visual Studio 2008 or Aptana have pretty good support for it. The IntelliSense support could be restored if the developer provides additional metadata but that would need time and standardization of some form (OpenAjax could help here) and we have many other tools that rely on reflection that would be broken by this anyway (class browsers, rule-based code verification tools, etc.).

The real question I'd like to ask is the following. Is it worth the trouble?

As John mentions, EcmaScript 4 has built-in method overloading and to be perfectly clear I don't have a problem with overloading in general and if ES4 succeeds I'd have no problem using that feature. I just think this is a case where trying to mimic other languages in ES3 for the sake of it is just not worth the trouble as there are plenty of good or not so good alternatives:

  1. Named parameters: Typically, your method takes a single Object parameter, and you use something like myObject.myMethod({ foo: "bar", baz: 42}) to call it.
    Pros: Completely free-form parameter list, both in number and type. Expressiveness and readability of calling code.
    Cons: More difficult to tool without additional metadata (how do you know what named parameters are allowed, what their types are, what validation constraints they might have?).
  2. Optional parameters: Some parameters can be omitted when calling the method.
    Pros: Extremely simple to set up. Just test each parameter before you use it like you should anyway. Toolable.
    Cons: Does not allow arbitrary combinations of parameters. Less expressive calling code than 1.
  3. Naming overloads differently: have "findByName", "findByCity", etc. instead of just "find".
    Pros: Expressive, simple. Allows for all forms of overloading.
    Cons: Object model is larger, which means your member list may be larger than you'd like in IntelliSense.
  4. Inspecting parameters from the method code: Basically, you just look at the arguments pseudo-array and do different things depending on the number and types of the parameters. There is only one method in this case.
    Pros: This is the closest thing to real overloading. Allows for both number and types of parameters to be overloaded.
    Cons: Poor performance. Tooling requires additional metadata. Reflection doesn't work. Pretty much the same cons as John's hack, only clumsier to write.

In Microsoft Ajax, we use a combination of options 2 and 3 and it's worked great so far. I've always liked the expressiveness of option 1 (code like foo("bar", true, false, true) is always hard to read as you have no idea just from that code what each boolean is for whereas foo({what:"bar", validateBaz: true, notifyListeners: false, doAdditionalStuff: true}) is a lot easier to understand (or would be if my example made any sense)) but we've stayed clear of it because of the tooling issue.

What do you think? Is overloading such a useful feature that it warrants losing some tooling?

Arbitrary Criteria Game Review: Portal is as delicious as cake

What a great time to be a gamer. It seems like there is no end in sight to that steady stream of excellent games. We already got Bioshock, Halo 3, the Orange Box, Guitar Hero III, and we're waiting for Rock Band, Mass Effect, all before Christmas. What we lack is time to play them all.

This is one that won't take too long. So I'm seeing this through our arbitrary prism of Seven Deadly Sins of Game Design...

  1. Checkpoints: the game automatically saves whenever you do something significant. Essentially, you never need to worry about saving. But you can if you want. Anytime. Perfect.
  2. Boss fights: there is one, and it's fun and balanced enough that you can reasonably beat it on your first try (I did). Perfect.
  3. Mini-games: there are none. Portal is a game that knows exactly what it is about, and it doesn't waste time diverging from what it does best. Perfect.
  4. Cut scenes and dialogues: Portal is a talkative game, and the text is wonderfully funny in a dark, random way. That doesn't break the rhythm of the game in any way, it just happens as you play. In that sense, the storytelling (and surprisingly there is storytelling in this game) is even less obtrusive than in Bioshock. Perfect.
  5. Reload times: the time you spend in elevators between levels could be shorter, but reload times are perfectly reasonable. Plus, you don't need to reload that often.
  6. Camera: you own it. No problem here.
  7. Control scheme: it's the usual FPS dual stick scheme, plus one button to jump, a choice of pressing a stick or a button to crouch and the triggers to project a hole of either color (blue or orange). Couldn't be simpler, each button has at most one function and it doesn't insist on using them all. Perfect.

So here it is, it's perfect. Buy it.

Seriously, this game is outrageously fun and clever at the same time. It will create fireworks in your brain. You'll have a big grin on your face the whole time you're playing it. The level design is exquisite, there is a unique atmosphere and personality to the game and of course it relies on an extremely original idea, which is this portal gun that can connect two places with a pair of portals no matter how far away from each other and enable instantaneous travel. This was originally a independent student's project (Narbacular Drop, free to download) that was bought by Valve to become part of the Half-Life universe. And one can see while playing the game how Portal is just an opening. The possibilities are endless. The first thing that comes to mind is how well this could work in a FPS like Half-Life. This portal gun may well be the new gravity gun, only even better and a lot more mind-bending (in addition to being space-bending).

Sure, it only lasts two to three hours, but three hours you'll never forget.

Just in case you don't know, Portal is part of the Orange Box.

Posted: Nov 07 2007, 03:56 PM by Bertrand Le Roy | with 3 comment(s) |
Filed under:
More Posts