A physics platformer becomes easier to reason about when speed, a movable object, and a timed route each have one clear job. In this invented first room, the player accelerates along an upper lane while a shove sends a block down a parallel lane. The block presses a plate, a bridge opens, and the player carries momentum through a jump to an exit beacon. The values below form a paper model only: no prompt was run, no playable build was supplied, and nothing here is a measured result.
Build speed before the gap
Start with one sequence: run up, shove, meet the plate trigger, cross the bridge, jump the gap, and reach the beacon. Keep the player and block on separate lanes until the block reaches its stopping marker. That separation makes cause and effect visible: the player supplies momentum to the route, while the block supplies the plate contact.
Switchback Span is a fictional design exercise. Its tile counts, speeds, trigger behavior, and reset are authored assumptions for learning how to specify a route; they do not describe a real game or SEELE output. Treat the image as a visual plan for that exercise, not a screenshot.
Specify momentum and object travel
Write down the player rule and block rule separately. Here, one tile is one distance unit. From rest, the player accelerates at 3 tiles per second squared until reaching a 3-tiles-per-second cap. A single shove launches the block at a fixed 2 markers per second. The block does not inherit player speed, so the two trajectories can be checked independently.
| System | Authored rule | Visible check |
|---|---|---|
| Player run-up | Start at rest; accelerate at 3 tiles/s² to a 3 tiles/s cap across 3 tiles. | Reach the cap after 1 second and 1.5 tiles, then cover 1.5 more tiles in 0.5 second. |
| Movable block | One edge-triggered shove moves the block at 2 markers/s for exactly 3 markers. | It stops at marker 3 after 1.5 seconds, independent of player speed. |
| Plate and bridge | Plate center is marker 3. Contact opens a 6-tile bridge and starts one 5-second timer. | Contact is visible; staying on the plate does not pause or restart the timer. |
| Gap and goal | After the bridge is a 2-tile gap; the exit beacon is a visual goal. | A 1-second jump covers 2 tiles. Falling resets player, block, and bridge to their initial positions. |
The three-tile run-up takes 1.5 seconds: in the first second, distance is 0.5 × 3 tiles/s² × (1 s)² = 1.5 tiles; the next half-second at the 3-tiles/s cap covers the remaining 1.5 tiles. At the same instant, the block covers 3 markers at 2 markers per second. The two lanes therefore meet at the trigger point after the same 1.5 seconds without requiring the block to inherit or imitate the player’s acceleration.
The bridge timer begins at contact, not at the start of the run-up. Continued block occupancy keeps the plate physically pressed but cannot refresh the five seconds. This rule avoids a hidden timer loophole: if the route is too long, standing on the plate will not keep it open forever.
Write the first-room prompt
A useful prompt states the camera, object order, actions, timing, feedback, failure state, and what to inspect. It also separates assumptions from verified behavior. The following is a copyable design specification for a future build request. It has not been submitted to SEELE or another generator.
Create one original side-view physics-platformer training room called Switchback Span. Use one tile as one distance unit and a fixed camera with readable floor markers. Keep two parallel lanes visible: an upper three-tile player run-up ending at the bridge mouth, and a lower block lane with a pale ramp and a pressure plate centered at marker 3. Place one teal movable block at marker 0.
Controls: hold right to move; press one edge-triggered shove once at the start. From rest, the player accelerates at 3 tiles per second squared to a maximum ground speed of 3 tiles per second. The block travels independently at 2 markers per second for exactly three markers and stops at marker 3. Begin player movement and the shove at the same time. The player should reach the bridge mouth at 1.5 seconds, when the block presses the plate.
On plate contact, extend a six-tile bridge and start one five-second timer. Continued block occupancy does not pause or refresh that timer. After the bridge, leave a two-tile gap and place a clearly visible exit beacon on the far ledge. For the example jump, preserve 3 tiles per second for the first 0.5 seconds, then cap air speed at 1 tile per second for the next 0.5 seconds. Landing at the beacon is the goal; it is not a respawn checkpoint. Falling resets player, block, and bridge to the original state. To retry, shove the block clear, then press it onto the plate again.
Return the control list, the state sequence, and a compact verification table. Check that the run-up covers 3 tiles in 1.5 seconds; the block covers 3 markers in 1.5 seconds; plate contact starts a single five-second timer; the bridge spans six tiles; the two-tile jump takes one second; the landing occurs before timer expiry; continued plate occupancy does not extend the timer; and a fall restores the full starting state. Do not add combat, portals, upgrades, checkpoints, extra rooms, or other trigger objects.After a first result exists, check the contract rather than asking whether the room merely “feels realistic.” If the block reaches the plate early, inspect its independent speed and marker count. If the player misses the mouth, inspect acceleration and run-up length. Change one authored input at a time so the next comparison has an interpretable cause.
Diagnose the block and the player separately
Keep observations blank until there is a real build to inspect. The table is a future checklist, not a report that these conditions have been tested. It helps isolate the first broken link instead of changing acceleration, block speed, plate position, and timer length together.
| If a future build shows… | Check first | Change only if needed |
|---|---|---|
| The block stops short of the plate. | Starting marker, shove trigger, and whether travel is exactly 3 markers at 2 markers/s. | Correct the block travel rule or plate marker; keep player acceleration unchanged. |
| The player reaches the mouth early or late. | Whether the player starts from rest and whether the cap applies after 1 second. | Adjust one of acceleration, cap, or run-up length, then recompute distance. |
| The bridge closes while the player is crossing. | Timer start, the 6-tile bridge distance, and the jump’s two speed phases. | Shorten the route or revise the timer only after checking the same 3-second trace. |
| The bridge stays open indefinitely. | Whether plate occupancy incorrectly pauses or refreshes the one-shot timer. | Keep the contact trigger and expiry rule explicit; do not add an occupancy reset. |
| A fall leaves the block or bridge in place. | Reset state for player position, block position, plate, and bridge. | Restore all three objects to the stated starting arrangement together. |
This diagnosis is about authored rules and future observations, not a universal physics-engine recipe. Real movement depends on implementation details that this paper model does not establish. Record the relevant input and visible result before revising a real project.
Paper-check the plate position
The baseline room deliberately has one mismatch: the block travels three markers, but the plate is centered at marker 4. It stops one marker short. The single revision moves only the plate center back to marker 3. The block rule, player rule, timer, bridge, gap, and goal stay fixed. That makes this a small hand-checkable design revision, not a tested iteration.
| Paper pass | Plate center | Block stop | Route consequence |
|---|---|---|---|
| v0 baseline | Marker 4 | Marker 3 at 1.5 s | One marker of separation remains, so the plate is not reached and the bridge stays closed. |
| v1 revision | Marker 3 | Marker 3 at 1.5 s | Contact starts the five-second bridge timer as the player arrives at the bridge mouth. |
Now calculate the crossing from timer zero. Six bridge tiles at 3 tiles per second take 2 seconds. The gap jump lasts 1 second: the first half covers 0.5 × 3 = 1.5 tiles, and the second half covers 0.5 × 1 = 0.5 tile. Together that is 2 tiles. The planned crossing takes 3 seconds, so the paper route reaches the beacon 2 seconds before the bridge timer expires.
On an absolute timeline, contact happens at 1.5 seconds after the run-up starts. The player then crosses for 3 more seconds and reaches the goal at 4.5 seconds. The timer expires at 6.5 seconds, leaving the same 2-second margin. If the player falls, restart all objects. To run the route again, clear the block and press it onto the plate for a new trigger.
Where an AI game maker fits
Once the room contract is clear, a plain-English brief can describe the scene and the first action you want a playable result to demonstrate. SEELE’s official Free AI Game Maker page describes a general workflow for describing a game in plain language, reviewing a playable 2D or 3D result, and iterating in Workspace. It advises checking the selected model, available Koin balance, and displayed generation cost before submitting. That page does not verify this room’s acceleration, block travel, collision, timer, or jump rules. Treat the prompt above as a design request, then inspect any actual result and test each mechanic before relying on it.
If you want to turn a focused game brief into a starting point, try the Free AI game maker. The candidate article route is still provisional; the CTA does not mean this example has been built or tested.
Start with one readable route
Keep the first slice to a three-tile run-up, one independent shove, one plate, one timed bridge, one two-tile jump, and one visual goal. The value of this small room is not that its invented numbers are “realistic”; it is that each transition can be checked. When you build a version, record what actually happens, then change the smallest rule that explains the difference. Do not call the paper v0-to-v1 comparison a playtest or a successful generated result.
Frequently asked questions
How do I make a physics platformer easier to tune?
Give each system a separate rule and an observable check. In this example, the player uses acceleration and a speed cap, the block follows a fixed marker speed, and the plate starts a one-shot timer. Those assumptions let you identify which rule to inspect if a future build misses its timing, instead of changing several values at once.
Does the paper v1 prove the route works in a game?
No. It only shows that the authored distances and speeds add up on paper: the run-up and block both take 1.5 seconds, while the bridge and jump use 3 of the 5 timer seconds. No prompt run, playable build, collision check, or playtest was supplied. A real implementation still needs to be built and observed.
Why does the block travel independently from the player?
That is a deliberate teaching simplification. It makes the block’s three-marker stop depend on one rule, 2 markers per second for 1.5 seconds, while the player’s run-up depends on acceleration and a cap. A more complex game could couple object motion to force, friction, or mass, but this example does not model those systems.
What if the plate stays pressed after the bridge opens?
In this authored rule set, staying pressed does not refresh or pause the one-shot five-second timer. The bridge retracts at expiry even if the block remains on the plate. To try again after a fall, reset the player, block, and bridge, then clear and re-press the plate to start a fresh attempt.
Does SEELE guarantee that these physics rules will work?
No. The official product page describes broad game creation and playable-result review, not a guarantee for this specific acceleration, block, trigger, or timer behavior. If you use a game maker, inspect the generated result and test controls, collisions, timing, and reset. Keep this room’s values labeled as design assumptions until you observe a real implementation.
