5 ms·
Oh incredible. Okay, then may be I was looking at the wrong approach all along. Are there clear HTML5 web components tied to those engines? I am thinking a con
by 2pointsomone 6y ago
Oh incredible. Okay, then may be I was looking at the wrong approach all along.
Are there clear HTML5 web components tied to those engines? I am thinking a confetti component, for example.
- 1123581321 6y agoThese engines generally don’t use the DOM; instead, they render in a canvas element and provide you a framework to deliver logic and drawing instructions to each frame before it renders. That’s an entirely web-standards-compliant approach as Canvas was meant for this. There is stock code and art out there to save you time creating in-game objects for any particular engine (my personal preference is Phaser. )
- 2pointsomone 6y agoThanks for explaining! I will check out Phaser.
- dylz 6y agoThey are not HTML5; they are totally "internals" - the only DOM involved is a <canvas> element or some WebGL element.
- 2pointsomone 6y agoThanks, dylz. I think I am not interested in high-performance graphics, so I am not sure I am fond of working only with the <canvas>, even with these abstracted game engines. I might just sit for a day to write beautiful CSS and use animeJS or something like that to go back to DOM approach of doing this.
- dylz 6y agoFWIW, I am doing something similar right now and I can tell you that making thousands of overlapping divs sucks for performance already on desktop, and is even worse on mobile. I can see why the canvas thing is in use. Most JS game engines should support firing native events of some sort, like you should theoretically have the ability to call window.confetti() from canvas-rendering game code in response to a victory screen or similar.
- 2pointsomone 6y agoThis is very useful to know, dylz. Thank you!!