Phaser and larger-scale games?

[QLNEO]

This is a more open-ended question than the "how to do X" or "is there a feature X" that are frequently posted by me and pretty much everyone else around here. It's more like a discussion I want to make.

I've read more than once that Phaser is not really ideal for "big" games, instead being for these smaller browser games we're all used to. And while I can see that, what are really the impediments for games of a larger scale? Is it the amount of data the user would have to download for every load (since it would be played on browser)? In that case, would a NWjs app do good no matter the size? Or is it that Phaser is not really optimized for games containing a lot of data and would lag/break on most machines? And what would be a scale too large for Phaser? Are we talking about indie large or AAA large?

These are some of the questions I have when I'm confronted with Phaser's supposed scale limitations. While I don't have immediate plans to start a bigger project right now, I'd wish to know a bit more about this.

EDIT FOR CLARIFICATION: When I say "large scale" I mean in terms of content. Not necessarily graphics or massive multiplayer characteristics, although these may be other factors of an ambitious project and are worth discussing.

[bruno_]

By larger scale do you mean high end graphics or online for millions of users?

For high end graphics running javascript in the browser may not be there yet in terms of performance. With  WebAssembly it will get better, WebGL is also getting better, but when compared to games in other technologies it still stays behind.

For online games it depends on your servers, but for client side it will need a lot of multithreading and processing power, both things that javascript in a browser is still not optimal.

It's not really about Phaser, but javascript.

You can't compare javascript with C++ (which most AAA games are), at least for now, C++ will perform faster and consume less resources like RAM and CPU. Graphic Cards also have better performance with C/C++ apis than WebGL.

NWjs is still chromium running javascript, it may be better than running a full browser, but not much better.

Still, for indie games, Phaser may be enough. Phaser is not meant for 3D, so if you are doing a 2D game, you won't need so much graphic and processing power.

I have a mobile game made in Cordova in Phaser, and I'm pretty happy with it's performance on mobile.

[Skeptron]

Most AAA games weight at least a few gigs, so yeah it would be pretty crazy to try to do a web game with such assets. A desktop application would be better suited, which you can probably do with some Phaser converter lib. Also, most AAA games are 3D games, which Phaser does not provide. So Phaser doesn't seem to be the right fit for such games.

That said, I would love to see more ambitious games made with Phaser. There are a few that really bring hope to the framework, like Feudal Wars or Wild Terra, who are more ambitious than the average mobile game. I am also myself trying to do a competitive online game, OWN.  

If your game is in 2D, Phaser is very capable. Most often your skills will be the limitation.

 

 

 

[QLNEO]

@bruno_I meant larger scale in respect to content (e.g. a full game, like a 20-hour JRPG for example) more than anything. I wonder what's the graphical limit of Phaser as well however, even though it's 2D-only - if I'm correct, Ori and the Blind Forest uses 2D graphics. I honestly can't imagine Phaser rendering something as graphical as Ori, but I don't think anyone even tried.

[tips4design]

I don't think the game engine is the limit of how complex a game can be. You can create really complex (2D) games with nice graphics in Phaser/JavaScript which if implemented well could be even better than the same game implemented in Unity.

 

So, to answer your question, for sure you can create games with Phaser with hours/gigabytes of content and nice graphics.

[mattstyles]

Downloading huge data sets over the wire is always going to be restrictive. Of course, if you could download a minimal set of data to get going and incrementally load the rest (caching where possible, service workers stand out for this use-case) then that would help greatly. Throwing you browser-based game in to Electron, nwjs etc is going to overcome a lot of these data restrictions obviously.

Once a project gets to a certain size JS as a language starts to struggle, there are lots of things in the ecosystem to try and combat these limitations and the latest round of large JS spec changes (ES5, part of HTML5) addressed many issues with trying to build larger, more complex applications in the browser.

The browser has the same level of access to the GPU as any other program/app, so some extremely complex scenes can be rendered at 60fps in the browser if the GPU does most/all of the heavy lifting (albeit webGL is slightly outdated and, as such, will never be able to really push GPUs to their limit).

