A Story of Safari, Form, and OnSubmit

I learned something today.

I learned that, on Safari(iPod or mac… didn’t try PC), if one is using an <input type=”submit”/> in order to make the Enter key work when typing into a textbox (as I was doing in Hammurabi), the wrapping <form> tag will actually submit the contents of the form to the same URL that you are already at.  Firefox doesn’t do this.

In order to handle this correctly, you have to put an onsubmit handler that returns false on the form tag, or you will be feeding 2000 grain to your people, and suddenly you will have reset the game entirely.

Also, in the course of doing HTW and Hammurabi, I have determined a really nice way to structure the javascript for doing it.

Generally speaking, I use a single <div> that is the (for lack of a better term) “render target”.  Each time I update the content, I basically just replace the innerHTML property of the <div>.  This works rather well.  The game state will be held in some global javascript variable. The various event handlers of the <button> or <input> tags call other functions that further manipulate the state of the game.

This is all great, except that I determined that I needed to be able to start the content in one function, and be able to pass it to another function.  So, I came up with the following template for all of my text based game javascript functions:

function template(content){
    if(content==null) content="";
    //add content here
    document.getElementById("content").innerHTML = content;

This way, since all parameters of all javascript functions are optional, I can call something with no parameters and have the default value of null, which starts the content off as a blank string.

This way, I can have one function start off the content of another function with some sort of snide comment, or I can add some action resolution verbage to the status panel.


Migration to PHP complete!

So, changing PlayDeez.com from html to PHP is now complete, and it looks pretty much the same as it did before, but that was rather the point really.

Next, I’ll be integrating the user system into the site, thanks to the new user system API I wound up writing a few days ago.  This’ll be my first usage of $_SESSION variables in PHP, so we’ll see how it goes.  Then I need to start having content that responds to being logged in.


Back to my old user system

I have now decided to go back to my old user system, which has been around for years.  It was originally an MDB/ASP based solution which morphed into a MySQL/ASP solution which now is in the process of morphing into a MySQL/PHP solution. I’m currently laying out the rough plumbing for it. The eventual goal is to make all of the pages able to be logged in.

For facebook apps, I’m going to find a way to shunt facebook users into the system, rather than do this the other way around.

So far I’ve constructed and tested my little helper functions for sending emails and connecting to and querying the backend.   Soon this will grow into a set of php functions for dealing with users.

Which means I need to get the rest of the HTML pages on the site converted over to PHP.

The plumbing stuff is just so time consuming.



I decided against putting iframes into my html pages to shove everything over to PHP.  I’m instead doing HTML redirection, which I’m not a big fan of, but I do what I must.  Thus far, I have made a new default page, and default.html redirects to it.

I’ve also put some image links to the various games on the site onto the default page.  This brings me to a decision point: I have multiple versions of JetLag. Am I going to put an image on the main page for each? The difference between Javascript JetLag, JetLag: Crystal, and Silverlight JetLag are relatively minor.  Also, when it comes time to start putting in the server side, the old stuff I’ve got for JS JetLag is going to be 86’d.

Slowly but surely, I need to severely revamp PlayDeez.com. Unfortunately, with all of the other time constraints, it’ll be a long road.


Nix on Facebook Connect

For now, I think I’m not going with Facebook connect for any of my games, at least until I get more of an idea of how it is done properly. Also, the way my website is built is sort of strange and apparently facebook connect objects don’t like being loaded on the fly, at least not in firefox. (My web page is built using various elements and setting the innerHTML value).

Another issue is that I would like to change over to php.  The problem is that my website is currently in regular HTML.  My plan for changing this is to put up the php versions, and then have the HTML versions have an iframe that talks to the php version. The php version links will need to have the “top” target so that the actual page gets changed.  But it is definitely time to get away from my weird dynamic JS website scheme.

In any case, it looks like that needs to be done first.


A Temporary Diversion

As a brief interlude from any solid HamQuest related work, I am working on a quick port of Hunt The Wumpus to WidgetBox.

Currently, only moving around works, so you can get eaten by the wumpus, fall into a pit, or get swept away by the bats, but you can’t shoot the wumpus and win. That’ll be the last bit.

The final destination of the HTW widget is facebook.  I did a brief search on both widgetbox and facebook, but did not turn up any wumpus hunting.

The game is based on the BASIC source code from Gregory Yob. It is done using javascript and HTML.  To give it a more “authentic” look I went with <PRE> tags for almost everything.


Good Progress

This evening, I was able to knock out features 2, 10, and 12.

There is now a winning animation that uses some cheerleader icons from IconBuffet.

The load time is pretty much instantaneous now.

The player now has the ability to save the state of his game and later restore it.

Most recently, my game development environment of choice has been HTML with JavaScript.  Usually, I start out the game pretty bare bones, with nothing more than a <DIV> tag in the HTML, and I use JavaScript to bootstrap the content into there.  The entirety of playdeez.com works this way.  The pages themselves consist of empty <BODY> tags and a bunch of scripts.

For example, the HTML behind the page with connect on it looks like:

		<title>PlayDeez Games</title>
		<link rel="stylesheet" type="text/css" href="styles/standard.css" />
	<body id="pagebody">
	<script src="scripts/common/pagebody.js"></script>
	<script src="scripts/common/titlepanel.js"></script>
	<script src="scripts/common/sidebar.js"></script>
	<script src="scripts/common/utilities.js"></script>
	<script src="scripts/jsconnect.js"></script>
	<script src="scripts/jsconnect/connect.js"></script>

As you can see… not much there.  All of the work is done in the JS files.  All of my layout stuff is in the scripts in scripts/common.

Typically, when I am building a page in  this manner, I build up a string filled with HTML, and at some point find an object in the DOM and set that objects innerHTML to the string I generated.

When I started putting together Connect! (which actually began as a Yahoo! Widget, which is why I made some of the architectural decisions I did), I instead APPENDED strings with HTML to the innerHTML of my main <DIV>.  For a Connect! board with 64 nodes, 56 vertical connectors, 56 horizontal connectors, a background image, a cheerleader image, and 6 buttons,  thats close to 200 DOM objects getting inserted, one at a time, into another DOM object.  No wonder it seemed to take forever to load.

So, I switched the code so that it instead build up a string as it went, and only put the objects into the DIV at a single time.  The result: nearly instant load.

And yet another valuable lesson learned about manipulating the HTML DOM with JavaScript