28.01.2009

Javascript Tetris Pt 8: Post Mortem & References

This was a fun project! Time to wrap it up…

What did I take away from all this?

Well, putting together the game (and these blog posts) helped me achieve my goal: I’ve got a better grip on core Javascript syntax and idioms now. I find I actually like working in the language. It’s very flexible, mainly because of its functional aspects and malleable Prototype object system. Ruby is still a more pleasant alternative, though. :)

Development is rapid… as long as I use disciplined regression tests. This is key - the only reason I was able to code (and constantly refactor) this little project relatively quickly was the constant safety net of my tests. Refreshing the browser and quickly hopping through the visual tests took about 10 secs each time, making for fairly rapid dev cycles.

I ended up with a basic but effective dev environment for dynamic web apps. I’m planning on extracting a stripped down template for future projects (with some improvements, see below).

Finally, rapidly building something concrete and visual is a rewarding feeling in and of itself… even for a trivial toy like my dinky little game.

Room for improvement

There are, apart from the myriad candidates for refactoring, some major issues to consider in the finished product as it stands now.

More of the code could be programmatically testdriven. For instance, much of the collision detection and state handling of Piece and Field could be tested and developed without relying on manual, visual tests. I managed without extensive unit tests here, however if the project had been a less trivial one I probably would’ve been more rigorous.

Piece shape matrices could be expressed in a more compact way if I’d defined each shape once, then used matrix rotation on them as needed. Unfortunately my math is a wee bit rusty, so I opted for “readability” instead. ;)

My use of OOP in this project could be a bit more disciplined. I reach right inside the Field and Piece objects and grab their state variables - so much for encapsulation, eh? I should’ve defined accessor functions, using closures to hide the actual state variables (this didn’t really occur to me until I was close to finishing the project).

Also, all the code should be hidden within the Quicktetris object (our application namespace). One of the quirks of Javascript is its notion of linkage through global variables - every library, function and general flotsam of Javascript code loaded in the current browser window ends up in the the same global namespace. Given the possible amount of library code that a serious application can load, our generic Test, Piece, Field , Graphics names could easily trigger naming conflicts.

How much thought did I put into performance? Nada. Zip. It loads fast enough, and runs fairly smoothly on my laptop. Works for me. However, if general web application performance was more of a concern I’d probably look into some of the most obvious remedies:

Using straight DOM scripting combined with styled div elements works for our game. Every visual element is nice and rectangular; because of this we don’t need more organic functionality such as lines, circles and curves. More flexible graphics would probably have called for a different approach. There are a few ways of doing this. The canvas approach is one, SVG based graphics another. Unfortunately, Internet Explorer doesn’t support either of them out of the box (without installing third party extensions).

Time spent

The code didn’t initially leap out in clean increments, as suggested throughout these blog posts. Being a relative newbie to serious Javascript development, I went through quite a few iterations - refactoring the code as I learned more.

Finishing the basic gameplay mechanics took roughly one week, using spare time in evenings and over the weekend. Improved graphics, animation, refactoring and general cleanup was finished after another week. Planning and preparing for this series of companion blog posts added overhead to the whole process.

Tools used:

Reference material

I usually find the W3Schools pages to be an ok starting point when I research unfamiliar web standards. Their tutorials and examples are uneven, but the site works well for quickly looking up stuff like API details and HTML DOM events.

For Norwegian readers: this is a very nice blog about Javascript and assorted web technologies. Kudos to Christian Johansen for a solid resource!

javascriptgoodpartscover

My main Javascript source, however, is Douglas Crockfords work. Crockford is the author of JsLint, the JSON standard, and general champion of Javascript. Crockford has essentially carved out and evangelized a subset of Javascript / EcmaScript, discouraging use of the more ugly parts in the language spec. You’ll find a lot of useful articles at his site, as well as a bunch of videos at the Yahoo YUI site.

I strongly recommend his book, which summarizes much of the material from the articles and videos mentioned above. At 153 pages it’s one of the most dense, concise language reference books I’ve ever seen.

Special thanks

My friend and colleague Alexander Odden (aka Flipside) was kind enough to whip up some sound and music - much appreciated!

I’m grateful to Johannes Brodwall, Christian Johansen, Lars Juel Jensen, Thomas Kristensen, Henrik Storm Ofteland and Bente StorÃ¥ker for (sometimes heeded) feedback, suggestions and criticism. Thanks guys (and gal)!


PreviousNext