Well, I ran into yet another problem with JavaScript. This time it comes from the fact that the button response code is asynchronous. That is, the JavaScript doesn’t sit around waiting for the player to push a button—it moves on to do other things. This is all well and good, but I need it to function synchronously. That is, I WANT the program to twiddle its thumbs while waiting for the player to push a button, then move on to the next stage of computation.
Now, the standard way to achieve this is to set a flag to false and go into a wait loop until the flag is set to true by the button-processing code. But this didn’t work for me. I tried several variations and JavaScript refused to do my bidding. So I took a break and thought it over while I attended to other tasks.
Then it hit me: fuck JavaScript. Fuck HTML. Fuck CSS and all that other crap.
I direct your attention to my first attempt at JavaScript, done some five or ten years ago. It’s called Rocket Science and it’s a little program simulating a moon shot. It’s not fully functional, for reasons I won’t bother to explain. But you can play with it, and it does handle all user input very nicely. But here’s the trick: it doesn’t use any of the standard buttons or HTML interface elements. The buttons in that program are all hand-prepared, with my own little response routines. I call it “programming from scratch”: I write my own stuff to handle tasks that are normally handled by obscure methods buried deep inside somebody else’s code and inadequately documented.
So perhaps I should throw away all the HTML crap in the code I have already written (in other words, start all over), and just set up my own JavaScript canvas that I draw everything onto. This is ridiculous, because my design doesn’t do anything graphical: it’s all text, all the time. At some point in the future I might want to insert an image, but that’s the most ambitious thing I might attempt.
Of course, there are objections to this crazy scheme: HTML automatically resizes to fit in whatever window you have. My home-cooked approach uses a fixed-size window. If it doesn’t fit onto your screen, you’re screwed. Too bad. I suppose this can be regarded as somewhat user-unfriendly. My approach is brittle; if for some reason I decide to move something around, or make one element a little bigger or a little smaller, I have to perform major surgery on the software, whereas if I do it all the conventional way, I can snap my fingers and have the whole thing show up upside-down and twirling.
OK, OK, let’s see if I can’t at least specify exactly what my problem is. Maybe some kind reader will save my sorry butt again. Here’s a screen shot of a typical encounter:
The player should click on one of the radio buttons and then press the “Submit” button. This should trigger the mathematical computations of the consequences of the player’s choice. So far, all this works just fine.
But once those mathematical computations are complete, I want to present a new encounter. That is, I want to wipe the screen clean, select a new encounter from the list, and draw that. That should be a piece of cake, right? Well, I can’t make any cake.
Here’s what the critical code that manages all this looks like:
a.innerHTML =‘’;
selectEncounter();
drawPage();
DrawPage sets up the radio buttons and the “Submit” button, and assigns the processing method for the “Submit” button:
a.innerHTML += '<input type="submit" value="Submit" onclick="processOption()">';
The method ‘processOption()’ does the mathematical calculations and then returns—to what? I don’t know. In any event, because processOption() is asynchronous with the rest of the program, my guess is that the rest of the program has completed its work and retired long before the processOption() method is invoked.
Simple enough, right? So if I want to do a bunch of pages, I just need to repeat this process. Here’s a really simple way to do it:
for (int i=0; (i<10); ++i) {
a.innerHTML =‘’;
selectEncounter();
drawPage();
}
This code works once. Its output is indistinguishable from the output of the previous code. You can click away on that “Submit” button, but it doesn’t do anything.OK, there’s a standard way to insure synchronicity in such situations: set up a flag and have the code twiddle its thumbs until processOption() sets the flag, like so:
var isOptionChosen = false;
for (var i=0; (i<10); ++i) {
a.innerHTML =‘';
selectEncounter();
drawPage();
while (!isOptionChosen) { a+=' ‘;}
}
I attach one more line to processOption() that sets isOptionChosen to true when that code executes.
This produces an empty page; apparently JavaScript decides that it can’t draw the page until it has finished everything. I tried a few other variations, none of which worked. So much for synchronicity.
And then, a really crazy idea hit me…
What if I don’t make any attempt to repeat anything in the code? What if, instead, I simply jump to another page when processOption() has completed its computations? And that other page is a copy of the first page? Which jumps back to the first page when it’s version of processOption() completes?
So I tried it. It worked perfectly. It’s a dirty trick, I admit. I’m sure that somewhere, the developers of JavaScript get heartburn every time I run this scheme. Serves ‘em right.