rich

The Phaser 3 Wishlist Thread :)

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!!! :D

 

 

 

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)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.