These "games" were written for web pages being developed for a government department responsible for protecting waterways and water supplies. They were originally developed on a Mac running Netscape Navigator version 3.01, which we found was much more reliable than early 4.x versions. Modern browsers should all handle them with no trouble. It is all done with Javascript, but no "advanced" features of the language (or HTML) were used to try to maximise the accessability from all browsers and platforms. As the sorry tale below indicates, this may be an impossible dream.

In game #1 there are two static flies and the frog moves at random when he (yes, it is a male frog. How do I know? Just trust me) is clicked on. If he lands on a bug (yes, yes, I know it looks like a fly - the name "bug" is used for historical reasons) then he splats it. If he is immediately to the left of the bug then he eats it, which involves a bit of animation involving his tongue. A few moves after a fly is eaten or squashed, a new one appears.

Game #2 was written when relatively minor, but probably impossible to solve, problems were found when game #1 was run under Internet Explorer on a PC. In this version, there is a frog-moving and fly-eating control panel on the left of the "lake" so the user has control of where the frog goes and if he eats a bug. As a result the flies move at random so it is not too easy for the frog. Again a new fly is introduced a random number of moves after one is killed. Since there is room for it, this version displays the bug-demise count and help on the left hand side of the screen.

Game #3 is the same as game #2 but it uses buttons rather than a clickable map to control the movement of the frog.

Both games use a grid of 4 x 4 rectangles defined in a table. Each cell of the table is entirely taken up by an image of some sort. Basically the game's appearance is the result of changing the images in the table cells. Images are referenced via the images property of the document - this is so powerful an approach that the requirement for the FROGBASE variable (to take account of any images declared before the table), and for all cells to be in sequence in the images array, is a small price to pay.

What was the problem with game #1? If you have IE on a PC you will see that a black rectangle is left behind after the frog moves. I believe that this is either there to indicate a link which has been taken (at least that is what the browser thinks since an HREF is used as a "container" for the images so that an event can be detected) or it is outlining the image in case the user wants to copy it. Either way it looks like a browser feature, and I have discovered more than once that one of the weaknesses of Javascript is an inability to control the actions of the browser (for example to trap errors, such as an invalid URL, which are detected by the browser). Game #2 avoids this problem by not needing HREF containers for the images since the events are now recorded from the image map to the left.

Both games #1 and #2 displayed a second problem with Internet Explorer on both Macs and PCs. The screen is not updated every time a scr property is changed - this means that the froggy tongue animation used to indicate a fly being captured and eaten does not occur - the fly just disappears. I am amazed that IE works like this - a significant proportion of the world's Javascript must be used to create animations! Disconcertingly, when diagnostic alerts were inserted between the "frames", everything appeared to work correctly. It appears that the alerts cause the screen to be redrawn in the true current state, but they do not do much for the flow of the game. Comments in the code indicate the solution arrived at (for IE on the Mac) after trying a number of things which felt like they should work but didn't (moving the document by 0,0 for example). The answer was to re-paint the background (the same colour of course). I subsequently discovered that this fix does not work with IE on PCs.

October 2000: After further reading and practice with Javascript I have found a way of animating which works with all browsers - the setTimeout and clearTimeout methods. On reflection I suppose that these routines are included in the language for just this purpose, but they are not always a good substitute for an immediate response to the src property being changed. Apart from the added complexity of using the function which otherwise would not be required, the weakness with setTimeout is that it requires the program structure to revolve around the animation, which often is not desirable. One by-product of this, since the routines appear to run asynchronously, is that all variables used by routines referred to in setTimeout must be declared global - not the best programming practice.

In fact for the froggy game, because there is only one localised bit of animation which requires setTimeout, it is not a difficult method to use, but even in this simple code a local variable must be copied to a global one to satisfy setTimeout. However, I have written a genetic simulation in Javascript (see below) which has a program structure reflecting the process of gamete production, zygote formation and selection applied to the result. The results are plotted on a generation by generation basis, and using setTimeout would grossly distort the desirable structure described above. So PC IE users just have to live with the plot appearing all at once at the end of the simulation, rather than seeing the plot grow as the simulation proceeds. This is preferable to a total and illogical reorganisation of the code.

There are several other annoying features with IE on the PC. When you click on a map the active area is outlined in black - this does not happen with either browser on the Mac. Also, IE displays the "missing image" pattern before images are loaded - this looks awful (particularly with the froggy game which wants to hide the underlying structure) and with slow-loading pictures gives entirely the wrong impression.

Having solved one problem by creating game #2, a new minor irritation emerged - still to do with not using HREF in its normal mode, and again reflecting the lack of control over simple features of the browser. However this time it only occurs with Navigator. Image maps support links but not the full set of events, in particular not onClick (is this true of all versions of all browsers on all platforms?) so the "Javascript:" URL form had to be used. This means that after every action is completed, the status bar shows "Document: Done" when it has completed taking a link. It does not seem to notice that just code was executed rather than a document being loaded. Of course it's message overprints any setting of the status in the code. There is no event handler to return true to (this cancels the default action of onClick), so game #3 was created with a set of buttons rather than an image map, providing access to a full set of events and control of the status bar. In this version the status bar can display messages related to the frog's feelings about the world.

It took me a while to discover another problem for which I do not have a good fix - when the user resizes the window the screen is redrawn from the HTML (to be fair the browser does not have much choice) but of course the Javascript has changed the original frog and fly positions and is maintaining pointers to their positions and status. So the pictures are out of step with the game logic and extra "ghost" frogs and flies hang around. They are removed if the game is continued when their positions are redrawn, which must happen sooner or later. The fix for this is either to encourage the user to start with a large-enough window or to detect the resize and reset the game status. The latter approach sounds better, but onresize is a Javascript 1.2 feature not available in older browsers, and (surprise, surprise) it is apparently somewhat different in IE from Navigator. I am still thinking about this one.

In game #2 I think there is a bit of a problem with the user perception when it comes to squashing flies - they often seem to escape by magic (because the game rules allow them to move before deciding if the frog is sitting on them?) but it is a minor point which I might look at in the future.

December 2004: For such an apparently simple game, froggy seems to be a never-ending source of challenges. While no doubt my limited skill with Javascript is partly to blame, it certainly would be easier if browsers were more consistent and logical.

Over the last month we have been doing a major rewrite on the site for which froggy was originally created. As part of the process, I updated the game to the latest version (four) and then decided to have another look at some of the problems.

The buttons used to control the frog looked unsatisfactory, so I made better looking ones and then realised why I had previously gone for the kludgy form-based ones. IE insists on leaving a blue square around any button or link which the user clicks on - this action was the reason why I had originally moved from version #1 to #2 - and it is not a good look. Netscape does something similar but Safari manages without this behaviour - one of a number of areas where it is superior to IE and Netscape. It occurred to me to wonder why other games did not have the same problem so I had a look at some of the ones we had written and some which we had got off the net. Concentration (written by Brian Gosselin) did not seem to suffer the same difficulties, and a look at its code explained what the blue square is about. It apparently indicates that the object has (had) focus, and the way to get rid of it is to send it elsewhere (ie. give something else focus). I implemented a similar trick and it worked reasonably well (thanks Brian).

Then I reconsidered the timing of the frog moving relative to the bugs moving, and rearranged things a bit so that the behavior of all the animals is a bit more logical. Also the frog and flies now start off in random positions. Along the way I found and fixed a bug in the code, so hopefully version five is better and more stable. Try it and see.

Please feel free to with comments on the froggy games (or better still solutions to any of these problems).