Stage is a minimalistic 2D, cross-platform HTML5 game engine

iPhone 11 and I'm getting what looks like 15-30 fps

People don’t give web browser engines enough credit sometimes. WebGL performs wonderfully. 2D Canvas performs very well. Even hardware accelerated transforms on DOM elements perform damn near flawlessly even on slow devices.

Unfortunately almost every web site out there does a poor job of showcasing those abilities.

Strange, my old Thinkpad t460 starts blowing fans all over. Running this in firefox.

After playing it for 15 minutes my desk appears to move in the opposite direction of the balls, I wonder what causes that?

I have no idea what game you are talking about?

Agreed, this is basically just a glorified draw list, nowhere near a "game engine".

Is there even a spatial index for accelerating collision detection?

In the days where writing 500 lines of C code just to draw an untextured triangle are advertised as the future, something like this does look like an engine to me, even if relatively simple.

That's right, it's only rendering and layout library.

Itch.io has free or very inexpensive assets. Also opengameart.org has free assets.

Just came across this one today, looks promising: https://skirmish.io/

That's a typical quality of game engines, they just blast the whole screen away. If their design is similar to CreateJS' they likely walk the tree and reduce it to a flat array of Canvas instructions. I imagine reconcilling with a cache structure is expensive for whatever reason.

It takes a bunch of effort to keep track of which nodes need to be redrawn (and in which areas of the screen).

If you end up needing to redraw most (or all) of the screen anyway, that effort is wasted. The overhead of it can even end up slowing things down.

Just assuming everything needs to be redraw from the start saves the effort, and is optimal in the case where everything does need to be redrawn.

For games in particular, this is usually a good assumption. If you're wrong, you end up slowing down less complex cases but they can usually afford it. When you're right, you're optimal for the most demanding cases. You're usually trying to hit a frame rate and care a lot more about hard cases falling below the target than how far above target easy cases are.

And there are many common cases in games where you do need to redraw everything anyway. E.g., once you start scrolling or any other kind of full-screen effect. (In the old, pre-PGU days you often actually would scroll the image in a buffer and only redraw newly the exposed area through the scene graph, but there's really not an advantage to that these days and doesn't help you with any other kind of full screen effect.)

Games typically need to redraw the entire screen anyways. Imagine a sidescroller where even a 1px movement requires the entire background and every object on top to be redrawn, or in 3D even a tiny camera move shifts the position of every triangle on the screen. Even very simple games without a lot of movement often have animations, where you then have to worry about transparency so you may have to redraw the region under the animated element anyways even of it doesn't move, etc. You could do a diff hoping for the happy occasion of a mostly-static frame, but a) that gives a performance penalty to the majority of frames that would need a total or near-total redraw anyways, and b) would lead to either unstable FPS or pointlessly hitting the FPS cap.

There are exceptions to this, for example a visual novel or a turn-based strategy game, but those are often satisfied to just eat the performance penalty for the ability to use standard tooling, or can use engines or standard UI toolkits like React that can do a temporal diff. For example, I've written several text-based games [1] that just use the DOM because using canvas or WebGL wasn't necessary. I've written other games that use a hybrid approach of absolutely-positioning temporally diffed DOM over a frame-by-frame redrawn canvas, to get the best of both worlds [2]. And I've also written games in e.g. Unity where it's easier and performant enough to use ImGui and redraw it every frame. Ultimately it cones down to what's practical and what's performant enough.

[1] https://vgel.itch.io/themengi , https://vgel.itch.io/the-sacred-text [2] https://vgel.me/hoverator

You won't need to write C++

mobile and desktop devices, because although html is supposed to already be cross platform, in theory, when it comes to games you have to make some assumptions about whether a user is using a mouse or a touch screen or a keyboard, specific screen sizes, testing on obscure browsers running linux and old versions of gecko and things start to break

That is a 7 year old laptop cpu.

(Also if the demo is single threaded and not frame rate capped it probably eats as much of a single core as it can, and that's a dual core cpu so 50% checks out)