Ein Buchhandlungs-Managementspiel wird interessant, wenn die Spielenden auswählen müssen, was sie auf Lager nehmen, bevor sie die Anfragen des Tages kennen. Beginnen Sie mit einem Laden, zwei Titeln, einer kurzen festen Warteschlange und Geld, das aus den Verkäufen übernommen wird. So entsteht eine verständliche Entscheidung: ein ausgewogenes Sortiment bestellen oder sich stärker auf den meistgefragten Titel festlegen. Das folgende Beispiel verwendet erfundene Lehrregeln für eine Papiersimulation – kein Spieltestergebnis und keinen Bericht über echte Kundschaft. Ihre erste Version benötigt weder einen vollständigen Katalog noch eine realistische Lieferkette. Sie braucht eine Bestandsentscheidung, deren Wirkung sichtbar bleibt. Die Werte sind klein, damit sich jedes Ergebnis ohne Tabellenkalkulation berechnen lässt. Das Beispiel zeigt, wie man einen Bestandsvertrag formuliert, das Kassenbuch nachvollzieht und einen kompakten Prototyp anfordert, dessen Verhalten überprüfbar ist.
Mit einer Bestandsentscheidung beginnen
Ein sinnvoller erster Tag hat vier verbundene Schritte: Anfragen lesen, Bestellung aufgeben, Kundschaft aus dem vorhandenen Bestand bedienen und das Ergebnis zur Planung der nächsten Bestellung verwenden. Die Reihenfolge ist wichtig. Kommt die Kundschaft, bevor die Spielenden den Bestand auswählen, ist die Bestellung keine Entscheidung. Werden Geld und Bestand nach jedem Verkauf zurückgesetzt, lässt sich die Kostenfolge einer Wahl nicht erkennen.
Lassen Sie für die erste Version Miete, Löhne, Rabatte, Dekorationsbewertungen, zufällige Nachfrage, Ersatzkäufe und Bestellungen mitten am Tag weg. Diese Systeme können später interessante Entscheidungen ergänzen, machen aber auch schwerer erkennbar, warum eine Person bedient oder abgewiesen wurde. Beschränken Sie den Katalog auf zwei angezeigte Titel und lassen Sie jeden Besuch genau ein Exemplar eines Titels anfragen. Bei Ladenschluss sollten die Spielenden die Anfrageliste mit Bestand und Kassenstand vergleichen können.
Einen kleinen Bestandsvertrag formulieren
Legen Sie ein festes Regelwerk fest, bevor Sie einen Build anfordern. Das folgende Beispiel Paper Lantern Books ist fiktiv. Preise und Kundenfolge wurden nur gewählt, um die Rechnung einfach nachvollziehbar zu machen; sie sind weder Marktdaten noch beobachtetes Ladenverhalten.
| Regel | Lehrwert bei Paper Lantern Books | Was die Spielenden prüfen können |
|---|---|---|
| Kassenbestand zu Beginn | 14 Münzen | Kassenstand vor der Bestellung |
| Bestellmenge und Kosten | Genau 4 Exemplare insgesamt; 3 Münzen je Exemplar | Die Bestellung kostet 12 Münzen und lässt 2 übrig |
| Angezeigte Titel | Mystery und Reise; von keinem Titel mehr als 3 Exemplare | Die vier bestellten Exemplare werden auf beide Titel verteilt |
| Verkauf und Kundenregel | Ein passendes Exemplar wird für 5 Münzen verkauft; ohne Bestand gilt die Anfrage als nicht erfüllt | Bei einem Verkauf sinkt der Bestand um eins, die Kasse steigt um 5 |
| Kundenwarteschlange | Mystery, Mystery, Mystery, Reise | Nach einer Bestandsänderung lässt sich dieselbe Folge erneut abspielen |
An diesem Tag gibt es keine weiteren Kosten oder Einnahmequellen. Das Kassenbuch bleibt dadurch geschlossen: Nach der Bestellung verändert sich der Kassenstand nur bei einem Verkauf. Eine nicht erfüllte Anfrage wird als nicht gedeckte Nachfrage erfasst, bringt aber keinen Verkauf und verringert den Bestand nicht.
Das Ausgangs-Kassenbuch nachvollziehen
Bestellen Sie zunächst zwei Mystery- und zwei Reise-Exemplare. Die vier Exemplare kosten 12 Münzen; der Laden öffnet also mit 2 Münzen. Die ersten beiden Mystery-Kundinnen und -Kunden kaufen jeweils ein Exemplar. Die dritte Mystery-Anfrage kann nicht erfüllt werden; der Besuch endet und die Anfrage wird erfasst. Der Reise-Titel wird verkauft, danach bleibt ein Exemplar auf dem Regal.
Lesen Sie das Ergebnis als Beispiel für Bestandsaufteilung, nicht als Vorhersage darüber, was echte Lesende kaufen werden. Die Warteschlange wurde im Voraus festgelegt und der Kassenstand folgt aus den gewählten Regeln. Wenn diese Annahmen sichtbar sind, kann eine andere Person die Rechnung prüfen und das Design gezielt verändern.
Den Tag mit einem verschobenen Exemplar erneut spielen
Vergleichen Sie nun eine zweite Bestellung: drei Mystery-Exemplare und eines aus der Kategorie Reise. Auch sie kostet 12 Münzen und startet daher mit 2. Behalten Sie dieselben vier Anfragen, Preise und denselben Startbetrag bei. Die ersten drei Mystery-Anfragen werden erfüllt, dann die Reise-Anfrage. Alle vier Besuche werden bedient und die vier bestellten Exemplare verkauft.
| Papierdurchlauf | Bestellung und Kosten | Kasse nach der Bestellung | Bedient / nicht bedient | Umsatz / Kasse bei Ladenschluss | Übriger Bestand |
|---|---|---|---|---|---|
| Ausgangsfall | 2 Mystery, 2 Reise; 12 Münzen | 2 | 3 / 1 | 15 / 17 | 1 Reise-Exemplar |
| Kontrollierter Vergleich | 3 Mystery, 1 Reise; 12 Münzen | 2 | 4 / 0 | 20 / 22 | Keiner |
Dies ist ein paralleler Papierdurchlauf mit demselben Startbetrag von 14 Münzen – nicht der Kalendertag nach Ladenschluss des Ausgangsfalls mit 17 Münzen. Nur die Mischung der Bestellung wurde verändert. Bei dieser erfundenen Warteschlange bleibt im Mystery-lastigen Fall kein Exemplar unverkauft und das Modell weist 5 Münzen mehr aus. Das ist eine Folge dieses Testaufbaus und weder eine gemessene Verbesserung noch die allgemeine Regel, einem Titel immer mehr Bestand zu geben.
Dem ersten Build einen vollständigen Prompt geben
Verbinden Sie Schauplatz, Startzustand, Regeln und sichtbare Prüfpunkte in einer Anfrage. Lassen Sie Implementierungsdetails offen, die Sie nicht vorgeben müssen, aber legen Sie genau fest, was nach jeder Aktion gelten muss.
Erstelle ein kleines, im Browser spielbares Buchhandlungs-Managementspiel namens Paper Lantern Books.
Verwende einen einzelnen Laden mit zwei angezeigten Titeln: Mystery und Reise. Dies ist ein
fiktiver Lehrprototyp und keine echte Ladensimulation.
Beginne jeden neuen Tag mit 14 Münzen und ohne vorhandenen Bestand. Vor der Öffnung darf
die spielende Person genau vier Exemplare insgesamt bestellen, höchstens drei Exemplare je Titel.
Jedes Exemplar kostet 3 Münzen. Lehne Bestellungen ab, die die Obergrenze von vier Exemplaren
überschreiten. Zeige Gesamtpreis und verbleibendes Geld an, bevor die Person bestätigt.
Verwende für diesen Eintagesfall die feste Kundenwarteschlange Mystery, Mystery, Mystery, Reise.
Jede Person fragt ein Exemplar an. Ist der gewünschte Titel auf Lager, wird genau ein Exemplar
entnommen und die Kasse um 5 Münzen erhöht. Fehlt der Bestand, erfasse eine nicht erfüllte Anfrage
und buche kein Geld. Biete keinen anderen Titel als Ersatz an. Ergänze weder Miete noch Löhne,
Zufallsnachfrage, Rabatte, Kreditaufnahme oder Bestellungen während des Tages.
Zeige am Ende der Warteschlange bestellte Exemplare, verkaufte Exemplare je Titel, Restbestand,
nicht erfüllte Anfragen, Verkaufserlös und Kassenstand bei Ladenschluss. Das Kassenbuch muss
mit Bestellung und Verkäufen übereinstimmen. Füge eine Neustartaktion hinzu, die 14 Münzen,
leeren Anfangsbestand, dieselbe Warteschlange und die ursprünglichen Regeln wiederherstellt.
Mache diese Prüfungen im Build sichtbar: Eine Bestellung über vier Exemplare kostet 12 Münzen
und lässt 2 übrig; eine Bestellung über fünf Exemplare wird wegen Überschreitung der Obergrenze
abgelehnt; in einem separaten Fall mit 11 Münzen wird die Bestellung für 12 wegen fehlenden Geldes
abgelehnt, ohne Kasse oder Bestand zu verändern. Eine passende Anfrage verbraucht ein Exemplar
und bringt 5 Münzen. Bei einem nicht verfügbaren Titel wird die Anfrage erfasst, aber nichts verkauft.
Führe die Bestellung 2 Mystery / 2 Reise aus und zeige 3 bediente Personen, 1 nicht erfüllte Anfrage,
1 Reise-Exemplar Restbestand und 17 Münzen bei Ladenschluss. Starte neu und führe 3 Mystery / 1 Reise
aus: Zeige 4 bediente Personen, keine nicht erfüllten Anfragen, keinen Restbestand und 22 Münzen
bei Ladenschluss. Beschreibe jede Regel, die nicht wie verlangt funktioniert; ändere die Rechnung
nicht stillschweigend.Der Prompt macht jedes Ergebnis überprüfbar, beweist aber nicht, dass ein generierter Build die Regeln korrekt umsetzt. Vergleichen Sie nach der Prüfung eines Builds angezeigte Bestellung, Verkäufe, nicht erfüllte Anfragen, Bestand und Kassenstand mit den beiden Kassenbüchern oben. Ist das Ergebnis falsch, grenzen Sie die Abweichung ein: Prüfen Sie zuerst, ob die Bestellung angenommen wurde, dann, ob ein Verkauf ein Exemplar verbraucht und fünf Münzen einbringt, und anschließend, ob der Schlussbetrag dem Restgeld plus Umsatz entspricht.
Das Kassenbuch prüfen, bevor weitere Systeme hinzukommen
- Bestellprüfung:Bestätigen Sie, dass vier Exemplare 12 Münzen kosten und vom Startbetrag 14 zwei übrig lassen. Prüfen Sie die Obergrenze von fünf Exemplaren und den gesonderten Fall mit 11 Münzen und nicht ausreichendem Bargeld unabhängig voneinander.
- Bestandsprüfung:Verfolgen Sie jede Anfrage der Reihe nach. Bei einer bedienten Person wird genau ein passendes Exemplar entnommen; eine nicht erfüllte Anfrage lässt Bestand und Kasse unverändert.
- Kassenprüfung:Zählen Sie Verkäufe, multiplizieren Sie mit 5 und addieren Sie den Erlös zu den 2 Münzen nach der Bestellung. Ausgangsfall: 17. Kontrollierter Vergleich: 22.
- Zurücksetzprüfung:Starten Sie zwischen den beiden Bestellungen neu. Prüfen Sie, dass Kasse, Anfangsbestand, Warteschlange und Regeln wieder dem Ausgangszustand entsprechen.
Stimmt der Kassenstand am Ende nicht, ändern Sie nicht mehrere Regeln gleichzeitig. Lassen Sie Warteschlange und Preise unverändert, bestimmen Sie die erste Aktion, bei der das Kassenbuch abweicht, und lassen Sie genau diese Regel korrigieren. Stimmen beide Fälle, können Sie als separate Designänderung eine neue Warteschlange ausprobieren oder Tageskosten hinzufügen – jeweils mit einem eigenen Kassenbuch davor und danach.
Den Regelvertrag in einen ersten spielbaren Entwurf übertragen
Die aktuelle Seite des SEELE Free AI Game Maker beschreibt einen allgemeinen Erstellungsablauf: eine Spielidee in Alltagssprache beschreiben, ein spielbares 2D- oder 3D-Ergebnis prüfen und im Workspace weiterentwickeln. Der Bestandsvertrag in diesem Artikel ist ein Vorschlag für eine allgemeine Erstellungsanfrage; die Seite dokumentiert keine spezielle Vorlage für eine Buchhandlung. Ein generierter Build dieses Beispiels wurde nicht geprüft. Die feste Warteschlange, Bestellobergrenzen, Verkaufsregeln und das Kassenbuch sind daher Anforderungen, die verifiziert werden müssen, und keine bestätigte Produktfunktion. Vergleichen Sie ein mögliches Ergebnis mit den beiden Papier-Kassenbüchern.
Wenn Sie eine fokussierte Spielidee beschreiben und einen spielbaren Ausgangspunkt prüfen möchten, besuchen Sie denkostenlosen KI-Spiel-Generator. Behalten Sie für die erste Prüfung dieselbe feste Warteschlange bei und ändern Sie erst dann eine Bestandsregel, wenn Sie das ursprüngliche Ergebnis nachvollziehen können.
Häufig gestellte Fragen
Wie viele Titel sollte ein erstes Buchhandlungsspiel verwenden?
Beginnen Sie mit zwei Titeln und einer kurzen Anfragewarteschlange. Das reicht aus, um die Bestellmischung sichtbar zu machen, ohne die Katalogverwaltung als zweites Problem hinzuzufügen. Nehmen Sie weitere Titel erst auf, wenn Sie jedes Exemplar vom Bestellbildschirm über die Kundenwarteschlange bis zum Bestand bei Ladenschluss nachvollziehen können.
Wie beeinflussen Kundenwünsche die Bestandsentscheidung?
Geben Sie jeder Person eine konkrete Titelanfrage und lassen Sie den verfügbaren Bestand entscheiden, ob daraus ein Verkauf wird. Erfassen Sie einen fehlenden Titel als nicht erfüllte Anfrage. Mit einer festen Warteschlange lassen sich Bestellungen leichter vergleichen, denn die Spielenden sehen, ob eine andere Bestandsmischung das Ergebnis verändert hat.
Sollte die Nachfrage im ersten Prototyp zufällig sein?
Eine feste Warteschlange ist leichter zu prüfen, solange Sie die Ladenregeln kontrollieren. Zufällige Nachfrage kann später hinzukommen, wenn Unsicherheit zur beabsichtigten Entscheidung gehört. Wenn Sie sie einführen, behalten Sie eine Möglichkeit, die Anfragen jedes Durchlaufs zu protokollieren. So lässt sich erkennen, ob ein Ergebnis durch die Bestellung oder durch eine andere Warteschlange entstand.
Was sollte ich prüfen, wenn das Kassenbuch nicht aufgeht?
Verfolgen Sie die erste Aktion, bei der der angezeigte Kassenstand von der Regel abweicht. Prüfen Sie zunächst die Bestellkosten, zählen Sie dann erfolgreiche Verkäufe und multiplizieren Sie diese mit dem Verkaufspreis. Eine nicht erfüllte Anfrage bringt keinen Umsatz. In diesem Beispiel setzt sich der Schlussbetrag aus den 2 Münzen nach der Bestellung und 15 oder 20 Münzen Verkaufserlös zusammen.
Stammen die Zahlen von Paper Lantern Books aus einem echten Test?
Nein. Es sind erfundene Lehrwerte aus einer Papiersimulation mit einer festen Warteschlange aus vier Kundinnen und Kunden. Die Rechnung veranschaulicht, wie eine andere Bestandsmischung das modellierte Kassenbuch verändert. Sie berichtet weder von einem Spieltest noch von echtem Buchhandlungsverhalten oder einem von SEELE erzeugten Ergebnis.
