rich

The Phaser 3 Wishlist Thread :)

Recommended Posts

This is a completely free-for-all "suggest whatever the heck you like" thread for Phaser 3. You can suggest things to do with the API, to do with the web site, tutorials, tools, whatever you feel like.

Updated: 17th February 2017


Here I'm collecting together the feature requests from GitHub that were issues raised there, that I've closed off to keep things tidy.


Static Signals https://github.com/photonstorm/phaser/issues/645

Generic Pool Class https://github.com/photonstorm/phaser/issues/747

Allow animation frames to be specified as flips https://github.com/photonstorm/phaser/issues/762

Animation Frame pooling https://github.com/photonstorm/phaser/issues/823

Default anchor points https://github.com/photonstorm/phaser/issues/914

Create sprite by cropping from a big sprite sheet https://github.com/photonstorm/phaser/issues/1140

Support for rotated tilemaps https://github.com/photonstorm/phaser/issues/1149

addTileSetImage should support BitmapDatas https://github.com/photonstorm/phaser/issues/1200

Removed from World signal https://github.com/photonstorm/phaser/issues/1227

Gyro support https://github.com/photonstorm/phaser/issues/1229

Animation loop quantity https://github.com/photonstorm/phaser/issues/1329

Collection of Images Tiled feature support https://github.com/photonstorm/phaser/issues/1339

p2 reset feature https://github.com/photonstorm/phaser/issues/1362

Module support https://github.com/photonstorm/phaser/issues/1475

Minimal Phaser.Device https://github.com/photonstorm/phaser/issues/1186

Anchor on BitmapText https://github.com/photonstorm/phaser/issues/1499

Unit Tests https://github.com/photonstorm/phaser/issues/1434

Input update regardless of move event https://github.com/photonstorm/phaser/issues/1508

Body.collideCameraBounds https://github.com/photonstorm/phaser/issues/1873

More complex camera follow https://github.com/photonstorm/phaser/issues/1830

Better handling of texture resolutions https://github.com/photonstorm/phaser/issues/1707

Disabled states for Buttons https://github.com/photonstorm/phaser/issues/1703

Check Pixel hit testing for non-Sprite object types https://github.com/photonstorm/phaser/issues/1684

Better handling of multi-sized tile sets https://github.com/photonstorm/phaser/issues/1476

Custom header support for the Loader https://github.com/photonstorm/phaser/issues/1591

Support for Texture Packer multi-atlas files https://github.com/photonstorm/phaser/issues/1708

Justified BitmapText https://github.com/photonstorm/phaser/issues/2396

Share this post


Link to post
Share on other sites

Almost certainly a hugely ambitious wish, but a standardised way to implement networking easily would be really great. The Unity networking system would probably be a great thing to base it on, as that simplifies the whole process a lot down to RPCs and state sync. Obviously this would need to be supported by an external server implementation, or at least some centralised peer-to-peer WebRTC connection management such as that used by PeerJS.

Share this post


Link to post
Share on other sites

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. :/

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

@lewster

I really think we should keep networking in plugins. There isn't much api that can be built to support different networking libs and protocols, not to mention auth systems, backend types, etc.

An official plugin would be fine, I'd be willing to help on that, but I don't think it should be in core. I can envision tons of support being needed to tell still learning people they can't just plug and play and everything will work just fine.

Edit: (Plus it will fracture everything even more for people who would rather use their own system)

Share this post


Link to post
Share on other sites

@Rich, I feel remembering is more of an issue for the events.

The use in constructors is to remain verbose and cut unnecessary passed params. (and they are just nicer to use, check p2.js :D)
https://github.com/schteppe/p2.js/blob/master/demos/car.html

 

Edit: since we are using js that lets us do these crazy thing we might as well, right? (lol)

Share this post


Link to post
Share on other sites

@fishrock: You're probably right, but if Phaser is going modular then I think it should maybe at least define some basic APIs, including something for bare-bones networking; even if it's just a concrete implementation of a 'network entity' object. At the moment, Phaser is very much a 'visuals first' framework and that makes it slightly awkard to separate the concerns of, say, physics and sprites, for instance - which you'd probably want to do with a network implementation.

Share this post


Link to post
Share on other sites

@Rich, I feel remembering is more of an issue for the events.

Edit: since we are using js that lets us do these crazy thing we might as well, right? (lol)

 

Don't forget the loyal TS users who will suddenly have meaningless defs :) What worries me most is that although TS is an edge-case, it's the way ES6 is heading very quickly! So we could spend months un-doing a whole load of work which may need re-doing later :)

 

