Server storage is a solution for tracking client state, but it is not an elegant one. Why write and maintain a web service if you can store state client side in a browser cookie?  This is easier, but the problem with this approach is that your program is not guaranteed to have access to cookies in every browser. For example, an end user might have cookie permissions turned-off by default.

This is where stateless oAuth comes in to the picture. Stateless oAuth flow allows us the ease of client-side data storage for client specific information without relying on the availability of browser cookies. The local state parameter in oAuth 2.0 is designed for precisely this use case, but unfortunately it is not supported by the most popular oAuth providers today, including Facebook.

But if we are passing a redirect URL in the oAuth specification anyway, then why not just encode client state in a URL parameter if it is small enough to fit?  This solution works well except for the fact that many special characters are disallowed in the redirect_uri parameter specification, most notably percent “%” and slash “/”. This limitation makes it very hard to put a nested callback URL as a query string parameter of the redirect URL. The most often cited solution here is to base64 encode client state using a file system encoding scheme to avoid getting another slash “/”, and then append it as a query string parameter to the redirect URL. When the client gets redirected back to the authentication service from the oAuth provider site, we can decode the client state from the query string.

Unfortunately there is another problem with this solution. When a string is base64 encoded, often times equal signs “=” are appended as padding characters to normalize the length of the encoded strings, and the equal sign is also an illegal character in the redirect_uri parameter. There are a few ways around this. You can replace these equal signs with a valid redirect_uri character, like perhaps an underscore “_”. Alternatively you can strip away the equal signs before starting the oAuth flow and then add them back once the client returns from the oAuth provider site. Since the amount of padding characters needed is determined solely by the length of the encoded string, adding the characters back is trivial, and might look something like this:

cb_url += "=" * ((4 - len(cb_url) % 4) % 4)
cb_url = base64.b64decode(cb_url)

Until mainstream oAuth providers support local state, base64 encoding local state into a redirect URL parameter is the best way to avoid storing client state on the server. With only a few lines of client-side code, stateless oAuth is an elegant way to store client data without relying on cookie access or writing and maintaining an extra server-side service.

There’s a lot of work that has been done on the game since this video, but it gives you a flavor of what we’re up to. I’m falling in love with our partner band – Red Card Royale. Too bad they aren’t still together.

But HTML5 will not automatically solve every problem of platform fragmentation. Any developer targeting multiple devices knows that handling multiple resolutions can turn into a long and annoying chore. Resolutions vary widely across common devices used for casual gaming as we see in the chart below.

Supporting multiple resolutions can be tedious, but there are a number of strategies to minimize the ammount of duplication of effort between devices of different resolutions.

MVC

An MVC design pattern (Model, View, Controller) keeps game display code separate from game logic and data. This is a first step in reducing the lines of code affected by a change in screen dimensions. At the most basic level a developer can write a separate view for each supported resolution. Further code reuse can be achieved by using parameterized views that make use of screen size constants stored in a JSON object.

Let’s walk through an example of how I would use this approach to resize an app, starting with a 320 x 480 app written with the iPhone’s dimensions in mind.

At 640 x 960, the iPhone 4′s dimensions are exactly double that of previous iPhones. So we can simply scale up the app’s dimensions by two and include double-resolution images. This is the default approach taken by Apple on the iOS platform.

The iPad has a resolution of 768 x 1024 which is also a good size for apps on the Chrome web store. This means the iPad has an aspect ratio of 3:4, so a simple scaling from the iPhone’s 2:3 aspect ratio will not work in this case. Moreover, scaling would involve yet another version of our image files. A better approach is aligning the iPhone 4-sized app to the lower left corner and then filling the extra pixels along the top and right margins with border art, branding, widgets (e.g. game clock), or in-game advertisements.

Many popular Android phones share a 480 x 800 resolution, giving them a 3:5 aspect ratio. Scaling up our original app by 1.5x gives an app of 480 x 720. I center this on the Android screen and add an artistic border on both sides.

Lastly, we have a Facebook iframe app, which is 760px wide and as high as the developer desires. I would make this 480px high and use the 1.5 scale app again, centering it horizontally and filling the smaller margins with an artistic border.

Game Mechanics

Some games adapt naturally to multiple devices. Games with tiled maps, scrolling or camera views can simply use zooming or cropping to fit the view to the screen. We have to be careful about multiplayer balance if a larger visual range gives one player an advantage over another, but for a single player RPG or a turn-based game it does not really matter. Zooming is a UI convenience for the player when dealing with panning a smaller viewport across a larger world.

Layout Choices

It is helpful to layout the size and position of UI widgets using something other than absolute coordinates i.e. specifying offsets from the parent element in either pixels, some resolution-independent grid or point system, or percentages. This layout model draws inspiration from the familiar box model used in CSS. Many software frameworks use a resolution-independent point-based grid system rather than working in pure physical pixels. For example, in iOS a layout “point” is equal to one pixel on iPhone 3 but four pixels on the higher resolution iPhone 4 retina displays. The developer only has to include higher resolution images to take advantage of the more dense displays on the iPhone 4.

There is no way to automatically adapt a game to all possible screen sizes, but good design makes it much easier.

What techniques do you use to support multiple resolutions?  Do you have suggestions for other developers?  Let us know in the comments!

Our grand vision is to make it as easy to write a multi-platform, multiplayer game as it is to write a single player game, and to do it all in JavaScript using HTML5 APIs. The web portion of our game SDK will be open source, and maybe more of the project depending on what makes sense. We think that’s pretty cool. If you agree then drop us a line.

SSE Labs is inspired by the YCombinator seed accelerator model. It gives aspiring startups with a Stanford connection resources to grow their companies including office space, experienced mentors, and a growing alumni network. But SSE is not a copycat of YC. One major difference is that SSE doesn’t take equity in its companies which leaves them with the flexibility to pursue other incubator and funding opportunities as well. Two YC companies with Stanford connections are working at the SSE space and serving as mentors to SSE companies, CrowdBooster and Hyperink.

The most tangible benefit of joining SSE is our new office space. The team had outgrown our old office – a cramped basement space in downtown Palo Alto with a spastic climate control system. Now we are graciously provided with free desks by AOL in their spacious new building off of Page Mill road. AOL’s offices come complete with all the expected web 3.0 workspace amenities: pool tables, beer kegs, espresso machines, white board walls, and room to stretch without poking each other in the eye.

Fire code violation?

You've got sunlight!

While the creature comforts are nice, the most valuable part of the office is collaboration with the other startups teams. Every Thursday evening all the teams come to the office to work concurrently. This week we gave feedback on the pitches of the previous batch of companies as they prepared for the upcoming Demo Day. Not all of the companies are ready to come out of stealth mode so I won’t describe their ventures in great detail. The breadth of the markets the startups address is impressive spanning devices for the blind, a clever new take on iPhone games, financial planning products for underserved demographics, and a Hayekian take on a social Q&A site. About half of the companies in the previous batch have some sort of hardware or wetware component.

SSE’s mission to serve the entire student body of Stanford draws brilliant founders from all over the engineering spectrum. It’s a refreshing break from flavor-of-the-week clones that dominate the valley.

SSE also connects startups to experienced mentors and investors. In the first week of the program we were given the opportunity to hone our pitch in a private meeting with a representative from a well-known VC firm. It would take many hours spent away from coding for a startup to duplicate the connections that SSE provides for free.

In the coming week we will be attending the previous class’s demo day, choosing an SSE mentor, and getting a visit from the founder of Shopkick. Of course, there will also be plenty of time hacking away on the Game Closure platform.

good company