Phaser 2.5 Roadmap (and request for ideas)

[rich]

As mentioned in the "Phaser is 3 years old" thread I want to close off Phaser development by sorting out a few things that have been bugging me for a while. So here's a tentative roadmap. It's intentionally short, because I don't want this to take very long to implement, but I do want it to address some key areas. Not all of these are confirmed, it will depend heavily on feedback:

1. Upgrade Pixi. I'd very much like to move to Pixi v4, as Pixi v3 is dead now, but it's extremely bleeding edge and changing daily. My worry is we'll inherit a mass of technical debt up front, which I have no doubt will be resolved in due course, but it's a little worrying. The alternative is use Pixi 3, even though we know it won't give any speed increases from earlier tests, but we do know it has a number of fixes deeper down. The final option of course is to remain with our Pixi 2 build we have currently.
2. Implement the new main loop that I developed for Lazer. This will get rid of timing issues across the board, and add in the option for interpolated sprite rendering, which in the right circumstances (i.e. tweens) looks fantastic.
3. Recode the tilemap renderer. Phaser used to have a really fast tilemap system, and it got changed too much over the years and now it mostly sucks. It's time to resolve this.
4. Consider swapping Arcade Physics for a proper SAT based system. This wouldn't take too long, and the rewards may be worth the time it'd take. It would feel different from AP though, and be computationally more expensive in places, but still orders of magnitude less than the likes of P2. I want SAT in Lazer anyway, so it feels like this may kill two birds with one stone.
5. I'm tempted to recode Phaser to use modules properly. Not full ES6 modules, not like Lazer, but definitely move to using modules properly, and then we can retire the custom grunt tasks (and stop the GitHub issues when people try to 'require' Phaser and wonder why it doesn't work ) - part of me thinks this might be a waste of time this late in the day, serving only a select few. Then again maybe it's worth it all the same? Votes please.
6. Create a new Pool class, and updated Group to inherit from Pool. Pool will handle non display object related tasks and be quite generic, where-as Group will remain the same as now (i.e. a display list container).

And I dare say some other little things will worm their way in during development, but those are the headliners.

So.. it's feedback time please. And before you say "do it all!" just know that time spent on this delays the release of Lazer. Which of the above do you feel are useful or useless? and are there any other things you think are important and worth doing?

Edited April 19, 2016 by rich
Clarified Pool and Group interaction

[WombatTurkey]

Sadly, I cannot address the SAT based system (Pre-Algebra Math Major here). Here are some of my thoughts though:

1. Only if upgrading offers a dramatic performance increase.  

2. I vote yes here. I think tweens are becoming more popular and if that would improve them visually, yes, yes, and yes.

3. Pointless I think. Most people I know just simply use the phaser-tiled plugin. Save that time for a new renderer for Lazer perhaps.

5. I vote no here as well. As you said, only a select few have this problem and comparing that to your invaluable time is not worth it in the end.  Plus, there are tons of Phaser tutorials out there so they should know better

6. I personally don't like this as I'm already ingrained of thinking that groups can be potential pools. Splitting that out would seem like it would be more confusing.

[rich]

6 - Groups would retain all the same functionality as now, it's just that lots of it will be inherited from Pool, and you could create a Pool on its own (without a Group).

[jackfreak]

They are all excellent ideas Rich!
Here are my votes:

