Looking for best solution for our needs

[rlisik]

Hello everybody,

I've been obliged to find best solution for making html5 games for our company. It'd be great if some experienced developers would advice on which direction to go.

We have a huge experience in Unity games development, but we already created around 10 games in Phaser 2 engine with WebStorm and TypeScript, but we're not fully satisfied because of the low performance of the games on mobile platforms and lack of support for optimised shaders.

Our needs are:
- Good performance on mobile platforms
- 2D (but 3D would be appreciated, majority of our projects would be 2D)
- Good support for sprite sheets (TexturePacker support would be great), sounds, particles, physics, real shaders (vertex, fragment), tweens, skeletal animations
- Layout Editor would be great
- JS ES6 or TypeScript support
- Can be commercial

[mkardas91]

If Phaser performance is not satisfying for You, then only option is vanilla js

[b10b]

Similar background.  Our approach was to avoid becoming deeply entrenched with an all-things-for-all-people-game-engine.  Instead we use an abstracted in-house framework and include discrete functionality per-project.  We then consume best in class libraries as they are needed (be they 2D, 3D, audio, particles, tweens, skeletel, services etc) - or develop proprietary functionality if required / preferred.  Likewise tooling is often discrete and relates to each library rather than an all-in-one.  All that being said, we started doing this long before there were really solid all-in-one choices - today a company-level choice would also consider recruitment and sales keywords.

[rlisik]

On 19/01/2018 at 2:51 PM, mkardas91 said:

If Phaser performance is not satisfying for You, then only option is vanilla js

I think this is not the point, Phaser 2.0 is just written very badly.
- Sprite extends so many classes, the funniest for me is Phaser.Component.Health. Why author of the framework thinks that all sprites are like organisms?
- The other thing is built-in ParticleSystem which requires all the particles to be Sprites..
- When you want to write Shaders you are forced to use filters which are very slow especially on mobile.

On 19/01/2018 at 6:16 PM, b10b said:

Similar background.  Our approach was to avoid becoming deeply entrenched with an all-things-for-all-people-game-engine.  Instead we use an abstracted in-house framework and include discrete functionality per-project.  We then consume best in class libraries as they are needed (be they 2D, 3D, audio, particles, tweens, skeletel, services etc) - or develop proprietary functionality if required / preferred.  Likewise tooling is often discrete and relates to each library rather than an all-in-one.  All that being said, we started doing this long before there were really solid all-in-one choices - today a company-level choice would also consider recruitment and sales keywords.

Thanks for the answer.  Did you start from just WebGL? Do your tools support also Canvas? If you and your colleagues would have to decide nowadays, would you choose the same option - to build own tools from scratch?

[b10b]

6 hours ago, rlisik said:

Thanks for the answer.  Did you start from just WebGL? Do your tools support also Canvas? If you and your colleagues would have to decide nowadays, would you choose the same option - to build own tools from scratch?

We started long before WebGL was a viable choice - in those days the question was DOM vs Canvas.  The advantage of decoupling the renderer from other functionality is that all such strategies are (mostly) independent so can evolve rapidly or be selected per-project.  Over time it has served us well because we are answering current questions using an established process.

To answer your other question I'd comment that we have found that value in video games are long-tail.  Therefore choices that focus on reducing longer-term frustrations are a higher priority to us than out-of-the-box productivity boosters with short-term benefits.  So, I expect we'd still have avoided becoming entrenched with any all-in-one solution if facing fresh choices today.  Your mileage may vary!

[rlisik]

On 24/01/2018 at 6:59 PM, b10b said:

We started long before WebGL was a viable choice - in those days the question was DOM vs Canvas.  The advantage of decoupling the renderer from other functionality is that all such strategies are (mostly) independent so can evolve rapidly or be selected per-project.  Over time it has served us well because we are answering current questions using an established process.

To answer your other question I'd comment that we have found that value in video games are long-tail.  Therefore choices that focus on reducing longer-term frustrations are a higher priority to us than out-of-the-box productivity boosters with short-term benefits.  So, I expect we'd still have avoided becoming entrenched with any all-in-one solution if facing fresh choices today.  Your mileage may vary!

I see. I think in our case we will have to use some engine since we're beginners in web environment, after we choose engine and see the results we can summarize pros/cons and think of creating our own technology.

After some research it seems that Pixi, Kiwi, Panda and Melon and are interesting options, but I'm uncertain about their own editor in case of Panda.

Phaser 3 seems unstable yet, but haven't tried it though.