Write Mini-Golf Game Prompts with a Shot You Can Check

Start with rules you can trace, not a list of features

Useful AI prompts for a mini-golf game define a small hole, the shot the player can take, how the ball reacts to an obstacle, what counts as a sink, and when the hole ends. Put those rules into a compact contract before asking for extra courses, collectibles, or menus. A single traceable shot makes missing physics and conflicting outcomes easier to spot.

This guide uses an invented solo par-3 hole called Lower Rail. Its coordinates, collision rules, and ball speeds are authored assumptions for a teaching example. The prompt templates and worked shot below were not submitted to a game generator. The example is hand-calculated; it is not a playable game, real test, or measured result.

The workflow is: bound one hole, specify the order of events, trace one shot by hand, then turn the expected states into acceptance checks. If a future prototype behaves differently, the trace gives you a concrete question to investigate.

Choose a first hole with one clear decision

“Make a mini-golf game” leaves the first build open to many interpretations. For this fictional slice, the player starts at S=(1,2) and aims for a cup at C=(7,2). A solid divider blocks the direct line, but a lower cushion leaves a possible bank route. The challenge is to choose enough shot speed to reach the cup without entering it too fast.

These are design choices for the example, not standard mini-golf rules. Keep each prompt scoped to one question: first the hole layout, then the shot contract, then a worked state, then acceptance checks.

Prompt 1: bound the first slice

Design a fictional solo mini-golf prototype plan for one flat par-3 hole. Place the ball at S=(1,2) and the cup center at C=(7,2). Add one solid divider that blocks the direct route and one lower cushion that can support a single bank. The goal is to sink within three strokes. Exclude wind, spin, moving obstacles, water, extra clubs, multiplayer, and course progression. Return the playable space, the player's first choice, visible success/failure states, and unresolved design questions. Do not invent a larger game mode.

Check that the answer describes one understandable hole, a player action, and a visible result. If it adds a tournament or course editor before the shot is defined, move that system to a later prompt.

Write the shot, bank, and cup rules in order

A shot prompt needs an event order as well as a target. For this invented model, coordinates are measured in metres from the lower-left of the green. Treat the rendered ball as a sphere of radius 0.10 m and calculate its centerline. The divider occupies 3.5≤x≤4.5 and 1.0≤y≤5.0. A lower cushion follows the ball-center contact line y=0.10. A direct ball at y=2 hits the divider near x=3.4; the ball stops there for that stroke.

Each released shot adds one stroke. The model uses constant deceleration a=1.0 m/s², with no spin or wind. At the first cushion contact, reflect the vertical component of velocity without losing speed. A second cushion contact during that stroke stops the ball instead of reflecting it again. The cup captures a ball whose center enters radius 0.25 m at speed no greater than 0.8 m/s. A faster pass continues rolling. After the third stroke reaches a stable stop without a sink, the hole is a miss; reset returns the ball to S and clears the stroke count.

All numeric values here are author-created parameters for a fictional model. They are not presented as real-world golf measurements or universal mini-golf behavior.

Prompt 2: request a mechanics contract

For the approved one-hole mini-golf slice, define the shot-resolution order using these assumptions: S=(1,2), C=(7,2), divider x=3.5..4.5 and y=1..5, lower cushion centerline y=0.10 m, constant deceleration a=1.0 m/s^2, no spin or wind, one reflected cushion contact per stroke, cup radius 0.25 m, capture speed at most 0.8 m/s, par 3. A divider contact stops the ball; a second cushion contact in one stroke also stops it. State when a stroke is spent, when the cup is checked, and when a third-stroke miss is declared. Flag ambiguities instead of inventing mechanics.

Review the output for collision order, bank limits, capture threshold, and finish timing. Words such as “before,” “at contact,” and “after the stable stop” matter: they determine whether two implementations would resolve the same shot the same way.

Hand-calculate one route and one overshoot

To trace a bank, mirror the cup across the cushion line. Reflecting C=(7,2) over y=0.10 gives C′=(7,-1.8). From S=(1,2) to C′, the vector is (6,-3.8), so the path length is √(6²+3.8²)=√50.44≈7.1021 m. It reaches the cushion halfway through the vertical change, at approximately (4.0,0.10). Where the path crosses x=3.5 and x=4.5, y is about 0.4167 m, below the divider’s lower edge at y=1.0 m.

