• "…let's not kid ourselves. If you sell a game that's a first-person shooter, then no matter how many RPG elements you shoe-horn into the game, the shadow that hangs over every character interaction that you have, no matter who they are, is the question in the player's mind of "What happens if I shoot this person?" And that's our own fault! We've sold the player that; we've made a contract with the player that says it's okay to kill people. Why would we then chastise them for exploring that?" Patrick Redding is brilliant. This interview, with Chris Remo on Gamasutra, is great – Remo asks some smart questions, and Redding gives some really smart answers.
  • "The game insists that I focus, even for mundane activities like carrying groceries, on carefully following directions delivered to me visually on-screen. The simple act of carrying groceries is subsumed by the mechanical procedure of executing a series of prompts _for no apparent reason_. This, for me, is the primary disconnect in Heavy Rain. My mechanical game-directed actions don't amplify or add meaning to the in-game behaviors they execute. They don't pull me in; they keep me out. " Hmn. I've been thinking about something similar recently. Time to fire up the blogpostmatron…
  • Lovely, lovely article explaining just how the PeepCode Blog works. The blog itself features unique layouts for every post. There's no CMS, no database, but what's going on under the hood is at least as clever – and the flexibility makes the beautiful and clear pages much easier to build.
  • "…for reasons that baffle me, my TV can only receive the four terrestrial channels, plus a grainy feed from the building’s security cameras. Easy choice."
  • "Red dot fever enforces a precision into your design that the rest must meet to feel coherent. There’s no room for the hereish, nowish, thenish and soonish. The ‘good enough’." Dingdingding. +5 points to Taylor, as usual. Place, not location.
  • "TinkerKit is an Arduino-compatible physical computing prototyping toolkit aimed at design professionals. The interest in physical computing as an area in development within the creative industries has been increasing rapidly. In response to this Tinker.it! is developing the TinkerKit to introduce fast iterative physical computing methodologies to newcomers, and particularly design professionals." Standardised modules, standardised connectors, Arduino-compatible. I remember Massimo showing me his keyboard-emulating board ages ago. Nice to see Tinker productising the platform, too.
  • "The buttons are designed to look very similar to basic HTML input buttons. But they can handle multiple interactions with one basic design. The buttons we’re using are imageless, and they’re created entirely using HTML and CSS, plus some JavaScript to manage the behavior." Dark, dark voodoo, but very impressive – and excellently explained by Doug Bowman. It's nice to see Doug blogging again.
  • "If 2009 is going to see the emergence of high-quality browser-based games, then 2009 is going to be the year of Unity. It has: lots of powerful features; iPhone support; Wii publishing; a developing community; quality developers using it; and an upcoming upcoming PC version. In short, it is about to make a major splash. I feel compelled to jump in with it — the indie license is cheaper than the Flash IDE."
  • "bash completion support for core Git." Ooh. This looks really, really nice.

I’ve just had my first patch accepted on an open source project. Quite chuffed with that! As of this weekend, the Rails calendar_helper plugin is now at version 0.21. My changes are very minimal, and only really to do with the markup.

Firstly, the default table markup’s had an overhaul. The date now goes into a %lt;caption> tag, outside the <thead>, as is appropriate. The <th>‘s in the thead now have scope="col" applied to them, again, as is appropriate.

The only other change is optional. If you pass in an option of :accessible => true, any dates in the grid which fall outside the current month will have <span> class="hidden"> monthName</span> appended to them. It could be reasonably inferred that plain numbers are dates that relate to the caption of the table, but the numbers outside the current month should probably be clarified.

You can come up with your own method of hiding content marked as .hidden; at NPG, we use the following:

.hidden {
	position:absolute;
 	left:0px;
 	top:-500px;
 	width:1px;
 	height:1px;
 	overflow:hidden;
}

but really, use whatever you’re most comfortable with.

You can get the plugin from Geoffrey Grosenbach’s subversion:

http://topfunky.net/svn/plugins/calendar_helper/

via the usual Rails plugin installation method.

There comes a point in every developer’s life when your realise the problem isn’t your work, but the tools you’ve got to hand. Toolsmithery is an important part of the job, and so I spent a few hours yesterday crafting a tool useful to any front-end developer.

The result is the CSS Redundancy Checker.

When you’re writing HTML, over time, your CSS files begin to fill up a lot. If you’re working on a large project, you might even end up with several people contributing to the CSS file, not to mention refactoring each other’s work. The result is a directory full of HTML files, and a very large CSS file.

What tends to happen is that not ever selector in the CSS file actually applies to your HTML; many are rendered redundant by refactoring, or by changes in HTML. But when you’ve got a 70k+ CSS file, it’s not easy to check precisely which selectors aren’t in use any more.

Enter the CSS Redundancy Checker. It’s a very simple tool, really. You pass in a single css file, and either a directory of HTML files, or a .txt file listing URLs (one to a line). It then proceeds to look at each file in turn, and at the end, list all the selectors in your css file that aren’t used by any of the HTML files.

That’s it. I’m pretty sure it’s accurate, and it should work with most CSS files. Most of the magic isn’t down to me, but down to _why the lucky stiff‘s marvelous Hpricot HTML parser. The script itself is about 50 lines of reasonably tidy Ruby. You’ll need Ruby, and Hpricot, in order to run it. There’s more full documentation over at the Google Code site where I’m hosting it. Please add any issues there, or get in touch if you want to contribute.

Things it doesn’t do: listing line numbers of where the selectors are. I wrote that functionality on the train this morning, but I can’t find a way to make it 100% accurate, so thought it best to leave it out – inaccurate line numbers are of no use to anyone. If you can come up with a way that works, let me know. Also, at some point I might turn it into a Textmate command. All in good time, though.

The need for the tool came out of a large project we’re working on at NPG, but I felt it would be useful to pretty much any HTML developer. So I’ve released it to the world. Let me know what you think, and do spread the word. You can get it via svn checkout, for now:

svn checkout http://css-redundancy-checker.googlecode.com/svn/trunk/ css-redundancy-checker