Build a Bookshop Game Around Stock and Customer Demand

A bookshop management game becomes interesting when the player must choose what to stock before seeing the day’s requests. Start with one shop, two titles, a short fixed queue, and cash that carries through the sales. That gives you a decision you can explain: order a balanced shelf, or commit more copies to the title requested most often. The example below uses invented teaching rules for a paper simulation, not a playtest or a report about real customers. Your first version does not need a full catalog or a realistic supply chain; it needs one stocking choice whose effect remains visible. The values are small so you can calculate each result without a spreadsheet. It shows how to write one stock contract, follow the ledger, and ask for a compact prototype whose behavior you can inspect.

Start with one stock decision

A useful first day has four connected steps: read the requests, place an order, serve customers from available stock, and use the result to plan the next order. The order matters. If customers arrive before the player chooses inventory, stocking is not a decision; if money and stock reset after every sale, the player cannot see the cost of a choice.

For the first version, leave out rent, wages, discounts, décor ratings, random demand, substitutions, and mid-day orders. Those systems can add useful choices later, but they also make it harder to identify why a customer was served or missed. Keep the catalog to two displayed titles and let every visitor request one copy of one title. The player should be able to compare the request list with the shelf and cash at closing.

Write a small stock contract

Use a fixed rule set before asking for a build. The following Paper Lantern Books example is fictional. Its prices and customer sequence are chosen only to make the arithmetic easy to follow; they are not market data or observed shop behavior.

There are no other costs or sources of income during this day. That keeps the ledger closed: after the order, cash changes only when a book sells. A missed request is recorded as unmet demand, but it creates no sale and does not remove stock.

Follow the baseline ledger

First order two Mystery copies and two Travel copies. The four copies cost 12 coins, so the shop has 2 coins left when it opens. The first two Mystery visitors each buy one copy. The third Mystery request cannot be filled, so the visitor leaves and the request is recorded. The Travel visitor buys one copy, leaving one Travel book on display.

Read the result as a stock allocation example, not a prediction about what actual readers will buy. The queue was fixed in advance, and the cash total follows from the chosen rules. Making those assumptions visible is what lets someone else check the arithmetic and change the design deliberately.

Replay the day with one copy moved

Now compare a second order: three Mystery copies and one Travel copy. It still costs 12 coins, so it also opens with 2. Keep the same four requests, prices, and starting cash. The first three Mystery requests are filled, followed by the Travel request. All four visitors are served, and the order’s four copies sell.

This is a parallel paper replay from the same 14-coin opening state, not the calendar day after the baseline closes at 17. It changes only the order mix. Under this invented queue, the Mystery-heavy order leaves no copy unused and earns 5 more coins in the model. Treat that as a consequence of the fixture, not a measured improvement or a general rule that one title should always get more stock.

Give the first build one complete prompt

Combine the setting, starting state, rules, and observable checks in one request. Keep implementation details open where you do not need to dictate them, but be explicit about what must be true after each action.

Build a small browser-playable bookshop management game called Paper Lantern Books.
Use a single shop with two displayed titles: Mystery and Travel. This is a fictional teaching prototype, not a real shop simulation.

Start each new day with 14 coins and no existing stock. Before opening, let the player order exactly four copies total, with no more than three copies of either title. Each copy costs 3 coins. Reject an order that exceeds the four-copy cap. Show the order total and cash remaining before the player confirms it.

For this one-day fixture, use the fixed customer queue Mystery, Mystery, Mystery, Travel. Each customer requests one copy. If the requested title is in stock, remove exactly one copy and add 5 coins. If it is out of stock, record one missed request and add no coins. Do not substitute another title. Do not add rent, wages, random demand, discounts, borrowing, or mid-day orders.

At the end of the queue, show copies ordered, copies sold by title, remaining inventory, missed requests, sales revenue, and closing cash. Keep the ledger consistent with the order and sales. Include a restart action that restores 14 coins, empty starting stock, the same queue, and the original rules.

Make these checks visible in the build: a four-copy order costs 12 and leaves 2 coins; a five-copy order is rejected for exceeding the item cap; in a separate fixture with 11 coins, the 12-coin order is rejected for insufficient cash without changing cash or stock. A matching visitor consumes one copy and adds 5 coins. An unavailable title records a missed request but no sale. Run the 2 Mystery / 2 Travel order and show 3 served, 1 missed, 1 Travel copy left, and 17 closing coins. Restart, then run 3 Mystery / 1 Travel and show 4 served, no misses, no remaining copies, and 22 closing coins. Describe any rule that does not work as requested; do not silently change the arithmetic.

The prompt makes each result inspectable, but it does not establish that a generated build will implement the rules correctly. After reviewing a build, compare the on-screen order, sales, missed requests, stock, and cash with the two ledgers above. If the result is wrong, isolate the mismatch: first check whether the order was accepted, then whether a sale consumes one copy and adds five coins, then whether the closing total equals remaining cash plus sales.

Check the ledger before adding more systems

• Order check: confirm that four copies cost 12 and leave 2 from the 14-coin start. Test the five-copy cap and the separate 11-coin insufficient-cash case independently.
• Inventory check: follow each request in order. A served visitor removes exactly one matching copy; a missed request leaves stock and cash unchanged.
• Cash check: count sales, multiply by 5, and add that revenue to the 2 coins left after ordering. Baseline: 17. Controlled replay: 22.
• Reset check: restart between the two orders. Verify cash, starting stock, queue, and rules all return to the same initial state.

If the final cash does not match, do not change several rules at once. Keep the queue and prices fixed, identify the first action where the ledger diverges, and ask for that rule to be corrected. Once both fixtures agree, you can try a new queue or add a daily expense as a separate design change with its own before-and-after ledger.

Turn the contract into a first playable draft

SEELE’s Free AI Game Maker page describes a general creation workflow: describe a game idea in plain English, review a playable 2D or 3D result, and iterate in Workspace. In this article, the stock contract is a suggested brief for a general creation request; the page does not document a bookshop-specific template. No generated build for this example has been reviewed, so the fixed queue, order caps, sales rules, and cash ledger are requirements to verify, not confirmed product behavior. If you try the brief, compare any result with the two paper ledgers.

When you are ready to describe a focused game idea and inspect a playable starting point, visit the Free AI game maker. Keep the same fixed queue for the first review, then change one stocking rule only after you can account for the original result.