Latest Posts

• By Rich

  Tags

  CreativeJS, demos, Games

  Posted in

  Cool Links

  2 comments

  Getting Creative with JavaScript

  26th Jul 2012

  2

  

  Since March 2012 I’ve been a regular contributor to the CreativeJS site. The site aims to showcase stand-out creative uses of web  technology as well as offering a growing collection of tutorials. As you may expect I tend to drop mostly gaming and demoscene related articles 🙂 Here’s the list so far:

  Get bitten by the Lunch Bug
  Visual 6502 and the Microchip Archaeologists
  JsExe – JavaScript Compressor
  Grand Theft Auto WebGL
  Score Rush
  Wizard of Wor
  Radiotheraphy Demo by Alcatraz and Scoopex
  Lux Ahoy
  VIP 2 Demo by Popsy Team converted to WebGL
  Trigger Rally – online Edition

  If you only check one, please check the top article – Lunch Bug, a brief review of the great new game by Lost Decade Games.

• By Rich

  Tags

  components, framework, game mechanics

  Posted in

  HTML5

  30 comments

  How we approached the design of our HTML5 game framework

  20th Jul 2012

  30

  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

• 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

  framework, Instinct

  Posted in

  HTML5

  33 comments

  Building an HTML5 game framework at the bottom of the world

  6th Jul 2012

  33

  

  It’s been a while since my last post, but I’ve certainly not been idle. In fact you could say it has been one of the most exciting periods of time in Photon Storms‘ history so far. As mentioned previously I hung-up my Technical Director gloves and bid farewell to the wonderful team at Aardman. After a single day of holiday I hopped onto a 737 at London Heathrow, shot off into the air and 30 hours later landed in beautiful Wellington, New Zealand – quite literally the other side of the world.

  My reason for being here is because the cool guys at Instinct Entertainment shared my same passion when it came to game development. They understood my desire to create a kick-ass and fully open source HTML5 game framework, and that is exactly what I’m here doing. These first few weeks are crucial to ensuring that our vision and plans make sense and that myself and the rest of the team draw-up a realistic  roadmap that will see this project to the end of 2012 and beyond.

  Why on earth do we need another HTML5 game framework?!

  Damn good question 😉 It does feel like you can’t go for a month at the moment without another new framework being announced. But there are several key reasons why we elected to start from scratch rather than adopt something already out there:

  • Very few of the existing frameworks actually care about the mobile browser, or optimise themselves for it. A lot of them just blast the entire contents to a single canvas and are done with it. For us the mobile web is the whole reason for existing in the first place and we’ll always optimise as best we can for it.
  • Virtually none of the frameworks have any kind of community behind them. This is of paramount importance to me. Having helped build and nurture game development communities for over a decade I firmly believe that they are the true life blood of any successful framework. A place to talk, share code, get support and feel included in what is going on.
  • The community will drive the features that end-up in the framework. We intend to be fully transparent about our development process, allowing you to feed into it and help us prioritise features.
  • We wanted a powerful architecture, flexible enough for both old-skool retro style games, and much more modern ones too. Yes we’ll have tilemap support, but you won’t be limited to just using that for creating game levels. Yes we’ll have sprite sheets, but we’ll support alternative animation formats as well. We’ll have arcade level physics built in, but we’ll allow for Box2D if you want it. We’ve been very careful to ensure you’re not forced into doing things just our way, but can bend the rules or extend them as you need.
  • Having spent many years working with Flixel I really appreciated what that did for developers, the way it helped them skip past the dry and dull set-up and just dive right in to making the game. I promise you’ll have the exact same level of ‘pick-up and play’ from this, and we’re working hard to keep function names and objects sensible and documented.
  • Game Objects – these are not part of the core package, but you’ll be seeing lots of them! An example of a Game Object may be a ‘grenade’ object. Drop the file in, add in a line of code to create the object and it’ll appear in your game – bouncing, ticking and exploding as you’d expect a grenade to do. There will be a good range of game objects at launch ready for direct use in your games, or just for you to open, edit and tweak as needed.
  • Online Tools to support your game making. We’re going to be providing comprehensive online level editor tools, animation tools, path tools and more. You won’t have to use them if you don’t want to, but they’ll be there if you need.
  • Careful integration with 3rd party APIs. From realtime multiplayer APIs to direct phone billing and all the social ones you can think of in between. Games these days rarely exist in isolation any more, there are a wealth of additional services out there you can benefit from, and we’ll provide the hooks to do so.

  Most importantly of all though – probably the largest reason why this is being built is because it has been my dream and desire to do so for many, many years. Back on the Atari ST I released piles of source code for others to use in their games, on the PC I released hundreds of DarkBASIC code snippets and ultimately spent years working there helping the community, with Flash as lots of you know I spent months releasing tutorials and Flixel libraries.

  This framework is really the culmination of all of this – the net result of decades of fascination and love for opening up game development to all abilities.

  So when is it out?

  Patience grasshopper 🙂 This week has been all about planning and careful structure (along with a few cool demos to check our effects pipeline will work!). We will be releasing our roadmap next week, with the first public release of the code shortly after. The plan is to develop on a live public github repo, so you can follow along and contribute from the start. Rest assured we’re in this for the long haul and are fully financed for the rest of this year, with the potential for that to carry on definitely. It’s exciting times indeed and I can’t wait to share what we’ve got in store for you. The strangest thing of all right now though is that we don’t yet have a name for it! It was going to be called Kiwi.js but that’s a popular node plugin. So back to the drawing board.

