Inside Technique : DHTML Sokoban - Game Overview
By Rajeev Hariharan

This article is the second in a series that discusses the design issues behind the development of the DHTML Sokoban game. You can either play the game on-line or download it for off-line play by clicking on the links at the bottom of the page. In the first article, Client-side Data Access, we looked at various options available to the IE4/5 developer for manipulating data files on the client. This (very) short article will briefly touch upon other topics of interest that arose during the design of the game. We suggest that you try the program out before continuing with this article, otherwise you may not be able to grasp the context of the topics.

Speed thrills

The game keeps track of 3 different parameters for scoring purposes - Pushes, Moves, and Time. You will notice that these parameters are displayed in absolutely positioned DIVs. The logic behind this is simple - when using DHTML to alter content in pages, the browser's rendering engine has to recalculate the position not only of the altered element, but also of each and every element on the page. This creates a problem in pages with complex layouts, because the engine can consume a significant amount of CPU cycles during the calculation. If however, the element being altered is positioned absolutely, the engine need not recalculate the rest of the page, so the redraw is significantly faster.

setTimeout() - The dirty hack's best friend

Let's face it - as browsers go, IE is less buggy than most, but every now and then, especially when dealing with ActiveX controls, you bump into an especially nasty one. If you're pretty sure that your code is perfect, but still get vague error messages, enclose the statement you think is bombing out, within a setTimeout call, like this:

setTimeout("suspect statement or function call()", 50)

This usually works - don't ask why. I personally suspect that it is because of code re-entrancy issues, but I'm not an expert on the subject.

Dynamic vs. Static

The game area is a 15 x 15 table, that's a total of 225 cells (see, I know my math:-), so we decided to generate the table dynamically rather than hard-code a static table into the page. This was primarily because we wanted the page to be as small as possible, and the HTML for the static table would have significantly increased the size of the page. The code to dynamically generate a table, on the other hand, runs to just a few bytes. This is an issue only when your deployment platform is the Web - for an Intranet application connection speed and dropouts are not a problem, so you would stick with static content.

The default gamepack

The game is being distributed with a default gamepack which contains 11 levels. Why 11? There's a very good reason for it, but we leave it to the SiteExperts community to figure that one out. The levels are not very difficult to solve (except maybe for the last 4), they were designed for the beginner, and should pose no problem to the serious gamer. The gamepack is a simple CSV (Comma Separated Value) text data file, designed for use with the Tabular Data Control.

What's coming up

In the next article, the last of this series, we will be releasing a companion program - the DHTML Sokoban Level Designer, which helps users to design their own gamepacks. This program is implemented as an HTML application (HTA), and we will see how this IE5 technology considerably eases the task of data access on the client. Next month, we look at a new game - Explorer Solitaire, and focus on an unfortunately much underrated topic - Development Methodologies. Keep giving us feedback on how helpful or interesting you have found this new column, along with any suggestions you may have for improving it. Till then, enjoy the game (IE4/ IE5 only).

© 1997-2000 InsideDHTML.com, LLC. All rights reserved.