The Evolution of Phaser 3 and Lazer

[rich]

Hi all,

There's a lot of confusion over Phaser 3 / Lazer, so I've written it all up as best as I could.

It's a lengthy, but I hope interesting read, with an important question at the end.

https://www.patreon.com/posts/7547955

I look forward to hearing your feedback.

Cheers,

Rich

[WiLD11]

Good read! 

I definitely agree about calling it Lazer and not Phaser 3 as a person who has made alot of phaser tutorials in the past. It would be less confusing for everyone I guess since they would be so different.

[Umz]

Things make a little more sense now. Would like to read the article about the conception and Phaser 1 wherever it is too.

I think naming generally follows simple rules: if it is expected to be the same as Phaser, name it Phaser. If it's expected to be very different, name it Lazer. Since it's going to be so different, it can't really share the same name. Thanks for all the hard work though!!!

[rich]

The API is very, very similar though. It's internally where it is nothing like Phaser. Which is what makes it such a hard choice

[PhaserEditor2D]

Hi @rich

 

I think you love Phaser and I honestly don't see a real need to change of name (unless you are worry about that question of the rights of the movie). You can call it Phaser v3 no matter how much internal changes it has or if you are using webpack, ES6 or typescript, or if it supports 3D.

What is Phaser? I see the answer is more about what users can do with it and how.

Is common to see how technologies change so much but the name remains, just take a look to Windows 3.11 vs Windows 10.

I don't code in python too much these days, but years ago Python 3 was a massive change internally and externally: they did not change the name.

Actually there is this sequence of C, C++ and C#! Why not a Phaser v3?

Phaser v3 is getting a lot of exciting features and the Phaser team is working with pleasure, it is a good sign. There are time to migrate it to ES6 later, I think.

 

 

[rich]

Thanks for the comment Arian - actually, as someone who has a commercial interest in this (re: sales of Phaser Editor) - would you prefer that I kept the name, even though it means lots of the things inside Phaser Editor would no longer work in v3? How would you handle that? One version for Phaser 2 and another for 3, or something internal, i.e. they create a Phaser 2 project, or a Phaser 3 project? I guess at least if we called it Lazer, you can just release Lazer Editor  But that does mean you'd have double the amount of work then, maintaining two different products.

Happy to hear your thoughts on this area of it specifically.

[cdelstad]

Wonderful explanation. I really appreciate you spelling it out for us.

Here are my thoughts. I would honestly say if you are going to go through a big shakeout cycle for Phaser 3, you may as well go full es6 and only do one shakeout cycle instead of two. I know you said not to suggest it. I am just bringing up an 'on the other hand' point of view. How many people are going to want to use it knowing not to far down the road there will be breaking changes again, ala Angular 1 to 2. And two huge shakeouts is a long time for Phaser not to be stable.

Using semver, won't the CE version hit Phaser 3 as well, or will it be retired as soon as Phaser3/Lazer is operational? It may cause some confusion having two v3's.

Going back to Angular. They announced they were going to be following semvar and Angular 4 and 5 are scheduled for 2017 releases. Now, it wont be a complete rewrite like 1 to 2, it just means there are breaking changes.

So you could either make phaser 3 include es6 out of the box - mostly to reduce multiple shakeout cycles, or make Phaser3 as is and make Phaser4 the es6 version.

Just me two bits.

-Chad

[the-simian]

Honestly there's nothing wrong with Phaser 3. With major version changes its totally ok to have a large departure from an API. Phaser 3 is , in many ways based on the hard work from Phaser 2 and Laser, so why not stick with the brand name? Breaking changes are acceptable, every other library does it! You increased the major version, so you did the right thing

[mattstyles]

I'm not clear why porting to ES6 would require a totally different project (Lazer and Phaser are, essential, individual projects, otherwise we wouldnt be having a discussion at all right?), what language your source is written in is an implementation detail, so long as I can `import` or `require` or `define` or whatever the Phaser modules into my project with the expectation that that code will run in the supported browsers then it doesn't matter what the source looks like.

