

Ask HN: Moving Flash games to HTML5 - syl

Hey folks,<p>I made a very simple Flash game a few years back for a college class. It was quite fun.  I had been thinking about recreating it with HTML and JS (and probably leveraging some HTML5 features like canvas).  I figured it could be a cool game for iPhone/Android/WebOS phones, as well.<p>My biggest concern with doing this is cheating.  This simple game had a scoreboard (Flash submitting a POST request to a PHP script, with some authentication/validation).  The biggest drive to playing the game over and over was the scoreboard.  I'm afraid that moving it HTML+JS would make it easy to cheat. (Example: Using Firebug to change the JavaScript to stop the countdown timer from working.)  With Flash, the users don't know what's going on.  The best they could do was intercept the POST traffic and see what's being sent.<p>I suppose I could use things like the YUI Compressor to keep the JS harder to modify. (http://developer.yahoo.com/yui/compressor/)<p>I'm more curious on ideas for Flash game developers moving to HTML5.  I probably haven't touched Flash since I made this game in college, so I don't know how Flash is these days.  Any advice on how to handle potential cheaters would be great.  Any other advice on moving Flash games to HTML5 for other developers could be helpful too.<p>Thanks!
======
chipsy
1\. You're overthinking the nature of cheating. Flash games have been put
through the wringer using memory-editing tools like Cheat Engine. The only
truly secure strategy is an expensive one - record, upload, and replay the
game on-server. The cheaper alternative is hand-moderated scoreboards. In any
case, high scores are not central to the success of most games - they're a
payoff that comes at the end of a session and many users will back out before
finishing even one session. (Yes your game may differ, but you haven't
presented data to back up the assertion.)

2\. It's just too early to move to HTML5 for commercial games - no developer
ecosystem, monetization methods are entirely DIY, limited user benefit, etc.
That will all change, but I would treat a port like this as a demo project.

~~~
syl
You're right about overthinking the cheating thing already. I should focus
more on how to make the game and its logic, and worry about cheating when it
happens. Moderating the scoreboards will probably be good enough.

Thanks for the tips!

------
tobyhede
It definitely early for a big leap if you have solid Flash skills and existing
content. If you don't have massive investment in existing tech, then new
development should definitely be done in HTML 5.

However, Canvas is years behind Flash in terms of ease of development. At the
moment using Canvas is a completely manual process. You have to manually
manage every single element, there are no events, no layers, no objects - you
roll all of this yourself. That said, looks like longer-term Adobe will be
targeting Canvas.

I am currently building a game using SVG via the RaphaelJS library. Overcomes
a lot of the problems with canvas (I get events and a real-life DOM), and my
use-case is not performance intensive so seems to be working fine so far.

Cheating is a problem in all games, Flash is arguably a little harder to
cheat, but it is still not particularly difficult. The best thing to do is
setup server-side controls for cheating - there are a range of different
options that can be pursued her.

------
SudarshanP
<http://scripty2.com/demos/cards/> You may find this library interesting if
you end up choosing to port to html5

