microrail

So this past weekend I participated in Ludum Dare 23, a 48-hour game jam and competition (those are two events, one cooperative and team-based, the other competitive.) The theme was "Tiny Worlds", and the end product for me and my team was the Java game "microrail".

As you can seee, I was the main programmer but the concept (and the Lisp program to generate and test puzzles) was Glenn Iba - this is well-worn territory for him, he's made a very similar game with his son that's available for iOS.

Still, I wanted to make a game that was outside my usual genres, and it was nice to let it be an exercise in UI and presentation. 

Processing is a great toolkit for this kind of thing, but the end result was rather processesor intensive (the map puzzle is actually drawing all the lines and circles of all the other puzzles) and sound playback continues to be one of the most challenging parts of coding in Processing, as it also is for html5/canvas games...

an a-z reference

I recently found this link, that is a pretty good reference to some of the tougher javascript concepts:
JavaScript language a- z cheat sheet.

content vs structure and the quixotic hopes of html5

So one old tag/feature that some whippersnappers might not know about, but comes in useful from time to time, is <nobr>. On old (and current, for that matter) browsers, it does a good job of telling the browser not to automatically insert any line breaks, that you want this line to just go on and on. A common use case is to safely wrap a phone number in a body of text, also with various widgets it can be useful for maintaining certain kinds of structure.

Of course, this is the Age of CSS, not the  bad old days of oddball tags, and the CSS equivalent is
white-space: nowrap; It seems to work pretty well. (Unlike text-wrap:none; which isn't supported by anyone.)

Anyway, thinking about the dirty old  <nobr> tag remind me of the dream the semantic web, and how it influences html5. For a while I've thought that it feels like html5 purists (especially ones with a designer background) try too hard to make the html page do things an engineer would use a Content Management System for; I tend to think of HTML as something people look at, ultimately; with many systems I've made, the html sits there as kind of a template, until some kind of server language or javascript fills in the blanks... it's not the ultimate repository of knowledge, and it doesn't have to pretend that it is.

And that, I guess, is what the html5 folks disagree with... with MVC (Model View Controller), they would like the page to be the M, the model, with all of the V/View aspects controlled by the CSS. One of the finest examples of this is  CSS Zen Garden that show off the ability to have vastly different look-and-feels just by swapping out the CSS. And it's really impressive -- so many variations looking so fantastic -- until you realize two things: the fundamental page really is pretty simple, and there's a fundamental sameness to all the variations, but worse than that: 80-90% of the "heavy lifting" is being done by custom graphics. For example, the Scouts-influenced Make 'em Proud look has those awesome headers.. but each one is a custom graphic. Similar, the merit-badge like links at the bottom... It's one big image, with some fixed-width floatingness used on the links to line them up with the image. (Also, the order is reversed relative to other CSS versions, I'm not sure why.)

So with all those custom graphics... if every html page needs its own handtuned CSS page to render properly, that seems rather messed up to me, a reversal of priorities, and a very un-engineerish in its separation of concerns, a tight coupling of form and content. And that's what it comes down to: I think HTML will always be influenced by traditional top to bottom reading order. (Then again I never liked how xml would often dictate a specific order for its elements, it goes against the "everything on one level should be unique key/value pairs and order should be unimportant" ideals that work so well for me on the code side of things.) Something like nobr-- it shouldn't exist in the html5 idealized world because it's purely a display thing, even if it's a reference to a CSS class.

I guess some day we might have a semantic "phone" tag that would know not to split itself on lines, but still, I think trying to treat html5 as just a holder of data is a fool's errand.

degrunting the work: make throwaway tools for exact positioning

Sometimes UI is gruntwork. Photoshop/fireworks slice and dice is often a bit tedious.

Recently at work I had to recreate these pages with little "VH1 style help balloons" over screenshots. It was easy enough to ripe out the individual balloons, but I had lost the positioning of them, the x- and y- offsets.

So I coulda just guesstimated the X and the Y, or try to read it off the big image (more difficult because the sliced out balloons had arbitrary amounts of whitespace), but I came up with a better solution:

$("#backdrop").mousemove(
function(e){
var x1 = Math.round(e.pageX - $("#backdrop").offset().left);
var y1 = Math.round(e.pageY - $("#backdrop").offset().top);
$(".mover").css("top",y1+"px");
$(".mover").css("left",x1+"px");
ccdebug("["+x1+","+y1+"]");
}
);


I made a system where the "next balloon to place" had a class of "mover". I then waved my mouse around the backdrop 'til the balloon was where it should be, and I read the X and Y coordinate from the console (the ccdebug) and entered it into the css (well, the javascript actually) of the page. Save, reload, repeat! Much easier. The "mousemove()" function event model tends to think in page values, so I had to subtract the left and top of the backdrop div.

I've used this technique before... for example to draw an inviation to the Game Kart Jam I was hosting, I made a simple drawing program, then drew the letters by hand, capturing the coordinates to standard out. Then for the final version it uses that raw data to show my message. When I use this technique I can often have the system out show data in the array initializer format, or sometimes even in program code, which gives the charming sensation of writing a program that is then writing more of itself. 

diy modals

This is a quick note to my future self about DIY Modals and what not.

First question should always be: wouldn't it be easier to use, say, jqModal? (like I discussed earlier)

But if not, if you need some specific customizations or it's modal-ish but not quite a modal, here are some pointers.

The first thing you might want to get straight is the overlay that shades out the stuff behind. Here's a sample bit of CSS, a class for a simple div:


.overlay {
position:fixed;
z-index:100;
width:100%;
height:100%;
background-color:black;
left:0px;
top:0px;
opacity:.5;
filter: alpha(opacity=50);
-ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";
}
So we start with it in a fixed position, so it's relative to the whole page, and then we make it take up the whole page. Setting the left and top makes sure it works even if the HTML for the div isn't the first thing on the page. Then we come to opacity- most browsers now support opacity, the next is for really old IE, the bottom is for IE8. (bleh.)

We then often want to put a dialog or something in front of that.


.dialog {
width:250px;
background-color:#FFFFFF;
z-index:175;
border:1px solid black;
position:relative;
top:40%;
margin:auto;
}
We set the z-index to a bit above the overlay. One gotcha is that, despite the z-index, it was still appearing behind the overlay until we set its position. Setting the margin to auto centers it (as long as it's a fixed width.)


The top is a bit of a hack; it's tricky to center things vertically in CSS, so a compromise is a %-based top value as shown. You could also use javascript or some other CSS layout trick depending on your goals.