Web based game on Pandora.. would you?

[skeezix]

For some types of applications or games, theres a hard choice; make it native for a device (better controls, well tailored, etc .. but having to do it for every device means 10x the work) versus web app (pita to write due to crazy not yet ratified standards, browser hell, etc), versus a whole gradiant inbetween.


For one game I've on-and-off-again been working on (a turn based wargame) its a tough choice -- turn based and slow paced really screams 'make it web based', so can be played on desktop or pandora or phone, without my having to bnuild and maintain many versions per se, plus just being that sort of thing possibly .. if I can provide enough info in the UI for the various screen sizes, then coudl be rgeat to pull out your phone and do some work, or your pandora, or desktop, or whatever. But native is alwasys great. Or maybe I need to do both ... web for most, and ship a native pandora client. Or a hybrid ... which is what I was working on for a long time (a native app with embedded browser, so it was native feeling, but future proofed as well.)


This whole business with my suddenly having twins in a few months is sort of making me take a hard look at this and others .. and I'd rather not 'just drop it forever', so its time to simplify like mad .. dropping all the 3d graphics and whatnot I've been working on and just go for a simple forms/dialog/basic-graphics interface for now, try and buld somethign that I will be able to maintain while severely sleep deprived, etc. I'm just not going to have the luxury to build several versions, or write a custom SDL app, or write up all this GLES stuff, or ... etc.


..


If I make a web based app that you can work with via Chromium Dev on the pandora, would you play it?


Or does the whole idea of being in a browsder just totally turn you off?


..


This is a multiplayer wargame, so network connectivity to check into the server and send in-game messages and such is essential anyway.


..


jeff


edit; one big thing against a web based game is .. have you ever heard a non-flash webapp play sound? I've got 90 minutes of really good background music for this game already (musician pal custom made it), and I'll be driven mad if I can't use it. Sort of thinking that I might ship a pnd-file, that you run and in which dfoes two things..


- plays music


- opens up chromium dev with some specific run options and points it at my game-site, so player doesn't jhave to remember.. they just need to remember how to get out of stupid chromium devs lack of 'quit' option until you remember how to pull up the file hidden menu


Then if you run the pnd, it'll play the music until you kill chromium, say.

 

[XxionxX]

I will play them in a car. I will play them in a train. I will play them on a goat or even swimming in a moat. But most of all and by far I will play them where they are. In a browser and in a card we love our games wherever they are.


I don't think that you have to worry, as long as it works. That is the only requirement for me at least.

 

[bzar]

Or you can use Qt and get the best of both worlds (a bit diluted). 3D is a question mark, but at least you get better visuals and integration than web apps and better portability than many other libraries. If you're going for 2D graphics with asynchronous (no immediate control) action the graphicsview framework combined with the animation framework can really give you nice results.


Web apps can use sound using the HTML5 audio tag and control it using Javascript. The problem is that no audio format is supported in every browser. Luckily <audio> allows you to define several sources for the same sound, so you can just transcode your audio files with a script and provide both mp3 and ogg versions.

 

[XxionxX]

That kicks ass. You are the best.

 

[skeezix]

Oh, I'm very aware of the many options .. my current client is QT (I've been beating the QT horse for >10 years now .. for awhile I 2was even payign the triple threat .. win/unix/osx paid licenses per year) ... (and aside, the future of QT is entirely questionable nowadays, due to Nokia going into bed with Microsoft; sure it's open source if it goes sour, but a poorer future all the same.)


Still, while QT makes it much easier to go cross platform, its still not really 'future proof' for a turn based thinking mans wargame; I coudl really see people wanting to pull up details or do correspondence etc using a website.


My one client (I've attacked the problem a half dozen times, not sure what direction to go was using QtWebkit embedded in the app so its hybrid .. feel native, but with a lot of stuff coming down as html from the server, so easier to switch to (or _also_ run) a webapp in the future.


Another option is for only some operations to be web based for 'utility'; ie: perhaps a map viewer and in-game email handler on website for convenience, with actual gameplay requiring the QT client.


But all of this has to be vuiewed through the lens of -- I will not have much free time or brain power soon


Hmmmm..


jeff

 

[sebt3]

even if there is no more Nokia sponsored dev for QT, it is far from dead as it wont die before kde


I would say : keep your client as it is

 

[renegadechic]

sounds pretty intriguing! i've not played a great number of web based games before (other than short flash games like escape the rooms, flash portal and mirrors edge 2D) but one game that is really nice on the pandora is Kingdom Of Loathing. not sure if what you had in mind was even remotely similar but there is definitely scope for making something absorbing! look forward to seeing how it turns out

 

[bzar]

Skeezix: Oh yeah, you told me about your Qt background some time ago! Sorry, forgot . I'm quite confident Qt will continue on in desktop, as there are still some ~4000 commercial Qt developing companies plus all the open software built around it, like KDE SC.

 

[skeezix]

Using a native client (QT or otherwise) also implies .. a necessarily smaller audience; ie: a web app is sort of clumsy on a handheld, but is normal on a desktop to users .. people have browsers open all the time, all day every day.


So if I keep a browserfied version available, it means more players to fight with, which is always good; I'm not sure our community is large enough to keep a niche (ie: turn based wargame, and one that will look like ass now due to my not having time to do all the graphic work, so tossing it out) going.


So many factors to consider


jeff

 

[bzar]

So true. We ended up doing a web client for wars. One thing you might consider is starting out with a Qt client with a web client in mind (or the other way around). Use protocols and paradigms that suit both worlds, like a subscribe/publish messaging model server and abstract the actual connection away serverside. This way you can do both clients for your game if you so please, or just concentrate on one. This is the direction I intend to develop wars once I get back to it. Fortunately node.js (which I intend to use) makes this quite easy . At least you only need to write the client if you choose to change the delivery platform

 

[skeezix]

yeah, my existing API is all JSON and JSON-RPC, nice and easy; currently, client connects and gets a big state dump, then calls API RPC to push up changes or fetch additional info or get updates, etc. Pretty workable with any sort of client.


I forgot about Wars .. that was pretty impressive Thats akin to what I'm going for (totalyl different game, but same old classic wargame model .. subscribe, create game, get players to join, then start the turn clock..)


jeff