JS and the JS engine isn't the quickest so whilst you might be able to offload a load of rendering calcs to the GPU everything else is still stuck with JS execution performance. JS actually isn't terrible in terms of raw performance but when you've got complex stuff like AI, pathfinding, physics, procedural generation etc going on there is a lot of work that needs to be done quickly. JS is single-threaded (this is great, usually) so trying to harness more of the CPU is usually fruitless from the browser (as other games might get away with).

I don't think Phaser has any scale issues, the web platform does, which Phaser inherits problems from, but nothing inside Phaser will force you to 'keep it small'. I think probably all of its benefits are equally applicable for small puzzlers as they would be for large roguelikes or huge space sims (for example).

[Rudrabhoj Bhati]

Phaser is okay for large games. Problem lies in the architecture of the games. You have to properly manage the resources. Plan downloads and rendering properly. Draw what is required, download what is required, in a planned manner. A poorly constructed game would be overkill on any platform. Phaser and JS just require us to be extra careful with  the performance. Understand what performs well and what doesn't.

[pixelburp]

Phaser seems perfectly capable for making "large" games, from what little I've worked with the framework, all the moving parts you'd need seem to be there (at first glance, the only thing missing IMO is a robust way of saving / persisting game data). I think just the broader JS community isn't really geared towards game-making so there's a much smaller volume of game output, compared to what to me would be the vast majority of JS work - WebApp frameworks, plugins etc.

For me, I feel there's a fair equivalence that can be drawn between something like Phaser & the SNES / MegaDrive era: both emphasising the necessity that the engineer be aware and considerate of the hardware limitations you're building for. 3D frameworks have their own drawbacks, but from what I've seen of Unity etc., you can pretty much throw what you want into the editor and magic happens in the background (I know there's more to it than that); with Phaser you kinda need to know what you're doing, and be ready to deal with the reality that what you've done may need fine tuning in Chrome / Electron / Native app etc. Back in the heyday of 2D gaming, all the studios had to factor in the basic limitations of the SNES, PC, or whatever the game was being built for. So there's a natural learning curve that (so far) dissuades developers from diving too deeply into Phaser, but IMO it's all there and viable, just needs some creative thinking to get around the performance / upscaling issues that'll arise.

[drhayes]

I was working on a game in Phaser and I was targeting the desktop. My plan was to wrap in Electron.