With initial speed 3.77 m/s, stopping distance is v²/(2a)=3.77²/2=7.10645 m. At the cup center, the calculated speed is √(3.77²−2×1.0×7.1021)≈0.093 m/s. At the cup’s first-entry point, 0.25 m before its center, speed is about √(3.77²−2×1.0×6.8521)≈0.713 m/s. That is below the fictional 0.8 m/s threshold, so this hand-resolved design sinks on stroke 1.

The high-speed result uses the same reflected line. The path is about 7.1021 m to the cup and 8.00 m to the stop. After the bank point, the remaining 4.449 m of travel moves the ball along a unit direction of approximately (0.8448,0.5351), giving an endpoint near (7.7586,2.4804). These values are arithmetic under the fictional rules, not measured physics or a software test.

Prompt 3: ask for an expected-state ledger

Using only the stated Lower Rail rules, hand-calculate the 3.77 m/s bank shot and the 4.00 m/s fast bank. Show the mirrored cup, total route length, cushion point, divider clearance at x=3.5 and x=4.5, stopping distance, speed at the cup center, speed at first entry into the 0.25 m radius, and final state. For the fast shot, give the endpoint and its distance from C. Keep units on every value, carry at least four decimals before rounding, and label the output as a calculation from the supplied fictional model, not a test.

Check each value independently before using it. The mirrored target gives a route length; the deceleration equation gives stopping distance and speed; the stroke rule determines the result. If the cup-speed and stopping-point rows disagree, revise the calculation or clarify the rules before writing an implementation prompt.

Turn the expected states into acceptance checks

A prompt becomes easier to evaluate when each case names the starting state, action, and expected feedback. The checks below are proposed for a future build; they have not been run against software.

Prompt 4: request acceptance cases

Write acceptance checks for the exact Lower Rail contract. Cover: the 3.77 m/s bank sink, the direct divider stop, the 4.00 m/s fast pass and stopping point, a second cushion contact, a third-stroke stable miss, and reset. For each case return the initial ball position/velocity, stroke count before and after, contacts in order, cup-radius/speed result, final position, and visible player feedback. Use the expected values from the supplied calculation and do not claim a check has been executed.

When reviewing a later output, compare one rule at a time. If the fast bank is incorrectly captured, inspect the cup-speed threshold; if the direct shot passes through the divider, inspect collision order. A focused revision makes it easier to see which rule changed.

Refine a vague prompt without inventing a test

A vague v0 might say, “Make a mini-golf game with a tricky obstacle and a satisfying hole-in-one.” A more useful v1 would name one solo par-3 lane, the ball and cup coordinates, the divider and cushion, the deceleration assumption, the capture radius and speed, and the expected 3.77 m/s trace. It would also request a fast-pass case so the cup rule is not inferred from the successful shot alone.

This v0-to-v1 contrast is a simulated edit written for this article. Neither prompt was submitted to a model, and the revised prompt is not a returned output or verified game. Use the method to clarify a design before a future run: add one observable rule, derive the expected state, then request a comparison you could inspect.

Use product guidance within its documented scope

The current official Free AI Game Maker page describes plain-English game creation, playable 2D or 3D results, browser testing, and refinement with follow-up prompts. It says to review the selected AI model, available Koin balance, and displayed generation cost in Workspace before submitting. The prominent prompt example is a fantasy RPG; a separate starter card and FAQ mention racing. The page documents a general creation workflow, not mini-golf support, this bank-shot physics, or the Lower Rail example.

If you later try a game-making workflow, bring the bounded rules and compare any result with the expected states before expanding the scope. Inspect the obstacle collision, bank direction, cup entry speed, stroke count, and reset directly. The prompt kit here is an unexecuted design aid, not evidence of a result from SEELE.

Keep the first prompt small enough to verify

Define the hole, shot, obstacle response, cup threshold, and finish order before adding more modes. Then hand-calculate one successful bank and one fast miss. That small expected-state ledger gives a future prototype review something concrete to compare.

When you are ready to explore your own scoped game idea, use the Free AI game maker. The official page describes general game creation and review; check any future result against the rules you intend to keep.

Mini-golf prompt questions