Jump to content

The Phaser 3 Wishlist Thread :)


rich
 Share

Recommended Posts

I would love to see some tools made exclusively for Phaser for polygon-mapping. I know the examples points you to PhysicsEditor, but you need a license, and it's honestly not that complicated a tool. I'm sure someone could do it in a couple of weeks, otherwise I might. It could be written in HTML5 JavaScript even.

 

To take it a step (long step) further, an entire editor made for Phaser would be awesome, since it was hell for me to pick an editor. Just like Unity has a terrain-editor, code-editor and much more in the very same tool, making this for phaser would be awesome. A simple HTML & JavaScript editor with inclusion of Phaser and a selection to choose your version/update the version for your project, with a tab for a physics-editor and one for tilemap-editor etc. etc. would be slick and help people get started faster and not rely on 5 different tools.

Link to comment
Share on other sites

I second the implementation of TweenMax into Phaser. Also native components but as a plugin of sorts and not in the core. I think overloading the Phaser core would result in more problems than solutions...

 

Also for 3D a Phaser3D standalone framework, its a whole new world there...

Link to comment
Share on other sites

Ok I will go half way with you guys Phaser2D and Phaser3D. :)

 

Actually I would be happy with 2.5D.

Can someone explain to me what the heck this actually means?

Can't you already achieve this via scaling?

Maybe we should build in a depth-based scaling and parallax thing? Would that work? (it sounds like it could be neat to me but idk if it would be feasible performance-wise)

(Also if you want a 3d game framework, there's probably as Three.js one somewhere.)

Link to comment
Share on other sites

I can't merge TweenMax with Phaser because you need a license to release a commercial game with it, and there's no point merging TweenLite because it does nothing that Tween.js doesn't, but still has its own baggage we don't need (raf implementation, css properties, etc). However it would be nice to make it easier to integrate (and ideally not clash with the internal game timers), then the license issue is up to you to resolve.

 

As for 3D, I'm not so sure. There are lots of frameworks out there that cover 3D SO well. Turbulenz, Goo, Unity. I'm not sure we really need another one - although granted they could all have nicer APIs ;) Maybe something that integrated three.js could be fun though, I'm thinking using 3D as a backdrop to a 2D game, rather than an actual 3D game. Still, a lot of effort though and done pretty well already.

Link to comment
Share on other sites

This one isn't super essential, but it's all the little bits of polish that have gone into Phaser that make it so great ;) So I will go ahead with this one:

 

I'm not sure how easy this is, or if it is even possible, but I'd love to have the audio decoding process built into the loading process. When loading a lot of audio that you definitely want to be ready, it is nice to show a truly accurate load bar or percentage. At the moment, we can constantly check audio files with this.cache.isSoundDecoded( 'audioKey' ), but that doesn't affect the load bar.

Link to comment
Share on other sites

The biggest problem with that is that it's impossible to tell how long a file will take to decode :( I could include the decoding step as part of the overall percentage though, maybe 1% (or 1 chunk, whatever is smaller). But yes having it decode during load is sensible for sure.

Link to comment
Share on other sites

I'm not a massive fan of ec systems in dynamic languages. I've yet to see a really clean way to access those properties from deep within game code. Are there any examples you can think of that don't have masses of 'sprite.getComponent()' tacked all over them?

Link to comment
Share on other sites

I know it wouldn't be easy, but this is a wish list :)

I do think it should seriously be considered though, especially if Rich is already talking about making a push towards more encapsulation.

I always feel slightly icky when debugging my phaser code and I have to wade through dozens of sprite and physics properties on every game object to get to the ones I added.

Link to comment
Share on other sites

I don't mean necessarily a proper ec system, just a more encapsulated entity system. Look at the way unity does it for example. Game objects are really simple, just a position basically, then you add a sprite.as a property, and a physics body as another, etc etc.

Its mainly an encapsulation issue, single responsibility principle and all that.

Link to comment
Share on other sites

An easy, built in way to handle different asset resolutions for different devices would be amazing.

 

