Downloadable Versus Browser Based (Could Use a Bit Of Technical Aid For Networking Code…)

The traitor game idea I’m prototyping next is technically relatively simple. There’s at maximum a few (technical) elements in the game: player characters (with few traits, location info and some attributes/state info) chatting, some items (objects to pick up and use), level scenery and then perhaps few more things.

Technically this is not so big deal that this couldn’t be done with a fully browser based system. There’s just some things that make me want to use downloadable version:

  • I have experience in promoting downloadable (I could imagine getting the game to gaming magazines, but I’d have doubt if a browser game could make it)
  • Downloadable games feel “worth more”, thus perhaps making it easier to sell the game. (Of course browser based games are big ones, but at least to me the feeling of “getting the game to my own computer” makes it somewhat more “valuable” to me compared to playing something in browser. Perhaps this is just me.)
  • It’s possible to get portals/distributors to promote the game. They are not accepting browser games in Steam you know…
  • Music and sounds. With the web technologies I’m familiar (HTML/PHP/JavaScript/AJAX/CSS) there’s practically no possibility to get proper sounds or music in the game. And I intend to keep it non-flash (since I’m the guy who is going to code the game anyway). And music and sounds play an important role in the feelings side of things.

Now there’s just some tiny technical issues that are already solved on the browser games:

  • Technically browser based game is very straightforward: just do bit of HTTP calls and throw in some AJAX and things are cool.
  • Nobody needs to download anything – sharing the fun gets so easy.

Which leads to my next point. I started imagining that I could simply “port” the browser client into a Blitzmax downloadable version (which would still do http calls). The thing here is that in downloadable game I would (possibly) want something slightly faster than inside a browser. This means that “polling game server every few seconds” is slightly silly, and I’d need a better option for this. I’m wondering if creating one big server (which would handle all games) using for example UDP be a wise move. Or whether I should do UDP server-client systems, and let each player host their own games (here’s the issues with NATs and shite which I really don’t want.)

To me the next thing is to see what kind of technical limitations the downloadable system has, and any tips on this would be most appreciated.

Juuso Hietalahti


  1. For me, downloadable game means you need to invest more, human resources, money, and many more.

    While a browser-based game means a small group of ppl could make it come true.

    I have created http://www.playbbg.com, but few ppl would like to advertise their games. The problem I think Browser-based game has small potential in the huge market.

    Anyway, each has its cons and pros. I’d like to stay current with your blog.

  2. @tycoon: yeh, and especially now in the prototyping phase. Even if I’d decide to do blitzmax at some point it might make sense to create web version first (mainly since there’s nothing to download – so testing becomes one step easier :)).

  3. If there was a simple & clear example code for a playable (mini) game, I could consider Unity again (they have been bringing these on the boards).

    What I’m not interested in is making a too big mess out of this… starting to configure different master servers (and handle any reboots to deal with crash issues or whatnot :))

    If there was a sample, I’d consider it… now I feel it’s too risky.

  4. In the end I’d say stick with what you know better, if is blitzbasic do it. We all know how a java browser game (minecraft) is doing, so really all that matter is the game itself.
    I picked webgame but I’m also using google appengine so I can still code in python :)

  5. There is (was?) some issues with the networking side of things. Master server and stuff like that. (I think I posted about those earlier)

  6. Make your game with Unity3D! It can build a web, Windows, MacOSX, iPhone/iPad, Wii, Xbox360 versions for you…

  7. @tycoon: good point on that art side. portals indeed want fancy looking stuff. nevertheless, the odds are higher than with browser games.

    turnbased rpg-card: sounds good! :)

    as for ready made libs: I was simply thinking using blitzmax enet libs. Since my game doesn’t need to be high speed shooter, I don’t need to worry about lag issues. Even few seconds lag doesn’t matter :)

    @Pathogen: yeh, I know this. I’ve actually done web (html/css/js/ajax) stuff part-time (outside gaming, and well – some gaming stuff as well) for close to a decade and I’m very familiar with the feeling of: “oh shit, IE does this thing differently. whadda heck, opera shows nothing…”. But things are getting slightly better and there’s some good libraries out there (jquery for example) that easen the burden.

    But with that being said… downloadable “feel worth more”. And another thing is: I haven’t purchased anything from any web game…

  8. IMHO, using non-flash/java/silverlight/whaterver would result in a disaster, every browser interprets that Javascript/HTML/etc a little different. If you think you had some compatibility issues with Dead Wake, then you’re in for a rude surprise.

    Also, like you said, downloadable games feel to be worth more.

  9. I was doing it as downloadable but recently moved to webgame. In my case though my reasoning has been different: is easier to get “decent” result as webgame than downloadable. Nowadays to get on Steam etc you need 3d stuff (check how many 2d games there are vs 3d…) and you need a big budget.
    With webgames instead, because of the technical limitations, unless you use Flash people don’t expect much.
    In my case I’m doing a turnbased rpg-card game so probably very different from your project anyway :)
    If you go with downloadable use a ready made network lib, there are many. With python connecting was 10 lines of code ;)

Comments are closed.