Eine Lagerverwaltungsschicht mit klaren Auftragsregeln planen

Vergleichen Sie zwei Lagerfach-Zuweisungen anhand derselben sechs Aktionsschritte.

Seele Editorial TeamAktualisiert 14. November 2026

Ein Lagerverwaltungsspiel lässt sich leichter entwerfen, wenn eine Schicht sichtbaren Anfang, wenige Lagerorte und Fristen innerhalb einer kurzen Aktionsuhr hat. Beginnen Sie mit einer Figur, die ein Lagerfach zuweist, einen Karton erhält, einlagert, einen Auftrag kommissioniert und versendet. Notieren Sie danach den Zustand nach jeder Aktion, damit sich erklären lässt, warum ein Auftrag verspätet ist.

Dieses Tutorial nutzt Bluegate Fulfillment, ein originelles fiktives Lager, für eine von Hand berechnete Schicht mit sechs Takten. Das Beispiel zeigt, wie eine Zuweisung des flexiblen Fachs vor Schichtbeginn das Papierergebnis von einem auf zwei pünktliche Aufträge ändert. Es ist nur eine manuelle Designübung: Es wurde kein Prompt ausgeführt, kein spielbarer Build erstellt und es liegen weder Lager- noch Spieltestdaten vor.

Bluegate Fulfillment mit Wareneingang, Regalfächern, Auftragsboxen und flexibler B-Zuweisung.
Vor der Schicht kann die Figur das leere flexible Fach B zuweisen; Lager und Auftragsregeln im Bild sind fiktives Designmaterial.

Den Umfang auf eine Schicht begrenzen

Beginnen Sie mit einer Frage, die in einer Spielsitzung beantwortbar ist: Kann die Figur zwei Aufträge rechtzeitig durch Wareneingang, Lagerung, Kommissionierung und Versand bewegen? Eine kompakte Schicht macht die Kernschleife sichtbar, ohne Stadtwirtschaft, Mitarbeiterentwicklung oder einen riesigen Inventarkatalog zu benötigen.

Bluegate Fulfillment hat ein Wareneingangsdock, einen Bodenstellplatz, zwei Regalfächer für je eine Einheit, eine Auftragsboxposition und ein getrenntes Versandtor. Fach A enthält anfangs eine orange Einheit A. Das zweite, flexible Fach ist leer und nicht zugewiesen. Ein blauer B-Karton wartet im Wareneingang. Der Eilauftrag braucht A bis Ende von Takt 2; Standard benötigt B bis Takt 6. Fristen sind inklusiv: Versand im Fälligkeitstakt gilt als pünktlich.

In diesem ersten Modell haben Beschäftigte keine individuellen Laufwege. Jeder Vorgang kostet einen Takt, damit der Zeitplan leicht zu prüfen ist. Diese Abstraktion ist eine bewusste Designentscheidung und keine Aussage über reale Lagerarbeit. Gänge und Personalkapazität können später ergänzt werden, sobald die Grundschleife aus Bestand und Auftrag klar ist.

ElementAnfangszustandDesignzweck
Fach AKapazität 1; enthält 1 orange A-EinheitVersorgt den Eilauftrag mit kurzer Frist
Flexibles FachKapazität 1; leer und nicht zugewiesenErzeugt vor der Schicht eine Einlagerungsentscheidung
WareneingangEin blauer B-Karton wartetStartet den Wareneingangsablauf
ZwischenlagerEin Bodenstellplatz, anfangs leerHält den erhaltenen Karton vorübergehend
AufträgeEilauftrag A fällig T2; Standard B fällig T6Macht Dringlichkeit und längere Auftragskette sichtbar
SchichtuhrSechs AktionstakteBegrenzt Zeitplan und Endbedingung

Halten Sie die erste Version als deterministische Einzelschicht. Es gibt keine zufälligen Lieferungen, Verderb, Staus, Mitarbeiterfähigkeiten, Konkurrenz, Marktgeschehen oder Nachschubregeln. Das sind mögliche getrennte Designvorhaben. Zunächst sollte der Bildschirm drei Fragen beantworten: Wo liegt jede Einheit, welche Aktion kann sie bewegen und wie viele Takte bleiben bis zum Versand?

Lager- und Auftragszustand definieren

