

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. So we’re not enforcing specific methods of coding on you when it comes to actually building your game.
#RUSH TEAM WEB GL CODE#
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.

Others really like using jQuery style method chaining and some even wrap their entire game up in one single massive function. To some the lack of OOP is a real issue, and they reintroduce it back into JS via external libs. And if there’s one thing we’ve identified – it’s that everyone codes differently! This is especially true in JavaScript. 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. 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. I suspect a lot of frameworks are born out of a collection of ‘commonly used’ classes that the developer has in his toolbox.

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!īut I just wanted to talk a little about how we’ve approached the design of the framework. 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. 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.