You're versioning against a contract, if the api is very very similar but with a few breaking changes then thats a dead-set increment of the major, not a new project.

If you then port it all to using ES6 but make no other changes then the contract remains the same. You'd probably release that after you've cracked some new features in and bump the minor, or the major if that refactor did indeed produce breaking changes to the contract.

The only possible difference here would be that importing your source directly would require the consumer to run a defined list of transforms to prepare it for the browser, but any decent build tool can now support this and there is even the unofficial use of jsmain inside your package.json description to allow various tools of using your source entry point. Again, I'd say this is supplementary to any discussion of a new project, this is a new feature to let consumers produce a slightly more efficient product bundle (rather than consuming your own transpilation, they might get advantages from running that themselves) so would be a minor bump.

I (wrongly) assumed Lazer would drastically change the api, hence the name change, it sounds like now that has Lazer has been used almost like a fork, and is now ready to come full circle back into the Phaser project.

Sounds to me like this is a Phaser 3, with the ES6 refactor either a 3.1 (with other features, as the refactor adds no new features by itself) or a 4 if it does introduce breaking changes. I'd assume, at this stage, that a v4 would be unlikely, a refactor should not introduce breaking changes ideally.

[spencerTL]

Personally, I think the goodwill and reputation you have earned through Phaser would allow you to go either way.  People will adapt to Phaser 3 or recognise Lazer as the next step.

One thing that struck me, though, was that in your history you didn't mention the time you spent trying to trademark Phaser and hence the switch to the Lazer name.  I remember you going into reasons etc on Twitter.   People will adapt to whatever you choose but we all win if you and your business benefit.  If fully controlling the name of the product would benefit you, then this should be a big consideration.

[end3r]

The key here is copyright on the name "Phaser" from the authors of the upcoming Star Trek series, at least that's what I remembered from a blog post some time ago. I'd try to contact them directly and ask if they have any problem with using the name. You can stick to the current name and if they force you to do so, then do it only then.

I was waiting for Lazer because I thought the decision was final, but if you're still considering it I'd say stick to Phaser. The difference internally it not a big problem - if it's a next version number it speaks for itself that you just can't include it in your old project and hope it'll make you fix a few lines and that's it. It would only mean you'd have to specify the version in which you're writing a tutorial, but it's a common sense to do it anyway.

There's a huge collection of materials about Phaser already, the gamedev community and the whole world got used to it, the framework is recognized as one of the best out there even from non-developers, and it would be a shame to waste such marketing recognition and start with something totally new. On the other hand you as the author is a recognizable figure and if you change the name to Lazer it will take some time to clear the confusion, but people will accept it and move on.

[PhaserEditor2D]

Hi Rich,

The philosophy we follow with Phaser Editor is always to support the latest official release of Phaser. And we mention that if Lazer is going to replace Phaser we are going do the same. The key is the "official" word. If PhotonStorm will officially support both projects, then we are going to support both too, probably as separated products because to keep both in the same application will increase the size of it too much, just look that we bundle all the examples that are an important number of megabytes.

Sure it could take some time to adopt the new Phaser v3 or Lazer but we see on it a great opportunity for us, to be one of the first editors to support the new super Phaser3/Lazer from the beginning  

About the name I don't know yet what to do. I used Phaser Editor to name the current editor but after some time I realized it was not a nice name because people can get confused about if it is a PhotonStorm product or not, so probably I will use other name, like... Lazer IDE? hahaha.. is joke, I was thinking something related to Reflection because the editor has a lot of Phaser reflection (metadata inspection) and it is a word related to the Light too.

 

Thanks for ask!

[cdelstad]

4 hours ago, mattstyles said:

I'm not clear why porting to ES6 would require a totally different project (Lazer and Phaser are, essential, individual projects, otherwise we wouldnt be having a discussion at all right?), what language your source is written in is an implementation detail, so long as I can `import` or `require` or `define` or whatever the Phaser modules into my project with the expectation that that code will run in the supported browsers then it doesn't matter what the source looks like.

You're versioning against a contract, if the api is very very similar but with a few breaking changes then thats a dead-set increment of the major, not a new project.

