Real Time Physics Editor: See Results As You Build

A real-time physics editor shows you the result of a physics change the moment you make it. Adjust a collider, raise the gravity, or slide down the friction, and the running simulation reacts immediately — no rebuild, no restart, no round trip through a build pipeline.

That immediacy matters more than it sounds. Physics is tuned by feel. The right amount of bounciness for a ball, the right friction for a platform, the right mass for a crate that has to feel heavy when the player pushes it — none of these come from a formula. You find them by watching objects move and nudging the numbers until the motion reads as correct. A tool that lets you nudge and watch in the same breath turns hours of trial-and-error into minutes.

This guide explains what real-time physics editing is, how the main 2D engines compare on it, the properties you actually tune, and the mistakes that make 2D physics feel wrong.

If you are new to building 2D games in general, start with our guide on how to make a 2D game without coding. For the wider tooling picture, see our overview of the best 2D game engines.

What "real-time physics editing" means#

Many 2D games run their physics through Box2D, a free, open-source 2D physics engine created by Erin Catto and first presented at the Game Developers Conference. It is the engine behind hits like Angry Birds and Crayon Physics, and it powers the 2D physics in Unity, Cocos, Phaser, and many other engines and frameworks. When you "edit physics," you are usually configuring the bodies Box2D simulates.

"Real-time" editing means the editor and the simulation share the same view. You change a value, and the object already on screen responds — it falls faster, bounces higher, or slides differently — without you leaving the editor. The alternative, common in older or heavier workflows, is the edit → build → run → observe → repeat loop: change a number, wait for a rebuild or restart, watch the result, go back and change it again. For a value you might adjust fifty times, that loop is punishing.

The payoff is the same one that makes fast preview loops valuable everywhere in game development: the number of good iterations you can do in an hour is capped by how long one iteration takes. We cover that principle in detail in our guide to game preview testing.

The objects you actually edit#

Under the jargon, 2D physics comes down to a few building blocks. Most of the "feel" of your game lives in how these are set.

Object	What it is	What it controls
Rigid body	An object the physics engine moves	Mass, velocity, how it responds to forces and collisions
Collider (shape)	The invisible geometry that actually touches things	Where contact happens; simple shapes are faster and more stable
Joint / constraint	A connection between two bodies	Hinges, ropes, springs, doors
Physics material	Surface properties applied to a collider	Friction and restitution (bounciness)

The properties you tune most often:

Property	Feels like…	Typical range and effect
Mass / density	Heaviness	Heavy bodies push light ones around on impact
Friction	Grip	High = sticky ground; near zero = ice
Restitution (bounciness)	Springiness	0 = lands dead; 1 = bounces back to the same height
Gravity	Weight of the world	Lower = floaty, moon-like; higher = heavy and fast-falling
Linear / angular damping	Air resistance	Higher = objects stop and stop spinning sooner

There is no universally correct value for any of these. A platformer wants snappy friction and low bounciness; an arcade pinball game wants the opposite. You decide by feel, and you decide faster when you can see the result immediately.

How 2D engines compare on live physics editing#

Engines differ less in what physics they simulate and more in how quickly you can see a change.

Engine	Tuning workflow	Live result?
Unity	Edit Rigidbody/Collider values in the Inspector during Play mode	Yes — but changes are discarded when you stop Play
Godot	Tune values, then run the scene in a separate window	Partial — the "Remote" tree mostly lets you inspect, not freely edit, a running scene
Construct 3	Set physics on objects, click to preview	Fast re-preview; limited editing of a running preview
GDevelop	Configure physics behavior, instant preview	Fast re-preview; parameters set before the preview runs
Egmatic	Edit colliders and physics materials in the editor	Yes — the result updates in real time, with no rebuild step

Two practical points stand out. In Unity, Play mode is a sandbox: it is the fastest way to find the right values, but anything you change is thrown away the moment you stop, so you have to note the numbers and re-enter them in Edit mode. In Godot, the running game lives in its own window, and the editor's link to it is largely read-only — live editing of a running physics scene is limited enough that embedding it in the editor remains an open feature request.

