The Meaning of "Jangaron"

Eventually, this post will unveil the meaning of the game's name, "Jangaron".
Jangaron stands for many things: fun, a hobby project, an attempt to gain eternal fame, but also a proof-of-concept for a tool set that allows using a subset of JavaScript 2 / ECMAScript 4 in browsers limited to JavaScript 1.x. I already mentioned the central tool, the JavaScript 2 to 1.x compiler, in a previous post.
The project that has the goal to put this whole tool set online as Open Source and create a community around it is code-named "Jangaroo". The rationale for that name is like so:

• The project was initiated by a group with the nerdish and preposterous name "True Kangaroo" (which I am a member of...).
• We wanted an artificial name (like all those other cool Web 2.0 projects have) with lots of "oooo"s in it. In fact, it is so artificial that a Google search only returns some folks using "Jangaroo" as their user name in some obscure forums and at Digg, and I'm pretty sure that Andrew Croshaw is not the type who sues us to grab the domain. Are you, Andy? The same holds true for "Jangaron", where the only off-topic match is on a Mongolian Online Music page. Let's just hope that "Jangaron" is not a Mongolian swear word or something... but would then someone name a song like that?
  
• While the "J" is most often used for Java frameworks, here, it stands mainly for JavaScript (unfortunately, JSangaroo was too unpronounceable). Well, the tools are written in Java, so in either case, there is a lot of "J" in the project!
  

Of course, my pseudonym "Joo" is nothing but a short version of "Jangaroo" (and also resembles the name "Joe"). Note that it can be written entirely using JavaScript's most important symbol, the square bracket. Self-evidently, the compiler mentioned above is is called "jooc", pronounced like "juice".
As you might have already guessed, the "n" in "Jangaron" simply rhymes with "Tron".
There you go.

From C-64 Till Dawn

I just joined the Tron Sector forum to create some promotion for Jangaron and was about writing a really long post, but then I thought, "hey, why did you just start a Jangaron blog? Spare Tron Sector a couple of bytes to host and blog it!" So I just posted a short introductory text and links to the game and this blog.
When browsing through their light cycle games list, I found several justifications for creating yet another one of these. My justification is that I wanted to start a game software project that feels like back in the 80s: Try to do something amazing with very limited technologies. So I got into my head to implement a 3D light cycle race not only as a browser game, but also (mainly to make it harder) without using any plug-in or proprietary browser features like filters or canvas. It had to be a challenge close to impossible.
Moreover, writing a light cycle game is something I failed to finish back when the Tron movie was new (I was young but didn't need the money). I started to implement the game, but my computer graphics skills were as inadequate as the C-64's, so it got buried in oblivion.
Well, in the meantime, things changed: I have a Ph.D. in computer science now, which makes me a perfect candidate to re-implement a 25 year old game idea in JavaScript.
I have been using and getting to love JavaScript at work for years. It features a unique combination of functional and object oriented programming that leaves the impression of an independent congeniality. To overcome some limitations of the language design and to make things more interesting, already in 2003, on of my colleagues (and co-founder of the company!) anticipated ECMAScript 4 by creating a compiler from a subset of the specification (as it was then) to JavaScript 1.x as it can be executed in browsers. I continued his work and built a second version that moved a bit more complexity to a run-time library for the sake of even better readable and debuggable compiler output. This left me in a situation where I had all the tools to create awesome JavaScript frameworks and applications, so I needed some excuse to use them even in my spare time.
Until half a year ago, I was totally convinced that it is impossible to do any ambitious graphics with (D)HTML. But I am a UI guy, meaning that software without a face is a no-go for me, so I didn't give up. In one of my never-ending CSS-DHTML-JavaScript-google-sessions, I stumbled across CSS border slants (at the latest then I started to be proud of my danish ancestors!), which opened up unbelievable possibilities and kept me from sleeping quite some time. I don't want to deprive you of one quote from the border slants page:

For a dynamic example, see the Rotating Star demo. Also proves that DHTML and JavaScript are not fast enough to do wire-frame games.

Ha!, I thought, I will prove you wrong! Despite the fact that Jangaron is not exactly a wire-frame game, but uses a lot of filled trapezia, I guess what you can see by now does prove them wrong. The trick is that I chose a game that quite coincidently has such a limited perspective and so simple game objects that the restrictions of border slants do not apply.
Furthermore, there are many things you have to bear in mind to end up with efficient DHTML (and which the creator of the Rotating Star demo probably was not aware of). One anecdote is that while I learned a lot from some Opera "efficient JavaScript" page, my game ran unbearably slow only in Opera, until very recently -- I still don't know which code change caused the sudden performance change. In many cases, trial and error is your friend. After all, I was surprised that at least on my hardware, the frame rates do not really vary tremendously between different browsers. One browser can treat transparency more efficiently, another delivers smoother animations (less jerking -- better garbage collection?), but the overall frame rate is almost equal. Even most-hated Internet Explorer is not bad when it comes to JavaScript and DHTML execution speed. And believe me, I did not implement browser-specific performance optimizations (the browser-specific workarounds for bugs to get it to run at all were sufficiently complicated).
What is said to be true for a Web-site seems to be true for a cross-browser game, too: If you do the right thing, it will be best played with any browser!
I hope we can use this blog to discuss more about what the right thing is in JavaScript browser game programming, but now, the daylight-savings-time-bastards have already stolen another hour of my life, Dawn has almost cracked and I have to sleep.
Good night.