Games Community Group meeting - TPAC 2020

Phaser

Now, what is Phaser? I'll keep the section brief, because I'm sure many of you are familiar with it, or have at least heard of it already. But Phaser is an open source HTML5 game framework, released under the MIT License. I published the very first version to GitHub back in April 2013. Now, the web was a very different place back then. To give you some context, we had Firefox at 20% browser share and IE and Edge at 28%, so it was so much more level playing field than we see today. 43% of web visitors were using Windows XP of all things with a resolution of just 1024 by 768. It was a before the time when everyone's getting the mobile phone app. For games, we could either use Canvas API, which was pretty much brand new or CSS. Because WebGL support was not going to actually land in iOS for another year and a half. Web Audio went awry for another four years.

So, like I said, a very different landscape both in terms of technology and platform. I created Phaser because I needed it, it was as simple as that. I was building HTML5 for clients day in day out, and there was nothing available at the time that met my demands, so I built something that did. And after I released it, people took notice of it, developers started using it, and the rest, as they say, is history.

Since that time, Phaser has been used to create thousands and thousands of games, played by literally hundreds of millions of people, from the Minecraft Hour of Code games to massively Multiplayer IO games. It genuinely never ceases to amaze me, what developers manage to create with it. Honestly, it's quite humbling and validating to both of my hard work and of web gaming as a platform.

Phaser has evolved quite dramatically over the last seven years. When I very first released it, it was actually built on a Beta release of TypeScript, they weren't even at version 1.0 then and it was, it's actually quite painful and bug prone experience. But it was something that we felt needed to do at the time, because we were traditionally Flash developers, so we had the type safety of ActionScript, and we wanted to recreate it on the web. We were still focusing on Canvas, because WebGL just wasn't there on mobile, and people wanted their games to work across desktop and mobile, that was the dream of HTML5. It was a few years later, with the version two release, where we were building on top of Pixi, which was an upcoming renderer at the time. And that gave us the power to have focus on both Canvas and WebGL.

Thanks to funding things basically just carried on going and Phaser was being adopted more and more and we hired developers, and we worked full time on version three release. Again, we were looking at using JavaScript, because we're still at a place about time back then when yes, ES6 modules just weren't there, and everyone had to deal with through transpiling, and it just wasn't the environment that we have today. So we created a custom renderer from scratch, which focused again on Canvas and WebGL, and, we've really built on that since that point.

There have actually been over 30 releases of Phaser three published since that time, and I'm actually getting ready to release the 3.5 release right now, which is the single largest one since the framework has first been started.

Because of the changes in the browser space, both in terms of features and tooling, Phaser4 will actually be a complete reboot of the framework. It is fully written in TypeScript now, version four as well, using ESBuild for bundling. It is completely modular, which will allow you to ingest into modern browser environments, and there is a completely new renderer capable of 2D and 3D. So we're splitting that up, so we would include Canvas, we would include WebGL, and we will obviously move to WebGPU when standards start to solidify and things settle down a bit.

If you track the life of Phaser from 2013 to today and beyond, it is a pretty close match to the way in which browser technology has evolved as well. I mean, obviously, I cannot pivot quite as fast as the tooling space does, but it's still a constant process of evolution and not a case of sitting still. And I think that's something that game developers also have to struggle with, when it comes to web technology. It is a constantly evolving and constantly moving goalposts. You can't just basically publish once and be done with it anymore.

Developers pain points

That to get to the meat of this talk: what are the developer pain points? I talked to the wider web game developer community, so not just Phaser Developers, but anyone using any framework or any means of building games for the web. And asked them about issues that they face on a regular basis. Because while it's important to celebrate what is good about web gaming being a group play field, we're only going to achieve something if we listen to those who are constantly fighting on the frontlines, with the reality of game development today.

These issues are by no means exhaustive, but I hope you'll see some common threads amongst them. I split them into three sections. Basically, we've got the platform, so issues involving stability of the platform, which games are built on. You've got tooling, which is around building and debugging. And then you've got monetization, so how people get to your games and play them and how to get income from them.

We'll start with platform. The following are quotes that I've collected from talking to developers recently, I've kept them anonymous but you'll get the feeling from them.

I can't even count how many hours we have wasted in our studio, collectively fixing random issues on various combinations of devices. At this point, it is Russian Roulette when everything will break again.

It is shocking how something as fundamentally simple as making your game go full-screen is so utterly broken across devices. The APIs are essentially too fragile to be relied upon.

90% of the bug reports we get are nothing to do with our code. Most of the time, the browser has messed up or changed how something works or obliterated the display of our game and the process.

