Posts Tagged ‘conversion’

• By Rich

  Tags

  ActionScript3, conversion, TypeScript

  Posted in

  ActionScript3

  4 comments

  AS3 to TypeScript Conversion Script

  2nd Apr 2013

  4

  

  I write a lot of HTML5 games and my preferred language of choice is TypeScript. I love the compile-time errors, code-insight and debugging tools it provides. A large part of my work is porting over ActionScript3 code from Flash games. I found that I was going through the same motions over and over again; simple things like changing “Boolean” to “bool”, or rename the class function to “constructor”.

  It got to the point where I figured it would save time to write a script to help with the process. So I did, and I’ve released it for anyone else who may benefit from it. The script runs on a local web server and can convert either a single file or a whole directory full of them. It will intelligently deep-scan a folder structure, converting just the ActionScript files that it finds along the way. I’ve successfully run it across the whole of the flixel codebase with no issues, so I’m hopeful it’ll work for you.

  It uses a set of 20 conversion tasks, but the list is easy to modify and extend. Indeed if you create new ones (or optimise some of my sucky regexps!) to the benefit other devs then please share them so I can update the script.

  Be under no illusion about the amount of work you’ll still have to do once the conversion has run. Properties, vars, native Flash objects and lots of other things will still need fixing and changing by hand. But at least a huge volume of the tedious grunt work will be out of the way. And if it saves you as much time as it has  me then that’s just a bonus in my books.

  Grab the AS3 to TypeScript Converter from github.

• By Rich

  Tags

  animation, conversion, flash, sprites

  Posted in

  HTML5

  14 comments

  12 Tools for Converting Flash Games to HTML5

  18th Jul 2012

  14

  As well as making our own games we also convert Flash games to HTML5 for clients. And having just finished our 9th conversion we’ve learnt a number of lessons along the way. So for fellow developers doing the same as us here is a list of our favourite tips, tools and libraries. Hopefully some of these can help you, and if you’ve got any others you would recommend then please leave a comment.

  1) One Size Doesn’t Fit All

  Every game we’ve done so far has been converted with the mobile web in mind. After all Flash is still plenty strong enough on Desktop, so our work has been in taking popular games designed for desktop and porting them ‘down’ to mobile browsers. As you’d expect the most immediate problem is that depending on how old the games are they can vary in size dramatically. From the classic 550 x 400 to more modern 800 x 600 and above. And needless to say, these don’t often play nicely with mobile resolutions.

  The base minimum you are likely to need to support is 320 x 480 (portrait) or 480 x 320 if the game will be in landscape. This caters for iPhone 3 and older Android handsets. However before you start resizing graphics always factor in how much room the browser UI will take-up. For example on an iPhone 3 you will lose the top 20px to the status bar and the bottom 44px to the navigation controls, neither of which can be removed in default browsing mode. In portrait mode this gives you a visible area of 416px once you have scrolled the URL bar out of the way and a paltry 268px in landscape mode, less than the 8 year old Nintendo DS. On iPads, Android phones and tablets such as the Kindle Fire this changes again.

  In short you should plan your game like you’d plan a presentation for an overhead projector: don’t put crucial information or items such as the “Play” button near the edges. And whatever you do, don’t assume that everyone will be playing your game at the same resolution. Stats from one of our own titles shows a staggering 4,000+ different reported  resolutions.

  Handy tip: If you’re going to mock-up screen shots for your client, make sure you do so with the browser UI visible. If you don’t they may assume the game is going to be full screen ‘just like a normal app’ when in reality it won’t. It may also save you precious design time later on if your designers know up-front they shouldn’t use device resolutions as their template.

  

  2) Different graphics for Low Res and High Res Devices

  I’m not going to labour on this point for long, but depending on the game you should almost certainly expect to be creating two sets of assets: SD (low resolution) and HD (high resolution) and dynamically load them based on device capabilities. You don’t want to squeeze a tiny game into the middle of an iPad screen for example, and as they’ve typically got the processing power to take advantage of pushing more pixels around it’d be wise to use that. There are a myriad of ways to deal with resizing your game for devices, and they all depend on how the game is built (canvas or DOM). Whatever you do don’t under-estimate the amount of work that goes into this aspect, but do plan for it up front.

  Read More