Space Economy — System-Design
Das datengetriebene Rückgrat deines Sci-Fi-Rohstoff-&-Produktionsspiels: eine Datenbank, die wächst, indem du Stichworte hineinwirfst, und die ich pflege.
🎴 Karten-Ansicht öffnen Wie füttere ich es?1 · Vision in einem Absatz
Im Universum sind alle dem Menschen bekannten Rohstoffe verteilt — auf Planeten, Monden, Asteroiden, in Gaswolken und Kometen. Der Spieler baut sie mit Schiffen, Fahrzeugen und Maschinen ab, verarbeitet sie über realistische Ketten zu Maschinen, Tech und Infrastruktur, und skaliert damit den nächsten Abbau. So realistisch wie möglich, solange es spielerisch bleibt. Diese Datenbank ist der „Bauplan-Katalog" dahinter: Was existiert, woraus besteht es, wie wird es gewonnen, welche Maschinen braucht man — alles als ein durchsuchbarer, verlinkter Produktionsgraph.
2 · Der Ingestion-Loop
Das ist das Herzstück, das du grob skizziert hast — hier voll ausformuliert. Jedes Stichwort, das du mir gibst, läuft durch genau diese Schritte. Verzweigt etwas (Unterprodukte, Maschinen), wird der Loop für jeden Zweig rekursiv neu gestartet, bis alles bei rohen Rohstoffen endet.
- Eingang & Normalisierung. Du gibst ein Stichwort ein (z.B.
Stahl). Ich normalisiere es (Akzente/Schreibweise) zu einem eindeutigen slug. - Gibt's das schon? Automatischer Dubletten- & Ähnlichkeits-Check: exakter Name, bekannte Aliasse und unscharfer Vergleich (fängt Tippfehler wie „stal" → Stahl). Treffer melde ich dir, statt blind ein Duplikat anzulegen.
- Rohstoff oder Produkt? Ich entscheide (und begründe): Kommt es roh aus der Welt → Rohstoff. Wird es aus etwas anderem gemacht → Produkt.
- Stammdaten anlegen. Kategorie (metal, gas, alloy, machine …), Tier (Veredelungsstufe), Aggregatzustand, eine kurze Beschreibung und ein Realismus-Anker (das echte Vorbild).
- Bei Rohstoff → Vorkommen + Abbau. Wo taucht es auf (Planet/Asteroid/Gaswolke …) und wie häufig? Dann bis zu 3 gamifizierte Abbaumethoden mit Trade-offs (siehe §4) und den nötigen Abbaumaschinen.
- Bei Produkt → woraus besteht es? Ich lege die Stückliste an (welche Unterprodukte/ Rohstoffe in welcher Menge). Besteht es aus Unterprodukten? → für jedes Unterprodukt, das es noch nicht gibt, starte ich denselben Loop von vorn (Rekursion).
- Wie wird es hergestellt? Gibt es mehrere reale Verfahren, teile ich sie in bis zu 3 spielbare Varianten auf (z.B. billig-langsam / Recycling / sauber-teuer) — jede mit eigenen Inputs, Maschinen und Dials.
- Maschinen erfassen. Jede Maschine, die ein Prozess braucht, wird ein eigenes entity. Existiert es noch nicht, lege ich es als Stub an (Platzhalter) und es kommt selbst durch den Loop — denn auch Maschinen werden ja aus Rohstoffen gebaut.
- Nebenprodukte. Realistische Prozesse werfen Abfall/Koppelprodukte ab (Schlacke, Gase …). Die erfasse ich, weil sie oft anderswo wieder zum wertvollen Input werden — das macht die Wirtschaft glaubwürdig und verzahnt.
- Abbruch & Rückmeldung. Der Zweig endet, wenn er bei reinen Rohstoffen (Tier 0) ankommt. Danach regeneriere ich den HTML-Katalog und fasse dir zusammen, was neu/geändert ist und welche Stubs noch auf Ausbau warten.
3 · Datenmodell (SQLite)
Alles steckt in space_economy.db. Sieben Tabellen, bewusst schlank gehalten:
| Tabelle | Wofür |
|---|---|
entities | Der Katalog. Jeder Rohstoff & jedes Produkt genau einmal (Name, Art, Kategorie, Tier, Beschreibung, Realismus-Anker, Status). |
aliases | Alternativnamen/Schreibweisen — treibt den „Gibt's das schon?"-Check. |
occurrences | Wo ein Rohstoff vorkommt (Ort + Häufigkeit). Realismus & Verteilung. |
processes | Wie man ein entity bekommt: Abbau oder Herstellung. Bis zu 3 Varianten je entity, je mit den Trade-off-Dials. |
process_inputs | Die Stückliste: welche entities ein Prozess verbraucht. Hier verzweigt der Loop. |
process_machines | Welche Maschinen ein Prozess braucht (Maschinen = entities → Rekursion). |
process_byproducts | Nebenprodukte/Koppelprodukte eines Prozesses. |
machine_spec | Betriebs-Eckdaten einer Maschine: wer bedient sie (Mindest-Skill-Tier × Anzahl Worker), Platzbedarf. |
operation_inputs | Laufender Verbrauch im Betrieb (Strom, Heißluft, Kühlwasser …) — hängt an der Maschine, nicht am Rezept. |
families | Bauteil-Familien (Schablonen wie „Sechskantschraube") + parametrisches Basis-Rezept. |
family_axes / family_axis_values | Die Parameter-Achsen einer Familie (Gewinde, Länge, Material …) und ihre erlaubten Werte. |
variant_params | Die gewählten Achsen-Werte einer konkreten Varianten-entity (z.B. M6 · 30 mm · Edelstahl). |
building_spec | Gebäude-Parameter: flexible Größe (min/max), skalierende Kosten, Maschinen-Kapazität. |
building_modules | Umweltabhängige Pflicht-Module (Thermalschild, Druckkuppel …), bedingt auf Planet/Klima. |
Neue Spalten in entities: mass_kg, volume_l, phys_unit
(Physik, §10). Neue Spalten in processes: worker_min_tier, worker_count,
duration_h (Aufbau-Crew & Dauer, §11), rate_per_hour (Durchsatz, §12)
sowie der neue process_type='installation'.
| Tabelle | Wofür |
|---|---|
worker_spec | Akku-/Energie-Profil eines Roboter-Workers (Kapazität, Leistung, Ladezeit → Endurance, §12). |
config | Globale Konstanten (Schichtlänge, Schichten/Tag) — von der Engine gelesen. |
packaging | Transportgebinde eines Produkts (Stück/Gebinde, Tara, Volumen) — die Handels-/Transporteinheit (§13). |
storage_spec | Lager-Parameter (zuweisbares Volumen, Kosten, nutzbarer Anteil, §14). |
storage_conditions / storage_requirements | Was ein Lager bereitstellt ↔ was ein Produkt braucht (Kühlung, Kryo, Druck, Gefahrgut … §14). |
Zusätzlich trägt jedes Worker-entity in entities.skill_tier seine Fähigkeits-Stufe (1–5).
Lesbar bleibt es über schema.sql (kommentiert) und die generierte
Karten-Ansicht. Gepflegt wird ausschließlich über db.py — das
garantiert, dass der Dubletten-Check immer läuft und nichts inkonsistent reinrutscht.
4 · Gamification-Dials
Mehrere reale Verfahren werden zu spielbaren Varianten — der Unterschied steckt in fünf Reglern, jeweils 1 (niedrig) bis 5 (hoch). Sie sind später direkt die Stellschrauben fürs Balancing.
| Dial | Bedeutung |
|---|---|
| Tempo | Durchsatz — wie schnell die Variante liefert. |
| Kosten | Kapital + laufende Input-Kosten. |
| Ausbeute | Wie effizient (wenig Abfall, hohe Reinheit). |
| Energie | Strom-/Hitzebedarf — koppelt an deine Energie-Infrastruktur. |
| Komplexität | Tech-/Infrastruktur-Hürde — wie spät im Spiel man rankommt. |
5 · Tiefe & Tiers
Du hast „tief bis zum Rohstoff" gewählt. Tier markiert die Veredelungsstufe:
Tier 0 = roher Rohstoff (Abbruchpunkt der Rekursion), jede Verarbeitungsstufe +1.
Ketten laufen typischerweise über 5–8 Stufen bis ganz unten.
├─ Roheisen T2
│ ├─ Eisenerz T0
│ ├─ Koks T1 ─ Kokskohle T0
│ ├─ Kalkstein T0
│ └─ Sauerstoff T0
├─ Stahlschrott T0
└─ Mangan T0
6 · Stub-Mechanik (gegen Explosion)
Wenn ein Produkt 5 Maschinen braucht und jede Maschine wieder 8 Teile, würde ein einziges Stichwort sofort hunderte Knoten aufmachen. Deshalb: Referenzierte, aber noch nicht ausgebaute entities werden als Stub angelegt — sie existieren im Graphen (verlinkt, zählbar), warten aber auf ihren eigenen Loop-Durchlauf. So bleibt jeder Schritt überschaubar, und du entscheidest, welchen Zweig wir als Nächstes vertiefen.
7 · Maschinen-Modell: Bauen · Betreiben · Bedienen
Komplexe Maschinen haben drei völlig verschiedene Bedarfs-Arten. Sie zu trennen ist der Schlüssel, damit die Stubs nicht explodieren und das spätere Balancing klare Hebel hat:
| Bedarfs-Art | Was | Wo in der DB | Kosten-Charakter |
|---|---|---|---|
| ① Bauen | Baugruppen/Stückliste (Stahlmantel, Auskleidung, Gebläse, Steuerung …). Jede Baugruppe ist ein eigenes entity → rekursiv bis zum Rohstoff. | processes (manufacture) + process_inputs | einmalig (Investition) |
| ② Betreiben | Laufender Verbrauch beim Arbeiten: Strom, Heißluft, Gas, Kühlwasser. Echte entities → koppeln an Kraftwerke/Versorgung. | operation_inputs | laufend (pro Charge/Stunde) |
| ③ Bedienen | Roboter-Worker mit Mindest-Skill-Tier × Anzahl. | machine_spec | Personal/Auslastung |
Explosions-Bremse: Beim Aufnehmen einer Maschine baue ich nur eine Ebene tief aus (Maschine → ihre direkten Baugruppen + Betrieb + Worker). Jede Baugruppe wird ein Stub und kommt erst dran, wenn du diesen Zweig vertiefen willst.
8 · Skill-Tiers & Roboter-Worker
Arbeit wird von Roboter-Workern erledigt — und die sind selbst eine Produktlinie: gebaut aus Chassis, Aktuatoren, Sensorik, KI-Kern und Energiezelle. Der KI-Kern bestimmt das Skill-Tier. Es gilt eine simple, mächtige Regel:
worker_min_tier
≤ seinem eigenen skill_tier ist. Höhere Tiers sind teurer, aber vielseitiger.Das erzeugt Progression ganz von allein: früh stellst du viele billige Tier-1-Bots an Hochöfen und Bagger; später brauchst du teure Tier-5-Spezialisten für Fusionsreaktoren und KI-Kern-Fertigung. Die 5-stufige Leiter:
| Tier | Worker | Bedient typischerweise |
|---|---|---|
| T1 | Bediener-Bot | Hochofen, Bagger, Steinbruch, Förderband |
| T2 | Techniker-Bot | Kokerei, Pelletierung, Konverter, Raffinerie |
| T3 | Facharbeiter-Bot | Elektrolyse, Direktreduktion, Schmelzwerk |
| T4 | Ingenieur-Bot | Werft, Orbital-Lift, Maschinen-Montage |
| T5 | Spezialist-Bot | Fusionsreaktor, KI-Kern-Fertigung, Forschung |
Die Maschinen→Tier-Zuordnung oben ist der Startvorschlag; sie wird je Maschine konkret
in machine_spec.worker_min_tier gesetzt, sobald die Maschine den Loop durchläuft.
9 · Parametrische Bauteil-Familien (Fein-Granularität ohne Explosion)
Echte Fertigung braucht tausende Schrauben-, Nieten-, Blech-, Rohr- und Kabel-Varianten — jede Größe/Material/Norm zählt, weil Maschinen genau bestimmte Teile verlangen. Diese Fein-Nachfrage wollen wir bewusst abbilden. Sie alle von Hand anzulegen wäre aber unmöglich. Lösung wie in der echten Industrie: nicht jedes Teil einzeln, sondern eine Familie + Achsen + Varianten.
| Begriff | Bedeutung | Beispiel |
|---|---|---|
| Familie | Schablone mit gemeinsamem Bauprinzip & parametrischem Rezept. | „Sechskantschraube" |
| Achsen | Die Parameter, in denen sich Varianten unterscheiden. | Gewinde · Länge · Material · Beschichtung |
| Variante | Eine konkrete Kombination = ein normales entity (steckt im Graphen). | „M6×30, Edelstahl A2, verzinkt" |
Jede Variante erbt das Familien-Rezept und skaliert mit ihrer Größe (Materialmenge ∝ Gewinde²×Länge).
Realistisch entsteht eine Schraube aus Draht:
Schraube ← Stahldraht ← Stahl ← Roheisen ← Eisenerz (5 Stufen tief, automatisch).
Warum das die Fein-Nachfrage erzeugt
Unterschiedliche Maschinen verlangen unterschiedliche, exakte Varianten — und genau das ist der gewünschte Detailgrad, der eine eigene Zulieferkette für Verbindungselemente rechtfertigt:
| Verbraucher | verlangt | Warum |
|---|---|---|
| Hochofen (Montage) | M24×100 Stahl 8.8, 5000 Stk | Schwerlast-Struktur einer Großanlage |
| Roboter-Montage | M3×10 Titan, 120 Stk | leicht, antimagnetisch, Präzision für Robotik |
Dieselbe Mechanik trägt später Bleche (Material/Dicke/Format), Rohre (Ø/Wandstärke), Kabel
(Querschnitt/Isolierung), Lager, Dichtungen — alles über families/variant_params.
10 · Physik: Masse & Volumen (nichts bewegt sich magisch)
Jedes entity — Rohstoff, Produkt, Maschine, Schraube — trägt zwei physikalische Werte, damit Transport und Bewegung real simuliert statt magisch geschehen:
| Feld | Einheit | Wofür im Spiel |
|---|---|---|
mass_kg | kg (je phys_unit) | Lastgrenzen von Fahrzeugen/Frachtern & Reisegeschwindigkeit (schwer = langsamer) |
volume_l | Liter (1000 L = 1 m³) | Lade-Kapazität von LKW/Shuttle/Tanker (passt es rein?) |
phys_unit | Stk / t / m³ … | Bezugseinheit, auf die sich Masse & Volumen beziehen |
11 · Gebäude & Installation
Fabrikation vs. Installation — zwei verschiedene Akte
Bisher beantwortete ein Prozess „woraus wird es gebaut". Jetzt unterscheiden wir, wie es entsteht:
| Typ | Bedeutung | Beispiel |
|---|---|---|
manufacture | In einer Halle/Fabrik gefertigt und transportierbar ausgeliefert. | Schraube, Bediener-Bot, Baugruppe |
installation 🏗 | Zu groß zum Transport → vor Ort errichtet aus angelieferten Baugruppen. Braucht Crew + schweres Gerät + Material + Zeit. | Hochofen, Produktionshalle |
Ein installation-Prozess trägt zusätzlich Crew (worker_min_tier ×
worker_count) und Dauer (duration_h). Beispiel Hochofen-Errichtung:
12× Ingenieur-Bot (Tier ≥ 4), Schwerlastkran + 8 Montage-Drohnen, 1200 t Beton fürs Fundament, ~90 Tage.
machine_spec = wer die
fertige Maschine im laufenden Betrieb bedient · installation-Crew = wer sie
einmalig aufbaut · die Prozess-Maschinen = welches Gerät beim Aufbau hilft.Produktionshallen — spielergebaut, flexibel groß
Auf Planetenoberflächen baut der Spieler Produktionshallen, die Maschinen beherbergen. Sie sind
ein Gebäude-entity mit building_spec:
- Freie Größe. Der Spieler wählt das Innenvolumen (z.B. 2.000–200.000 m³). Modular in 1.000-m³-Schritten errichtet — beliebige Größe = N Module.
- Skalierende Kosten. Kosten ∝ Größe, mit Exponent > 1 (große Hallen werden pro m³ teurer) — ein bewusster Trade-off zwischen „eine Riesenhalle" und „mehrere kleine".
- Maschinen-Kapazität über Volumen. Nur ein Teil (z.B. 70 %) ist nutzbar (Rest = Wege,
Versorgung). Eine Maschine passt rein, wenn ihr
volume_lin die Restkapazität passt — hier greift die Physik aus §10 direkt. - Umwelt-Pflichtmodule je Standort. Je nach Planet/Klima braucht die Halle Zusatz-Module:
🔥 Hitze → Thermalschild ❄ Kälte → Kryo-Isolierung
Vakuum → Druckkuppel ☢ Strahlung → Strahlenschutz.
Sie sind eigene entities; die Bedingung (
condition) matcht später den konkreten Standort.
12 · Zeit, Schichten & Fertigung (der Kern-Loop)
Das Zeitmodell
Die Spielzeit läuft in einem festen 24h-Format mit 3 Schichten à 8h — unabhängig vom
lokalen Tag/Nacht-Zyklus des Planeten. Diese Konstanten stehen in config und gelten global.
Fertigungsauftrag (FA) — die Regeln
- Ort. Jede Produktionshalle nimmt FAs an, sofern die nötigen Maschinen darin stehen.
- Voraussetzungen je Schicht. Ein FA startet eine Schicht nur, wenn Maschine + Material + Workforce vorhanden sind.
- Alles-oder-nichts. Fehlt zu Schichtbeginn irgendetwas, steht die Produktion die ganze Schicht (kein Teil-Output). Das macht Logistik-Planung zur Kern-Herausforderung.
- Output. Läuft der FA, entsteht am Schichtende eine feste Menge des Produkts.
Durchsatz — wie viel pro Schicht?
Output je Schicht = rate_per_hour × Schichtstunden × aktive Linien.
Die Maschinen-Kapazität (rate_per_hour) und die Anzahl aktiver Linien bestimmen
also gemeinsam die Stückzahl — genau wie gewünscht.Beispiel M24×100-Bolzen: 1.800 Stk/h × 8 h × 3 Pressen = 43.200 Stück je Schicht (129.600/Tag).
Roboter-Energie: deckt der Akku eine Schicht?
Jeder Worker hat ein Akku-Profil (worker_spec): Kapazität, Leistungsaufnahme, Ladezeit.
Daraus folgt die Endurance = Kapazität ÷ Leistung. Entscheidend: Reicht sie für eine 8h-Schicht?
Und wie viele Bots braucht eine Station für 24/7-Dauerbetrieb?
| Tier | Akku | Leistung | Endurance | Laden | Bots für 24/7 |
|---|---|---|---|---|---|
| T1 Bediener | 12 kWh | 1,5 kW | 8,0 h | 2,0 h | 2 / Station |
| T2 Techniker | 16 kWh | 1,8 kW | 8,9 h | 2,0 h | 2 / Station |
| T5 Spezialist | 36 kWh | 3,2 kW | 11,3 h | 3,0 h | 2 / Station |
Ein Bot schafft pro Tag nur ⌊24 ÷ (8 h Schicht + Ladezeit)⌋ Schichten — bei ~2h Laden also 2. Für 3 Schichten Dauerbetrieb braucht eine Station daher ~2 Bots in Rotation. Das Laden zieht Strom (≈ Leistung × 8 h je Bot/Schicht) und koppelt so an dein Energienetz.
Logistik je Schicht
Jeder FA braucht pro Schicht eine Antransport- und eine Abtransport-Einheit: Antransport füllt das Material für die nächste Schicht auf, Abtransport schafft die fertigen Produkte weg (Lager/Versand). Wie viel sie tragen müssen, ergibt sich automatisch aus Output × Physik (§10):
| M24-Auftrag (3 Linien) | Masse | Volumen |
|---|---|---|
| Antransport: Stahldraht | 17,3 t | 2,2 m³ |
| Abtransport: 43.200 Bolzen | 19,4 t | 2,6 m³ |
python report_shift.py "Produktname" <Linien>
liefert genau diese Schicht-Bilanz (Output, Material, Workforce inkl. Akku/Bots, Logistik) für jedes Produkt.13 · Verpackung & Gebinde (die handelbare Einheit)
Man bewegt nicht „43.200 lose Schrauben", sondern Gebinde: Kisten, Paletten, Fässer, IBCs,
Drucktanks, Gasflaschen, Coils. Jedes Produkt bekommt deshalb eine oder mehrere Verpackungen
(packaging). Ein Gebinde legt fest:
| Feld | Bedeutung |
|---|---|
units_per_pkg | Wie viele Produkt-Einheiten in einem Gebinde stecken |
tare_kg | Leergewicht der Verpackung (Brutto = Inhalt × Stückmasse + Tara) |
volume_l | Außenvolumen des gepackten Gebindes — das zählt für den Laderaum |
pkg_type | crate · pallet · drum · ibc · tank · gas_cylinder · bulk_container · coil … |
Ein Produkt kann mehrere Gebinde haben (eines ist is_default = Standard-Handelsgebinde).
Sauerstoff z.B. wahlweise als „O2-Druckflaschen-Palette" oder „Kryo-Tank LOX" — verschiedene Gebinde,
verschiedene Lageranforderungen.
Behälter sind selbst Produkte
Jeder Behälter (Stahlkiste, Palette, IBC, Drucktank, Kryotank, Gasflasche, Big-Bag, Spule, ESD-Box,
Tankcontainer …) ist ein eigenes, klickbares Produkt mit voller Kette bis zum Rohstoff
(z.B. IBC ← Kunststoff + Stahl ← … ← Erdöl/Eisenerz). packaging.container_id
verweist auf das Behälter-entity; seine Masse = Tara, sein Volumen = Außenmaß.
packaging)
bekommen selbst keine Verpackung — sie werden lose, gestapelt, geschachtelt oder flat-pack
gehandhabt (eine Palette kommt nicht in eine Kiste). Damit bricht die Rekursion sauber ab.14 · Lager & Lagerbedingungen
Lager werden wie Produktionshallen gebaut (Installation vor Ort, flexible Größe) — nur weist man
hier Lagervolumen zu statt Maschinen aufzustellen (storage_spec). Der Kern ist ein
vollständiges Bedingungs-Match:
storage_requirements). Jedes Lager stellt Bedingungen bereit
(storage_conditions, via Basis + zugebaute Module). Ein Produkt darf nur dort lagern, wo
alle seine Bedingungen erfüllt sind und Platz ist. Sonst: Verlust/Schaden/Verbot.Das Bedingungs-Vokabular (vollständig)
| Gruppe | Bedingungen | Beispiel-Güter |
|---|---|---|
| Temperatur | ambient · cooled · frozen · cryogenic · heated | Kryogen: Flüssig-O₂/-H₂; Beheizt: frostempfindliche Chemie |
| Druck / Atmosphäre | pressurized · inert_atmosphere · sealed_dry | Druck: alle Gase; Schutzgas: oxidationsempfindlich; Trocken: Elektronik |
| Gefahrgut | hazmat_flammable · hazmat_explosive · hazmat_toxic · hazmat_corrosive · hazmat_radioactive | H₂ (brennbar), Teer (giftig), Spaltstoffe (radioaktiv) |
| Sonstige | clean_room · uv_protected · vibration_isolated | KI-Kerne & Elektronik: Reinraum + UV-Schutz |
Lager als Module — Spezialisierung lohnt
Bedingungen kommen über Ausbau-Module (eigene entities): Kühlaggregat, Kryo-Speichersystem, Druckspeicher, Gefahrgut-Bunker, Reinraum-Modul. Das erzeugt sinnvolle Spezialisierung:
| Lagertyp | stellt bereit | nutzbar | Kosten |
|---|---|---|---|
| Allzweck-Lagerhalle | ambient, sealed_dry, (+ Kühlung) cooled/frozen | 82 % | günstig |
| Kryo-Druck-Tanklager | pressurized, cryogenic, inert_atmosphere | 60 % | teuer |
So muss der Spieler überlegen: ein billiges Schüttgutlager neben der Erzgrube, aber eine teure Kryo-Tankfarm für Flüssiggase — und Gefahrstoffe gehören in den Bunker, nicht neben die Elektronik.
15 · Karten-UI & KI-Bilder
Look & Feel: modern/tech, animiert, übersichtlich. Jeder Rohstoff, jede Maschine, jedes Produkt wird zu einer Karte, die alle Infos zeigt (wie der Katalog, aber spielnah). Prototyp: cards.html.
- Kompakte Karte im Grid. Bild-Bereich + Kategorie/Tier-Badge + die wichtigsten Kennwerte (Masse, Volumen, Durchsatz, Skill) als Chips.
- Klick = Vollbild-Fenster. Ein großes Modal öffnet sich mit allen Infos wie im Katalog (Herstellung/Abbau mit allen Varianten & Dials, Betrieb, Bedienung, Akku, Gebäude/Lager, Verpackung, Lagerbedingungen, Vorkommen).
- Alles ist verlinkt. Jede Referenz im Fenster (Inputs, Maschinen, Module, Nebenprodukte, Familien …) ist klickbar und öffnet die jeweilige Karte im selben Fenster — z.B. Klick auf „Turbogebläse" springt direkt zu dessen Karte. ← Zurück navigiert die Kette zurück, Esc schließt.
- Animiert & tech. Gestaffelter Einflug, Hover-Glow in Kategoriefarbe, Sheen übers Bild, Filter-Chips + Suche. Kategorie-Farbcode: Rohstoff grün · Produkt blau · Maschine lila · Gebäude amber · Worker pink.
KI-Bilder für die Karten
Die Karten-Grafiken werden per Image-AI erzeugt (OpenRouter + Gemini 2.5 Flash Image, ~4 ct/Bild).
Zwei neue Felder je entity: image (Pfad zur Grafik) und art_prompt (optionaler
Prompt-Override). Pipeline: generate_card_images.py.
art_style) + ein Motiv-Template je Kategorie (Erz-Brocken, Maschinen-Render,
Worker-Roboter …) + ein Stil-Anker-Bild halten alle Karten visuell konsistent — wie eine
Produktreihe. Bis echte Bilder da sind, zeigt jede Karte einen sauberen prozeduralen SVG-Platzhalter.16 · Durchgespielt: „Stahl", „Hochofen" & „Schrauben"
Der mitgelieferte Beispiel-Durchlauf (seed_steel.py) zeigt das ganze System an einem
Strang: eine Legierung mit 3 Wegen, Rekursion in Zwischenprodukte, runter bis zu rohem Erz
mit Vorkommen & Abbau, plus 16 Maschinen als Stubs.
Die 3 Stahl-Varianten
| Variante | Kern-Inputs | Maschine | Charakter |
|---|---|---|---|
| V1 · Sauerstoffblas (Primär) | Roheisen, Schrott, O₂, Kalkstein | Sauerstoffkonverter | Massenware, schnell, energiehungrig |
| V2 · Elektrostahl (Recycling) | Stahlschrott | Elektrolichtbogenofen | Schlank, schrott- & stromabhängig |
| V3 · Grüner Stahl (H₂-DRI) | Eisenschwamm (aus H₂-Reduktion) | Direktreduktion + E-Ofen | Sauber, teuer, infrastrukturhungrig |
In der Karten-Ansicht kannst du jeden dieser Knoten anklicken und dich durch die
Kette nach unten hangeln, inklusive der grünen Nebenkette
Wasser → Elektrolyse → Wasserstoff → Eisenschwamm.
Der Hochofen unter dem 3-Bedarfs-Modell
Der zweite Durchlauf (seed_hochofen.py) nimmt eine der Maschinen-Stubs und baut sie
eine Ebene tief aus — als Vorlage für alle weiteren Maschinen:
| ① Bauen (Baugruppen) | ② Betreiben (laufend) | ③ Bedienen |
|---|---|---|
| Stahlmantel · Feuerfeste Auskleidung · Winderhitzer · Turbogebläse · Begichtungs-/Abstichanlage · Steuerung · Schwerfundament (+ 400 t Stahl → Bootstrap-Zyklus) | ⚡ Strom 2,5 MWh/h 💨 Heißluft 4000 m³/t ❄ Kühlwasser 15 m³/h |
2× Worker mit Skill-Tier ≥ 1 Routinebetrieb, T1-Bediener-Bot genügt |
Die Betriebs-Inputs sind echte entities mit eigener Herkunft:
Strom ← Fusionsreaktor/Solar, Heißluft ← Winderhitzer (befeuert mit Gichtgas),
Kühlwasser ← Wasser. So verzahnt sich die Energie-/Versorgungswirtschaft automatisch mit
der Produktion. Die acht Baugruppen liegen als Stubs bereit — der nächste Loop-Durchlauf vertieft sie.
Schrauben als parametrische Familie
Der dritte Durchlauf (seed_fasteners.py) legt die Familie Sechskantschraube samt
Achsen an und materialisiert drei reale Varianten — jede mit eigener, voll bis zum Erz reichender Kette:
└─ Stahldraht T4 ─ Stahl T3 ─ Roheisen T2 ─ Eisenerz T0 …
Verdrahtet ist die Fein-Nachfrage bereits: der Hochofen zieht M24×100-Bolzen,
die Roboter-Montage winzige M3×10-Titanschrauben. Eine zweite Familie
(Blindniete) ist als Beleg der Allgemeingültigkeit angelegt.
17 · So benutzt du es
Im Alltag machst du nur eins: mir ein Stichwort geben. Den Rest (Einordnen, Dubletten-Check, Rekursion, Katalog neu bauen) übernehme ich.
„Nimm Titan auf." · „Wie wird ein Solarpanel gebaut?" · „Bau die Maschine Hochofen aus." · „Zeig mir alles, was Wasserstoff braucht."
Technische Befehle (falls du selbst reinschauen willst)
python loader.py # DB aus data/ bauen (KANONISCHER Build-Weg) python db.py stats # Zählerstand der Datenbank python db.py tree "Stahl" # Produktionsbaum im Terminal python build_catalog.py # dichter HTML-Katalog (Referenz) python build_cards.py # spielnahe Karten-Ansicht (cards.html) python report_shift.py "Sechskantschraube M24x100 - Stahl 8.8" 3 # Schicht-Bilanz python generate_card_images.py 6 # KI-Karten-Bilder (braucht OPENROUTER_API_KEY) python deploy.py # Website auf Hostinger hochladen (braucht HOSTINGER_FTP_PASS)
index.html,
cards.html, System-Design.html) sind die öffentliche Website
(startraders-syndicate.com). Ablauf eines Updates: loader.py →
build_cards.py → deploy.py (lädt per FTPS nach public_html).
Das FTP-Passwort steht NUR in .env (git-ignoriert), nie im Code. Deploy
veröffentlicht die Inhalte öffentlich im Web.data/entities/<key>.json; loader.py baut daraus die DB. Der Dateiname/key
ist der stabile Schlüssel (Links + Bilder hängen daran), das Feld name ist der
frei änderbare Anzeigename — umbenennen bricht nichts. Querverweise (Inputs, Maschinen, Module …)
laufen über den key. Die alten seed_*.py sind nach archive_seeds/ verschoben.
Versioniert mit git.18 · Offene Design-Fragen (bewusst noch offen)
Damit wir nicht zu früh festlegen, was du noch erkunden willst — Kandidaten für die nächsten Sessions:
- Mengen-Einheiten & Bilanz. Sollen Input/Output-Mengen später spielmechanisch exakt aufgehen (echte Massenbilanz) oder nur grobe Richtwerte fürs Gefühl bleiben?
- Energienetz vertiefen. Strom ist jetzt ein echtes entity (Fusion/Solar). Offen: Netz, Speicher, Lastspitzen, Übertragungsverluste — als eigenes Spielsystem oder bewusst abstrakt?
- Standort & Klima-Matching. Masse/Volumen (§10) und Aufbau-Dauer (§11) stehen jetzt.
Offen: ein echtes Planeten-/Klima-Modell, gegen das die
condition-Tags der Umwelt-Module matchen — plus Transportwege & Distanzen zwischen Himmelskörpern. DB oder Engine? - Tech-Tree / Freischaltung. Reihenfolge, in der Spieler Verfahren/Maschinen freischalten — als eigene Ebene über dem Graphen?
- Engine-Anbindung. Welche Engine soll diese DB später lesen (Godot/Unity/eigene)? Export als JSON ist jederzeit aus der DB möglich.