Posts Tagged ‘framework’
-
Phaser 1.1 is released! New API docs, 150+ examples and hundreds of updates
25th Oct 20131
We’re really pleased to announce that Phaser version 1.1 was just released and pushed to the master branch of our github repo. We’ve worked extremely hard on this release to make Phaser the most stable and powerful 2D HTML5 game framework we can.
Here are some of the headline new features:
API Docs are live!
We know these were a long time coming, but we’ve finally documented nearly every part of the framework with jsdoc3 and published the resulting docs as well. So you can at least now look at the docs first before having to dig through the source code to figure things out. We’ve still got more work to do in this area, but it’s a great start.
150+ Examples!
We’ve got a brand new Example Test Suite, with a great design, two display modes (full stack or side-by-side) and over 150 different examples for you to work through. We’ve tried to cover all of the core features of Phaser, there are even little mini games included (some in more complete states than others) and lots of demos.
What’s more, we’re looking for new Examples to add to our collection and we’ve got prizes for the best submission each month 🙂
Enhanced Arcade Physics
The Arcade Physics system that ships with Phaser has been almost completely rewritten. It’s now considerably more robust than before, the Sprite update loop has been heavily optimised and refined, and collision is now a lot more stable. Gone are the ‘jitters’ and potential wall-sticking of the previous release!
-
Phaser 1.0 and the journey we took to get there
16th Sep 2013
After months of hard work everything came to a head on Friday September 13th when we released version 1.0 of Phaser, our HTML5 game framework. This was a monumental milestone release for us, and the fact that it has taken us 3 days to even write about it on our own site should give you some indication of the whirlwind that ensued following launch.
We punched the shiny ‘release’ button quite late on Friday, which not only pushed 1.0 to our github master branch but also unveiled the lovely new Phaser web site as well. Although just a single page site for now the design reflects everything that I want a game framework to be: fun, fast and easy to use. I wanted people to look at the site and instantly feel like it was approachable: not too ‘serious’ or dour, but by no means amateur either. The site certainly had the desired effect, as sure enough the tweets spread like wildfire and the site is getting thousands of visitors a day. As a result we’re seeing great levels of activity on our github repo and the Phaser section of the HTML5 Game Devs forum has exploded, with fresh new sign-ups and questions coming every hour.
-
Announcing Phaser (Flixel HTML5) and our Adobe Max session
12th Apr 2013
We’ve two exciting bits of news to share today. First we have just released Phaser. Phaser is a light-weight 2D HTML5 game framework based heavily on Flixel. Indeed it started life called Flixel5 but was renamed to avoid any potential confusion 🙂 The current feature list is pretty comprehensive:
- Asset Loading
Easy loading for Images, Sprite Sheets, Texture Packer Data, JSON, Text Files and Audio Files. - Cameras
Multiple world cameras that can scale, rotate, flash, shake, alpha and track sprites around the game world. - Sprites
All sprites have physics properties including velocity, acceleration, bounce and drag and collision built-in. - Groups
Group sprites together for collision checks, visibility toggling and easy function iteration. - Animation
Sprites can be animated by a sprite sheet or Texture Atlas (JSON Array format supported). Animation playback controls, looping, fps based timer and custom frames. - Collision
A QuadTree based Sprite to Sprite, Sprite to Group or Group to Group collision system within world space. - Particles
An easy to use Emitter can emit sprites in a burst or at a constant rate, setting physics properties on them as it does so. - Input
Keyboard, Mouse and Touch support (advanced gestures coming soon) - Stage
Easily change properties about your game via the stage, such as background color, position and size. - World
The game world can be any size and collision and motion is tracked across the whole world. - Sound (partial support)
Currently uses WebAudio for playback. More work needs to be done in this area. - State Management
For larger games it’s useful to break your game down into States, i.e. MainMenu, Level1, GameOver. The state manager makes swapping states easy, but the use of a state is completely optional. - Cache
All loaded resources are stored in an easy to access cache, which can be cleared between State changes or persist through-out the whole game. - Tilemaps
Support for CSV and Tiled JSON format tile maps is implemented. - Random Number Generator
A seed based random number generator allows for reproducible in-game effects. - Game Scaling
Games can scale to fit any device and will scroll the URL/status bar away on Android and iOS mobile.
- Asset Loading
-
How we approached the design of our HTML5 game framework
20th Jul 2012
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.
-
Building an HTML5 game framework at the bottom of the world
6th Jul 2012
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.
Hire Us
All about Photon Storm and our
HTML5 game development services
Recent Posts
OurGames
Filter our Content
- ActionScript3
- Art
- Cool Links
- Demoscene
- Flash Game Dev Tips
- Game Development
- Gaming
- Geek Shopping
- HTML5
- In the Media
- Phaser
- Phaser 3
- Projects
Brain Food
