Ask HN: Moving Flash games to HTML5 | Hacker News Reader

Ask HN: Moving Flash games to HTML5

5 pointssyl4 comments

Hey folks,

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.

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.

I suppose I could use things like the YUI Compressor to keep the JS harder to modify. (http://developer.yahoo.com/yui/compressor/)

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.

Thanks!

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.

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!

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.

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

Reply on news.ycombinator.com