Bullet time works when the world slows down but the player still has time to move, aim, and act. Start by assigning those jobs to two clocks. Then build one enemy attack with a readable warning and one escape route. Only after the normal-speed exchange is clear should you add a small focus meter that temporarily slows enemy events.
Last Light is an original fictional design used for the calculations below. No game-creation prompt has been run, and there is no playable build or playtest to report. Treat every number as a proposed game rule, not a measured result.

Separate world time from player input
A bullet-time mechanic is easier to reason about when the project does not use one scaled clock for every action. In Last Light, worldTime controls the enemy’s wait, warning, and bolt. playerTime controls movement, aim, weapon cooldown, and the pulse fired by the player. Focus energy drains on real time. That split is the central rule: a threat can slow down without making the controls sluggish.
| System | Clock | Proposed rule | What to inspect |
|---|---|---|---|
| Drone wait and warning | World | At focus scale 0.25, one real second advances 0.25 world-seconds. | Wait and warning timers advance more slowly only while focus is active. |
| Drone bolt | World | Its 240-unit-per-world-second velocity is scaled with the world. | A full second of focus moves it 60 design units; at normal scale it moves 240. |
| Player movement, aim, and pulse | Player / real time | Movement stays 180 units per real second; a pulse travels at 400 units per real second. | Holding focus does not reduce movement or change the 0.35-second firing cooldown. |
| Focus energy | Real time | Start and cap at 2.0 seconds; drain 1.0 second for each real second Q is held. | Energy reaches zero after two real seconds, even while the world advances only 0.5 seconds. |
Keep each rule attached to one clock. If you scale a shared update loop, a player’s movement may be reduced along with the enemy’s. If you slow the enemy wait but leave the fired bolt on an unscaled timer, the warning and projectile can disagree. A short clock-ownership table gives you a first check before you add visual effects or more opponents.
Build the combat loop at normal speed
Use one opponent and one attack first. The player begins at (400, 420) in an 800-by-500 top-down arena with three health. A one-health sentry begins at (400, 80). WASD moves the player at 180 units per second; aim follows the pointer; Space fires a one-damage pulse with a 0.35-second cooldown. The pulse travels at 400 units per second. This is enough to check aiming, projectile travel, and one hit before time control enters the design.
The sentry waits 1.5 world-seconds, then shows a line toward the player’s position at the start of its warning. The line lasts 0.6 world-seconds. The sentry fires one non-homing bolt along that locked line at 240 units per world-second, then waits two world-seconds before the next warning. A bolt removes one player health on contact. These values define a readable sequence: see the line, move out of it, and return fire. The player’s shot is never slowed.
| Phase | Clock and duration | Player decision | Expected feedback |
|---|---|---|---|
| Wait | 1.5 world-seconds | Approach, aim, or hold position. | The sentry has not selected a firing line yet. |
| Tell | 0.6 world-seconds | Read the locked line and move sideways out of it. | The line stays on the original target position while the player moves. |
| Bolt | 240 units per world-second | Stay clear of the line and keep aiming. | Contact removes exactly one health; the bolt does not turn toward the player. |
| Next cycle | 2 world-seconds after the bolt | Use the opening to fire a pulse. | The sentry repeats the same tell if it is still alive. |
For the first pass, leave focus off. Check that the initial wait, warning, bolt, hit, and repeat wait occur in that order. Then add the other two one-health drones at (220, 120) and (580, 120), one at a time with a 0.5-real-second gap after each defeat. The complete loop becomes: read a locked tell, leave its lane, fire during the opening, collect one focus second from a kill, then decide where to spend it against the next sentry.
Add a bounded focus resource
Focus should buy a short decision window, not freeze the match indefinitely. In this design, holding Q drains one real-time second of energy per real second. The world scale becomes 0.25 while Q is held and energy remains. Player movement, aim, the weapon cooldown, and player pulses continue on their real-time clock. Focus starts at 2.0 seconds, cannot exceed 2.0, does not regenerate passively, and a defeated drone restores one second.
Here is the partial-warning calculation from the first tell. Let the full warning be 0.6 world-seconds. Start Q at the tell’s onset. After two real seconds, the meter is empty and the warning has advanced by 2.0 × 0.25 = 0.5 world-seconds. The remaining 0.6 − 0.5 = 0.1 world-second finishes at normal speed in 0.1 real seconds before the bolt launches. The whole tell therefore lasts 2.1 real seconds in this specific example; the full warning is not slowed at 0.25 for its entire duration.
The same meter can be divided between a tell and a projectile. For a paper-only example, hold Q for one real second during the tell: 0.25 world-seconds pass and one focus second remains. Release Q for the other 0.35 tell-seconds. When the bolt launches, hold Q for one real second. The bolt then advances 0.25 world-seconds and covers 240 × 0.25 = 60 design units, while a player pulse can cover 400 units in that same real second. This illustrates the two clocks; it is not an observed playtest.

