Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Let me explain what I mean by "standard way of delivering"...

Think about Flash games sites. Flash games can be delivered as a single file, either hosted by the site, or, I guess, provided by someone else.

HTML5 games, on the other hand, don't have something so standard. Usually, they have their own page, and portals just link to that page. I think that it greatly hinders the purpose of that portal, because, well, you want people to stay on your site and look for other games.

Now, I think that a some kind of iframe way of delivering games would help solve this problem greatly. I saw some games doing that, and they were often included on tutorial sites to show a live example, which is obviously a great thing.

So, is there a standard at all? Any suggestions? Can you create a game that just preloads itself in an iframe (I heard something about a "single document" or something)?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

I'm not aware of a standard way to deliver a HTML5 game (yet). Most portals I'm aware of just list the games (together with ratings), but then link to external sites where the games are hosted (eg. to the site of the game-creator).

As things evolve, I'm sure there will be efforts to keep people on the portal-site and similar things that are currently known from flash-games (eg. centralized high-scores, ads within the game etc.).

Currently I see two valid approaches:

  • Integrate the game via iFrame. This is very easy to do, doesn't introduce any JavaScript conflicts and also offloads server-load to third-party sites.

  • Provide a JavaScript framework with asset-loaders, highscores etc. Game-Developers would have to prepare their game for the framework but would benefit from easy asset-loading and centralized high-scores.

With the plethora of currently available JavaScript game engines/libraries the second solution seems unlikely, as a lot of engines will already have their own means of loading assets and depending on how the game was implemented, JS conflicts can occur. It would work well in an environment where the game-engine is already known, eg. for a showcase of an engine developer.

Another approach are packaged applications. Google allows this as a way to package apps for their web store. Packaged apps can be downloaded and can also use the Chrome Extension APIs. This could be a great way to distribute games but if there's ever going to be a cross-browser standard is questionable.

share|improve this answer
add comment

it's ironic how HTML5 distribution isn't standardized (when the language itself is).

someone's got to make it a single package, for all websites/portals/app stores.

share|improve this answer
    
Hey, I agree with you: but this isn't really an answer. Could you please add it as a comment instead? –  akled Jul 19 '12 at 4:52
    
current rep of 31 means the guy doesn't have commenting privileges yet... upvoted so you can participate. –  tugs Jul 19 '12 at 22:47
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.