Tag: HTML

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:

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.

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.

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.

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.

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.

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