Wählen Sie den kleinsten prüfbaren Zustandsvektor, bevor Sie eine Karte zeichnen oder ein KI-Tool um einen Prototyp bitten. Verfolgen Sie aktuellen Takt, Inhalt von Fach A, Zuweisung und Inhalt des flexiblen Fachs, Zwischenlager, Wareneingang, jede Auftragsbox, Fälligkeit und Lieferstatus. Die Punktzahl ist die Zahl pünktlich versandter Aufträge, sobald die sechste Aktion abgewickelt wurde.

Lagerbestand und Auftragsstatus sollten getrennt bleiben. B anzunehmen macht es noch nicht kommissionierbar; der Karton muss in ein B zugewiesenes Fach eingelagert werden. Kommissionieren verschiebt danach eine Einheit aus dem Regal in die passende Auftragsbox. Versand ist eine eigene Aktion, die eine vollständige Box voraussetzt. So kann ein vager Befehl „Auftrag erfüllen“ keine mehreren Zustandsänderungen und Fristkosten verbergen.

AktionVoraussetzungZustandsänderung und Kosten
Flexfach zuweisenVor SchichtbeginnZulässige SKU A, B oder keine setzen; kostet keinen Takt
AnnehmenEingangskarton vorhanden und Zwischenlager leerEinen Karton vom Dock ins Zwischenlager bewegen; 1 Takt verbrauchen
EinlagernZwischenlager enthält Karton und ein passendes zugewiesenes Fach hat PlatzEinheit aus Zwischenlager ins Fach bewegen; 1 Takt verbrauchen
KommissionierenPassendes Regalfach hat Bestand und Auftragsbox braucht diese SKUEine Einheit aus dem Regal in die passende Box bewegen; 1 Takt verbrauchen
VersendenAuftragsbox ist vollständigEine Box durch das Versandtor schicken; 1 Takt verbrauchen
WartenJede noch laufende SchichtKeine Zustandsänderung; 1 Takt verbrauchen

In diesem fiktiven Entwurf verbraucht eine ungültige Aufgabe einen Takt, ändert aber weder Bestand noch Ort. Ein fehlgeschlagenes Einlagern kostet also Zeit; der Karton bleibt im Zwischenlager. Dort passt nur ein Karton hinein, daher ist kein weiterer Wareneingang möglich, bevor der erste eingelagert wurde. Direktes Kommissionieren aus dem Zwischenlager ist verboten. Legen Sie solche Randfälle vor der Umsetzung fest, sonst erfindet der Prototyp womöglich Abkürzungen, die nicht mit dem Design vergleichbar sind.

Lösen Sie Aktionen immer gleich auf: Voraussetzungen prüfen, genau einen Zustandsübergang ausführen, den Takt erhöhen und dann den Versandzeitpunkt mit der Fälligkeit vergleichen. Versand am oder vor dem Termin bringt einen Punkt; ein unfertiger oder verspäteter Auftrag bringt beim Ende von Takt 6 keinen. Neustart stellt Zuweisung, Bestand, Karton, Zwischenlager, Aufträge, Takt und Punktestand der gewählten Version wieder her.

Fach zuweisen und Wareneingang abwickeln

Wählen Sie nun die eine Variable, die das Beispiel ändern soll. Version 0 lässt das flexible Fach unzugewiesen. Version 1 weist es vor der Schicht B zu. Ändern Sie weder Fristen noch Aktionskosten, Bestandsmengen oder Uhr. So bleibt die Wirkung interpretierbar.

In Version 0 kommissioniert die Figur zuerst A in die Eilauftragsbox und versendet sie in Takt 2, also pünktlich. B wird in Takt 3 angenommen und belegt das Zwischenlager. In Takt 4 ist Einlagern blockiert, weil kein Fach B annimmt. Der Fehlschlag lässt den Karton im Zwischenlager, verbraucht aber trotzdem einen Aktionstakt. Direktes Kommissionieren daraus ist verboten, daher kann Standard im verbleibenden Zeitplan nicht abgeschlossen werden.

In Version 1 erhält der eingehende Karton durch die B-Zuweisung des flexiblen Fachs ein gültiges Ziel. Dock, Zwischenlager, Fristen und Aktionskosten bleiben gleich. Annehmen verschiebt B in Takt 3 ins Zwischenlager; Einlagern bewegt ihn in Takt 4 ins zugewiesene Fach und leert den Stellplatz. Die letzten zwei Aktionen kommissionieren und versenden Standard bis Takt 6. Der Eilauftrag wurde bereits in Takt 2 pünktlich versendet.

