A shopkeeper game becomes a management game when the player must decide what to stock and how much to charge before customers arrive. A small price choice can affect the number of sales, the cash available tomorrow and the items left on the shelf. Start with one product and one short day so those consequences are easy to follow.
This guide specifies a fictional potion-shop prototype and an AI-assisted build request. Its prices and customer demand are invented game rules, not evidence about real shoppers or a report of a completed game. Use the worked examples to verify the behavior of your own build.
Connect stock, price and customers
Start the player with 30 coins and no potions. Before opening, allow one purchase of six identical potions at 2 coins each. The batch costs 12 coins, leaving 18. The player then selects one of two selling prices, opens the shop and watches a fixed sequence of interested customers.
| Stage | Player action | State to show |
|---|---|---|
| Buy stock | Purchase the six-potion batch | Cash and available units |
| Set price | Choose 3 or 4 coins per potion | Selected price before opening |
| Sell | Serve eligible customers | Sales, stock and cash |
| Close | Review the day | Revenue, unsold stock and closing cash |
Each customer buys at most one potion, and a sale is possible only while stock remains. The shop cannot sell a negative number of items or collect payment for a customer already served. Make those constraints visible in both the interface and the underlying state.
Compare two fictional price choices
For this example only, define demand with a fixed table: at a price of 3 coins, six customers are interested; at 4 coins, four customers are interested. This is a deliberately simple design assumption, not a general law about how price affects demand.
| Price | Interested customers | Units sold | Revenue | Closing cash | Unsold stock |
|---|---|---|---|---|---|
| 3 coins | 6 | 6 | 18 | 18 + 18 = 36 | 0 |
| 4 coins | 4 | 4 | 16 | 18 + 16 = 34 | 2 |
In both paths, closing cash begins from 18 after purchasing the batch. Revenue counts sales only; it is not the same as the total cash balance. No rent, wages or other costs are included, and unsold potions remain in stock rather than disappearing. Under these particular numbers, the lower price earns 2 more coins and sells all six. A different demand table could reverse that result.
Describe the shop in an AI build request
Specify purchasing, price selection, customer eligibility and payment timing. SEELE's capability catalogue describes creating games from written ideas and producing coordinated 2D characters, scenes and interface elements. These are broad categories; they do not prove that this particular shop or demand system has been generated and tested.
Create an original small shopkeeper management game prototype.
Start with 30 coins and zero potions. Before opening, offer one purchase:
six potions for 12 coins total. Reject a duplicate or unaffordable purchase.
Allow the player to choose a price of 3 or 4 coins per potion before opening.
At price 3, create six interested customers; at price 4, create four.
Each customer buys at most one potion if stock remains. Each successful sale
reduces stock by one and increases cash and revenue by the selected price.
When the fixed customer sequence ends, close the day and show units sold,
revenue, unsold stock and cash. Keep unsold stock; do not add other costs.
Reject a sale when stock is zero or the customer has already been served.
Do not pay twice when the day closes. Show clear messages for blocked actions.
Restart restores 30 coins, zero stock, no price and the unopened shop.
Use original illustrated shop assets without real brand logos.Implement the purchase and sales ledger first. Add character movement and shop decoration after the quantities and cash balance match the rules. If the generated game charges for a batch twice, give the assistant the starting balance and the exact repeated action instead of requesting a complete rewrite.
Give feedback before and after a sale
Show the batch cost before purchase and the resulting stock and cash afterward. Once a price is chosen, keep it visible during the day. A customer who cannot buy because the shelf is empty should be marked unserved rather than producing a sale with negative inventory.
The close-day summary should separate starting cash, stock cost, sales revenue and closing cash. For example, the 3-coin path has 18 coins in sales revenue, but the final cash balance is 36 because 18 coins remained after the purchase. This distinction helps the player understand which number changed.
Check both price paths
- Purchase: buy one batch from 30 coins. Expect 18 coins and six potions; a second purchase should be rejected.
- Price 3: restart, buy the batch and choose 3. After six customers buy once each, expect six sold, zero stock, 18 revenue and 36 cash.
- Price 4: restart and choose 4 after purchasing. Expect four sold, two remaining, 16 revenue and 34 cash.
- Sales guard: try to sell to an already-served customer or after stock is zero. Neither action should change revenue or cash.
- Close and restart: close the day twice and confirm the summary does not pay again. Restart should restore the original cash, empty shelf and no selected price.
For a failure, provide the initial state, action and expected result. For example: “The player started with six potions. Six customers bought one each, but a seventh sale made stock negative. Reject a sale when stock is zero and leave the cash balance unchanged.” Then retest a valid final sale as well as the blocked one.
Plan a second-day inventory choice
As a hypothetical iteration, carry the two unsold potions from the 4-coin path into a second day. Suppose the player can buy another six for 12 coins and the same fixed demand table applies. Buying the batch would raise stock from two to eight and reduce cash from 34 to 22 before sales. At the 3-coin price, at most six interested customers buy, producing 18 revenue, 40 closing cash and two potions left.
That proposed rule makes a different question visible: whether to buy more stock when some inventory remains. Before comparing alternatives, decide whether the player may buy fewer than six, whether the same prices remain available and what happens to leftovers after the second day. This is a design calculation, not a tested result or a recommendation for a real shop.
Frequently asked questions
How should I choose customer demand?
For the first prototype, a small fixed table makes both price paths reproducible. Later you can add varied customer preferences or random demand, but define their inputs and keep a way to repeat a scenario. Avoid presenting a fictional demand table as real market evidence.
What happens if demand is higher than stock?
Sales stop when inventory reaches zero. Each remaining interested customer is unserved, and no additional revenue is recorded. Show the stockout so the player can consider purchasing differently on a later day instead of silently creating extra items.
Why are revenue and cash different?
Revenue is the money received from sales during the day. Cash also includes the starting balance and purchase spending in this example. Show the calculation for each separately; if you later add costs or debt, define where those changes appear in the ledger.
Should unsold items disappear at closing?
Not in the first version: remaining potions stay in stock. If you later introduce expiration or storage limits, make the timing and consequence explicit before the player sets a price. Test the next-day starting inventory against the prior day's closing balance.
Make one shelf and one price choice work
A single product, a visible purchase cost and a fixed customer sequence create a useful first shopkeeping loop. Verify cash and inventory after every action, then add new products or demand rules one at a time. Develop your own shop in the SEELE AI Creator Game Maker, then test how each addition changes the next decision. For a broader workflow, read how to create a game with AI.
