This was a fun project! Time to wrap it up…
What did I take away from all this?
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).
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:
- Compressing the image and sound assets. Lower bitrate for sound, reduced color debth for images
- Using YSlow to profile and suggest further performance tweaks
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).
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.
- Rake is my preferred build tool. Writing procedural build scripts in Ruby is very expressive, fast and readable, especially compared to certain other xml-based, declarative monstrosities. :)
- Any editor will do, but I personally prefer Textmate when I work in OS X. Well worth the money.
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.
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)!