If you then port it all to using ES6 but make no other changes then the contract remains the same. You'd probably release that after you've cracked some new features in and bump the minor, or the major if that refactor did indeed produce breaking changes to the contract.

The only possible difference here would be that importing your source directly would require the consumer to run a defined list of transforms to prepare it for the browser, but any decent build tool can now support this and there is even the unofficial use of jsmain inside your package.json description to allow various tools of using your source entry point. Again, I'd say this is supplementary to any discussion of a new project, this is a new feature to let consumers produce a slightly more efficient product bundle (rather than consuming your own transpilation, they might get advantages from running that themselves) so would be a minor bump.

I (wrongly) assumed Lazer would drastically change the api, hence the name change, it sounds like now that has Lazer has been used almost like a fork, and is now ready to come full circle back into the Phaser project.

Sounds to me like this is a Phaser 3, with the ES6 refactor either a 3.1 (with other features, as the refactor adds no new features by itself) or a 4 if it does introduce breaking changes. I'd assume, at this stage, that a v4 would be unlikely, a refactor should not introduce breaking changes ideally.

I was thinking about this last night after posting. Realistically, any es6 code would be transpiled to es5, for now, so I am not even sure es6 upgrade would be a breaking change. And as mattstyles brings up, if the api isn't a breaking change, it isnt a breaking change. The internals are just that.

I am just breaking down the es6 effort, not trying to push you into changing direction.

Honestly, which parts of es6 would you want to implement? If you already have js modules, so do you need to refactor them to classes? Seems like not enough value for the effort. I can definately see using let and const, Symbols can be very handy, though you're already using prototypes. A lot of the code you have does not become invalid or no longer a best practice because of es6. Most of es6 are just more handy ways of doing the things you are already doing.

I can see es6 changes where their counterparts are more performant than es5, but there are not many of those atm.

Talking es6 as a whole sounds like a huge effort, but if you broke down which parts you want/need to use, and where it needs to be implemented, I bet it seems a lot more managable. 

[mattstyles]

Phaser has a real performance slant, as most ES6 features are to do with developer ergonomics and writing better source code (i.e. more reliable and less error prone), not performance, so there would have to be some careful tracking of whether an ES6 code rewrite is actually harming performance, which it probably will, most es6 stuff that has already been implemented in browsers is slower than the es5 counterparts although in the case of transpilation some of the transpilers are so efficient that they produce more performant code than the hand-written es5 implementations!

