Find the promise the game cannot fake
Caveman Taxi promises a responsive 2D helicopter moving through authored levels. Super Air Hockey promises trustworthy contact on a three-dimensional table. GridInc and BuyoutInc promise a dense management interface that stays understandable as the numbers expand. Those are architecture requirements, even though the player never calls them that.
Start by naming the interaction that must remain excellent after the prototype. If the answer is sprite movement, collisions and scene flow, a 2D game framework deserves a serious look. If the camera and space carry the experience, begin with the renderer. If the game is mostly decisions expressed through panels, lists and changing state, the browser's interface ecosystem can be the stronger foundation.
Phaser owns Caveman Taxi's moment-to-moment world
Caveman Taxi needs scene transitions, physics, animation, cameras, audio and touch input to agree on the same game clock. Phaser gives those systems a shared home. Pausing for phone rotation can stop physics, tweens, animation and audio together instead of asking unrelated libraries to imitate one lifecycle.
That convenience is valuable because the unusual part of Caveman Taxi is the flight model and route design. I want engineering attention there. Rebuilding a scene graph or asset loader would add code without giving Grug a better helicopter.
Three.js renders the room, but it does not own the rules
Three.js gives Super Air Hockey its table, venue, camera and lights. The puck simulation remains deliberately separate. It advances at a fixed 120 Hz, performs swept collision checks and returns state for the renderer to present. A dropped visual frame cannot be allowed to invent or erase a goal.
This separation matters whenever rendering and simulation have different standards of truth. The renderer may interpolate for smoothness. The match rules must remain repeatable. Choosing Three.js did not mean handing the game design to the render loop.
React works when the interface is the playfield
In GridInc and BuyoutInc, the player spends most of the session reading state and making economic choices. React is good at keeping those views consistent with a large state model. Animation supports those decisions and gives the economy a visible world.
React would be a poor reason to force the air hockey table into component state at 120 Hz. Three.js would be an expensive way to build hundreds of accessible management controls. A familiar tool is still the wrong tool when its update model disagrees with the game.
AI increases the cost of a vague architecture
An AI agent can produce competent code in any of these stacks. That makes a clear boundary more important. Without one, an agent will solve a rendering problem in the state layer, put business rules in a component, or create a second source of truth because the local change looks convenient.
I record which layer owns simulation, presentation, platform policy and saves before implementation begins. The stack then becomes a set of constraints the agents can respect. Speed comes from fewer architectural arguments, not from generating more files.
I choose the stack after naming the interaction the game cannot afford to fake. That decision has been more reliable than comparing framework feature lists.