Here is what the team has been up to this week:

Arian: Greetings friends. This week we almost finished our first version of the online editor. This editor will be available to everyone, and despite being online, you will be able to access your local projects. We have also worked on the desktop version of the editor, integrating it with the authentication of Phaser.io users. Next week will be very similar to this one, except that we hope to have both versions of the editor ready: online and desktop. See you!

Robert: ¡Otra semana ocupada que pasó demasiado rápido!

The ES6 build is almost here, just working out a few pieces of glue I had to get specific parts working and replacing them with proper solutions. The trickiest part being the renderer and pipelines playing nicely with the new build, for test purposes its all included but this isn't why we are upgrading. Tree shaking is one of the more popular benefits and renderers would be a good target for it, cutting out bloat if you're not using WebGL specific features for example. Next week will be cleanup and linting, but at least it's coming together!

Francisco: Greetings from Spain (and also Nicaragua from my heart).

This week we've released the first version of the create-game cli template installer. We've also resumed development of phaser-fiber, and I've spent time cleaning and getting up to speed with the code to continue developing it.

We've started to create base components such as Game and Scene. These components will be the entry points for Fiber, and I intend for all updates to occur within the scenes.

I hope you warmly welcome this new project, until next week.

Can: Greetings fellow Phaser lovers,

We are in spring time in Cyprus and it’s boiling here! Despite the heat(in spring!), I have some amazing news. Following the launch of our Discord template, we are not stopping there! I started working on Discord Colyseus Phaser template so you can make your favorite multiplayer game to be shared with your loved ones on Discord! I’m itching to complete and serve it to you all!

Rich: There are lots of things all coming together right now, but one of the most exciting for me personally will be the launch of proper User Accounts on the Phaser site. I know, it sounds so basic and trivial, right? It's something I have felt the site lacked for many years now. Our community was always split between Discord, Patreon, our Forum, and Twitter. If you wanted to comment on one of the news articles on our site, you couldn't do it. If you wanted to ask a question about a code example in the labs, you couldn't do that either.

By opening user accounts on our site, we can finally start offering all kinds of fun services! Plus, of course, with Arian and Phaser Editor as part of the team, it's time to fully integrate the Editor with our site too.

As well as this, we're also in the process of collating all our legacy content and pulling it back to the new site. For example, our Dev Logs first started life on my personal PhotonStorm blog! Then they moved to a mixture of Patreon and this newsletter, some on the site, some not. It's all a bit of a mess, really. So we sat down and scraped and converted all of this content into markdown, imported it all into the new CMS and will finally be able to present the whole Phaser story and journey with you, starting right from day 1.

The Phaser Labs will also be revamped and merged with the site. And with proper user accounts we can even let you do things like forking the examples and tweaking them for your own use, or submitting your own examples for inclusion on the site. Much like CodePen does, we want to foster a similar kind of feeling and feedback loop for Phaser examples.

Finally, did you know that next Friday (April 12th) is Phaser's 11th birthday?! We probably ought to do something to celebrate, although I'm not entirely sure what yet :) If you've any suggestions, please let me know in Discord!

Ben: My hacked-together new renderer is doing something and is now using the new data structures to handle all of the WebGL calls.

A simple test scene with a single Image in it takes 6 WebGL commands in 3.80:

• bindFramebuffer
• clearColor
• clear
• enable SCISSOR_TEST
• bufferSubData
• drawArrays

In the new version, it's down to 3:

• clear
• bufferSubData
• drawArrays

Because it knows the full state, it knows it doesn't need to bind the same framebuffer again, or set a new clear color, or change the scissor state. Those are all being called by the DrawingContext, but the state management is skipping them.

It's successful in automatically assigning a DrawingContext, and passing it through a RenderStep. The DrawingContext is correctly assigning the Canvas, and correctly clearing itself when it figures it's time (visible via debug). The RenderStep is correctly compiling a shader program, connecting its attributes to a buffer, computing basic transform matrices, and setting uniforms.

In its current state, the system can only render Images and Sprites. But it's already fine with animations on Sprites.

This isn't using Compositor nodes yet. I really aimed for minimum viable proof of concept. However, it's giving me lots to work on.

As mentioned, I need to tighten up some of the attribute handling, and allow more control over data types.

There's also a lot of boilerplate around vertex transforms. I've just inlined it in my hacky code to get it working, but it needs a better place to live. What started off as WebGLPipeline.batchSprite is probably going to be broken up into some smaller functions, such as a universal function for computing vertex transforms. And maybe there'll be a topology helper function for zipping that coordinate data together with other attributes like tints and texture units; TRIANGLES topology requires repeating two vertices out of every six and we might as well automate that. Splitting this all up can make it really efficient; a MultiTexture step wants the same vertex transform data as a SingleTexture step, but it treats texture units differently. This also helps us pull data off individual RenderSteps, leaving them very svelte and single-purpose. Right now I've got several temporary matrices on the Single step, which might be able to live entirely in a more specialised step. I'd love for each Step to be just a couple hundred lines of code.

Like Pipelines, but lighter, more focused, and with fewer points of friction.

It's feeling good, though. I can see the nodes coming together as simple parts of a complex system, the drawing contexts controlling framebuffer usage, the programs efficiently handling their inputs. Once I've got all the basic parts in place, we're going to see an explosion of nodes restoring all the old functionality, only more efficient and intercompatible. And then we can start setting blend modes and FX in places they've never been seen before.