That contrast is the design opportunity: a player can reposition or fire while a world projectile covers fewer units. Do not infer that every animation or effect is automatically attached to the correct clock. Write down the owner for each timer, then check one value on each side of focus: player distance in real seconds and world progress in the same interval.
Sequence the encounter and test edge states
Once the one-sentry exchange is understandable, let three identical sentries appear in order. Each has one health point; a player pulse removes it. After each defeat, wait 0.5 real seconds before the next sentry appears. Each kill restores one focus second, capped at two. Clearing all three while the player has health above zero wins. Reaching zero health loses. Restart restores the player’s position and health, the first sentry, all bolts and world timers, and focus energy at 2.0 seconds.
Keep these transitions explicit. A player can release Q before energy is empty, or keep holding after it reaches zero; either way, an empty meter means Q has no effect and world time is normal. If focus ends while a bolt is in flight, the remaining distance should resume at normal bolt speed. A drone kill should add only one focus second, and never push the meter above its cap. Reset should clear an old projectile rather than letting it damage the player after a new run starts.
Test one state at a time and keep the starting values fixed. Useful checks include: begin the first tell with a full meter and reproduce the 0.5/0.6 plus 0.1-second remainder above; check that a bolt moves 60 units during one focused real second while a player pulse moves 400; release Q mid-flight and confirm the bolt returns to 240 units per real second; empty the meter and verify no world slowing continues; then test one health loss, one kill reward, victory, defeat, and restart. These are proposed checks for a future build, not results from one.

| Run | Starting condition | Record | What the comparison can tell you |
|---|---|---|---|
| Normal tell | Focus off; same player and sentry positions. | Tell duration, escape, bolt contact. | Whether the warning and lane can be read without time control. |
| Partial focus tell | 2.0 energy; Q starts at the 0.6-world-second tell onset. | 0.5 world-seconds during two real seconds, then 0.1 world-second at normal speed. | Whether the player can use the extended window while retaining responsive movement. |
| Focus on bolt | 1.0 energy remains as the bolt launches. | After one real second, 0.25 world-seconds and 60 bolt units have elapsed. | Whether projectile time uses the world clock while player actions stay real-time. |
If the starting state changes between comparisons, the result becomes harder to interpret. Reuse the same positions, enemy cycle, and action sequence, changing only whether focus is active for the interval you are measuring. Record the expected state separately from what a real build actually does.
Refine a clock rule without faking a test
A useful first iteration can be shown on paper without claiming that a game was tested. In fictional v0, the player movement timer was mistakenly assigned to world time. With Q held for one real second at a 0.25 scale, the player would travel 180 × 0.25 = 45 units while the enemy clock advanced 0.25 world-seconds. In fictional v1, change only the movement clock assignment: the player travels 180 units in that real second, while the enemy still advances 0.25 world-seconds. This is a calculated design rehearsal, not an observed result or a real implementation change.
For an actual build, turn that calculation into a check: move along a clear lane for one real second with focus active, and compare player displacement with the enemy timer’s change. If either value differs from its expected clock, write the observed state, identify the first mismatch, and request one targeted correction. Rerun the dependent check before calling the change successful. Keep the paper example, unexecuted prompts, and any future playtest notes in separate categories.
Review your own result
When the clock contract is ready, describe the player, main action, and intended result in plain English. SEELE’s official Free AI Game Maker page describes a playable 2D or 3D first result that can be tested in the browser and refined with follow-up prompts. Before submitting, review the selected model, available Koin balance, and displayed generation cost. Those general capabilities do not verify this bullet-time design or guarantee that its timing rules will be implemented correctly. Inspect the result and check the focused action yourself. Free AI game maker.
Start with two clocks, one tell, one bolt, and one escape decision. Add the focus meter only when the normal-speed exchange is readable. Then use a fixed check to decide whether slowing the world creates more room for action without slowing the player’s response.
Frequently asked questions
What should slow during bullet time?
Start by slowing the world events that create the decision: enemy waits, telegraphs, enemy actions, and enemy projectiles. Keep player movement, aim, firing cadence, and player-fired shots on real time if the intended feel is responsive control during a slower threat. Treat this as a design choice to verify, not a universal rule for every game.
Should the player's controls slow too?
Not in the Last Light contract. The player moves 180 design units per real second and fires on a real-time cooldown even while the sentry’s clock runs at 0.25. If your game is meant to make every actor feel slowed, choose that on purpose and test it separately. Do not let one shared timer make the decision accidentally.
How long should the focus meter last?
Last Light uses a fictional 2.0-second meter that drains at one second per real second and refills by one second on each sentry defeat, up to its cap. That value lets you calculate a partial warning: two focused seconds advance 0.5 world-seconds at a 0.25 scale. Tune the capacity for your intended encounter, then check whether an empty meter returns the world to normal speed.
How do I test whether the warning feels fair?
Use the same starting positions and attack cycle for each comparison. Record whether the tell was noticed, whether the player left its lane, whether the bolt hit, and whether the player could answer during the next opening. Label each measurement as a future test plan until a real build is run; a paper calculation can check timing arithmetic but cannot establish player perception or fairness.
Has Last Light been built or playtested?
No. Last Light is an original fictional design, and the v0-to-v1 clock correction is a hand-calculated rehearsal. No game-creation prompt execution, generated game, playable build, or playtest is represented in this article. The proposed values and images show a target design that a reader can evaluate in their own build, not a result already produced by SEELE.