WebAudio API goodness such as room ambience (reverb), delay and panning would be nice.

 

I think it's on the roadmap, but some way of bringing in Flash animations for cut scenes would be cool.

 

Phaser3D would be fantastic, especially in the new modular set up so we could reuse a lot of things across 2d and 3d games, but understand it would be a massive undertaking!

 

I quite like entity component because, for me, it makes some things really easy such as multiplayer games and code reuse across games. However, I think conceptually it's not as easy to grasp as the current set up and I like that Phaser is so accessible. 

Link to comment
Share on other sites

Hello to all !! [*** My first post ****]

 

Iam a newbie using the framework. Right now making my first game using Phaser :D  and the first stuff i didnt liked in 2.0.x is the way to configure an object with properties. Let say i want to configure a sprite like this:
 

var mySprite = game.make.sprite(150, 450, 'analog');mySprite.width = 13;mySprite.rotation = 220;mySprite.alpha = 0;mySprite.anchor.setTo(0.5, 0); game.physics.p2.enable(Mysprite , true);

In my opinion the code just get hard to read and a little hard to manage, for Phaser 3 maybe will be nice to have :
 

var Mysprite = game.make.sprite( 'analog', {
  position: {x:150, y:450},
  width: 13,
  rotation: 220,
  alpha: 0,
  anchor: {x:0.5, y:0},
  physics: {type:'p2', enable:true, debug:true}
});

 

So we can create the sprite and config it in the same call. And maybe add other Method to update the values of an object:
 

game.config.sprite( Mysprite , {  height:255,  rotation:0,  alpha:1,  body: {    bounce:{x:0.2, y:0},    drag: {x:20, y:20},    maxVelocity:2400  } });

This also will have a positive impact in the Game .js file size.

 

Infact, i think it will be good to allow Phaser 3 to have this "extra methods", and let the old way for those that are used to.   :ph34r:

 

Is just a newbie suggestion... i didn't have time to learn all the Framework yet so maybe is a bad idea...

Link to comment
Share on other sites

Unity can get away with using an ec system because it's a compiled language. Unless you have a common accessor to a component (such as my hated 'getComponent' approach) you end up modifying the class shape internally, which invalidates it for any kind of V8 level optimisation or hot pathing, which is a really bad thing imho. I want to move more towards ensuring the code is static enough that it doesn't morph class type and the compiler can then optimise for that. Right now that isn't the case, even at the Pixi level, so there is a lot of work to be done.

 

I also feel that you sacrifice speed of coding / usability, so like I said if anyone can post up some code examples that would map well to JS of accessing deep components, I would love to see them (there are so many frameworks out there, one of them must have found an elegant solution!)

 

--

 

Ginawa - yes there's quite a bit of talk about using magic objects for configs already, and it's something we will look at supporting in some capacity. It will make the Phaser codebase ever so marginally smaller, but it will have the knock-on effect of making your game code longer in a number of places (where parameters are used in constructors) and less accurate to debug (in terms of line numbers coming out of the debugger). These are probably quite minor things though, so we'll see how it goes. There's also of course the performance trade off of creating new magic objects* in hot areas, but I think mostly this is for set-up and configuration use anyway, not in the actual game loop.

 

* just to clarify, I consider an object as being "magical" when it contains English language properties that you have absolutely no idea what they are without first checking out example source or the documentation and cannot get any code-insight on from editors like JetBrains or VS.

Link to comment
Share on other sites

I'd definitely want to keep midi support separate from Phaser's main codebase because there's a lot of complexity in doing this right. Browser midi support is woeful, as is the rendition on different sound cards - but using something like jasmid (only not so out of date) alongside your game could be cool.

 

I think playing modules is a far better option as they sound the same on all devices, are much more flexibile and can sound better than any midi file. In fact there's already a plugin for ProTracker modules: https://github.com/photonstorm/phaser-plugins/tree/master/ProTracker

 

There's also this for more advanced module formats: https://github.com/photonstorm/FlodJS

Link to comment
Share on other sites

  • rich unpinned this topic
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...