onedayitwillmake

Hey Everyone, Even though development on it finished over 2 months ago, it took a while to be released. I thought I would share a client project which I created while at Ogilvy & Mather for IBM just before the end of the year. It is a physics puzzle game called FlexFrenzy. The idea is to move the 'Flex' pieces into place such that the data can get from to the datacenter(s). Built using Phaser.js Physics powered by Chipmunk.js port (https://github.com/josephg/Chipmunk-js) Additional modifications added to support Magnets / Repellers / Portals Component based entity system 25 levels of increasingly difficulty If there is anything in the game anyone would like me to discuss in more detail, let me know! Link: http://www-03.ibm.com/systems/flex/flex-game/ Screenshots:

Get Webstorm from intellij, it's autocomplete is aware of your js objects - across the whole project

Are gesture events fired by the class? A simple way to do it, is to go into the instance on mouseUp, and then retrieve the array of points and use those to create a phaser graphics object.

A simple optimization would be to check the distsquared against min*min, and only then call sqrt on distSquared avoiding as many uneccesary calls as possible

There's a draw method that gets called on each state in which you can do some final drawing, what I'm doing is keeping an array of sprites which want to do extra drawing and calling a draw method on them each frame

I vote for using the same one pixi is using behind the scenes. Less confusion for users

In my current game I am using chipmunk.js to great success, and I was hoping to take my small wrapper / physics controller I've made on top of it and making it a plugin for phaser as a way of giving back. Is this the right usage of a plugin, and where can I find some info regarding plugin creation?

I propose having those systems as part of the statemachine itself, and letting states decide how or if they want to pause Tweens themselves when they are entered or exited. Too much over thinking here will lead to an inflexible engine, people making games know best how to handle what their game needs - forcing too strict a paradigm will make it so that as soon as you try to do something different, most of your time is spent fight with the engine. A lot of engines fall victim to this in the quest to be as easy to use as possible, so I hope the same fate does not happen to phaser

The way I am handling this for my current game is not, really how I'm sure phase is meant to be used however it is the only way to achieve this for now. I only use a single "real" phaser state, which acts as my StateMachine. The state machine allows a previous state to exist, and can pop back to it. Every state has an onEnter onUpdate, onExit and destroy method. onUpdate is only called on the currentState and destroy is called once a say a third state is pushed the first one will be destroyed and the second will become previousState This works quiet well, and I have experienced no issues with this paradigm existing on top of phaser.

If it's possible to iterate over the particles, you could take their current speed and multiply it by some damping value, such as 0.9 Is that what you mean? Sorry if I miss ubderstood

Very cool, i love this!

Interesting approach, are you talking about creating an ImageElement via 'new Image();' and storing it as a reference? Also thanks for the info about Cache.removeImage

Does phaser have a function to purge unused textures, or if not, how can I manually remove a texture from phaser - for example if I have some textures for the start screen of my game, and some textures for the gameplay section. The reason is that on mobile the game is running out of video memory, however it's only because I cannot purge the textures that I am no longer using.

Is there any reason why it's called destroy and not kill?

I'm using tweenlite on a current project without issue, in fact I found it to be slightly more performant (which makes sense since phaser is doing some things to handle Tweens if the game is paused etc that using Tweenlite doesn't do as it is does not know or care what context it is run from)