Posts Tagged ‘flash’

• By Rich

  Tags

  flash, html5, jsfl, Phaser, workflow

  Posted in

  Phaser

  5 comments

  Flash to Phaser JSFL Script

  28th May 2014

  5

  

  What is it?

  Flash to Phaser is a JSFL script that will aid in the process of laying out scenes within the Flash IDE and converting them into Phaser JavaScript files. It works by parsing the Stage for any Bitmap or Symbol objects and then automatically builds-up a JavaScript source file including preload and create functions that accurately re-create what is seen inside the Flash IDE.

  If the script encounters a Symbol it treats it as a Phaser Group and uses the Symbol name as a Group name. Any Bitmaps within the Symbol are treated as Group children and positioned accordingly.

  Objects have their x, y, rotation and scale properties re-created in the JavaScript.

  Installation

  Download the JSFL file from Github (you’ll also find this guide as a PDF there)

  There are two ways to install JSFL scripts into the Flash IDE. One is to copy them into the Flash application data folder, specifically into the “Configuration/Commands” sub-folder. The location of this varies tremendously based on OS and Flash version. There is a slightly out dated guide available here on the Adobe site.

  An easier method is to create the script manually, which is what I’ll describe here.

  Read More

• 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

• By Rich

  Tags

  adobe, flash, future, html5, unity, webgl

  Posted in

  Game Development

  146 comments

  The reality of developing web games with Flash, HTML5 and Unity

  10th Nov 2011

  146

  

  Update: Lots of new links added at the bottom and feedback from comments inserted into the article body.

  Today was a black day for Flash developers world-wide. Adobe announced it will drop Flash support for mobile browsers. This came the day after announcing mass redundancies across the company. On the face of it that doesn’t seem like a significant problem. But it has got the whole “Flash hate wagon” on the roll again, so I felt it was time to finally commit my thoughts to this blog.

  First of all: I am only concerned about game development for the web. This entire article focuses on this specific topic and this topic alone. This is not a “Flash vs. HTML5” article. It’s not an article about building native apps for mobile. It’s entirely and utterly about the reality of making web games today.

  I compare Flash, HTML5 and Unity, as they are the only viable web gaming platforms today. For each of them I cover 10 topics:

  1. Workflow – How easy is it to actually create a game?
  2. Platform Stability – Will things change between the time you start and finish your game?
  3. Backward Support – Will your game still run 10 years down the line?
  4. Mobile – Will your game run at all?!
  5. Distribution – There’s no point making something no-one will play
  6. Security – Code and IP protection
  7. Monetization – All about making games to make money
  8. Facebook – The social gaming angle
  9. How many people will play your game?
  10. 3D Support – Stage3D vs. WebGL vs. Unity

  These are all areas that I feel game developers ought to be aware of when evaluating new platforms. I conclude this with my advice to Flash game developers both new and seasoned.

  It’s a long read but it was vital I covered as much as I could, using facts and stats rather than hyperbole, so you can make the best informed decision possible.

  Read More