1. I think this would be a waste of time unless there's a clear increase in performance. Maybe pixi 3 if that fixes some issues. My vote is neutral (0).
2. Tweening is very important, I use it regularly in my games, so if this can improve them then it has my vote: yes. (+1)
3. THIS IS A MUST. I can't tell you how much I have strugle with the current TileMap implementation, it is just slow, specially with big maps. I know there's the phaser-tiled plugin but it only supports p2 physics, it lacks many features of the official TileMap implementation and the code isn't all that friendly and well documented (to make extensions/customizations). So...  Recode the tilemap renderer... yes please! (+1)
4. This is also a great idea. I would even make it a separate physics engine altogether, "SAT Physics" or something, leaving Arcade physics just as it is. Then people can start playing with SAT and go from there. My vote is yes (+1).
5. This is the least appealing idea for me. I know it has its advantages but as you say... modules will come with Lazer so this might be too much at this stage. Plus Im very comfortable with the Grunt task, it was easy to learn and use. My vote is nay. (-1).
6. This would be very useful. I found myself using Groups and its pooling system more and more each time. Having a Pool class and making Group inherit from it sounds like the way to go. That generic Pool class is something the framework needs. My vote is yes (+1).

[SignalSin]

I would absolutely love it if you were to improve the tilemap renderer!

[horkoda]

2. +1

3. +1

5. -1

[sanojian]

One more vote for number three: recode the tile map renderer.  That would be fantastic.  The current one feels clunky to use and renders very slowly with large or complicated maps.

[Binary Moon]

3 and 4 are the ones I think are most important. The other features are nice to haves - but not essential imo

[qdrj]

For me, Pixi 4 is a "game-changer" because of the performance boost.  I spend a lot of time trying to achieve 60 fps on mobile devices. So anything that will help would be a huge time saver for me.

p.2 sounds nice but from my experience if a game runs >45fps sprites movement looks good enough.

Pools are very easy to code and can be tailored for specific games. So I don't think that it should be part of the game framework.

[JakeCake]

1. Yes to this, v4 is a huge step it seems. I don't think Phaser needs to natively support new features of v4, but the performance is definitely worth the effort in my opinion.

2. Havn't heard of this yet, but it seems awesome! Generally anything that has to do with better performance, or the illusion of better performance gets a +1 from me.

3. There are some great plugins for this already, so I vote no.

4. This seems like a huge API change. I'd wait and only do it for Lazer.

5. A rebase of code seems too timeconsuming and error-prone, maybe let this be a Lazer-only feature.

[rich]

To explain a little further (as it was 4am when I made the initial post)

• The reasoning behind recoding Phaser to use modules actually ties to moving to Pixi 4, which is modular in nature. So rather than meld in the entire compiled pixi v4 lib, I was seriously considering swapping Phaser classes to be modules instead so I could pull in which parts of Pixi were needed.
• Group is a Pool already, the only change here would be to abstract away the 'pure' pool stuff from the display list stuff. I myself get frustrated by this one, so I'm positive others do too.
• Making SAT into its own mini physics system is actually a great idea, one I hadn't considered, thank you

Keep the feedback coming!

[Madi]

While I do think many of these changes would be great, I feel that its pretty short-sighted. I think the time spent on these changes would be better spent on development of Lazer. Especially considering the amount of new bugs these changes would introduce. Phaser development should be mainly limited to bug fixes/stability improvements now.

[nilocesar]

One more vote for number three: recode the tile map renderer. 

[FelixNemis]

If I had to have only 1 thing out of the list it would have to be improved tilemap rendering speed.

Moving to Pixi v4 would be great, but if it introduces too much work then maybe sticking with v2 or v3 is the best idea.

As for the Abstraction of pool from group, that's a great idea, and it sounds like it shouldn't take very much time, so I say go for it.

#2 would also be cool, but I'd rather have the above imrovements

[s4m_ur4i]

my vote:
1. hell, yes
2. no
3. no
4. yes (using tiled plugin does the job - native impro would be great)
5. yes (relies on pixi)
6. no

[Zeterain]

I oppose simply in favor of time spent on Lazer. All of the options would be welcome upgrades.

1. Pixi: I would take a Pixi upgrade for performance upgrades, but not for feature upgrades. Most likely, Support
2. Main loop: Oppose
3. Tilemap Renderer: Oppose
4. Arcade physics swap: Oppose
5. Modules: Just work on Lazer. Oppose
6. Pool class: If this is quick, sure, otherwise, Oppose