A tricky subject as many es6 features are 'native' in modern browsers already, but not all, although I guess that issue is solved by allowing consumers to import your source and run whatever transforms they want to for their target platform (i.e. if I'm only targeting iOS Safari on newer devices, maybe wrapped in Cordova, I can use most es6 stuff whilst a web game that has ie11 in its target list would need to transpile most of it). When the time comes that es6 language features are faster than their es5 counterparts it would be a shame if any library was only consumable as transpiled, but they would have to ship a transpiled version for full browser compat.

[rich]

Thanks for the feedback so far everyone. To be clear:

The API *is* different in places, but also very similar. It will be instantly familiar to anyone who has used Phaser before. But the changes are significant enough to warrant the v3 change.

Moving to ES6 should be far less of a change, from an API point of view. There is no compelling reason to make the change yet. It would undo months of hard work for really little more than syntactic sugar. It *will* happen in the future though, but right now just shipping something is priority.

There *are* legal issues with the name Phaser. I could never own it as a trademark, ever. Keeping it is a risk. But equally I've got the Lazer name secured everywhere, so it's always there as a fallback if CBS lawyers come knocking.

Or I just make the change once and for all, and rename it.

Keep the thoughts coming please

[WiLD11]

If you can plug v3 into your v2 project and not have to go through hundreds of errors then I think Phaser 3 would be more suitable.

[rich]

You can't. A v2 game will need changing to run in v3. How much depends on how big the game is.

[WiLD11]

1 hour ago, rich said:

You can't. A v2 game will need changing to run in v3. How much depends on how big the game is.

I see, I will be sure to make it very clear what version of phaser I am using in future tutorials to avoid people having errors. I don't think changing to Lazer would be that beneficial. The only thing really is the legal issues, if they come knocking at your door then Lazer sounds like a good fallback. 

[nkholski]

Thank you for sharing. My interest in the framework aside it's an interesting read. Really inspiring for someone like me who never manages to keep a straight path to get a little insight to the processes behind Phaser which is such an excellent framework in the end.

I've been away from Phaser and game development for some months focusing mostly on an Angular 2 project. AFIK there is no code reused from Angular 1 to 2, and from now Angular is using semver skipping v3 with Angular 4 coming up. Without any prior knowledge, I would expect Phaser 3 to introduce breaking changes. I would vote for keeping Phaser as the name of the framework as it is established and with semver people should really read the changelog before updating. Even if you switch from Phaser (which is very well established) to Lazer (which is not), it would be a temporary fix. Updates of Lazer would inevitably introduce breaking changes sometimes, making tutorials obsolete again etcetera. Either that would be okay then or Lazer needs a new name. I think this article on Angular versioning is a good read: http://angularjs.blogspot.se/2016/12/ok-let-me-explain-its-going-to-be.html and I especially like the second conclusion in the end:  we do need to evolve Angular in order to avoid another Angular 1 to Angular 2 change, but we should do it together as a community in a transparent, predictable and incremental way."

I wouldn't expect Star Trek copyright holders to act either. They did so against the Axanar fan film because the way and scale it was financed and that they refused to comply to demands. Before that they just ignored Star Trek fan productions. Just using the word Phaser out of context should be safe. It seems that you're well prepared for any legal challenges with Lazer as a backup plan, so I vote for Phaser.

I hope to be back to Phaser (Lazer?) soon again, and I'm looking forward digging into whatever the framework will have to offer.

[mattstyles]

NG2 should have been a different name, not solely because there is limited code carry-over but mainly because conceptually the model has changed, with only some aspects of NG1 making the cut. They are living off of the name, I'm sure they'll follow semver again now they've made the switch but it was purely a commercial decision to keep calling the project Angular, based on the weight of the name. It solves the same problems as the earlier project, but in drastically different ways most of the time.

Rich has a similar decision, Phaser is very well known, but, the crucial difference is that conceptually Phaser isn't changing that much, the implementation sounds pretty different, which has necessitated a new api, but fundamentally the project solves the same problems in largely the same way, there are just some different bits in it to solve those problems with.

The appeal of a locked-down name is attractive though, on the flip side, I've heard of many projects/products renaming when they are in need of rejuvenation, Phaser clearly needs no rejuvenation and I'm not sure I can think of many things that have been renamed whilst riding high.

[raenset]

I would keep the Phaser name. It's well established, and it's a more appealing name in my opinion. It's an English noun, "a device that alters a sound signal by phasing it", so I don't think it's a problem with anyone using a noun for the name of a library. That would be like calling it "runner" and having someone complain since it's trademarked. Highly unlikely.

This said, I don't think that it is a problem with the Star Trek authors if a free JavaScript library is named the same as something they did. That would be like Python having to rename to something much less cool because of Monthy Python. I don't think that the Monthy Python authors ever complained with a famous programming language being named Python. In any case, you could always change the name if and when actually forced to, which is, I repeat, very unlikely.

Lazer does not mean anything in itself, while Phaser is evocative, (a phase is a transition) and it reminds me of sci-fi and games, at least more than Lazer. Naming it Lazer would be like saying: ok, this is no longer Phaser, and furthermore, the Phaser legacy, or background, is no more needed.

Furthermore, major changes will happen to "Lazer" too in the future, so a new name would be needed again, following the "big changes = new name" logic.

But, I repeat, for me the main reason I'd keep the old name is that Phaser is much cooler.

 

[Arcanorum]

Will Arcade Physics 2 be tied to display objects?

[valueerror]

thank you very much for this explanaiton!

i'd suggest Phaser3 as a name..   just because the name stands for a good and easy to use js gameframework..  a good brand should stick to it's name and logo ...    have a look at this...  they know why they are doing this ^^