• By Rich

  Tags

  Aardman, freelance, future, job

  Posted in

  HTML5

  29 comments

  No more cheese Gromit: The future of Photon Storm

  16th May 2012

  29

  

  So the cat was let out of the bag today and it’s true: I’m leaving my very good friends at Aardman Digital and heading for pastures new. Giving up the “day job” and becoming a freelancer / indie dev hybrid. As you can appreciate this is both an exciting and somewhat scary move, especially being the sole income earner for my young family. But I’ve been careful with my planning and sensible with my predictions and  will make the best of it that I possibly can.

  Fancy working with Wallace and Gromit?

  This of course means that Aardman are now looking for a kick-ass Technical Director to join their digital department. If you’re in the UK and either live near or would re-locate to Bristol and have the experience, then I strongly suggest you apply for this job. You’ll get to work with some fantastic brands and characters, including both Aardman’s own such as Wallace and Gromit, and 3rd party. There’s a truly brilliant and talented team there, working on fun stuff in a gorgeous office (complete with its own canteen and cinema). If this sounds appealing and you’ve got the skills then please do consider sending in your CV.

  So you’re probably thinking why on earth would I give this up? There’s no one significant reason. It’s more a collection of smaller things which ultimately boils down to wanting a change in lifestyle that allows me to create the sort of games I enjoy and spend more time with my family in the process. I’ve been at Aardman for 6.5 years, indeed I was the very first employee in the department. And I’ve seen it grow and expand, taken on huge challenging projects and then morphed into a director role. Those of you in this position know it’s more about technical guidance than actually building stuff. And while you do have a large amount of creative input into a project, it’s always working with someone elses characters or brand. You can never really push it quite as far as you’d like 🙂 (and for sensible business reasons too).

  But it’s not just about the creativity. In March my daughter had her second birthday, and this was really something of a wake-up call for me. I live quite a long way from the Aardman offices and the daily commute often means I’ll see a maximum of 5 minutes of my children, during a frantic pre-school rush in the mornings, each day. Often they’re both sound asleep by the time I get home. Even though Aardman were great in letting me work from home one day a week, I was still effectively missing my children growing up. And they’re only going to do that once! I know a lot of Dads are in a similar situation, and I’m under no illusion that my new role will be any less busy (if anything, it’ll be more so!). But at least the way in which I work will be under my control, and if I want to go and collect my son from school, I can do that now. That, to me anyway, is worth giving-up my generous monthly salary for.

  The Future Sound of Photons

  So what will happen from this point on? It’s actually pretty damned exciting. Photon Storm was incorporated as a company on April 18th, preparing for what’s coming. I’ll work out my notice until the end of June and then our new life begins, but with a really awesome project to kick things off. A great company based in New Zealand have hired me to build a fully open-source HTML5 game engine. We’ll be taking all the virtues of frameworks like Flixel, applying what we’ve learned from our HTML5 game development and mixing it all together. Our primary aims will be ease of use, solid documentation, examples and tutorials and a strong plugin driven architecture: A minimal core supported by a huge array of components to extend or replace the engine however you want. Everything that was ever planned and dreamed of for the aborted Reflex project will come to fruition here.

  I’ll be working on this solidly for 6 months (and beyond). The nice thing about it, aside from the fact it’s a freaking cool project!, is that we’ve agreed I’ll have free time every week to work on our own games as well. This means you will start to see a rapidly elevated output from us as we set about finishing games currently sat collecting dust, and building out new ideas and concepts we’ve been itching to try but have avoided due to lack of time.

  It also means that we’re open for contract work too. I’ve got to be practical about this change. The 6-month starter project is great, but I’m not naive enough to think that after this if I swap to being a full-time indie that it’ll continue to feed my family. Instead I’ll settle for trying to balance freelance/contract work with my indie dreams. This should ensure that we can carry on making great stuff and still pay the bills.

  Maybe one day the indie side of it might be large enough, but I’m sure you can appreciate I need to play it safely for now. So if you’ve ever wanted us to create a game for you (HTML5 or Flash), or need help porting a Flash game to mobile browser, now would be a great time to drop me a line 🙂

  *sniff* You’ve been beautiful guys

  I also just want to say a quick thank you to everyone who has supported what we’ve been doing here over the years. Thousands of you have expressed your gratitude for our hard work, be it by enjoying our games or benefiting from our tutorials and code. We really do appreciate it when people drop us a line to say thank you, and I still get a genuinely warm and fuzzy feeling inside when we see or hear about our code helping fellow developers get their games made. We do try our best to answer all emails we get sent, no matter how trivial they may seem, and apologise to all the people who keep writing to us asking for intern-ships 🙂

  There are a lot of great people out there that we’ve met, both online and off. People who continue to influence and inspire us on a daily basis. Your feedback and support has meant a lot. And as we enter this new and very exciting phase of “Photon Storm” we hope you’ll stay along for the ride.