• Asus Transformer Prime
• Samsung Galaxy Tab
• iPad 3
• iPhone 3GS
• Apple TV 2
• Chrome Book
• Macbook Air 11”
• Dell PC with two monitors
• Xbox 360 wireless controller for Windows Controller
• Dell Mouse
• Microsoft Trackball
• and of course a Space Quest II box. Who hasn’t one these days?

Why do I need all this stuff today? Well, my default setup is the PC with two monitors, mouse and trackball. I carry my iPad, iPhone and Macbook along with me when I travel from home to the Q42 office. For the Q42 Games project I tested gamepad support in HTML a few weeks ago, and for the Schooltas project at the moment I’m doing a bit of Android research.

The Apple TV is a version 2 that I traded with Chris today for my newly purchased version 3 because tonight I’ll be doing some legal jailbreaking of it and enjoying my new XBMC box :D 

And the Space Quest II box is one of my many Sierra boxes that I brought here in the office, which couldn’t be a better timing as we just finished the Two Guys Kickstarter HTML5 prototypes.

In an attempt bring something new to the Kickstarter table we signed up with legendary Space Quest designers Mark Crowe and Scott Murphy to do something insane: 

Release a new game every time another $100.000 milestone is reached during their SpaceVenture Kickstarter campaign.

Little did we know what we were in for, but I can tell you it’s been one heck of a ride, and it’s not over yet. As we’re in a nailbiting finish of the final 20 or so hours and not having reached the goal of $500.000 yet, I thought this would be a swell time to show what we’ve done “so far” :D

Game 0: How we got involved in the first place.

Read all about it in this post.

Game 1: The sketch

We built a first playable adventure game based on a pencil sketch by Mark Crowe. The game involves an anonymous player and just basic interactivity. If you’ve got Chrome you can play it here for free:

https://chrome.google.com/webstore/detail/lomnnfeooofoenddphjjfdfbpkiiboof

Game 2: The game in full color artwork with death scenes

For the second demo we implemented the full color artwork of Mark and added death scenes. There were 3 ways to die, including a man-eating plant, we added an animating space backdrop and a better interface.

Play it here for free right from your Chrome browser if you like.

https://chrome.google.com/webstore/detail/mhjbdidbieimmfipadjkioniffgcgopp

Game 3 - iPad support, other browsers and lots of gimmicks

For this version the game became playable outside the Chrome Web Store and allowed players to install it on the iPad for offline play. Music was added (though not for the iPad through html yet) and lots of jokes were added like a DOS prompt, an “Insert Disk 2” installation joke and much more.

Check out this page for installation instructions for any platform.

http://guysfromandromeda.com/living-concept-art-phase-3/

Game 4 - Playable minigame

Game four actually had game 5 inside: a little minigame!

We added a new iPad touch interface, music, water particle effects, new music and sound effects, puzzles and the new jokes that Scott Murphy sent us. But the minigame was a personal favorite for the development team here at Q42. It was hilarious to do, and the reception was amazing.

Play it here:

http://guysfromandromeda.com/living-concept-art-phase-4/

Game 5 - ???

We’re not at the $500.000 yet so we haven’t released a fifth game. 

Bonus material

And just for fun we thought it would be cool if we gave the Two Guys and all the fans something in return for the awesome time we already had together. So we put together a few 1986-style spoof images of a (nonexisting) game exactly like the one we’ve been working on, only this time with the retro look and feel of the original Space Quests:

Closing thoughts

As I’m wrapping up this blogpost, the Kickstarter is at $489.000 with 21 hours to go. So if you’ve got $15 bucks to spare and want to play a really cool new adventure game from the guys who brought the world Space Quest, well then please go here and pledge. $15 will do just fine :D

http://www.kickstarter.com/projects/spaceventure/two-guys-spaceventure-by-the-creators-of-space-que

Hey mobile web developers. You can use Chrome to behave as an iPad or iPhone by overriding the User Agent and emulating touch events, and it’s just a click away.

In Chrome press F12 to open the Developer Tools. On the bottom right is a little settings gear. Press it, and voila:

Happy coding :D

When I heared about the Guys From Andromeda teaming up again to make another Space Quest-ish sci-fi adventure game I was thrilled. Mark Crowe and Scott Murphy have been my adventure game heroes since I was 8, and have no doubt influenced my interest in computer game development.

Let’s rewind time to two weeks ago.

Read More

q42games:

A few days per week we are now working on a new game for iOS and the Chrome Web Store with a small team. We know what direction we’re heading, and we take our time to experiment with artistic twists, new gameplay elements, unlockables, collectible items and different approaches in terms of…

God I love adventure games. So oh boy did I back the Double Fine kickstarter. Hey, it ended 2 days ago, so your money and mine was transferred to Double Fine  - for great justice. 

$3,336,371 gets you a long way, but what if more people want to “back” it? Impossible this way, as kickstarter is about starting new ideas by funding them and once the time is up it’s a done deal.

Since Double Fine, we’ve seen more projects pass $1M in funding, and governments discussing on whether or not crowdfunding should be regulated - though that’s another discussion. 

