Inside Technique : DHTML Sokoban - Game Overview
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.
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.