The Oculus Rift Is Pretty Awesome

Contents of the Oculus Rift developer kit.

Image via

The year is 1995, the climax of the “virtual reality” fad. Virtual reality was about to become a big industry, or something. You could even get a degree in it.

Except… where is it? It’s in movies, some pretty bad movies, at least. It’s at the mall, though it’s pretty awkward. You can buy it at Fry’s Electronics, but it’s quite expensive, very slow, and there are only a handful of games that support it. Virtual reality never really happened all the way, at least not like it was portrayed in science fiction. It had arrived, but only virtually, not in substance.

Fast forward almost twenty years. That should be enough time to rinse away the bad taste of Lawnmower Man.

Game On

C64_startup_animiertI assume that like many developers, I first became interested in computers while playing computer games. Our family owned a Commodore 64 and I can only wonder how many hours I wasted collecting cave artifacts, dodging neighborhood obstacles on my paper route, and conquering the new world. And the theme song to M.U.L.E. will forever be ingrained into my memory (side note: A really interesting article on the creation of M.U.L.E.).

Unfortunately, I spent all of my time playing games and not learning how to create them. My BASIC knowledge didn’t get past:

I’ve always wanted to learn more about game development and decided to start learning some of the basics. I thought a good first step would be looking into collision detection. One quick Google search later and I came across a great post by Paul Firth on that exact topic. I only needed to get halfway through the article to learn how to animate balls bouncing in a box, animate balls bouncing in a rotated box, and to develop a simple game of Pong (source code can be found here). Paul’s blog contains a wealth of in-depth information about game creation and I hope to get through many more of his posts.

With the advent of HTML5 canvas and the large number of JavaScript libraries/frameworks supporting it, game development has become accessible to anyone with a modern browser and a text editor. It will be very interesting to see how gaming on the web evolves into the future.

Friday Linked List (06/01/12)

Three cheers and a tiger for me — today is my 15th anniversary with Art & Logic, and in lieu of a party I’ve decided to dump some links that have collected in my pinboard account:

First, two different blog posts discussing ideas about user interface design. For me, these two posts have been shifting back and forth between agreeing with each other and disagreeing with each other, like an optical illusion.

Joshua Porter (no relation) gives 20 Principles of User Interface Design. Very clean, very sensible.

…but on the other hand, the always-worth-reading Rands looks to the techniques of progressive disclosure and hypothesis-driven learning that are used in games as a guide to user interface design.

Game designers have a different set of incentives to make their tools easier to learn via sandbox and atomically chunked learning. They may obsessively play test their games looking for user frustration earlier, but whether you’re leaping through a portal or creating masks of transparent elements in Photoshop, both use cases strive for a moment where you can cleverly and unexpected solve a seemingly impossible problem on your own.

Game designers and application designers might exist in different universes, but there is no reason one universe can’t teach the other.

Another list-based link from The Twelve-Factor App:

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

I’ve certainly seen a lot of projects going through various degrees of pain that could have been reduced or eliminated had they implemented these ideas.

Lastly — Blockly:

What is Blockly?

A new programming language made up of “blocks” that look like jigsaw puzzle pieces.

What do I use Blockly for?

First, a programmer needs to integrate Blockly with a web application, like Gmail or Google Docs, that you already use. Then you can use Blockly to write simple programs like macros and scripts that work with the web application.

For example, in Gmail, you can use Blockly to create email filters that do things like, “If Bob emails me three times in less than an hour, and each email contains the word ‘deadline’, delete all his emails except the first one.”

The image at the top of this post is a quick thing I threw together with their Blockly demo. Took me about 5 minutes (where I could have written and tested it in Python in much less). On the other hand, it’s very close to the programming interface used by MIT’s Scratch, which my kids both enjoyed using when they were little. It might prove to be a very easy and useful way to add end-user programmability to a system at some point. Their ‘Code’ demo lets you create a program with the Blockly editor and then export it to working code in any of JavaScript, Dart, Python, or XML.