Ultimately, the memory usage of Chromium before it had even loaded my game proved very restrictive (hovering between 500 and 800 megs and I hadn't even loaded music assets yet!). I made the decision to switch to love2d for my desktop game, unfortunately. The main factor in my decision was that I was using Phaser (and a browser) in a way that wasn't congruent with the browser or my goals.

Phaser's a great game engine, especially for making games that feature things that the web is *really* good at: anonymous users, free games, online play of any kind (slither.io or multiplayer or whatever). That's not a restrictive or exhaustive list, I'm just saying that not enough games for the web exemplify the ethos of the web, if that makes sense. I think that's why all those .io games (agar.io, slither.io, etc) are so popular: instant play, massive multiplayer, short attention spans.

Ultimately, outside of hard technical limitations, I think you could do whatever you want with Phaser.

EDIT: And I meant to say that the community around Phaser is really great; it should be considered a feature of the engine. Lots of skilled people hanging out on the forums and willing to help.

[rich]

On 09/09/2017 at 6:45 PM, QLNEO said:

@bruno_I meant larger scale in respect to content (e.g. a full game, like a 20-hour JRPG for example) more than anything. I wonder what's the graphical limit of Phaser as well however, even though it's 2D-only - if I'm correct, Ori and the Blind Forest uses 2D graphics. I honestly can't imagine Phaser rendering something as graphical as Ori, but I don't think anyone even tried.

Ori and the Blind Forest is all in 3D. Very clever, very smart 3D that looks like hand-painted 2D, but still 3D. That is how they get the superb detailed animation, depth and lighting effects. There's a great GDC talk on how they achieved it if you're interested, given by James Benson (one of the team, who it's worth adding worked on Fable 3 before doing Ori, so you've got some indication of the pedigree there).

Phaser is aimed specifically at building browser games, which by their nature are nearly always going to be smaller in scale compared to console / AAA releases - mostly because browsers themselves just aren't optimized for the kind of memory or GPU management that console environments provide, but also because that is what the players expect. If there was a genuine demand for AAA games in the browser this would have been solved years ago, but it never was. Equally, you need to be able to make your investment back again. It costs a lot of money to make a game with the graphical fidelity and scope of Ori. Earning it back has to be a consideration before a team would embark on such a venture.

You can make some great games, no doubt about it, and there's plenty of evidence for this. But temper expectations to meet the reality of the environment in which you're working. And it's a memory constricted, bandwidth limited, processing heavy environment that at heart is just trying to render a web page.

[pixelburp]

I think there's a lot of wriggle-room though between Browser Games & what are thought of as "AAA" games that Phaser could fit into; it doesn't feel like an either-or scenario here that Phaser is simply out of the question. The burgeoning indie side of the games industry has shown there is space for keen developers to make their mark (though arguably it's a bit of an over-saturated market now & difficult to make a splash) and often those games are made within fairly narrow budgets or technologies: Binding of Isaac was famously built with Flash to pick just one example of a popular game that used an ... unorthodox tech -  even if its own limitations forced Ed McMillen to port the game to another language. In theory, you could build a modest, low-fi, small to medium sized game in Phaser IMO, albeit with an appreciation that you'll be massaging every line of code to eek out every last drop of performance - effort vs. reward might be its own frustration there.

I definitely think there's a culture gap between Javascript developers & game programming though, one that accounts for the relatively smaller amount of JS Game Dev - technological limitations notwithstanding. Going by my own personal experiences & career, a lot of JS devs I'd know would have come to the language explicitly from web development, either via Web Design (like myself) or backend technologies such as Java or Ruby; so their general focus & areas of interest then tend towards web applications, data presentation etc. rather than anything more multimedia based. From the outset, there's a cultural base that just doesn't think of game programming.

[QLNEO]

First, thanks to you all for the insight.
 

Now, for some observations:

On 09/09/2017 at 5:45 PM, mattstyles said:

JS is single-threaded (this is great, usually) so trying to harness more of the CPU is usually fruitless from the browser (as other games might get away with).

So, service workers would come to the rescue?

On 11/09/2017 at 1:00 PM, rich said:

Equally, you need to be able to make your investment back again. It costs a lot of money to make a game with the graphical fidelity and scope of Ori. Earning it back has to be a consideration before a team would embark on such a venture.

Naturally. I'm not even thinking about doing something with that scope (or at least not with that level of graphical complexity), but thought that'd be a nice example, considering WebGL looks reasonably robust. Maybe I wouldn't do that, but I'd like to know how possible would it be for someone more prepared.

On 11/09/2017 at 1:00 PM, rich said:

browsers themselves just aren't optimized for the kind of memory or GPU management that console environments provide

What do you mean by console environments? You mean a dedicated engine or something like that?

 

Based on all your comments, if I wanted to do a large scale game, I could take some options into consideration:

• If the game's too large for the player to download every time they access the page, either use NWjs to make it a native app or try some clever new thing with having the player load previously downloaded game files directly from their pc into the browser, if that's even possible;
• Service workers to simulate threading;
• A bunch of optimizations for nasty browser behavior;
• Waiting for Nidium to mature;
• If all else fails, give up on HTML5 for bigger games and try Löve2D or something instead.

As Rich accurately stated, HTML5 is not really a platform geared towards serious gaming, so the last option seems the most viable, but it would be very sad to leave Javascript. I can learn another language if required, but I'd have to abandon the rapidly-growing Javascript ecosystem. I'm making a rhythm game of sorts, where MIDI files are converted to data to be used in the game; what if the engine I migrate to simply doesn't have something like this around? That's one of the reasons why I started this thread.

To wrap it up: Following your insights, most browser constraints appear to concern the GPU. Will games that are not particularly graphic-intensive suffer? To be more practical: would a game like, say, Nuclear Throne work well if it was made in Phaser? It does have a ton of stuff happening on screen at once, but no fancy shaders and stuff. What about the likes of Dwarf Fortress? Nearly no graphics but a crapton of data. Or what about a SNES-styled JRPG? Not graphically intensive but games like that usually have around 20 hours worth of content.

[mattstyles]

2 hours ago, QLNEO said:

If the game's too large for the player to download every time they access the page, either use NWjs to make it a native app or try some clever new thing with having the player load previously downloaded game files directly from their pc into the browser, if that's even possible;

This is a fine solution and solves loading large datasets by removing 'the wire' from the equation. Your second point relates to caching, the browser does this automatically to some degree, it is also the primary use case for service workers, see here for more details.

2 hours ago, QLNEO said:

Service workers to simulate threading;

I'm assuming this is another use-case for service workers. I've used web workers to achieve this. Aside from the very real problem that tooling and debugging is a major pain (as is simply dealing with threaded environments) there is an overload for starting and stopping web workers. As a terse example, I wanted a way to generate reasonably complex heightmaps on-the-fly on the client, given that even modest tests could take 200-300ms of blocking calls (which obviously nuke any animations, or anything else, happening in the page) I figured I'd explore web workers. The result was that my animations remained silky smooth, however, my heightmap generation shot up over 3x duration, most of that excess time being spent in starting a web worker, some in finishing up and communicating back. I was surprised at this (although it was hardly an exhaustive test) but for my trivial use-case that would have been acceptable, for more real life solutions, it probably isn't worth the hit (as an alternative, I could have requested this from a remote service and anything other than 3g network delay probably would have given better performance).

The key take-away is probably that threading isn't the magic bullet for performance and it increases the complexity of what you're doing by a huge amount.

2 hours ago, QLNEO said:

A bunch of optimizations for nasty browser behavior

If only it were so simple...

2 hours ago, QLNEO said:

Waiting for Nidium to mature

Not sure how this really helps. I don't know who backs the project but its unlikely they have the resources to mix it with the current big players in their project scope areas. As highlighted in this thread, most issues are web issues, and those issues exist because for the vast amount of users these things are important, you can't simply strip them out. It's like becoming a master at Chess and just assuming you'll be equally proficient at Go.

2 hours ago, QLNEO said:

If all else fails, give up on HTML5 for bigger games and try Löve2D or something instead.

If you're making a rhythm game the current web ecosystem sounds more than powerful enough to support what you need (although audio support is admittedly fairly poor on the web).

Rich hit on a non-technical consideration of the web platform, namely monetisation. Take a look at the mobile app stores (particularly Apples App Store as its the most mature), its only fairly recently that some games there are really very very impressive, given the (relatively) crap hardware they run on its simply incredible, but, the point is that it has taken a long time for the demand for such games to be present. I think this is so fundamental that the technical side of whether it can even be achieved is almost moot, put darkly, whats the point? Why bankrupt yourself for it?

That's a bit bleak for an ending though, I'd say that we need to think more incrementally. The web needs apps/games that continue to incrementally grow in complexity and delivery, then expectations rise, which raises demand, which raises revenue, which raises standards. So long as that growth is at a faster rate than other environments (consoles, desktop, mobile app stores) then at some point we reach a tipping point.

[rich]

I would say that yes, the browser and JavaScript ecosystem we have today could handle Nuclear Throne, Dwarf Fortress or any SNES era JRPG, on both a processing and rendering level. Assuming the developer has the skills to pull it off of course.

[pixelburp]

13 hours ago, QLNEO said:

Now, for some observations:

On 09/09/2017 at 9:45 PM, mattstyles said:

JS is single-threaded (this is great, usually) so trying to harness more of the CPU is usually fruitless from the browser (as other games might get away with).

So, service workers would come to the rescue?

I imagine you meant "Web Workers" for multithreading, but unfortunately this isn't a silver bullet solution to passing computations to other threads. JS workers don't have access to the window or document object for starters, so Phaser can't be accessed from the worker, and couldn't be cloned into the worker either as it needs window itself. There are also speed trade offs for starting / loading workers too so while they can give a performance boost for the actual calculations you want to have in another thread, the startup cost may impact performance itself.