Engines that put physics tuning into the design view itself — where the object you are editing is the object already simulating — remove both friction points at once.

A practical workflow for tuning physics live#

1. Start from a sane scale. Set up your units before touching any value (more on why below). A one-meter reference helps.
2. Get one object right first. Take a single representative body — the player, a ball — and tune its mass, gravity, and damping until its fall and landing feel correct.
3. Tune surfaces next. With the body feeling right, adjust friction and restitution on the ground and walls.
4. Add interactions last. Only when a body and its surfaces feel good, bring in collisions between multiple bodies, joints, and stacks.
5. Tune at real speed. Resist the temptation to do all your tuning in slow motion. Slow-mo hides problems that appear only at the speed players actually play.

This order — body, then surface, then interaction — keeps each change isolated. If you tune ten bodies and five materials at once and something feels off, you will not know which number to blame.

Common mistakes that make physics feel wrong#

Mistake	What happens	Fix
Using pixels as units	Objects are enormous in physics terms; gravity acts weakly; everything feels slow and floaty	Convert pixels to meters with a scaling factor and keep moving objects roughly 0.1–10 m
Tuning only in slow motion	Problems that show up at real speed stay hidden	Do final tuning at the speed players will experience
Editing values in a play sandbox you can't save	Good values are lost the moment you stop (Unity Play mode)	Note values, stop, and apply them in edit mode — or use a tool that tunes in the design view
Too many or too complex colliders	Jitter, tunneling, and frame drops	Use the simplest shapes that work; combine small shapes into one where possible
Tying physics to the frame rate	Behavior changes with performance	Keep physics on the fixed timestep, independent of frames

The scale mistake deserves emphasis, because it is the single most common reason a 2D game's physics "feels off." Box2D is tuned for meters, and its documentation states plainly that it works best with moving shapes between roughly 0.1 and 10 meters — "soup cans to buses" — and that you should not use pixels as units. A 100-pixel-wide crate fed straight in becomes a 100-meter object. Gravity, sized for meters, barely budges it, and the whole world turns sluggish and floaty. A scaling factor (for example, 1 meter = 32 or 100 pixels) between your rendering and your physics world fixes this at the root.

The fixed-timestep point is the other quiet killer. Physics is simulated in fixed steps — Unity's default is 50 steps per second — specifically so the simulation stays stable and consistent regardless of frame rate. If you move physics in a per-frame update, your game will behave differently on a 60 Hz screen than on a 144 Hz one. Keep physics on the fixed update.

Conclusion#

Real-time physics editing is not a luxury feature. It is the difference between tuning by feel — the only reliable way to set bounciness, friction, and gravity — and tuning through a slow loop of rebuilds. The engine that shows you the result the instant you change a value lets you try dozens of variations where a slower one lets you try two.

When you choose a 2D engine, ask how its physics workflow handles iteration. Does it let you edit colliders and materials and watch the simulation respond without a rebuild? Does it keep your changes, or throw them away when you stop? Does it work in sane units? A tool that gets these right keeps the physics loop as fast as the rest of your iteration — and that speed is what lets a game's feel emerge at all.

For a broader look at where this fits in a 2D workflow, see our guides to visual scripting for 2D games and scene editors that streamline development.

---

Sources#

1. Box2D: the open-source 2D physics engine (Erin Catto, MIT license, presented at GDC; used in Angry Birds and Crayon Physics) — Box2D.org and Wikipedia: Box2D
2. Box2D is tuned for meters, with moving shapes best kept between 0.1 and 10 meters; do not use pixels as units — Box2D documentation and Box2D FAQ
3. Box2D features: continuous collision detection, multithreading, and SIMD optimization — Box2D on GitHub
4. Unity runs physics on a fixed timestep (Fixed Timestep, default 0.02 s) and Play-mode edits are discarded on stop — Unity Manual: Time and Fixed Timestep
5. Unity Rigidbody and Collider components for 2D physics — Unity Manual: Rigidbody
6. Godot runs the game in a separate process; embedded live editing of a running scene is an open proposal — Godot Proposal #9142
7. Fast preview loops and iteration speed in 2D development — our guide to game preview testing