A while back I participated in a One Laptop Per Child physics game jam. The game my team made, Babel, had two phases: the second part was a slingshot game (NOT UNLIKE ANGRY BIRDS BUT YEARS BEFORE THANK YOU VERY MUCH) and the first parts was a "make as high a tower as you can" game.
My game used a pleasingly springy mouse joint tool to grab the bricks, but it was difficult to control. So I appreciate the cleverness of UX shown by "99 Bricks Wizard Academy":
At it heart it's a Tetris-like game, with the same set of 7 "bricks of 4" tetrominoes and the same idea of stacking them as the descend. However, rather than completed rows disappearing, 99 Bricks keeps all the bricks, and you build as high a structure as possible- but the physics matter. An unbalanced tower will fall in short order.
The UX is really smart. When a brick is falling, it plays just like Tetris, except the tetrominoes can be moved in half-steps, not just full 1x1 block spaces. Once it lands, THEN the physics take over. The result is very satisfying, and less frustrating and more educational than what I made in 2008.
There's a lot of other smarts in this game: spells to make things a little easier, rival wizards interfering, and a good set of specific challenges/achievements that move the game beyond a simple "how high can you get?" play mechanic.
Angry Birds (and to a lesser extent, Flappy Bird) are probably the most famous physics-based popular games, but I feel like both of them suffer from poor repeatability. It's not trivial to reproduce the same shot in Angry Birds, so it's more random and less thoughtful than it could other wise be.
Another excellent physics based game with very think-y puzzles is Red Remover -- you can get it for iOS or play it online. (Actually you can also play the original 99 Bricks online, but it plays more like a technical demo for the Wizard Academy game. Plus, the bricks feel less wobbly and fun over all.)
Finally, my all time favorite online physics-y game might just be Fantastic Contraption where you build little machines that really kinda work! (Unlike the other 2 games, I found it better on a laptop than on a touch screen device.)
Friday, June 27, 2014
Wednesday, June 25, 2014
improved ux in cars
My car, a slightly dinged but beloved 2004 Scion xA, is now "a little old". (But has just under 90K miles on it, which isn't so bad.) This past weekend at my friends I had to move two less-old cars, a Jeep and a Pontiac (so not a "new" car). With Jeep, I was confused when I turned off the car but the radio kept playing - I turned it off by hand. But then the same thing happened with the Pontiac, and the owners explained that that's how cars work these days: the electricity for the radio and power windows stays on until you open a door.
That's brilliant! What a nice and humane idea. From a strict nerdy-engineer standpoint it might seem a little weird and arbitrary, but it's a terrific 90/10 solution... either you just leave the car and it's barely different than the old way, or you roll down the windows, THEN leave, or you just sit there because you're waiting for something. So smart and subtle!
That's brilliant! What a nice and humane idea. From a strict nerdy-engineer standpoint it might seem a little weird and arbitrary, but it's a terrific 90/10 solution... either you just leave the car and it's barely different than the old way, or you roll down the windows, THEN leave, or you just sit there because you're waiting for something. So smart and subtle!
Tuesday, June 24, 2014
centering stuff vertically via css
via http://css-tricks.com/centering-in-the-unknown/,
.timeblock {
height:36px;
display:table;
}
.timeblock p {
padding:0px;
margin:0px;
display:table-cell;
text-align:center;
vertical-align:middle;
}
worked pretty well for
<div class="timeblock"><p>Some stuff</p></div>
[Insert usual note about how CSS isn't great at some stuff that comes really easily with tables]
.timeblock {
height:36px;
display:table;
}
.timeblock p {
padding:0px;
margin:0px;
display:table-cell;
text-align:center;
vertical-align:middle;
}
worked pretty well for
<div class="timeblock"><p>Some stuff</p></div>
[Insert usual note about how CSS isn't great at some stuff that comes really easily with tables]
Sunday, June 22, 2014
reminder: from .js to .json
tl;dr: Use json.parser.online.fr to check your hand-rolled JSON, and remember that JSON embedded in .js code lets you get away with not quoting your keys.
I'm making a new toy web-based database. I regularly use this ancient Perl CGI db I constructed a decade ago to hold information online; before I started this blog it held my devnotes, it holds my list of media watched, it used to hold my list of possible future blog entries, etc. (Now I use the awesome app "simplenote" for that, since it syncs to my devices and I can get to and update the information even when I don't have net access, like on the subway.) Overall the simple HTML form based, CGI/flatfile database has held up pretty well, but for "self education" as well as this porches project I'm on, I'd like to make something similar to it, but using json, and more javascript.
Eventually I will have a trivial CRUD protocol, and can swap out the front end (would be a good angular project) and the backend (would be a good node.js project). For now it's a crude jQuery-based UI and an even cruder hand-rolled JSON-in-Perl (couldn't get the JSON module working, sadly) on the backend.
ANYWAY, building up the toy, I started with a "mockDB" that implemented the middleware interface by just keeping information in the browser. When I went to construct the Perl backend, I grabbed the JSON I was using in the mock and put it into individual .json files. Luckily, The Ghost of Annoying Bugs Past tapped me on the shoulder, and before I used the resulting CGI output I ran it through json.parser.online.fr and it came up all red. Quickly I sussed the issue, having seen it before: when you build some static json in a .js file, you don't have to quote your keys, i.e. you can do something like:
var map = { key1: "foo", key2: "bar" };
That works but is not proper JSON, which should be
var map = { "key1": "foo", "key2": "bar" };
(The former only ever works because Javascript has this weird-ish concept of labels, which can act like strings as well.)
To quote F.P. Jones:
Experience is that marvelous thing that enables you recognize a mistake when you make it again.
I'm making a new toy web-based database. I regularly use this ancient Perl CGI db I constructed a decade ago to hold information online; before I started this blog it held my devnotes, it holds my list of media watched, it used to hold my list of possible future blog entries, etc. (Now I use the awesome app "simplenote" for that, since it syncs to my devices and I can get to and update the information even when I don't have net access, like on the subway.) Overall the simple HTML form based, CGI/flatfile database has held up pretty well, but for "self education" as well as this porches project I'm on, I'd like to make something similar to it, but using json, and more javascript.
Eventually I will have a trivial CRUD protocol, and can swap out the front end (would be a good angular project) and the backend (would be a good node.js project). For now it's a crude jQuery-based UI and an even cruder hand-rolled JSON-in-Perl (couldn't get the JSON module working, sadly) on the backend.
ANYWAY, building up the toy, I started with a "mockDB" that implemented the middleware interface by just keeping information in the browser. When I went to construct the Perl backend, I grabbed the JSON I was using in the mock and put it into individual .json files. Luckily, The Ghost of Annoying Bugs Past tapped me on the shoulder, and before I used the resulting CGI output I ran it through json.parser.online.fr and it came up all red. Quickly I sussed the issue, having seen it before: when you build some static json in a .js file, you don't have to quote your keys, i.e. you can do something like:
var map = { key1: "foo", key2: "bar" };
That works but is not proper JSON, which should be
var map = { "key1": "foo", "key2": "bar" };
(The former only ever works because Javascript has this weird-ish concept of labels, which can act like strings as well.)
To quote F.P. Jones:
Experience is that marvelous thing that enables you recognize a mistake when you make it again.
Friday, June 20, 2014
Thursday, June 12, 2014
thank skew very much
(Busy day on the blog!)
I'm doing the website for the JP Porchfest and we have a logo like this:
We were putting "A Music Festival on Porches / All Over Jamaica Plain" over it, but I thought it looked boring and not terribly professional:
I thought putting the text on the roof but slanting it like it was actually written there, would be cool to try out.
I wrote a program in Processing to let me rotate the text in various ways, but wasn't quite smart enough to get the order of rotations right.
Then I thought (hoped) maybe italics might be enough... but then I remembered html5/CSS has some transformations built-in ... those worked really well. Once I got the numbers right it was easy to churn out multiple variants of font and capitalization.
I think the winning design will be this, with (an actually appropriate use of) Comic Sans:
Anyway, you can look at that last link for how I did it.
I'm doing the website for the JP Porchfest and we have a logo like this:
We were putting "A Music Festival on Porches / All Over Jamaica Plain" over it, but I thought it looked boring and not terribly professional:
I thought putting the text on the roof but slanting it like it was actually written there, would be cool to try out.
I wrote a program in Processing to let me rotate the text in various ways, but wasn't quite smart enough to get the order of rotations right.
Then I thought (hoped) maybe italics might be enough... but then I remembered html5/CSS has some transformations built-in ... those worked really well. Once I got the numbers right it was easy to churn out multiple variants of font and capitalization.
I think the winning design will be this, with (an actually appropriate use of) Comic Sans:
Anyway, you can look at that last link for how I did it.
debuggin' and safe js iterators
I just spend like a whole work day digging through a sampload of datatables code to find this issue... I finally tracked it down to some datatable wrapper/filter code we had that was iterating over an array like this:
for(var i in arrayOfFilterFunctions) {
//...
}
The trouble is, the "legacy" page the datatables widget was on included "prototype.js", and prototype adds an each function (ironically enough, for iterating) and that meant arrayOfFilterFunctions["each"] was a function that could be called, and was returning undefined, which were false-y enough to "filter out" the rows I was trying to add.
for(var i = 0; i < someArray; i++) {
//...
}
is clunky, but safer for reasons like this. (9 times out of 10 either will work, but that 1 in 10 can be a doozy, case in point my last day at work) Also, personally, I always subconsciously expect
for(var thing in someMap) {
//...
}
to set thing to the array entry, but of course you have to do something like
for(var key in someMap){
var thing = someMap[key];
//...
}
Some people think this is a strong argument for CoffeeScript and other preprocessed variants of javascript that let you write syntactically sweeter code than "raw JS", but I don't think that sweetness makes up for the disconnect between the code the coder writes and the code the coder looks at in the debugger window / what the browser is actually running.
for(var i in arrayOfFilterFunctions) {
//...
}
The trouble is, the "legacy" page the datatables widget was on included "prototype.js", and prototype adds an each function (ironically enough, for iterating) and that meant arrayOfFilterFunctions["each"] was a function that could be called, and was returning undefined, which were false-y enough to "filter out" the rows I was trying to add.
for(var i = 0; i < someArray; i++) {
//...
}
is clunky, but safer for reasons like this. (9 times out of 10 either will work, but that 1 in 10 can be a doozy, case in point my last day at work) Also, personally, I always subconsciously expect
for(var thing in someMap) {
//...
}
to set thing to the array entry, but of course you have to do something like
for(var key in someMap){
var thing = someMap[key];
//...
}
Some people think this is a strong argument for CoffeeScript and other preprocessed variants of javascript that let you write syntactically sweeter code than "raw JS", but I don't think that sweetness makes up for the disconnect between the code the coder writes and the code the coder looks at in the debugger window / what the browser is actually running.
arrange icons by face
The excellent site Lost in Mobile linked to this Mashable piece about alternate ways to organize your mobile app icons. It reminded me of one time when I had some spare mental cycles during a conference and decided to arrange my iPad's icons by ones that had lazy, one-letter based icon design:
I then decided to do a screenful of "icons by face" (then vehicle) - admittedly these were mostly games.
Finally, this all reminded me of one of my favorite videos, the The Website is Down, and it's infamous bit starting at 7:50 -- "You can't arrange them by penis" (Obvioiusly language is a bit NSFW.)
All jokes aside, it's interesting how people use different methods to arrange icons, from the more OCD-ish and orderly (e.g. by name or color), by function, by "muscle memory", or some mix of all of those.
FWIW, here's how I arrange the icons on the device that's by far most important to me, my iPhone. (Lost in Mobile is running a "readers show us your homescreen" series, which is why this is so nerdily annotated. The site's forums are very civil, given how many Android and iPhone fans are onboard there.)
I then decided to do a screenful of "icons by face" (then vehicle) - admittedly these were mostly games.
Finally, this all reminded me of one of my favorite videos, the The Website is Down, and it's infamous bit starting at 7:50 -- "You can't arrange them by penis" (Obvioiusly language is a bit NSFW.)
All jokes aside, it's interesting how people use different methods to arrange icons, from the more OCD-ish and orderly (e.g. by name or color), by function, by "muscle memory", or some mix of all of those.
FWIW, here's how I arrange the icons on the device that's by far most important to me, my iPhone. (Lost in Mobile is running a "readers show us your homescreen" series, which is why this is so nerdily annotated. The site's forums are very civil, given how many Android and iPhone fans are onboard there.)
Wednesday, June 11, 2014
on ios8
Some good insights into upcoming iMessage changes in iOS8. The radial control is kind of intriguing. I appreciate that unlike some gesture-based interfaces, visual affordances are provided, so you know more about what options are available. (It reminds me a bit of the "tap the round face thumbnail to open the conversation or drag it to the X to dismiss" interface for Facebook's iOS app)
Wednesday, June 4, 2014
ben fry, Processing and infographics
Ben Fry, as one of the inventors of the toolkit Processing (the thing I make so many of my toys and games in) is kind of a hero of mine. He currently runs Fathom, a company that does awesome interactive data visualizations. I got to see him speaking at a Thomson Reuters "Knowledge Worker Innovation" series:
(a 2 minute tl;dr highlights version is available as well.)
(a 2 minute tl;dr highlights version is available as well.)
google maps is pretty easy!
I'm doing the website for Jamaica Plain's Porchfest (an afternoon with a bunch of bands on various porches across the city) I decided to go with Google Maps... I found their Javascript API reasonably well-documented with examples, and achieving a pretty good balance of simplicity and power.
You can see the rough Proof-of-Concept site and get a feel for what I through together, before it gets more complex. Google doesn't want to do a lookup-by-address for every point of interest, I think, so you should use a site like this convertor to lookup the Latitude/Longitude of your locations. The rest was straightforward, with some jQuery special sauce to tie in the markers on the map with the table. Making little information displays for each marker was straightforward as well (forgive my moderately crappy code there).
You can see the rough Proof-of-Concept site and get a feel for what I through together, before it gets more complex. Google doesn't want to do a lookup-by-address for every point of interest, I think, so you should use a site like this convertor to lookup the Latitude/Longitude of your locations. The rest was straightforward, with some jQuery special sauce to tie in the markers on the map with the table. Making little information displays for each marker was straightforward as well (forgive my moderately crappy code there).
The default examples tend to be the "map is the full screen", and come to think of it, that might be a better bet for a website you expect to be viewed on mobile, the scrolling/zooming of window vs scrolling/zooming of map gets a little weird, so I think I might use the fullscreen approach for the final product.
Subscribe to:
Posts (Atom)