The Phaser 3 Wishlist Thread :)

[mz103]

2d lighting similar to this: http://greweb.me/2012/05/illuminated-js-2d-lights-and-shadows-rendering-engine-for-html5-applications/

[mz103]

I wouldn't aim for ES6 until it stably lands in all the Major browsers.

If possible, I would like Phaser 3 to contain a massive api re-thinking to using objects for both options when creating / configuring things, events, any maybe other non-super-performance-critical things.

 

Think constructors:

 

// oldnew Phaser.Game(800, 600, Phaser.AUTO, 'canvas', null, false, true)// proposednew Phaser.Game({    width     : 800   , height    : 600  , renderer  : Phaser.AUTO  , domID     : 'canvas'  , antialias : true})// for those  of you who prefer more traditional js stylingnew Phaser.Game({  width: 800,  height: 600,  renderer: Phaser.AUTO,   domID: 'canvas',  antialias: true})

This would help to keep code verbose and readable, while only making people pass the options that they need.

 

 

Think events: 

 

// taken from the loader events example// none of us actually remember this param orderfunction fileComplete(progress, cacheKey, success, totalLoaded, totalFiles) {  text.setText("File Complete: " + progress + "% - " + totalLoaded + " out of " + totalFiles)  var newImage = game.add.image(x, y, cacheKey)  // stuff}// more in line with native js eventsfunction fileComplete(event) {  text.setText("File Complete: " + event.progress + "% - " + event.totalLoaded + " out of " + event.totalFiles)  var newImage = game.add.image(x, y, event.cacheKey)  // stuff}

In addition, HDPI support would be very nice, though I think that belongs in PIXI.

Text renders awfully in canvas on my Retina display. :/

 

 

I'm coming into Phaser, looking at the docs thinking... why doesn't it work like this? This would lower the entry level required for learning Phaser, and make it much easier to understand. The practice of using object literals as arguments has become standard in most JavaScript frameworks / libraries. As for the changing of how events are used, I can't agree more.

 

These changes would be relatively easy to implement, and would really benefit the developer experience. All you would be doing is changing the constructors / functions.

[rich]

Using objects instead of defined parameters is a trait common to web site development, not game development, and that is where it can remain.

[mz103]

Using objects instead of defined parameters is a trait common to web site development, not game development, and that is where it can remain.

 

I completely understand, but who's to say both traditional game developers and web developers can't benefit simultaneously?

 

In other words: why not support both? It's completely logical to support both; developers who are accustomed to different things will be happy with their choice of Phaser.

 

Using objects instead of defined parameters is a trait common to web site development, not game development, and that is where it can remain.

 

We're breeding the two categories together by making games on the web.

 

An analogy:

• Computer information was traditionally represented as text in a command-line-interface.
• However, the command-line-interface didn't stop us from upgrading to bitmap.
• Today, we still support command-line-interfaces within the bitmap screen.

It's the best of both worlds. Everybody wins.

[rich]

Actually, everyone loses.

 

Configuration objects are terrible in hot places. Although yes, everyone should create their objects up front and pool them, that isn't always possible - and then you'd significantly pay for it. Allocation is cheap, and sometimes can be elided entirely, but you should never rely on that in performance critical code.

 

More importantly though: If you sometimes do X.foo({ x: 10, y: 20 }) and then sometimes do X.foo({ y: 20, visible: false }) then all the code that interprets these configuration objects will go polymorphic, and you will pay for this with performance. Each of the configuration objects will have a well defined shape, set-up by Phaser, but if (as a developer) you take advantage of excluding some of the properties just once then it's detrimental for optimisations, because you really want it to be as monomorphic as possible. And if you're going to have to always use the exact same object shape every time anyway, then you may as well save yourself some typing and learn the parameters.

[mz103]

Actually, everyone loses.

 

Configuration objects are terrible in hot places. Although yes, everyone should create their objects up front and pool them, that isn't always possible - and then you'd significantly pay for it. Allocation is cheap, and sometimes can be elided entirely, but you should never rely on that in performance critical code.

 

More importantly though: If you sometimes do X.foo({ x: 10, y: 20 }) and then sometimes do X.foo({ y: 20, visible: false }) then all the code that interprets these configuration objects will go polymorphic, and you will pay for this with performance. Each of the configuration objects will have a well defined shape, set-up by Phaser, but if (as a developer) you take advantage of excluding some of the properties just once then it's detrimental for optimisations, because you really want it to be as monomorphic as possible. And if you're going to have to always use the exact same object shape every time anyway, then you may as well save yourself some typing and learn the parameters.

 

We were just talking about creating a new instance of the Phaser.Game object, not converting the entire framework to use objects as parameters extensively.

 

But if you still disagree with that, then what are your thoughts on making Phaser events more similar to native JavaScript events?

[rich]

Nope, I was talking about using config objects through-out the framework, because you can already use an object to define the game constructor properties. Phaser has supported that for quite a long time:

var game = new Phaser.Game( { width: 800, height: 600, renderer: Phaser.AUTO } );

