Ooops -- last night, I encountered an embarrassing bug in Jangaron: If you chose the same color for multiple players, a crash of one of them claimed the lives of all same-colored players!
I found the bug when trying to reconstruct the original scene from the movie, where all good players feature slightly different red/orange/something colors, while the bad guys are uniformed with blue light cycles. Not too bad, to get rid of all bad guys by crashing one of them, but not too fair, either (hey, good guys always have to be fair, but at least they don't have to brag about their ingenious plan to rule the world until eventually, they are fragged...). Another thing I noticed was that I really have to add a team mode.
Of course, I fixed the bug as soon as I could, i.e. on my way to work. Although I don't live in Alabama, riding public transport trains with my laptop (well, the company's laptop) gives my the opportunity to code on Jangaron. In Hamburg, when using a Laptop in public transport, you are still met with puzzled gazes and sometimes even snide remarks, mostly by folks who one minute ago were busy scuffing their thumbs on their mobile's knobby keys.
The bug was, as most often, caused by over-optimization combined with sloppiness: The color was a shared object (aliasing), and its alpha value was modified, although Color objects are intended to be immutable. More over, the alpha value is used as (the only) indication of a dying player. For the time being, I just fixed the first issue, but will care about the others later.
If you played the game before and still experience the bug after reloading the page, try to clear your browser cache.
Have fun!
Monday, March 31, 2008
Sunday, March 30, 2008
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:
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.
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.
Thursday, March 27, 2008
See you on the Grid
After having released a first version of "Jangaron", I thought it was about time to start blogging about all I had to learn (sometimes painfully) to write a wow browser game: JavaScript, (X)HTML, CSS, and many other technologies.
But before I really start to give you all the dirty details, have a look at the game in action and tell me if you think it a wow:
But before I really start to give you all the dirty details, have a look at the game in action and tell me if you think it a wow:
Subscribe to:
Posts (Atom)
Posts