Fiktiver Zustand in Takt 4: Ein blauer B-Karton wird ins zugewiesene Fach eingelagert.
Am Ende von Takt 4 der fiktiven V1-Folge wird B ins zugewiesene Fach gelegt, das Zwischenlager ist frei und Standard noch offen.

Das Mechanikbild ist eine Konzeptdarstellung dieses konkreten Brettzustands: Ein blauer B-Karton wird in das bodennahe Fach eingelagert, Eilauftrag ist bereits fertig und Standard noch offen. Es ist weder Lagerfoto noch Screenshot eines generierten Spiels. Nur einen aktiven Karton zu zeigen, macht die Zuweisungsentscheidung lesbarer.

Kommissionierung und Versand vor den Fristen planen

Fristen machen die Aktionsreihenfolge wichtig. Der Eilauftrag ist in Takt 2 fällig; die ersten beiden Takte müssen also A kommissionieren und den Auftrag versenden. Verzögert sich eine Aktion, geht der Punkt verloren. Standard hat eine längere Kette: B annehmen, einlagern, kommissionieren und versenden. Bei sechs Takten bleiben nach dem Eilauftrag genau vier Aktionen.

Die Auftragsbox ist keine Abkürzung am Lager vorbei. Das Spiel erlaubt Kommissionierung erst, wenn die Einheit im passenden Regalfach liegt. So wird Einlagern sichtbar und die Zuweisung des flexiblen Fachs bedeutsam. Versucht jemand B ohne B-Fach einzulagern, sollte die Fehlermeldung den Grund nennen und B im Zwischenlager lassen; Karton nicht stillschweigend löschen oder Aufgabe als erledigt markieren.

Das Modell fasst Laufwege bewusst in die Ein-Takt-Kosten. Ergänzen Sie spätere Wegdistanzen als neue ausdrückliche Regel, zum Beispiel einen Bewegungstakt zwischen benannten Zonen. Berechnen Sie dann beide Zeitpläne neu. Fügen Sie keine verborgenen Wegkosten hinzu, nachdem die Papierfolge gezeigt wurde; sonst ist nicht erkennbar, ob der Auftrag wegen Einlagerung oder einer unangekündigten Bewegungsregel verpasst wurde.

Legen Sie außerdem fest, wie die Oberfläche Zeit vermittelt. Eine Uhr aus sechs Punkten kann verbrauchte Aktionen ohne Kleinsttext anzeigen. Geben Sie nach jedem Vorgang direkte Rückmeldung: Eingangszahl nach Annehmen, freies Zwischenlager nach Einlagern, Regalbestand nach Kommissionieren und geänderte Auftragsmarke nur nach gültigem Versand. Blockierte Arbeit braucht ein anderes Signal als eine erfolgreiche Bewegung.

V0-zu-V1-Schicht von Hand prüfen

Schreiben Sie die Folge vor dem Build auf. Jede Zeile nutzt eine Aktion und hält danach Ort von Einheiten und Auftragszustand fest. In V0 kostet fehlgeschlagenes Einlagern Takt 4; in V1 erlaubt die einzige geänderte Fachzuweisung den Erfolg. Keine Folge enthält versteckte Laufaktionen.

Version/TaktAktionFach AFlexfach BZwischenlagerAuftragsergebnis
V0 StartFlexfach nicht zugewiesenA=1Nicht verfügbarLeerEilauftrag fällig T2; Standard fällig T6
V0 T1A in Eilauftragsbox kommissionierenA=0Nicht verfügbarLeerEilbox=1
V0 T2Eilauftrag versendenA=0Nicht verfügbarLeerEilauftrag pünktlich; Punktzahl 1
V0 T3B annehmenA=0Nicht verfügbarB=1Standard wartet
V0 T4Einlagern versuchenA=0Nicht verfügbarB=1Blockiert, Takt verbraucht
V0 T5–T6Warten; Schicht endetA=0Nicht verfügbarB=1Standard verspätet; Punktzahl 1/2
V1 VorbereitungFlexfach B zuweisenA=1B-Kapazität=1LeerEinzige geänderte Variable
V1 T1A in Eilauftragsbox kommissionierenA=0B=0LeerEilbox=1
V1 T2Eilauftrag versendenA=0B=0LeerEilauftrag pünktlich
V1 T3B annehmenA=0B=0B=1Standard wartet
V1 T4B einlagernA=0B=1LeerZwischenlager frei
V1 T5B in Standard-Box kommissionierenA=0B=0LeerStandardbox=1
V1 T6Standard versendenA=0B=0LeerBeide pünktlich; Punktzahl 2/2