But I think there are ways around this. Objects OR parameters are easy enough to support from the exact same method.

 

And as for the events it's time to drop Signals imho and look at something more native. Promises are a bit of a fudge imho, but could work. Needs investigation.

 

The network stuff is interesting. It's not something I'd want to add directly but lewster is right, it does need support for it from the very bottom level. And then just let whatever API add its own implementation on the top. We're quite tied to Pixi though, so it may need some tweaking to get right.

 

Anyway this is a wish list, nothing is discounted.

Share this post


Link to post
Share on other sites
it does need support for it from the very bottom level. And then just let whatever API add its own implementation on the top.

 

I'd like to know what you exactly mean you'd like to add. Most of everything can be added by hand fairly easily from what I've experienced. (except for per-state handling.. but...)

As for when networking is handled, that depends on how you states are set up and I'd rather networking not be tied to the game or a specific state.

Share this post


Link to post
Share on other sites

• Native UI Components (inputs, dropdowns, checkboxes, etc). Perhaps as a plugin?

 

 

• Box2D or even LiquidFun physics implemented

Hmm really? p2 is native js and is only getting better. Box2D ports are a mess haha.

 

• Native UI Components (inputs, dropdowns, checkboxes, etc). Perhaps as a plugin?

 

I think we should incorporate React.js for this.

EDIT: I thought he meant specifically DOM components. But it seems silly to re-do these in canvas,

@Rich thoughts?

Share this post


Link to post
Share on other sites

AudioAtlas support can come in well before v3 :) and yes Box2D ought to be added (there are some fantastic builds of it these days, things have moved fast here).

 

UI components makes sense too, as long as you'd find them in a game. I'm not interested in recreating the DOM and anything we support on a UI level has to work perfectly from WebGL too (hence why most, if not all, 3rd party libs are out here).

Share this post


Link to post
Share on other sites
Kai    5

Strictly speaking, it's not a Phaser 3 request– but I'd really like to see community support for a web-based development environment. 

 

Perhaps Mighty Editor, or another open source project.

 

Do you think it would be possible to set up another topic folder in the forum for this? I want to help, but I can contribute more in terms of design than on the coding side– it needs official leadership.

Share this post


Link to post
Share on other sites

Strictly speaking, it's not a Phaser 3 request– but I'd really like to see community support for a web-based development environment. 

 

Perhaps Mighty Editor, or another open source project.

 

Do you think it would be possible to set up another topic folder in the forum for this? I want to help, but I can contribute more in terms of design than on the coding side– it needs official leadership.

 

Hi,

 

You can check our LREditor on this post : http://www.html5gamedevs.com/topic/7890-lreditor-free-opensource-game-editor/

Share this post


Link to post
Share on other sites

A full UI framework is in my opinion one of the hardest libraries to write but specifically to maintain. I have loads of respect for Josh@Bowlerhat and his Feathers UI. In HTML there is access to all of that by default. Maybe a better or more official way to communicate between the Dom and Canvas for menus or UI or stuff?

Ask Greensock to let us include TweenMax :P

The ES6 stuff sounds good but i am clueless! What is the status of it? Also what does ES6 and TypeScript have in common? I will go where the project goes.

More support for supporting multiple resolutions on multiple devices.

Some kind of performance thing to selectively adapt features to fit device Capability

To be honest though, I am struggling. I think Rich has done an incredible job on the structure of this library, after 5 months there is nothing I want that I have not already found in Phaser.

Share this post


Link to post
Share on other sites

I think Promises, used well, are a really good improvement to asynchronous code and one that can be polyfilled successfully for legacy browsers.

 

More exciting features for users might be multiple cameras for split screen or similar effects. I know you had to drop this early on when moving to Pixi as a renderer. Is this still constrained by Pixi?

 

If it is going to be optional to load it in, an AI module. For example, you could abstract the state machine that is used for game states into something that can be used for opponent behaviour. Obviously AI is a massive subject area but a few useful structures could be included in Phaser: finite and hierarchical state machines, navigation via A* search or similar, maybe even behaviour trees, etc. You could treat this similarly to the physics - arcade ai, learning ai, etc.

 

Just wondering about how these changes to a more modular approach might relate to plugins?

Share this post


Link to post
Share on other sites

- SVG support (incl manipulation)

- a user registration framework, sharing features (mail, social media etc), paypal integration

- projection mapping/free transform

- 3d features, eg three.js integration or something

- packed file support (ie for stuff like 5mb json files that would pack to 12kb)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.