Posts Tagged ‘Web Development’

The Final Stretch?

February 9, 2008!.html

Well, I’ve got all of the buttons on the main menu doing something, and my last two dialogs (theme selection and options) are now in and working.

Which means I now head into polish mode.  The game has been functionally there for quite some time, and now I’ve got all of the menuing and UI support stuff finished.

Typically, where I am at right now would be about as far as I’d go with a game. While I actually touched the real game code today (the stuff that actually contains game mechanics), it was a small change to support the options I put in.

From here on out, it is all small, barely noticeable changes that  take a lot of time and, truth be told, are really annoying and frustrating.

For example, there is one tweak that will be necessary involving the menu button and how it initially shows up in internet explorer. IE and fox handle the “right” style a little differently, and making code that works in both is a little hackish.

Another thing still to do is put in a “you win” dialog or something when the puzzle is complete. I’ve long since ditched the cheerleader, and I’m most likely to just go with a simple window popping up that states “you win! congrats!” and maybe show some statistics.

For a while, I had toyed with the idea of completely ditching <img> tags everywhere, and strictly go with html tags <input> <button> <div> for my graphical elements.  I could easily replace all of the images used on the board with <div>s, and the load time would be amazing, since there would be no images to download.

I have decided not to go that route for this game (I’d like to be done someday, and this sort of constraint reminds me a bit of my ASCII graphics and hexagonal board fetishes, and nobody likes an eccentric game developer) .


February 4, 2008

New Version of Connect!

Currently, I’m working on it in an isolated manner, so this link is a temporary work in progress type of deal. Eventually it’ll be merged into the real online version again.  Really this isn’t too big of a deal… I only have to changed a couple of paths to images (on the actual version, the path to images is images/jsconnect rather than simply images), but I have over numerous updates tired of doing this as often as I have been.

Also, as far as Connect! is concerned, I want to have it as fully functional as possible before  I update it on the main site again.

The main menu is up and two buttons are operational.  The new game dialog has been made and is operational.  You can now use game numbers to play the same game over again. I currently don’t have a way to retrieve the game number of the current game, but that’ll happen soon.

This project has really taught me a lot about the platform I’m working on. I’m a lot more <div> savvy than I was before, and I’ve picked up a couple of “this’ll work in browser X but not browser Y” tricks.  At the moment, I still only target IE and Fox.

In copying the project to the site, I noticed there is a bit of image clutter for me to clean up. I completely ditched images for the main menu and new game dialog (and all other dialogs, but I didn’t make any images for them, so there is nothing to get rid of).

I am on Revision 32 in my SVN repository already, which is quite a few to go through from January 18 to February 3.   Of course, I don’t make myself go through code reviews.

New Backup Scheme and Other Tales

February 3, 2008

The title of the post may be a little misleading, as a “new” backup scheme implies that I had an “old” backup scheme, and I didn’t.  Yes, shame on me.

Yesterday, I got an external 160GB USB hard drive, and have since migrated my SVN Repository to it.

Today I was working on Connect!, especially the main menu and now the sub menus (the new game menu for instance).  When I was first putting together the main menu, I made images for each button’s up, down, disabled, and hover states. With 7 buttons, that’s 28 images.  I then changed one button today, and it was rather a pain to do, so at this time I am making a decision to switch from image based buttons on the menu screens to <button> tags.  Yes, to a degree I lose the consistent look and feel across browsers, but I do still have the ability to manipulate styles.

I will be leaving the imagebuttons on the navigator, however.  Mostly because they are “done”.

Menu Dialog

February 1, 2008

I’ve got a main menu dialog coming along for Connect!

While I originally used <input> and <button> tags, I am now ditching those in favor of my own “buttons” using <img> tags.  This is mainly so that I can get a consist look and feel across browsers. Also, buttons and check boxes are not terribly difficult to implement with an <img> tag: just four images and a few javascript handlers (onmouseover, onmouseout, onmousedown, onmouseup, and onclick).

For some things, I’m going to be stuck with the inconsistent rendering of various <input> tags, especially text boxes and combo boxes. I’ll go as far as reinventing the wheel with simple controls, but not when it comes to complex controls like that.

I’m really quite pleased with how Connect! is turning out. My earlier javascript work looked very cheesy and plain, but as I improve with my mad js/html skills, it is looking like nothing is too hard to do in js.

Which means that the programming world has become something like it was when I first started approximately 20 years ago, by which I mean that anybody can write software without buying big, expensive, complicated tools and IDEs and compilers.  I can make a game with notepad and MS Paint if I want (although I don’t… I use Notepad++ and Paint .NET)

Problem Solved(ish)

January 28, 2008

The issue with the clever JavaScript code not working in IE has been solved, and an important lesson has been learned!

That lesson?

Don’t do:


And expect it to work in IE.

Fox likes it just fine.

And yes, I know clever use of eval is discouraged, but I needed it! No, really! I needed to encapsulate the event handling mechanism for a DOM object, shunting the event to a different controller object!  eval was the only way!

Fixing the problem for IE caused a different problem for IE. I was calling a different event handler from one of my event handlers, but in the IE version of the event handler window.event.type is used, which caused a stack overflow. So, I took out the call, replaced with equivalent code, and moved on.

It now works in both fox and IE, with the new navigator. I’ll upload it after I’ve gotten a few more kinks out.

I had my wife play the game with the new navigator, and the only part that she did not find intuitive was my “revert” button.  I had originally designed it so that if you were looking at a historical view of the game (by using the previous move or previous mark buttons), making new moves was not allowed (because it would mess up the rest of the history), so I made a “revert” button to restore the game to that point in the history.

Except that it turns out that the natural inclination of a player is to back up to the point they want, and then just start making moves.

I didn’t want to just make an auto-revert when making a move, because that might be a mistake on the part of the player. However, I it was clear that the revert button wasn’t the right solution, so I left the revert button in (although I’ll likely take it back out) and made a prompt if the player decides to make a move when looking at the history. This way, I prevent mistakes on the player’s part by being too hasty with a move while scanning the history, but I also don’t frustrate the player with unintuitive controls.

In the next few days, I should have it updated on the site, and I should have an updated feature list left to implement.  I’m feeling it start to take some of its final shape at last.

UI enhancements, and a new problem…

January 27, 2008

New screenshot:

Connect Screen Shot with new Navigator Controls

Here you can see the new navigator controls on the bottom of the screen. I like the new scheme a lot better than the old one.

Unfortunately, in the creation of this navigator, I used some clever JavaScript that IE apparently does not like, so until I figure out what’ll make IE happy, no update on the site.

Good Progress

January 16, 2008

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 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