Posts Tagged ‘sprites’
18th Jul 2012
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.
13th Oct 2011
While playing around with my shoot-em-up test for Stage3D I realised that I wanted my enemies to follow interesting and varied paths. And I wanted to create those paths visually. This is something I’ve needed in Flixel for a while actually, and although you can do it via the Flash IDE with motion guides, I knew I would eventually need more features, and also wanted to produce something that was free for all.
So I started playing around and this is the result of my first experiment. It’s only a few hours work (can you tell?!) but I think it’s going in the right direction. Drag the nodes around, press SPACE to toggle the sprite preview.
All about Photon Storm and our
HTML5 game development services
Filter our Content
- Cool Links
- Flash Game Dev Tips
- Game Development
- Geek Shopping
- In the Media
- Phaser 3