HTML5 Category

  • 3 new HTML5 games released for the Agilent Technologies Summer of Fun campaign

    We were very happy to work with Tminus1 Creative on a set of 3 games for Agilent Technologies Summer of Fun campaign. We produced mobile, tablet and Flash versions of each game to cover the widest range of devices possible. The games by their very design were just meant to be small slices of fun before the player entered a prize draw. There’s no real way to “fail” at any of the games, you just keep going until you’ve won them 🙂

    You can check out each of them in our games portfolio, they are: Slide ‘n Glide, Water Blaster and Photo Hunt.

  • Two of our HTML5 games for the NFL Rush Zone site are out

    We’re pleased to announce that 2 of the games we built for the new NFL Rush Zone site are out. The site was designed and built by Brandissimo! and has been a key destination for American football loving kids since 2007. But due to increasing mobile traffic they built a mobile browser experience to coincide with the desktop one.

    Part of this revamp included porting some of their much loved Flash games over to HTML5. We were pleased to have been asked to handle the ports of the games Galactic Rusherz and Jump Duck. As with all our games they were built for both mobile and tablet scale, and offer small slices of quick action fun.

    Play them both at http://nflrz.nflrush.com/games – make sure you use a mobile browser or it’ll redirect you to the desktop site.

  • Our HTML5 game for McCoy’s Crisps is out

    We’re very pleased to announce that today saw the start of the McCoy’s “Darts Pro’s at your pub” campaign. McCoy’s are a very popular brand of crisp (potato chip) in the UK. This on-pack campaign allows players to challenge a virtual darts professional to a single or triple throw contest. Winners get entered into the draw to win Xbox 360s and other prizes.

    The web side of the campaign was run by local agency Activation Digital who contracted us to build the game. Over 50 million packets of crisps have been printed with the QR code and URL on them, so if you fancy a bag of cheese and onion be sure to look out for it 🙂

    Read more about our build process and play the game here.

  • Solving black screens and corrupted graphics in HTML5 games on the Samsung S3

    This is pretty much how I felt over the past few days debugging this

    One thing we always try to do as HTML5 game developers is maximise performance. This isn’t an easy task as pretty much every handset is fighting against you when it comes to draw speeds and available RAM in the browser. So when I ordered a Samsung Galaxy S III – quite literally the pinnacle of the Samsung device range at the moment, I wasn’t expecting its beast-like technical specifications to give me any problems at all. Oh how wrong I was.

    For some reason several of our games were either turning entirely black or parts of them were not displaying at all. They didn’t crash, there was no error log entry to look at, they just didn’t actually display. The game was still running however, sounds could be heard and touch events were still received – so if you knew where to touch you could still play it, it just wasn’t rendering anything. What followed was a full day and sleepless night spent debugging to find the solution. It was such a task I had to share it here to help fellow devs!

    Read More

  • How we approached the design of our HTML5 game framework

    First of all I just wanted to say that the framework we’re working on (which we’ve nick-named Kiwi.js) isn’t just a Photon Storm project. I’m jointly coding it with the super-talented Ross Kettle, and you should definitely check out his blog for some exciting WebGL and Stage3D experiments, including a rather neat Furious Furball demo. We’ve also got the Instinct Entertainment team behind us, providing service and plugin development and community management – and of course once we release it, hopefully you can join in too!

    But I just wanted to talk a little about how we’ve approached the design of the framework.

    There’s no place like home

    I suspect a lot of frameworks are born out of a collection of ‘commonly used’ classes that the developer has in his toolbox. When you start to repeat the way you do things several times over, you naturally start forming common templates and processes that will speed this up for you. There’s nothing wrong with this approach, but it does mean that end-users who come to your framework often have to force themselves to work the same way as you do. And if there’s one thing we’ve identified – it’s that everyone codes differently! 🙂 This is especially true in JavaScript. To some the lack of OOP is a real issue, and they reintroduce it back into JS via external libs. Others really like using jQuery style method chaining and some even wrap their entire game up in one single massive function.

    The important thing is that they’re all different, and it was essential to us that we let you code your game in the way you want. So we’re not enforcing specific methods of coding on you when it comes to actually building your game. Internally within the framework we’re doing things in a very set way, and if you wish to get deep and dirty with plugins then you’ll need to follow our lead. But on the outside we’re making it as flexible as possible, so that you can approach the structure in a way you’re familiar with.

    Our design is driven by analysing games

    This may seem blindingly obvious, but in studying a huge number of frameworks over the years it strikes me that this doesn’t actually happen much! We’re building a game framework, so we want to be sure that the features it has are useful for games.

    In order to do this we sat down and went through a huge collection of games – from early Atari video games to modern iOS and console hits, and all kinds in-between. Sports games, RPG, action games, physics games, dungeon brawlers, racing and even Text Adventures. We picked 100 games initially, stripped away the story and drilled down specifically into the game mechanics and what would be required in order to successfully re-create it using our framework. This is a process we continue to do. By dissecting as many games as possible we’re finding lots of common mechanics that are helping prioritise our development roadmap.

    Here are some examples:

    Space Invaders

    You’ve a big group of aliens moving in sync, randomly firing at you. As the invaders fire at you (and you at them) there is pixel-level destruction of the bases. From this simple game it was clear we wanted our Group object to be flexible enough that we could apply a transform component to it, updating invaders at once. Our collision system should be able to support group to group collision and we’d need the ability to dynamically modify the base sprite image at run-time.

    Galaxians

    Very similar to Space Invaders, we’d take the same group abilities and then add Path support, so the galaxians can follow smooth paths curving down towards the player and shooting at him, rotating slightly as they go. This game would also require a bullet pool and bullet management system.

    Read More