[drhayes]

I'm coming from the perspective of someone with a game in development on Phaser 2.4.x, so most of my needs are pretty selfish.

1. Upgrade Pixi: don't know the codebase enough to make the call, especially w/r/t upcoming Lazer release and Phaser EOL. My selfish vote is "yes" because my game probably won't move to Lazer and this benefits me.
2. Main loop: like it.
3. Recode the tilemap renderer. Holy shit yes.  My maps aren't huge and I don't see the inherent problems others do, but they're very important to me.
4. SAT: fourth physics system FTW. I'm super familiar with Arcade and would mourn its loss. 
5. Modules: I'm one of the select few, a total webpack and/or browserify adherent. That said, I'm fine the way things are now and this seems far-reaching and corner-case heavy; lots of dark corners and circular dependencies and refactorings. I vote ¯\_(ツ)_/¯
6. Pools: Yup, do it, you've been talking about this forever. This one seems easyish, too?

 

[hexus]

I really like the idea of SAT based physics, as you know from Github.  Faster tilemap rendering would also be fantastic, they're used everywhere.

[Yora]

I support the idea of switching to pixi v4, and the main loop improvement.  Performance is crucial, and if pixi v4 is a good improvement it will benefit many people, albeit a heavy decision to make.  

[sapptime]

1. Sounds awesome if it doesn't impact the API too much. I'd definitely share your concern about it being too bleeding edge though.
2. Sounds great.
3. Amazing - I've been working with tile maps quite a bit in a game I'm currently working on, I've tried both the Tiled plugin and the built-in, and if it gives any kind of performance boost on mobile, especially when scrolling, it'll be an awesome improvement to have.
4. I could take it or leave it, but I'm not familiar enough with SAT to understand the reasoning behind it.
5. Could take it or leave it at this point, as I know this is the way Lazer is headed anyways.
6. Sounds like a great add on that wouldn't take too much work to do.

To sum up, I love the idea of 1,2,3 and 6. 4 and 5 (selfishly) mean less to me, but I'm sure they'd be great additions.

 

[VitaZheltyakov]

Yes, all

Richard, read this

Please

[jouniii]

I'd like the pixi v4, but I fear it means there will be Phaser 2.6 as well to fix and patch new issues. The current pixi v2 works fairly well imho and I'd rather just switch directly to Lazer if it brings similar functionality anyway as pixi v4 update would do. 

What I really would like to see is some internal patches/fixes.

- Support texture compression, it would give much needed improvements for texture heavy games on mobile, hard to do externally 

- Patch to support more of the TexturePacker (and other) options such as the pivot trim/crop (would give optimization on webgl filter's when the filterArea would be "automatic") and rotation, again hard to do externally

- Support for preloaded image resolutions (based on the the url @NNx). Now you can start the game with resolution for pixi, but the image BaseTextures don't get their resolutions set (defaults to 1). You have to manually access the private cache._cache.image to post-process the objects to support hi-dpi the pixi v2 way. Pixi v4 has more generic regex for the url processing. Other than that, hi-dpi works very well.

Pool class is something one can easily implement. not sure if needed for Phaser. I already see Phaser is getting some bloat which could/should be plugin or just external extra code instead. I'd rather concentrate on features more deep internal improvements. Of course Lazer in it's nature would (as far as i understand) be more modular in this sense too.

[shimlong]

For my own selfish purposes it'd be helpful to have "infinite" tilemaps and performance improvements on tilemap rendering. If not exactly infinite, then some API that allows a player to transition from one tilemap to an adjacent one as they approach an edge.

[webcaetano]

1 - Pixi 4, have alot new very useful filters. +1.

[rich]

Just wanted to say that I have decided to take a chunk of the Phaser patreon money, and use it to fund paying a very skilled developer to create a brand new WebGL Tilemap renderer in Phaser.

Early test results are great, it will make a *huge* difference.