Category “hardware”

On Panic’s Playdate, Alternative Game Platforms, and an Upcoming Platform Release

Panic unveiled their new game platform, Playdate, yesterday — a custom game system running on its own OS that includes a handful of buttons, black and white screen, and curiously, a crank. Suffice to say, having built custom game platforms and controllers for the past six or seven years, I received quite a few emails from friends asking for my thoughts on the platform and what it could mean for gaming.

Here’s a compilation of some of my initial thoughts that I sent around:

  1. Hardware at scale is hard. Kudos to Panic for building a piece of hardware at scale. Scaling in hardware is dramatically different than software, and dramatically more difficult. The real world — and the manufacturing process — have a way of pushing back much more forcefully on the way we want things to work than software does. Consequently, many people getting into game hardware build one-off platforms that can only be experienced by the fairly privileged: those who have the time and money to attend a conference where an “alternative platform” is shown as an exhibit. Alternatively, very few approach the problem at scale, and while the cost ($150) of Panic’s new device may be prohibitive to some, it’s notable that a) with that comes a 1-year subscription that gives you access to 12 games, and b) they are selling an entirely home-rolled platform including OS, hardware, etc which adds to development costs.
  2. Alternative game platforms are the future. As I have noted here, here, and talked about at events like this one, custom game platforms are one piece of the future of computer games, which have largely been stagnant in scope, scale, and kind for the last decade or more. If we take the design of hardware into our own hands, we have the ability to control the entire experience at a much more granular and intentional level. John Gruber touches on this over on Daring Fireball in his post about Playdate, and I can only assume that the excellent designers at Panic also intuitively feel this. In game design terms, you are giving yourself much broader control over mechanics (through interface), dynamics (through outputs), and aesthetics (by having stronger control over the former two things).
  3. Screens are not the future. I have also written (quite extensively) about how screens are the death of everything. This is the one point that I think Panic didn’t take a chance on: they stuck with the traditional form of communication that we’re all used to with computer games, and it’s a shame. Screens have a lot of historical baggage and limitations that convey expectations of affordances while also constraining the way designers are capable of expressing themselves through the dynamics of a game. There are many other ways to communicate the dynamics of a game than through screen displays (you can see early forms of this in the badge work that we’ve been working on, but also through things like the Meggy Jr. RGB or work by the Toymakers), and I don’t see enough people experimenting with that.
  4. Inputs drive mechanics. The crank. An interesting choice of interface, and I’m sure it will spawn some novel mechanics. I wonder, though, how much of Nielson’s Heuristics (or any of the handful of other design heuristic standards) Panic paid attention to when they added a crank as an interface. Were considerations taken into account for consistency and standards, for instance? In other words, the semiotics of a crank convey specific meaning: will users have to learn different verbs associated with cranking? This is an interesting problem one would have to solve when adding an otherwise common interface into an uncommon context. I’ve had my own experiences with this issue with both successes and failures.

The promise of alternative platforms is also the promise of doing it better than it was done before, not simply being different for the sake of being different. I’m interested in seeing which way this platform goes.

On another note, this gets me really excited for the platform that my creative partner, Rudy Ristich, and I are about to launch based off the Thotcon 0xA badge. I’ve been fascinated lately by the idea of wireless radio itself as an input and an output. As a means to tie a game platform into other forms of media. As a way to create an interconnected object that transcends the game platform, and stretches itself out into other physical things.

More missives from the fringes of alternative computing development soon.

Jay Margalus is on Twitter at @jaymargalus

Thotcon Sponsoring IRL at DePaul

I’ve loved working on the Thotcon badges over the last couple years, and am excited to announce today that Thotcon is an official sponsor of the Idea Realization Lab at DePaul University. Thank you to Nick Percoco, Rudy Ristich, and all the folks at DePaul who made this become a real thing.

If you aren’t familiar with Thotcon, or the work that DePaul has been doing with the event over the last year (on their conference badges) check out last year’s writeup here.

Jay Margalus is on Twitter at @jaymargalus

Really Great Supply Chain Security Talk by Bunnie

If you’ve ever wondered about the different ways someone might use hardware as a way to exfiltrate data, Bunnie goes through a bunch of different exploit vectors in this talk that he shared over at his blog.

Jay Margalus is on Twitter at @jaymargalus

Particle CLI Install Error

I’ve been tinkering with Particle’s Photon boards, and figured I’d give their CLI a try. Unfortunately, on running their install with npm install -g particle-cli, I started receiving the following error:

gyp ERR! build error
 gyp ERR! stack Error: make failed with exit code: 2
 gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:262:23)
 gyp ERR! stack     at ChildProcess.emit (events.js:188:13)
 gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:254:12)
 gyp ERR! System Darwin 18.2.0
 gyp ERR! command "/usr/local/Cellar/node/11.6.0/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
 gyp ERR! cwd /usr/local/lib/node_modules/particle-cli/node_modules/serialport
 gyp ERR! node -v v11.6.0
 gyp ERR! node-gyp -v v3.8.0
 gyp ERR! not ok
 npm ERR! errno 1
 npm ERR! [email protected] install: prebuild-install || node-gyp rebuild
 npm ERR! Exit status 1

After looking around online, uninstalling/reinstalling Homebrew, Node, etc, I still got nowhere. Figuring it had something to do with my recent swap to a new Mac, I started poking around forums for path issues and finally found this.

The solution in the link is simple. Go to your profile (vi ~/.bash_profile for most people) and enter the following:

if [ -d "$HOME/bin" ] ; then

Save the file and reload your profile using source ~/.bash_profile

This took care of the problem for me!

Jay Margalus is on Twitter at @jaymargalus