Version 0 kann den angenommenen Karton nicht in kommissionierbaren Bestand verwandeln, da das Flexfach keinem B zugewiesen ist. Version 1 ändert nur diese Zuweisung; ihre Aktionen lauten: A kommissionieren, Eilauftrag versenden, B annehmen, B einlagern, B kommissionieren, Standard versenden. Der letzte Versand liegt auf der inklusiven Frist Takt 6. Die fiktive Punktzahl steigt dadurch von einem auf zwei pünktliche Aufträge.

Konzeptbild zum Ende von Takt 6: Standard wird versendet; beide Aufträge sind pünktlich.
Am Ende von V1-Takt 6 wird die B-Box als einziger physischer Auftrag durchs Versandtor bewegt; Eilauftrag ist bereits abgeschlossen und beide Auftragsmarken sind grün.

In diesem dargestellten Endzustand sind Regalfächer, Zwischenlager und Auftragsboxposition leer. Alle sechs Fortschrittspunkte sind voll. Das Bild ist ein manuell gestaltetes Spielkonzept passend zur Papierfolge, kein Beleg für einen generierten Build oder versandte Aufträge.

Erste Version bauen und prüfen

Sind die Regeln klar, geben Sie einem Spielbau-Tool eine begrenzte Anfrage statt der vagen Anweisung „mach ein realistisches Lager“. Bitten Sie etwa um eine kompakte Einzelspieler-Lagerschicht mit Dock, einem Zwischenlagerplatz, zwei Regalfächern für je eine Einheit, zwei Auftragsboxen, sechs Aktionstakten und symbolischer Rückmeldung. Geben Sie Zustandsübergänge und blockiertes Einlagern an und nennen Sie die Abnahmefolge, die Sie später prüfen.

Trennen Sie Designvertrag, spätere Build-Anfrage und Prüfliste. Der Vertrag legt fest, welche Aktion welchen Zustand ändert. Die Build-Anfrage beschreibt die kleinste Szene und Interaktionen. Die Prüfliste sagt, was eine Person später tatsächlich beobachten muss. Dieser Artikel behauptet nicht, solche Prompts an ein Modell gesendet oder ein spielbares Ergebnis erzeugt zu haben; es sind vorgeschlagene Schritte für einen künftigen Versuch.

Die aktuelle Seite Free AI Game Maker beschreibt einen allgemeinen Ablauf: Spielidee in Alltagssprache formulieren, ein spielbares 2D- oder 3D-Ergebnis prüfen, im Workspace iterieren und angezeigte Generierungskosten sowie Kontooptionen kontrollieren. Sie dokumentiert weder einen lagerbezogenen Generator noch garantiert sie die Einlagerungsregeln oben. Prüfen Sie bei Nutzung eines Erstellungsablaufs das tatsächliche Ergebnis am Regelvertrag, statt dessen Befolgung anzunehmen.

Prüfen Sie bei einem späteren Build die Folge ab dem Anfangszustand. Zuweisung ändert nur die akzeptierte SKU; Annehmen verschiebt genau einen Karton ins Zwischenlager; blockiertes Einlagern bewahrt den Karton, verbraucht aber den fiktiven Takt; gültiges Einlagern leert den Stellplatz; Kommissionierung nimmt nur aus dem passenden Regal; Versand verlangt vollständige Box; Versand in Takt 6 zählt vor Ablauf der inklusiven Frist. Prüfen Sie danach den Neustart auf Zuweisung, Bestand, Aufträge, Takt und Punktestand.

Eine Regel anhand beobachteten Verhaltens ändern

Gibt es später einen echten Build, notieren Sie zuerst die Abweichung vom erwarteten Zustand: Starttakt, Fachzuweisung, Kartonort, gewählte Aktion, erwarteter Folgezustand, tatsächliche Anzeige und Beleg. „Das Lager ist verwirrend“ verrät nicht, ob Fachregel, fehlender Statushinweis oder Zeitplan das Problem ist.

  1. Erste Abweichung finden. Vergleichen Sie die Beobachtung mit der passenden Übergangszeile, bevor Sie das ganze Konzept ändern.
  2. Eine Regel benennen. Beispiele sind Voraussetzung des passenden Fachs, Zwischenlagerkapazität oder inklusive Versandgrenze.
  3. Eine gezielte Reparatur vornehmen. Bestand, Auftragsbedarf und Fristen bleiben gleich, während Sie Regel oder Rückmeldung anpassen.
  4. Betroffene Prüfungen wiederholen. Eine Änderung am Zwischenlager braucht blockierte Annehmen-/Einlagern-Fälle; eine Friständerung beide Zeitpläne.
  5. Belege korrekt kennzeichnen. Eine Papierfolge beschreibt erwartetes Verhalten. Ein Prompt ist eine Anweisung. Ein Erfolgsnachweis verlangt eine tatsächliche Beobachtung aus einem echten Lauf.