Now, unstable platform, this is a commonly reoccurring thread, which is, quite sad in a way. And I think it's all too easy for browser vendors to get lost inside the technology. It is easy for them to forget the real world implications of what changes. You can bask in the glow of new tech like WebGPU, and that's all good and well. But I received hundreds of similar messages to the ones I've just read out. Although web technology has definitely settled down, and the baseline of WebGL1 on my body has become more ubiquitous, you still can't rely upon it. The process of making web games was likened to building upon sand, in that it is constantly shifting below you. This isn't surprising given the rapidity of change that goes on in the browser space, but it makes game developers very wary. Making a game is not like building a website, the APIs may fundamentally be the same, but that is literally about where it ends. Very often, clients do not have the budget to constantly revisit a game a few years down the line that's suddenly broken because maybe audio has stopped working, or the way in which gestures are handled is different.

It also appears that the more devices you involve in the mix, then unstability just increases exponentially. And the more browsers you involve across those devices, it just continues and continues. A lot of developers gave up after fighting platform issues. And even tools like Unity and WebAssembly are not going to be able to avoid this. If an API changes, it changes for everyone regardless of how that game was built.

The next category I talked about with developers was tooling. And this fell into two parts, so developing game and debugging it. On the whole thanks to advances in apps like Visual Studio Code, there were next to no issues at all with the process of actually programming a game. Developers, both hobbyist and professional, have surrounded themselves with editor setups that they feel comfortable with, and coding really isn't an issue for them. Some of them missed the visual aspects of game dev tools like Unity and Unreal provide but it was unanimously agreed that these tools do exist and can be found out there, Playcanvas for example, or can be created ad hoc as needed, and it's not perceived as being a barrier to getting involved.

However, where this opinion dramatically changes, is in the assistance that we get when debugging our games. The consensus is that dev tools, while great, is focused on debugging websites, so they just cannot cope with the sheer volume of data, or the speed at which we use to accurately profile a game. Which makes sense after all, dev tools is for debugging websites, but it also feels like a lost opportunity.

Having no idea whether my shaders will actually work on a target device was crippling to the project. Having no means to remotely debug it was even worse.

It was agreed that there are a number of existing professional tools that game developers can use such as Nvidia Nsight System and Auto tools, that could help give us the insights needed into what is going on on a per frame rendering basis, but they're incredibly difficult to use an isolation with a browser in order to tell what your game is doing.

Equally, logging data or inspecting values at runtime, especially across devices much harder than it should be. And while there is no guarantee that the same code will work equally across devices, without that, developers lose confidence dramatically. For those who want or need to persevere and try and resolve these issues, when there are next to no tools to inspect this process on a fine grained enough level to be useful, it just about finishes them off.

I personally feel this should be a pretty easy problem to resolve, ensuring that we could run a game in a browser, in a process isolated enough that Nsight could pick it up without any issue. That would go a really long way to helping resolve a decent number of these issues.

And the final section is on monetization and distribution. And rather than give you lots of quotes, I feel that I would just summarize the points that came up frequently, especially because there is no real one solution to this either. In short, developers find it really hard to make money from the web games. This is assuming that the game hasn't been built directly for a client, which is a large percentage of the work that web game developers do, contract and freelance space agency work. But for those who invest in creating a game, either on their own or as part of a studio, they find it increasingly hard to get players to them, and then get money from them once they have them.

It's ironic that the lack of a unified place in which to find web games, such as you have the iOS App Store or Steam, makes discoverability so difficult in the first place. And once the games are out there, actually earning money is really difficult too. So it forces the developers to wrap their games and bundle them in Cordova, for example, just so they can release them into an existing App store to circumvent this problem. A number of developers told me they have implemented their own technology, so often based on WebView, in order to target an App store, so they don't have to suffer the pain of the platform itself, as much as possible anyway.

Because those with big enough budgets can afford to pay for players, they can run Facebook ad campaigns, and they can get players to their games. But it's still a crying shame that the very platform that allows anyone to create anything for anyone to see, is equally the issue causing these games to never be seen. I suspect that's why, if you look at current trends, companies are targeting new platforms, such as making games inside of Messenger Apps, iOS App clips, Twitch games, basically instant to play games. It's also why I'm rebooting Phaser4 from scratch to take advantage of modern technology that will allow for tiny, tiny bundle sizes, to allow for instant downloads and instant gaming.

That is why casual play and instant play is where the market is shifting to, as opposed to long form play. However, I cannot help but feel that it's a real shame that game developers ignore the potential of the web because they cannot see a route to making money from it.

I will end with one quote, which I feel sums things up quite well.

Further improving web tech won't result in lots more devs publishing to the web. Sure there are lots of things still to be solved, but it won't move the needle on that, only good monetization options will.

This is a really interesting quote, and I think it's fundamental to actually what is the crux of the problem with a lot of developers. I mean, you have the platform which has issues and you have debugging issues, but you can push past those if you are, determined enough, but no one's gonna bother to try and do that, if they can't see a means to making money at the end of it. So I think actually solving this first before people through the harder bits of the problem which couldn't be solved with technology.