Engines of Gamification

After years of talking about games for science, I'm finally going to jump in and make one.  I've got an idea (which I will elaborate on soon) and now I'm trying to figure out how to go about implementing it.  The challenge right now is to decide which of the infinite options that I should use to make it happen.

My basic requirements are pretty simple:

1. the game should be accessible in most Web browsers
2. it should run happily on an iPad
3. it should have basic graphics (e.g. blocks and arrows) and sounds
4. it should talk to a server running Java that will perform some computations and keep track of the data
5. it should enable fast prototyping
6. I should be able to do the prototyping myself

I discussed this with Josh Peay, a longtime game engineer at Sony and recent founder of mobile gaming company South Bird Studios, and he advocated jumping right in and learning a full-fledged game development system called Unity3d.  So I had a look.. and was immediately intimidated by its complexity.  It turns out that building immersive interactive games in a 3d environment still takes quite a bit of work - and quite a bit of artistic support - even with a hulking (2GB application) gaming engine in the background.  Since I really haven't conceived of anything that would benefit substantially from the level of interactive control offered by Unity or its brethren I'm really hesitant to start climbing up its learning curve.

Flash seems like it would probably do the job pretty well, but see #2 above.

And that leads me towards some sort of javascript environment.  Though I have played a bit with javascript before, I'm really not very good at it.  This causes me concern for #5 and #6 above.  To reduce this concern I've started looking for library support.

Here is a year-old list of 66 game-related javascript libraries that clearly is an underrepresentation of what is out there.  One that isn't listed is a Google product called PlayN (formerly 'forplay') based on GWT.  PlayN is tempting for me because you write your code in Java (which I guess is appealing to those of us in their thirties or greater) and it can generate deployable games in HTML5, Flash, the desktop and there are rumors maybe someday for iOS.  Its also easy to distribute the games via the Chrome store.  It doesn't have a lot of the Unity3d bells and whistles but, like I said, I don't need to use it to build the next Call of Duty.  Still, PlayN is still alpha code and, as my colleagues enjoy reminding me, Java and other compiled languages are for old farts...

Which to choose????

Update The interested gamifier might also like to have a look at the following frameworks for creating computerized versions of board and card games:

1. Vassal
2. Battlegrounds
3. ZunTzu

I like that you have the basics of player/card/board/hand/deck etc. management taken care of, there are nice realtime communication features ready out of the box and that you are provided with what appears to be a pretty straightforward development environment.  I don't like that players would have to install the engine on their computers before they could play the game and that none of them would work on an iPad.