Write Physics Sandbox Prompts Around Force, Mass, and Feedback

Specify the physics before the spectacle

A useful physics-sandbox prompt names an object’s mass, the force applied, the time and direction of that force, gravity, surface behavior, and the condition that counts as success. Keep the first scene small enough that you can compare one predicted state with what a later build actually does.

This guide uses Pocket Physics Yard, a fictional side-view test scene. Its crate, fan, and floor switch are an original paper design; the calculations are idealized and the prompt templates have not been run. No generated trajectory, playable build, engine test, or measured result is claimed. The example gives you a checkable starting point for a future prototype, not evidence about a physics solver.

The workflow is: define units and assumptions, request one interaction, compare its expected motion with the result, then change one physical variable. If the actual build differs, record the version, starting state, action, and observed contact before deciding which rule to revise.

Define one bounded test scene

Start with a single object and a single goal. Here the player positions a crate beside a fan, releases it, and tries to land it on a pressure plate. Each value matters: mass changes acceleration under the same force; the pulse duration changes horizontal travel; and the plate has a defined contact range.

Use the scene as a small rule contract, not a claim that a particular engine must behave exactly this way. A real game may include a fixed time step, collision tolerances, damping, rotation, or different switch geometry. Either specify those rules or list them as measurements to collect during a later test.

Prompt 1: state the physical contract

Design one side-view physics-sandbox test called Pocket Physics Yard. Use meters, seconds, kilograms, newtons, x to the right and y upward. The floor is y=0. A 0.2 m-wide, 2 kg blue crate starts at x=0 with its bottom at y=2.0 m and zero velocity. Gravity is 10 m/s² downward. A fan applies a constant 4 N horizontal force toward +x for exactly the first 0.5 seconds after release, then stops. The crate remains axis-aligned: apply force through its center of mass, with no torque or rotation. Ignore air drag and floor friction. On first floor contact use an inelastic landing with no bounce: vertical motion stops, horizontal speed is preserved. The pressure switch spans x=0.45–0.55 m and activates if the crate’s horizontal footprint overlaps it at contact; it does not push the crate. List initial state, force duration, assumptions, predicted observable output, and unresolved questions. Do not add extra objects or infer engine behavior not stated here.

The prompt includes the units and coordinate direction so a reader can audit the numbers. If a response invents a slope, bounce, or drag coefficient, ask whether it is an intentional rule before treating it as part of the design.

Prompt one interaction and its feedback

A first playable slice needs a small set of actions: position the crate, pulse the fan, release the object, and restart. Ask for state feedback that helps a player see what happened. The fan should visibly turn off after the specified half-second; the pressure plate should show whether contact occurred; and a reset should restore the exact start position and velocity.

Prompt 2: build one observable loop

Using the Pocket Physics Yard contract, create one playable test room and no additional level. Let the player drag the 2 kg crate to the marked release point, activate the fan, and release it. Apply the 4 N force only during the first 0.5 seconds; after the pulse ends, retain the horizontal velocity because floor friction is zero. Keep the crate axis-aligned with no torque or rotation. At first contact with y=0, stop vertical motion without a bounce and check whether the crate overlaps the x=0.45–0.55 m pressure plate. Turn the feedback lamp on only for an overlap at that first contact; do not let the plate push the crate. Show the fan pulse, crate path, switch state, and restart control. Restart must restore x=0, bottom y=2.0 m, zero velocity, fan idle, and lamp off. Return the control mapping, state variables, collision assumptions, and one trace a reviewer can repeat. Do not add ramps, extra crates, collectibles, or unsupported physics.

Keep the display useful rather than busy. One path trace and one clear target indicator can explain more than decorative speed lines. If a build exposes velocity or force, show the units; otherwise, let the visible pulse and contact response carry the explanation.

Hand-check the expected landing

Use a basic constant-acceleration estimate to make a reference state. The bottom of the crate falls 2.0 m under 10 m/s², so the ideal fall time is t = sqrt(2h/g) = sqrt(4/10) ≈ 0.632 s. The fan acts for 0.5 s, leaving about 0.132 s before first contact.

For the 2 kg case, the horizontal acceleration during the pulse is a = F/m = 4/2 = 2 m/s². In 0.5 s, the crate moves 0.5 × a × t² = 0.25 m and reaches 1 m/s. With no horizontal force or friction after the pulse, it travels another 1 × 0.132 ≈ 0.132 m. The center is therefore near x=0.382 m when the crate first touches the floor.

The 4 kg comparison keeps the scene, force, pulse, and starting height fixed. Acceleration becomes 1 m/s². The pulse covers 0.125 m and reaches 0.5 m/s; the remaining fall adds about 0.066 m. That places the center near x=0.191 m, so a 0.2 m-wide crate ends at about x=0.291 m—short of the plate.

This is an idealized calculation, not a collision-engine prediction. The crate is assumed not to rotate, the fan acts through its center of mass, and the first floor contact has no rebound. A real build may approximate these values differently. Treat the numbers as a question to test and record what the version actually does.

Revise one physical variable

If the first build misses the plate, keep the starting geometry and fan pulse fixed while changing one variable. For example, compare a 2 kg crate with a 4 kg crate under the same 4 N fan for 0.5 seconds. Then inspect the recorded path and contact point. Changing mass, pulse duration, gravity, and plate location together would make the result harder to interpret.

Prompt 3: compare mass only

Repeat the same Pocket Physics Yard trial twice from the exact reset state. Run A uses crate mass 2 kg; Run B changes only mass to 4 kg. Keep crate width, start position and height, gravity, 4 N fan direction and 0.5 s duration, no-rotation/no-torque assumption, inelastic no-bounce landing, frictionless horizontal motion, and switch bounds fixed. For each run, return time to first floor contact, horizontal center position, crate right edge, whether the x=0.45–0.55 m plate overlaps at contact, and the lamp state. Separate predicted values from observed game values. If a value is not exposed by the build, say what should be logged instead of guessing. Do not add another design change.

The design expectation is that the 2 kg case overlaps while the 4 kg case misses. That expectation comes from the stated equations, not an executed prompt. If a real result disagrees, preserve the run and inspect force timing, coordinates, mass units, collision footprint, and time step before changing the objective.

Check the boundaries before adding objects

Once the central action is clear, try cases that should differ for an explicit reason. These are proposed checks for a future build, not tests that have already been performed.

The shorter-pulse estimate is another paper calculation: after 0.25 s at 2 m/s², the crate has moved 0.0625 m and reaches 0.5 m/s. The remaining 0.382 s adds about 0.191 m, placing the right edge near 0.354 m. As with the main trace, a real build must be measured before calling this its behavior.

Carry the physics brief into a creation workflow

The official Free AI Game Maker page describes a general workflow: describe a game in plain English, generate a playable 2D or 3D first version, test it in a browser, and refine it with follow-up prompts. It offers free Koins and asks creators to review the cost before each generation. Those broad facts do not validate Pocket Physics Yard, its values, or any generated physics behavior.

When you take your own experiment into a game workflow, specify what the player controls, what force is applied, what response should be visible, and how to reset. Review the actual object motion and collision state after generation. A concept image or ideal equation can clarify a question, but neither proves that a build follows it.

Turn one interaction into a repeatable test

Name the units, starting pose, force, duration, gravity, contact rule, and target before adding more objects. Then compare one predicted state with a recorded run and revise a single variable at a time. That gives a physics sandbox a clear first interaction—and gives you a way to tell what changed when it behaves differently.

To shape your own experiment, continue with the Free AI game maker. Bring a small action, expected response, and reset condition, then inspect the returned result against those rules.

Physics sandbox prompt questions