Measured performance

This page has measured figures only. Each table says with which class of browser and of graphics card and under which conditions it was measured, and which file of the Green Games repository it comes from. Where there is no measurement, it says so.

How it was measured#

Both series use the same procedure (pruebas/medir.mjs), on October 13, 2026, on the portal built and served on the same machine:

1. The page of each game is opened with the bot in control and seed 1.
2. The time is measured from the moment the page is requested until the match is running.
3. It is left to play for 25 seconds, or until the match ends if it ends sooner.
4. The game player's statistics are read.

The simulation always runs at 60 frames per second, whatever the screen draws: see Determinism. The frames per second in these tables are those of the drawing.

With a graphics card#

Source: capturas/medidas-gpu/medidas.json. A current desktop browser, with a visible window, on Windows. A high-end dedicated graphics card. Window of 1366 x 768, normal difficulty.

On that machine, the six measured games give between 237.4 and 239.3 frames per second, with 54 to 377 pieces. The number of pieces does not move the figure in that range.

Three more runs from the same file, with emulated conditions:

With the processor slowed down four times, what changes most is the wait until you can play: from 322 to 937 ms in Defensa del Faro. On the emulated phone, whose screen is 3x, the game player ended up drawing at a scale of 1.5.

Without a graphics card#

This is the worst case: the browser draws everything with the processor.

Source: capturas/medidas-sin-gpu/medidas.json. A current desktop browser, headless, inside a Linux container. Software drawing: with no graphics card, the processor computes every frame. Window of 1366 x 768, normal difficulty.

In four of the six games, the game player finished the run without shadows: its automatic quality setting turns them off when the drawing cannot keep up. Even so, two games stay at 36 and 37 frames per second, with slow frames of 67 ms.

The same three emulated conditions, without a graphics card:

What to take away#

• The games' script weighs almost nothing. In the 18 runs of the two files, the script spends between 0.048 and 0.109 ms per frame. The limit is 4 ms on average: the game that spends the most uses less than 3% of that cap.
• What decides the frames per second is the drawing, not the simulation. With the same match and the same script, Isla Taller goes from 239.3 frames per second with a graphics card to 36.0 without one.
• Loading takes fractions of a second on the same machine. Between 310 and 356 ms until you can play with a graphics card; between 464 and 624 ms without one. These figures do not include the download over the internet: the portal was served locally.

What is not measured#

• A real phone. There is only emulation.
• A modest desktop computer with an integrated graphics card. The two series are the extremes: a high-end dedicated card and none.
• The launcher and the editor. The figures are from the portal in a browser. The launcher and the editor use the same game player inside the system's WebView (on Windows, Linux and macOS), and there are no measurements made with this procedure there.
• The newest game types. The two series measure six games of the catalog, all of them third person. For 2D, isometric, first-person and split-screen games there are no figures with a graphics card yet.
• The open world. Open Valley, the seventh game of the catalog, is not in these two series: there are no figures here for a game with cube terrain. In those games the game player shortens the draw distance if the machine cannot keep up and lengthens it again: Open world.
• The download over the internet. The room's file weighs 4.3 MB (1.6 MB compressed with gzip), because it carries the physics engine inside. How long it takes to download depends on your connection.

The script's time limits#

The room measures how long your game's script takes in each frame and cuts it off if it goes over. The values come from packages/sdk/src/limites.ts.

A frame lasts 16.7 ms at 60 frames per second. The physics, the script and the sending of changes have to fit in that time.

All the caps for pieces, zones, lights and the rest: Limits.

What is asked of a game#

The Green Games quality checklist asks for two numbers:

The six measured games meet both: the one with the most pieces in these measurements is Laberinto de Luces, with 377, and the one that spends the most script, Copa de Bloques, with 0.109 ms.

To lower the cost of your game:

• Do not go through all the pieces on every frame. Use events (mundo.alTocar, mundo.alEntrar) and timers (reloj.cada(0.5, ...)) instead of juego.cadaCuadro for what does not change 60 times per second.
• Decoration with "fisica": "ninguna". What nobody touches needs no collision.
• Few dynamic pieces. The cap is 150 alive at once.
• Update the HUD when the data changes, not on every frame.

Next#

• Limits: the full table.
• Good practices: the whole quality checklist.
• Requirements: what computer you need to play.