But I wonder: what would happen if, say, the Double Fine kickstarter still left the payment option open for people to back that project post-fundem? Where would they be in a month? And more importantly; what more would the (financially) connected community get beyond what they are already getting?^*

(* a sarien.net kinda hosted online version up in the Chrome Web Store or on Facebook perhaps? Hey Tim, if you read this - “how you doin?” ;) )

Apple’s iPad 3 is set to launch a few days from now, and if the rumors are true it will feature a retina display of 2048 × 1536 pixels. That’s about π megapixels for games and apps to make use of.

Mobile Safari has a few resource limits that web developers may not have encountered yet as full-screen 1024 × 768 images did not exceed that limit. If Apple doesn’t change the limitations then you will want to know this.

In short, the limitation states that:

• JPEG images of any size between 2 and 32 megapixels are subsampled down to 2, regardless of the amount of RAM you have.
• PNG, GIF and TIFF have a 3 megapixel limit for devices with 256 MB of RAM, and a 5 megapixel cap for devices with 512 MB of RAM.

It means your JPEG images will not remain as crisp as you have designed them when their width × height exceeds 1024 × 1024 × 2 pixels, which they will when designed for the iPad 3 retina display.

So when the iPad 3 is launched, check if this limitation is still active. If so, break up large images into multiple smaller pieces that - when combined - offer the original crisp and sharp visual that you had designed. 

This post by Dave Spurr might give you some more information about this resampling behavior, and my experiences early last year got me to debugging different image sizes exactly like that until I found Apple’s resource limit information.

If you want to better prepare yourself for designing and developing retina iPad (web) apps, Luke Wroblewski’s Designing for the Retina Display is a great place to start.

Take a cardboard box.

Measure its width and height.

Put something in it. Om Nom for example.

Add some padding.

Now measure that box again.

Guess what? It’s still the same width and height!

Now then, what if we tried this in HTML and CSS? Today?

For the record, today is 2012. We’re in the midst of a rapidly evolving web that has brought us hardware accelerated 3D transforms, webGL shaders, audio processing, gamepad support, notifications, offline local SQL storage, mouse pointer locking and laserbeams that can destroy entire planets.

With all that artillery in place, let’s make a box, give it a certain width and add some padding.

We specify a box with a width of 100 pixels.

#box { width: 100px; }

Saying our box is 100 pixels wide is like saying our box is 100 pixels wide and it kindof means that “OUR BOX IS 100 PIXELS WIDE”. That’s 100 pixels. Wide. 

Now add a ten pixels of padding inside.

#box { width: 100px; padding: 10px; }

Measure the box again. Guess what? It’s 120 pixels wide.

Jeff Kaufman’s post “The Revenge Of the IE Boxmodel?“ came at the perfect timing and reminded me to stop going at this the hard way and adopt the old IE box model in a similar fashion that giveupandusetables.com has been the pragmatic programmer’s best friend over the advice of many white-bearded committee members.

All you need is this:

* { box-sizing: border-box; }

Or, as Paul Irish recommends: 

* { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }

And BAM! Our box is 100 pixels wide. We’re in sense-making mode again. The one that the loving people at Microsoft came up with back in 1997. Back when IE was bashed at for doing their own browser enhancements (which is deemed perfectly normal for other browser vendors for many years now).

To get a compatibity overview of how box-sizing is supported in different browsers, you could also check HTML5Please. 

Today I have switched to the border-box model for a real project I’m working on for a real client with a really big team. Already it has saved me loads of stupid calculations (“okay, so the box is 496 pixels wide and there’s 18 pixels padding, and …”) and I wish I had done this 10 years earlier. 

So here’s my advice. Stop using todays box-model and party like it’s 1997.

Today I stumbled upon what seems to be a cross-dmain issue in IE when trying to obtain data from server at domain A to client at domain B through an XmlHttpRequest (XHR) using jQuery.ajax for coding convenience.

Servers disallow such requests by default and setting the Access-Control-Allow-Origin header will whitelist other domains (or all domains by setting its value to “*”).

I was working on an html/js page on my localhost debug environment and I tried to get content from our staging server at a different domain. The Access-Control-Allow-Origin header was set to “*” and I am doing the required requests by said jQuery ajax call. Everything works fine in Chrome and Firefox.

IE however gave an error without many details and after some googling it seems this was due to IE XmlHttpRequests not allowing cross-domain requests regardless of the server’s setting. Instead, one needs to use IE’s proprietary XDomainRequest.

All well and good, but I was surprised to find that jQuery doesn’t work around this. There’s a ghist that adds XDomainRequest support to jQuery so the solution to this problem was simple, but I found this discussion far more interesting:

Ticket #8283 BUILT-IN SUPPORT FOR XDOMAINREQUEST

In short, the discussion is about wether jQuery should offer built-in support for XDomainRequest or if it should be provided as a plugin. I agree with some of the posters that jQuery’s main use is two-fold:

1. Work around browser inconsistencies
2. Simplifying complex operations

To me, a difference in XHR implementation in regard to cross domain requests falls under the same category as working around the difference is setting up DOM event listeners, and jQuery should offer built-in support.

What do you think?