Ohne Build oder Laufnotizen bleibt jede Abnahmeprüfung unbestätigt. Machen Sie aus einer verfassten Simulation keine Behauptung, ein Prompt habe ein Spiel verbessert. Das manuelle Beispiel ist trotzdem nützlich: Es liefert der nächsten erstellenden Person einen Vergleichsmaßstab und hilft, den frühesten falschen Übergang zu finden.

Ein Lager-Spielbriefing beginnen

Ein guter erster Lagerprototyp ist ein kleiner, nachvollziehbarer Betrieb: ein eingehender Karton, eine Lagerentscheidung, zwei Aufträge und eine Schichtuhr. Der berechnete Zeitplan zeigt, wo bei einer späteren Umsetzung zuerst zu suchen ist, falls eine Frist verpasst wird. Er belegt weder reale Lagerpraxis noch, dass ein Spiel-Tool exakt dieses System erzeugt.

Für einen allgemeinen Spielbau-Ablauf können Sie den Free AI Game Makerausprobieren. Seine veröffentlichte Beschreibung nennt Prompts in Alltagssprache, ein erstes spielbares 2D- oder 3D-Ergebnis für Browser-Tests und Folgeprompts zur Iteration. Prüfen Sie vor dem Absenden Modell, verfügbares Koin-Guthaben und angezeigte Generierungskosten. Dies sind allgemeine Produktangaben; der mögliche Blog-Pfad und seine Quellenzuordnung bleiben lokale Planungswerte, bis die Route bestätigt ist.

Häufige Fragen

Was sollte das erste Lagerverwaltungsspiel enthalten?

Beginnen Sie mit einer Schicht, kleiner Karte, wenigen Lagerorten, klaren Auftragszeilen und Fristen innerhalb der Aktionsuhr. Jede Annahme, Einlagerung, Kommissionierung und jeder Versand sollte einen sichtbaren Zustand ändern. Stadtwirtschaft, Mitarbeiterentwicklung oder große Kataloge erst ergänzen, wenn sich die erste Betriebsschleife leicht erklären und prüfen lässt.

Warum muss der B-Karton vor der Kommissionierung eingelagert werden?

Nach den fiktiven Regeln darf ein Auftrag Bestand nur aus einem Regal entnehmen, das seiner SKU zugewiesen ist. Annahme verschiebt B vom Dock ins Zwischenlager, macht ihn aber nicht kommissionierbar. Erfolgreiches Einlagern bringt den Karton ins B-Fach und gibt den einzigen Zwischenlagerplatz frei.

Warum verpasst Version 0 die Standard-Frist?

V0 lässt das Flexfach unzugewiesen. Nach Annahme von B in Takt 3 ist Einlagern in Takt 4 blockiert und verbraucht dennoch eine Aktion. Da Kommissionieren aus dem Zwischenlager verboten ist, erreicht B vor Ende der sechstaktigen Schicht keinen entnahmefähigen Ort; Standard wird verspätet.

Was ändert sich in Version 1?

Nur die Zuweisung des Flexfachs vor Schichtbeginn: Es nimmt SKU B auf. Eilauftrag geht weiterhin in Takt 2; B wird in Takt 3 angenommen, in Takt 4 eingelagert, in Takt 5 kommissioniert und in Takt 6 versendet. Nach den inklusiven Fristen gelten beide fiktiven Aufträge als pünktlich.

Wurde dieses Lagerbeispiel generiert oder getestet?

Nein. Bluegate Fulfillment, Kapazitäten, Kosten, Fristen, Ergebnisse und Bilder sind fiktives Lehrmaterial. V0- und V1-Folgen wurden anhand der angegebenen Regeln von Hand berechnet. Es wird weder Prompt-Ausführung noch generierter Build, Lagerdaten, Software- oder Spieltest oder Messwert behauptet.

SEELE AI

Mach aus diesem Leitfaden ein spielbares Projekt.

Beginne mit einem klaren Briefing und entwickle es im Seele AI Workspace weiter.

Jetzt erstellen