There are other properties too (transparent, antialias, parent, preserveDrawingBuffer, etc.)

[swissnetizen]

I was thinking about the entity component model, and I think we could solve the

e.addComponent

hassle by removing it all together and doing something like crafty does.

new Phaser.entity(game, x, y, [component array(or have one string which is parsed)])

[MikauSchekzen]

Erm, I'm not sure if this has been requested yet, but I would love support for Image Collections for Tiled maps.

 

In fact, is there a list that says what's been approved/being considered?

[Cedric]

A way to make a health/damage system.

Like you could in the previous version ( entity.damege(bullet_damage) )

[jdnichollsc]

Add horizontal scroller efect to bitmapdata and sprites? For example: http://codepen.io/jdnichollsc/pen/Xbqrzd

My plugin for the camera: http://jdnichollsc.github.io/Phaser-Kinetic-Scrolling-Plugin/

 

Regards, Nicholls   

[InsOp]

id like phaser to easily zoom in and out the world

[yahiko]

Without a doubt, Phaser should support SVG natively.

[codevinsky]

Here's a request:

 

Let's say we've got and endless runner game with three states:

• Menu
• Play
• Game Over

In menu, we have a scene that has a parallaxing background with floating buttons. When we click the "Play" button, we move to the play state... but without wiping the scene of current game objects. The player character enters from the left, running at a constant speed with the background is still parallaxing properly. On player death, we switch to the gameover state, the background stops parallaxing, and a "stats" display flies in with a "try again" button. When this button is pressed, the background seems to "rewind" all the back to the beginning, and we switch back over to the "play" state.

 

The Request:

Be able to switch states without having to wipe all of the game objects that are still on screen and retain references to those objects.

[Tilde]

Officially-sanctioned OBB for Arcade without having to use P2 is a huge one for me.

[hollowdoor]

Would it be too crazy to ask for something like this http://syzygy.st/javascript-coroutines/ as a type of game loop as an option to the normal one.

[hayesmaker]

A camera which can zoom please

[rich]

A camera which can zoom please

 

Already done.

[Bengalaa]

it would be awesome to have body physics enabled to the camera...

 

So we would be able to rotate, put acceleration, velocity, and even tweens to it!!!

 

 

 

also... camera zoom is confusing the arcade physics as shown here: http://www.html5gamedevs.com/topic/12097-world-scale-messing-arcade-collisions-up/ it'd be awesome to have a more stable camera zoom @.@


(lol, i am feeling like a child writing a letter to Santa Claus XD)

[J4G]

I'm kinda at a loss with this one.

 

I had a game with a procedurally generated 100x100 tilemap (but rendered as individual sprites), sometimes with 2 or 3 sprites per location. It's a shooter so I needed more complex physics interactions than Arcade's rectangle-on-rectangle collisions, so there were lots of P2 bodies. I spent weeks trying to optimize it and I eventually had to give up - I just couldn't get it to perform. I tried the same demo in Unity and it ran flawlessly.

 

I know JS can't be expected to have Unity's performance, but v8 is more than 20fps fast. I have no special love for Unity - I'd love to code everything in Phaser, but I dunno what new approaches I can try or where Phaser is lacking.

 

Thanks for all of your work - I'd love to see Phaser 3 at a point where I can attempt ambitious projects like this.

[rich]

When you tried it in Unity, was it as a native app, or do you mean the WebGL export?

[J4G]

Both. I did a lot of performance testing and most of the issue was with P2, but I had to do a *lot* of render optimization to get the draw times down - and even then they were around 8 ms.

[rich]

I don't expect JS (in any framework) will ever beat Unity in terms of speed when compiled to a native app.

 

Under WebGL they still have a massive advantage, being compiled down to bytecode effectively, which no 'pure' JS engine could ever compete with. There are so many optimisations they can make at compile time which we can never have. Plus of course they're a multi-million dollar company employing hundreds of talented staff. They can afford the research time into rendering and physics improvements The downside is their runtimes are massive and being WebGL only it will never fall back to canvas, and you'll always need to compile first. Swings and roundabouts really.

[J4G]

Do you think that P2 is the best library for Phaser integration? http://brm.io/matter-js/ and http://wellcaffeinated.net/PhysicsJS/ seem to get more attention. It's also really hard to manage collision groups - the whole flow of that feels pretty unnatural for anything remotely complex.

[Firenibbler]

I hear the "objects as parameters" request quite often. The issue I have with it is that I don't see any real difference between having to remember magic object properties as to having to remember parameters. You need to know what they are either way, and if you don't know (or don't have them in code in front of you), you need to check the docs regardless.

 

There are definitely cases where there are too many parameters though.

 

And ES6 is getting closer and closer, so many features are already usable today in stable Chrome, by early 2015 there will be many many more!

I think the point of changing parameters to objects, is not necessarily the ease of use, but how most JavaScript developers think. The proposed method is more in the comfort zone fore most JavaScript developers witch will make development easier, and reduce initial learning curve.