Make each mowing job change the next day
To make a lawn-care business game with AI, connect four decisions: choose contracts, fit them into a daily fuel and work-slot limit, earn money and reputation, then decide whether equipment unlocks a better job. If mowing only changes the scenery, the business theme has no management loop. Start with a short service week whose rewards and constraints can be checked by hand.
The example below is a proposed game-design exercise, not an existing game, a SEELE-generated result, a business forecast, or a playtest. Its values are invented so a reader can follow every resource change before asking a game maker for a prototype.
Define a three-day service week
Call the fictional slice Greenline Week. The player starts with a level-1 mower, 0 Coins, and 0 Reputation. Each morning brings 4 Fuel and up to two work slots. Fuel covers both travel and mowing for the selected job; unused Fuel expires at the end of the day. This abstraction keeps the first decision focused on which contracts fit, without charging again for a separate driving action.
Set a finish condition before adding extra systems: after Day 3 jobs resolve, the business wins at 65 Coins or more and at least 4 Reputation. That target makes the mower upgrade matter. A high cash balance without the reputation threshold is not a win, and reaching the goal before the last day's jobs does not skip the rest of the schedule.
| Contract | Mower requirement | Fuel and slot | Reward on completion |
|---|---|---|---|
| Close Lawn | Level 1 or higher | 2 Fuel; 1 slot | 10 Coins and 1 Reputation |
| Overgrown Lot | Level 2 | 3 Fuel; 1 slot | 32 Coins and 1 Reputation |
| Blade upgrade | Between workdays | 12 Coins; no Fuel | Raises mower level from 1 to 2 for the remaining days |
One day can fit two Close Lawns exactly: 2 + 2 = 4 Fuel and two slots. An Overgrown Lot leaves one Fuel, which is not enough for another Close Lawn. The upgrade therefore changes eligibility, not the daily capacity: the player trades some early cash for access to a more valuable contract later.
Show eligibility before the player accepts a job
Place contract size, mower level, Fuel cost, payout, and reputation on the job board. A player should be able to see why a tall lot is locked while a nearby short lawn remains available. Keep the first route abstract: each listed Fuel cost already includes travel and mowing. If driving distance becomes its own choice later, split that cost deliberately instead of charging the same route twice.
Resolve a contract in a fixed order. First check that a work slot remains, then check mower eligibility, then check available Fuel. If any check fails, do not accept or charge the job. On success, spend the listed Fuel, complete the mowing action, and award Coins and Reputation. This order prevents a blocked contract from silently consuming resources.
Hand-resolve the upgrade route
Write the expected result before building. On Day 1, two Close Lawns earn 20 Coins and 2 Reputation. The player can afford the 12-Coin upgrade between workdays, leaving 8 Coins and a level-2 mower. The following ledger carries that balance forward and resets daily Fuel to 4 each morning.
| Day | Jobs | Fuel used | Coins after jobs and upgrade | Mower | Reputation |
|---|---|---|---|---|---|
| Start | None | — | 0 | Level 1 | 0 |
| Day 1 | Two Close Lawns (+20 Coins) | 4 of 4 | 20 − 12 upgrade = 8 | Level 2 | 2 |
| Day 2 | One Overgrown Lot (+32 Coins) | 3 of 4 | 40 | Level 2 | 3 |
| Day 3 | One Overgrown Lot (+32 Coins) | 3 of 4 | 72 | Level 2 | 4 |
The result clears both gates: 72 Coins is above 65, and Reputation reaches 4 after Day 3 resolves. Without buying the upgrade, the two available Close Lawns could produce at most 60 Coins in three days, so the cash gate would be missed. The hand calculation shows why the purchase matters; it does not establish that a game already implements these rules.
Turn the rules into acceptance checks
A compact test list catches edge cases that a happy-path ledger can hide. Record the starting state, action, expected resource change, and whether the day continues.
| Situation | Expected result | What it protects |
|---|---|---|
| Level-1 mower tries to accept Overgrown Lot | Blocked before acceptance; no Fuel, reward, or slot is consumed | Eligibility cannot be bypassed by the job button |
| Level-2 mower has only 2 Fuel and selects Overgrown Lot | Blocked; current Fuel and balance stay unchanged | Insufficient Fuel cannot create a negative balance |
| Two Close Lawns are completed on one day | Exactly 4 Fuel and two slots are used; rewards total 20 Coins and 2 Reputation | Resource and slot limits agree |
| One Overgrown Lot is completed with 1 Fuel remaining | That Fuel expires at day end; it does not carry into tomorrow | The next morning starts with the stated 4 Fuel |
| Day 3 jobs finish | Check both thresholds after rewards resolve; this route wins at 72 Coins and 4 Reputation | Victory timing and the two-part goal are explicit |
For a real build, compare each result against the ledger and log the state before and after a job. If a reward appears before mowing finishes, or a failed contract uses Fuel, the implementation order differs from the rules brief and needs correction.
Treat interface feedback as a hypothesis
A useful end-of-day card would show completed jobs, Fuel spent, Fuel remaining, mower level, Coins, and Reputation together. If the card showed only income, a player might not understand why one unused work slot could not fit another job. This proposed revision is a design hypothesis; no interface was built or tested for Greenline Week.
When a playable version exists, run the same three-day route and compare its displayed ledger with the expected values above. If one value differs, inspect the job resolution order before changing the payouts. A discrepancy may come from Fuel reset, upgrade timing, reward timing, or an ineligible contract consuming a slot. Change one rule at a time and record the observed result before calling the revision tested.
Take a compact rules brief to a game maker
Give a game-creation tool the player action, the resource rules, the result to inspect, and limits on scope. Ask it to expose the job board and day-end ledger, but do not assume a generated result will preserve every price or edge case. The official AI game maker page describes turning a plain-English idea into a playable first version, testing it in a browser, and refining it with follow-up prompts. It supports 2D or 3D games, offers free starter Koins, and says to review the cost before each generation.
Make a small single-player lawn-care business simulation called Greenline Week.
Core loop: choose eligible lawn contracts, fit them into daily Fuel and work-slot limits,
complete jobs, earn Coins and Reputation, then upgrade the mower between days.
Rules: start with 0 Coins, 0 Reputation, a level-1 mower, 4 Fuel per morning, and at most
two jobs per day. A Close Lawn needs level 1, costs 2 Fuel and pays 10 Coins plus 1
Reputation. An Overgrown Lot needs level 2, costs 3 Fuel and pays 32 Coins plus 1
Reputation. Upgrade from level 1 to level 2 between days for 12 Coins. Check eligibility
and Fuel before accepting a job; blocked jobs change no state. Unused Fuel does not carry.
After Day 3 rewards resolve, win only with at least 65 Coins and 4 Reputation.
Build only a job board, one playable neighborhood, contract completion, the upgrade, and
an end-of-day ledger. Do not add staff, shops, random demand, fuel purchases, or repairs.
Show the current mower level, eligible jobs, Fuel, cash, Reputation, and the reason a job
is blocked. Report any assumption that conflicts with these rules.After generation, inspect the actual gameplay and compare one contract at a time with the written checks. If the tool changes a rule or leaves behavior unclear, narrow the next request to that mismatch. The prompt above is a reusable design template, not a prompt run in SEELE and not proof that this exact game can be generated as written.
Start with one service loop
Keep the first version about contracts, daily capacity, a consequential upgrade, and a clear finish condition. Greenline Week’s hand ledger provides expected values to compare with a future build; the next step is to make your own small rule set and review the playable result against it. Review the displayed cost before each generation, test the playable first version in your browser, and use follow-up prompts to refine a specific mismatch before expanding the simulation.
Open the Free AI game maker and describe the service loop you want to explore.
Frequently asked questions
What makes a lawn-care business game different from a mowing game?
Give each completed yard a consequence for the next workday. In Greenline Week, the player weighs fuel, contract eligibility, cash, and a mower upgrade. A lawn is the setting; the business loop comes from deciding which jobs fit, what each earns, and which future contracts an upgrade opens.
How should I model route cost in a first prototype?
Start with one cost per job that combines travel and mowing fuel, then state that assumption. Greenline Week assigns each Close Lawn 2 Fuel and each Overgrown Lot 3. A later prototype can split driving from cutting if route length becomes a meaningful player choice; do not charge twice for travel.
When can the mower upgrade change the route?
Place the purchase between workdays and check that the player can afford it before the next reset. In the example, two Day 1 Close Lawns earn 20 Coins, leaving 8 after the 12-Coin upgrade. Level 2 makes Overgrown Lots available on Days 2 and 3.
What happens when a contract is ineligible?
Check mower level and remaining Fuel before accepting the contract. An ineligible attempt spends no Fuel, earns no reward, and uses no work slot because the job never starts. Showing the reason on the job board helps players distinguish a locked contract from a failed mowing action.
Was Greenline Week built or tested?
No. Greenline Week and its three-day ledger are invented teaching examples checked manually against the rules in this article. No game build, SEELE generation, lawn-care business, or player test was supplied. Treat the numbers as a design exercise and validate your own prototype when one exists.
