Tramway SDK – die unheilige Verbindung der Engines von Half-Life und Morrowind

• Tramway SDK ist ein in den letzten drei Jahren entwickeltes Grafikpaket/Framework/Game-Engine, das als leichtgewichtige Engine den hohen Hardwareanforderungen und monolithischen Editor-Workflows gängiger Engines entgegentreten will
• Es geht davon aus, dass Mainstream-Engines wie Unity und Godot selbst für einfache Low-Poly-Spiele überzogene Hardware verlangen, und zielt auch auf Hardware der letzten 15 Jahre sowie Software-Rasterisierung als Laufzeitumgebungen ab
• Statt zwischen Node-GUI und Code zu wechseln, schreibt man Code durch Vererbung der Entity-Klasse und nutzt nur die Editoren, die tatsächlich benötigt werden
• Für den Levelbau nutzt es einen Quake-artigen Brush-Workflow mit .map-Konverter, Lightmaps, Gouraud-Shading und einem Ein-/Ausgabesystem im Stil von Source
• Ziel sind Open-World-Streaming und ein RPG-Framework, das einem 3D-RPG-Maker nahekommt; da es sich aber noch in einem frühen Entwicklungsstadium befindet, muss man mit instabilen APIs und fehlenden Implementierungen rechnen

---

Das Problem, auf das Tramway SDK abzielt

• Tramway SDK ist Grafikpaket, Framework und Game-Engine; daneben wird auch die Heavy-Metal-artige Schreibweise „T̈ra̦m̊ẅa̦ÿ SD̈K“ verwendet
• Die Kritik an Mainstream-Engines konzentriert sich auf Turbobloat
  • Unity verlange nach Ansicht des Projekts sehr starke Hardware und viel Strom
  • Godot sei etwas besser als Unity, brauche aber weiterhin vergleichsweise leistungsfähige Hardware
  • Spiele wie Low-Poly-Horror-Roguelite-Deckbuilder-Simulatoren sollten aus dieser Sicht auch auf 15 Jahre alter Hardware problemlos laufen können
• Tramway SDK stellt heraus, dass es ohne Turbobloat auf nahezu jeder Hardware der letzten 15 Jahre lauffähig sei
  • Es kann auf Software-Rasterisierung umschalten, um auch ohne Grafikkarte zu funktionieren
  • Als Beispiele werden sogar Geräte wie Toaster oder Kühlschränke genannt, auf denen Grafik angezeigt werden könnte
• Dem Gegenargument „Dann kauf dir eben einen besseren Computer“ hält es drei Gründe entgegen
  • das Problem der Erschwinglichkeit, weil viele Menschen sich keine starke Hardware leisten können
  • das Problem des Elektroschrotts, weil die Produktion von Computerchips schlecht für die Umwelt ist und man neue Hardware nur kaufen müsste, wenn alte kaputt und nicht reparierbar ist, sofern Software nicht aufgebläht wäre
  • die Haltung, dass es keinen Grund gibt, einen neuen Computer zu kaufen, wenn der vorhandene gut funktioniert, nur wegen des Turbobloats anderer

Arbeitsweise und Funktionen

• Node-basierte Produktionsweisen werden kritisiert, weil man dabei mit „mehreren Dingen, die wie ein einziges wirken“ umgehen und zwischen Node-GUI und Code wechseln müsse
• In Tramway SDK reicht es, Code durch Vererbung der Entity-Klasse zu schreiben und anschließend mit dem Level-Editor Levels zu erstellen
  • Die Struktur ist entity-zentriert und kommt ohne Nodes aus
  • Der Wechsel zwischen Code und Node-GUI wird vermieden
• Auch die monolithischen Editoren gängiger Engines werden als Problem gesehen
  • Man müsse warten, bis der gesamte Editor inklusive nicht genutzter Funktionen geladen ist
  • Die Editoren von Tramway SDK sind alle optional
  • Wer es nur als Framework verwenden will, kann lediglich die C++-Runtime nutzen
  • Wer nur Levels erstellen möchte, kann ausschließlich den Level-Editor verwenden
  • Datendateien liegen als durch Leerzeichen getrennte Werte vor und können auch ohne Editor von Hand geändert werden
• Grafisch lassen sich Beispielbilder bereits nur mit Lightmaps und Gouraud-Shading erzeugen
  • Das entsprechende Beispiel kann auch auf der Fixed-Function-Pipeline einer Grafikkarte auf Direct3D-7-Niveau gerendert werden
• Für den Levelbau wird ein Brush-basierter Workflow aus der Quake-Familie unterstützt
  • Tramway SDK bietet einen Konverter für .map-Dateien und wandelt Brushes in Dreiecksmeshes um
  • Gezeigt wird ein Ablauf, bei dem Levels in Trenchbroom erstellt und im Tramway-SDK-Level-Editor konfiguriert werden
  • Innerhalb der Engine werden Levels mit angewendeten Lightmaps gerendert
  • Mit einem Ein-/Ausgabesystem ähnlich Source lassen sich Interaktionen zwischen Entities im Level einrichten
  • Künftig soll die gesamte Source-Logic-Entity implementiert werden, damit visuelles Scripting im Level-Editor möglich wird
• Im RPG-Bereich gelten Werkzeuge wie RPG Maker sowie Morrowind-basierte Mods und Total Conversions, bei denen sich vieles durch Datenänderungen bauen lässt, als interessante Beispiele
  • Tramway SDK enthält eine Erweiterung als RPG-Framework, die einem RPG Maker für 3D nahekommt
  • Die Engine ist von Anfang an für Level-Streaming ausgelegt, was die Entwicklung von Spielen im Stil von Open-World-RPGs schnell und einfach machen soll
• Kurz gesagt ist Tramway SDK eine entity-basierte Game-Engine im Stil von Quake/Source und bietet optionale Erweiterungen wie Open-World-Streaming und ein RPG-Framework
• Der Entwicklungsstand ist noch sehr früh
  • Die API ist instabil
  • Funktionen können kaputt sein oder nicht funktionieren
  • Viele Elemente sind noch nicht implementiert
  • Das Projekt gibt an, sich schnell zu verbessern
• GitHub-Repository: racenis/tram-sdk

[GN⁺]

Meinungen auf Hacker News

• Manche würden vielleicht sagen: „Kauf dir einfach einen besseren Computer“, aber genau deshalb stimme ich völlig zu, dass es schlecht ist, einen besseren Computer zu kaufen. Viele Menschen, besonders in Entwicklungsländern, können sich keine Hardware leisten, um Turbobloat auszuführen, und die Chipproduktion hat negative Auswirkungen auf die Umwelt.
  Wenn moderne Software nicht so aufgebläht wäre, würde man neue Hardware nur dann kaufen, wenn die vorhandene kaputtgeht und nicht mehr reparierbar ist. Es gibt keinen Grund, einen neuen Computer zu kaufen, wenn der vorhandene einwandfrei funktioniert, nur wegen der aufgeblähten Software anderer Leute; für das Geld könnte man auch 1000 Dosen Dr. Pepper kaufen. Wirklich ein gutes Projekt, ich hoffe, sie posten weiter Updates zum Fortschritt.

  • Es heißt zwar „Bildschirmauflösungen von 320x200 bis 800x600“, aber höhere Auflösungen wurden nicht nur wegen Turbobloat erfunden.
  • Gleichzeitig scheint die Engine aber eine OpenGL-4-GPU zu verlangen, obwohl die Grafik so aussieht, als wäre sie auch mit einer Voodoo-Karte machbar.
  • Ich weiß nicht, was Turbobloat sein soll. Aus dem Kontext liest es sich wie „Grafiktechnik, die ich nicht mag“, aber mir ist nicht klar, wo Turbobloat anfängt und endet.
  • Einen neuen Computer zu bauen und auszuliefern, kann sich langfristig lohnen, weil Verbesserungen bei Leistung und Energieeffizienz die Umweltbelastung mit der Zeit ausgleichen können.
    Bei Unterhaltung ist das natürlich schwer zu beurteilen; ein alter Game Boy kann mehr Spaß machen als ein moderner 1000-Watt-Gaming-PC.

• Der Satz „Eins sollte eins sein. Es sollte nicht aus vielen Dingen bestehen, die so tun, als wären sie eins. Wenn man Nodes verwendet, muss man viele Sammlungen so tun lassen, als wären sie eins“ klingt wirklich sehr nach Terry Pratchett und ist großartig.
  Das ist genau ein Satz, der Sam Vimes bei einer komplizierten Ermittlung einfallen könnte; gefällt mir sehr, und ich hoffe, es entwickelt sich weiter. Ich habe es selbst noch nicht ausprobiert, aber ich habe eine Idee, wie ich es für mein AI-Projekt nutzen könnte.

  • Wenn man nur diesen Satz für sich nimmt, wirkt er auf mich eher offensichtlich falsch. Wir begreifen ständig Sammlungen vieler Dinge als ein Ding.
    Ein Mensch ist eine Sammlung von Körperteilen, Körperteile sind Sammlungen von Chemikalien, Chemikalien sind Sammlungen von Molekülen, Moleküle sind Sammlungen von Atomen, und trotzdem betrachten wir jede Ebene als eins. Zu sagen, man solle das nicht tun, ergibt keinen Sinn. Das Projekt sieht trotzdem cool aus.
  • Ich kann mir vorstellen, dass Sam Vimes so etwas sagt und dann durch Sybil eine schmerzhafte Entwicklung durchmacht, bis er widerwillig zugibt: „Manchmal muss eins vielleicht einfach mehr als eins sein.“
    Und Vetinaris Entity-Component-System wirkt zwar kompliziert, funktioniert aber richtig und hält diese verdammte Stadt am Laufen.
  • Diese Formulierung scheint sich an Leute zu richten, die andere Lösungen ausprobiert und nicht gemocht haben. Aus der Sicht von jemandem, der noch nie eine Game Engine benutzt hat, wäre aber eine einfache Erklärung hilfreich, wie Nodes damit zusammenhängen, „eine Sammlung mehrerer Dinge so tun zu lassen, als wäre sie eins“.
    Vielleicht ist gemeint, dass die User Experience eines Node-Editors dazu verleitet, Dingen wie einem Vector aus Fingers Eigenschaften und Beziehungen zu geben, dass ein Vector am Ende aber nur eine „Sammlung von Dingen“ ist und keine „Art“ mit eigenem Verhalten, weshalb es schwierig ist, Code daran zu hängen.
    Ich frage mich, ob „Alles ist eine Entity und schreib einfach Code“ bedeutet, statt eines Vectors eine Hand-Klasse zu erstellen, die Fingers enthält und eigenen Zustand sowie eigenes Verhalten hat. Oder ob es darum geht, statt Node-Instanzen zu erstellen, die bestimmte statische Werte und Beziehungs-Member vorab bündeln, eher Unterklassen von Entity weiter abzuleiten und zu konkretisieren.
  • Der direkt folgende Absatz ist interessant: „Wenn man etwas mit Nodes baut, muss man ständig zwischen der Node-GUI und dem Code hin- und herwechseln.“
    Godots Node/GDScript-Aufbau kann man als eine Art Antwort auf diese Behauptung sehen. Mit Dingen wie dem $-Operator und Autocomplete versucht er, dieses „Hin und Her“ so reibungslos und integriert wie möglich zu machen. Trotzdem muss am Ende ein Spiel ausgeliefert werden, daher denke ich, dass die Denkweise „eins ist eins“ am Schluss gewinnt.
  • Leider ist alles eine Sammlung von Dingen, die so tun, als wären sie eins, selbst ein einzelnes Ding. Das Beste, was wir tun können, ist, so zu tun als ob – oder es so zu vermeiden, dass wir nicht erwischt werden.

• Mit der Zeit bekomme ich den Eindruck, dass es eine äußere Kraft gibt, die die Qualität von Game-Engines senkt. Was sich in der Technik allgemein durchsetzt, sind meist Dinge, für die sich leicht ein Curriculum erstellen lässt.
  Node-basierte Editoren wie Unity haben genau die richtige Struktur, um sie über mehrere Unterrichtseinheiten hinweg zu erklären. Engines wie raylib dagegen kann man an einem Nachmittag verstehen, sodass sich ein Universitätskurs auf raylib-Niveau kaum sinnvoll aufbauen lässt. So entsteht ein Kreislauf: Aus Bootcamp-artigen Schulen kommen Amateurentwickler, die nur Unity/Unreal kennen; Unternehmen stellen Leute mit Unity/Unreal-Kenntnissen ein; Universitäten lehren das dann wieder. Das ähnelt auch dem Phänomen, warum Java so populär ist.
  Außerdem unterscheiden sich die Anforderungen an Unity-Projekte von Unternehmen zu Unternehmen. Unity muss die Engine daher nicht wie ein einzelner unzufriedener Programmierer, sondern als gewinnorientiertes Unternehmen mit Kunden ständig anpassen – und wird am Ende zu Turbobloat. Die Engines von Half-Life und Morrowind entstanden in der besonderen Situation, dass leidenschaftliche Programmierer dafür bezahlt wurden, das zu entwickeln, was sie für cool hielten. Daraus kamen minimale Engines, die zu professionellen Spieleentwicklern passten, und großartige Technik.
  Dieses Projekt scheint irgendwo zwischen raylib und Unity zu liegen. Ich frage mich, ob es zu wenig bietet, um Amateurprogrammierer anzusprechen, und gleichzeitig für Programmierer, die eine kleine Engine wollen, vielleicht schon zu viel macht. Ich hoffe, ich liege falsch; Performance und Reifegrad sehen gut aus. Es gibt definitiv Entwickler, die Unity leid sind, und da die Nostalgiewelle inzwischen in die 2000er wandert, gibt es tatsächlich Nachfrage danach, Spiele zu spielen und zu entwickeln, die grafisch nicht komplexer sind als Half-Life 2. Auch Webdesign und Dokumentationston sind gut.

  • Wichtig ist auch, dass sich Spiel und Engine gegenseitig anpassen können, wenn sie gemeinsam entstehen. In Doom konnte man keinen Boden über einen anderen Boden legen; das war eine Engine-Grenze durch CPU-Beschränkungen, und Leveldesigner entwickelten Tricks, damit es trotzdem so aussah.
    Wenn man beides zusammen entwirft, kann man hinzugefügte Features aktiv nutzen und Funktionen, die die Engine schlecht beherrscht, vermeiden – oder gleich den Art Style an die Engine anpassen. Die pixeligen, kantigen Mobs von Minecraft passen gut zur Engine; sobald man sie aber detaillierter macht, fällt man in ein Uncanny Valley, in dem sie älter und unbeholfener wirken als Minecraft, bis sie mit genügend Polygonen ordentlich gerendert werden können.
  • Ich erinnere mich, dass jemand, der an Bioshock gearbeitet hat – vermutlich der Lead Designer –, in einem Interview sagte: „Wenn ich in der Firma eine neue Idee ausprobieren will, muss ich ein Team zusammenstellen und mindestens einen Monat investieren, bevor man etwas Anfassbares hat. Zu Hause dagegen kann ich an einem Abend eine komplette Doom-Kampagne bauen.“
  • Ich mag Library-basiertes Game Development wie mit raylib oder libgdx, aber es gibt Gründe, warum ein Spiel wie Slay the Spire beim Nachfolger von Unity zu Godot gewechselt ist.
    Ich glaube nicht, dass Leute Unity verwenden, weil sie von Professoren, die Komplexität mögen, falsch ausgebildet wurden.
  • Früher waren Spiele wirklich klar und direkt; heutige Spiele laufen miserabel, crashen, brauchen 150 GB Download und 150 Jahre zum Starten. Wenn wir Spiele wegen der Grafik spielen würden, wäre eines der beliebtesten MMOs wohl kaum auf einem Browsergame von 2002 aufgebaut – und wir würden überhaupt keine Spiele spielen, sondern die Realität.
    Man muss nur ansehen, was Epic Games mit Fortnite gemacht hat. Sie haben ein flüssig laufendes, kompetitiv geprägtes Spiel wegen Turbobloat-Grafik und Skins kaputtgemacht.
  • Das Phänomen „Es kommen Programmierer heraus, die nur Unity/Unreal kennen; Firmen stellen Unity/Unreal-Leute ein; Universitäten lehren es wieder“ zeigt sich ähnlich auch bei ArcGIS.

• Dem Problem der Turbo-Aufblähung stimme ich voll zu. Heutige Maschinen sind viel leistungsfähiger, aber die meisten Programme fühlen sich eher langsamer an als früher.
  Das Projekt ist auch sehr cool, und das Websitedesign bekommt eine Eins mit Sternchen.

  • „Die meisten Programme sind langsamer als früher“ scheint mir nur für Leute zu gelten, die das Glück hatten, zu einem bestimmten Zeitpunkt etwas überdimensionierte Hardware zu nutzen.
    Aus der Perspektive von jemandem, der zu Zeiten von Windows 98/2000/XP normale Hardware verwendet hat, ist ein günstiger moderner Laptop mit SSD unter Windows 10/11/KDE/Gnome usw. deutlich reaktionsschneller – selbst wenn man als aufgebläht geltende Webapps wie vscode oder Slack ausführt.
  • Ich verstehe den Begriff Turbobloat nicht. Ich habe Spiele entwickelt, ihn aber noch nie gehört; der Autor definiert ihn nicht, und bei Kagi findet man nur den eingereichten Beitrag, bei Google keine relevanten Ergebnisse.
    Ich frage mich, ob es einfach „sehr aufgebläht“ bedeutet. Nachdem ich auf der Website weitergelesen habe, gibt es dort auch Formulierungen wie „hyperrealistische Physiksimulation“, daher scheint es letztlich wohl „sehr aufgebläht“ zu bedeuten.

• Die Sichtweise, dass „die meisten Unity-Spiele trotz schicker Shader, Normal Mapping und anderer Techniken ziemlich schlecht aussehen“, scheint in bestimmten Generationen immer verbreiteter zu werden.
  Eine bestimmte Art von Texture-Mapping-Technik ist definitiv verschwunden. Die Hintergründe von Ikaruga sind besser als nötig, besonders der simple Waldeffekt am Anfang. Auch einige Zugsimulatoren aus der PS2-Ära haben das hinbekommen.
  Allerdings bricht diese Methode zusammen, wenn eine starke gerichtete Lichtquelle wie die Sonne auf glänzende Objekte trifft und der Spieler sich bewegt. Wenn die Umgebung diesig ist und es keinerlei dynamische Objekte gibt, kann man viele moderne Tricks ziemlich gut umgehen.

  • Stimmt. Das Problem ist, dass manche modernen Spiele selbst dann Lumen einsetzen, wenn sie diesig sind und keine dynamische Beleuchtung haben. Beim Silent-Hill-Remake war das so: Es läuft sehr langsam, sieht auf der PS5 Pro noch schlechter aus, und selbst das Gras wirkt schlechter als in älteren Spielen.
    Das ursprüngliche Setting von Silent Hill wurde ja geschaffen, um Optimierungstricks zu rechtfertigen. Um die Verwaltung der Objekte auf dem Bildschirm zu erleichtern, gab es einen permanent nebligen „Nebelraum“. Das Remake verschwendet dagegen enorme Rechenleistung darauf, realistischen Nebel zu erzeugen, statt übernatürlich wirkenden Nebel.
  • Hübsche Spiele, die mit Unity gemacht wurden, sehen nicht „wie Unity-Spiele“ aus, deshalb fallen sie Leuten nicht als Beispiele dafür ein, „wie Unity-Spiele aussehen“. Dadurch bleibt das typische Bild von Unity-Spielen weiterhin bei „ziemlich grob“.
    Die künstlerischen Fähigkeiten, mit denen etwas gut aussieht, sind keineswegs verschwunden; sie sind nur sehr ungleich verteilt. Ein Team mit guten Modelern, Texture Artists, Animatoren und Visual-Programming-Kompetenz kann ein Spiel gut aussehen lassen, egal ob mit Unreal, Unity oder einer eigenen Engine.
  • Es gibt diese fixe Idee, dass Materialien allein unzureichendes Texturing und Normal Mapping ausgleichen könnten. Das stimmt nicht und ist das Ergebnis missverstandener oder verzerrter Marketingaussagen von Dingen wie der Unreal Engine.
    Für die „scharfen“ Schatten, die der GameCube in Super Mario Sunshine nicht rendern konnte, wurden tatsächlich flache Meshes verwendet. In Delfino Plaza ist der Schatten unter der Markise in der Nähe des Shine Gate kein Texture, sondern ein Mesh. Der geflieste Platz, auf dem dieser Mesh-Schatten liegt, sieht dagegen nicht wegen einer riesigen Texture gut aus, sondern weil Dutzende 128x128px-Texturen sauber UV-gemappt wurden.
    Ein modernes Spiel würde vermutlich zwei Ziegeltexturen und ein Noise-Pattern zum Mischen verwenden, alle drei in 2048x2048px, und die Schatten würden per Raytracing scharfe Kanten bekommen. Ironischerweise haben wir mehr VRAM und höhere Busgeschwindigkeiten, entscheiden uns aber für größere statt für mehr Texturen. Beim Normal Mapping ist es ähnlich: Statt es zusammen mit stärker unterteilten Modellen zu verwenden, hält man Normal Maps irrtümlich für veraltet und glaubt, jedes Detail tatsächlich zu modellieren sei der technisch fortschrittlichere Weg. Eine weniger kantige Kugel ist in Ordnung, aber jede Ritze und jeden Kratzer auf der Kugel real zu modellieren, ist dumm und Rechenverschwendung.
  • Mit etwas wie Unity kann man ziemlich schnell etwas zum Laufen bringen, aber damit es wirklich großartig aussieht, braucht es eigene Fähigkeiten und Feinschliff.
    Selbst bei einem „2D“-Spiel wie Factorio ist der Polishing-Unterschied zwischen Erstveröffentlichung, Version 1.0 und der heutigen Version enorm. Auch in Spielen mit Mods ist dieser Unterschied klar zu sehen: Mod-Assets sind meist „brauchbar“, wirken aber nicht so ausgearbeitet wie die des Hauptspiels.

• Ich habe kürzlich Half-Life 2 wieder gespielt und war überrascht, wie gut es auch heute noch aussieht, selbst ohne hochauflösendes Texture-Pack.

  • Ich glaube, das liegt daran, dass der Artstyle des Spiels extrem klug gewählt wurde. Es gibt viele diffus reflektierende Oberflächen, bei denen vorgebackenes Licht gut funktioniert, und der bedeckte Himmel ermöglicht weiches Umgebungslicht statt gerichteter Beleuchtung, die winkelabhängiges Shading und harte, kontrastreiche Schattenkonturen erzwingen würde.
    Auch die glänzenden Oberflächen sind meist nicht allzu spiegelnd, was ebenfalls hilft. Diese Entscheidungen passen glaubwürdig zu einer verfallenen, besetzten, extrem dystopischen Welt, und die gedämpften Texturfarben halten alles zusammen.
  • Deshalb denke ich, dass wirklich gute Art Direction reine Grafikleistung immer schlägt. Source war damals schon beeindruckend, aber was überdauert hat, ist, wie sorgfältig Umgebungen und Modelle gestaltet wurden.
    Valve konzentrierte seine Ressourcen darauf, innerhalb technischer Grenzen Details unterzubringen und das Maximum herauszuholen. Auch 20 Jahre später wirkt das noch kohärent und gut designt.
  • Half-Life 2 hat seit dem Release mehrere Updates bei Shading und Detailgrad bekommen und sieht deshalb etwas besser aus als zum Veröffentlichungszeitpunkt. Aber schon damals war es visuell beeindruckend.
  • Ich habe Half-Life 2 vor weniger als einer Woche wieder gespielt und dachte mir: „Auch wenn die Level nicht so voller Details sind wie moderne Spiele, sind die künstlerische Richtung der Grafik und das Leveldesign besser als bei vielen heutigen Designern mit deutlich größeren Budgets.“
  • Black Mesa, das Remake von HL1 in der HL2-Engine, ist ebenfalls spielenswert. Ich habe es während der Pandemie gespielt und es nicht bereut.

• Aus der Perspektive von jemandem, der in einem kleinen Team mit Godot an einem Low-Poly-Spiel arbeitet, ist das hier großartig.
  Aussagen wie „Wenn man etwas mit Nodes baut, muss man ständig zwischen Node-GUI und Code hin und her wechseln“ und „Mainstream-Engines haben einen einzigen riesigen Game-Editor, und egal welche Funktion man nutzen will, man wartet zehn Minuten, bis alles geladen ist“ treffen sehr ins Schwarze. Selbst in Godot nutze ich kaum die ausgefallenen Features, aber der Debug-Loop fühlt sich viel langsamer an als beim Programmieren in anderen Umgebungen.
  Auch die Idee, dass mehrere Editoren rund um eine gemeinsame Datenfile-Spezifikation zusammenarbeiten, gefällt mir. Eine integrierte IDE macht es mehreren Entwicklern leicht, Merge-Konflikte zu erzeugen; spezialisiertere Editoren könnten daher auch dabei helfen, dass Entwickler je nach Rolle Umfang und Art ihrer Änderungen begrenzen. Ich bin gespannt, wie sich die Engine weiterentwickelt.

  • Ich war ziemlich stolz, als ich letzten Monat bei einem Hackathon herausgefunden habe, wie man C#-Module testgetrieben entwickelt, ohne Unity zu starten.
    So konnte ich sogar mit einem leistungsschwachen Netbook meinen Teil beitragen. Ich hatte noch nie eine Zeile C# geschrieben, aber ich wollte TDD auf der Kommandozeile nicht aufgeben. Ich fand heraus, dass es möglich ist, und habe es am Ende zum Laufen gebracht. Alle hielten mich für verrückt, und die Developer-Relations-Leute des Sponsors waren keinerlei Hilfe.
    Der größte Reibungspunkt an diesem Wochenende war trotzdem, dass der beste Rechner eine Ewigkeit damit verbringen musste, die verdammte Unity-IDE zu starten und neu zu starten. Es ist erstaunlich, welche Fesseln die Leute hinnehmen.

• Es werden Begriffe wie „Turbobloat“ verwendet und gesagt, die Engine sei „aufgebläht“; bis zu einem gewissen Grad stimmt das. Trotzdem wäre es sinnvoll zu erklären, was das für einen selbst bedeutet, welche Funktionen man als Bloat betrachtet und was im Tramway-Projekt weggelassen wurde.
  Für manche könnte zum Beispiel schon ein enthaltenes RPG-Framework als Bloat gelten, und Tramway enthält so etwas.

  • Deshalb habe ich es als optionale Erweiterung eingebaut. Es ist zwar Teil des größeren Engine-Projekts, aber vollständig optional.
    Ich mag das C++-Prinzip „Man bezahlt nur für das, was man nutzt“.

• Es heißt dort „Verwendung des Frameworks für Anfänger, denen C++ Angst macht oder die es einfach nicht können“; bei mir ist es Letzteres, und ich war dankbar für die Getting Started-Seite.
  Die Teekanne erschien, und ich verstand Dinge, von denen ich dachte, ich würde sie nicht verstehen. Ich habe jetzt in der Mittagspause nur 30 Minuten und keine Zeit, das Tutorial zu beenden, aber dass ich Lust bekommen habe weiterzumachen, zeigt sehr gut, wie unterhaltsam und zugänglich diese Dokumentation ist.

• Hat jemand die Design Patterns-Seite gefunden? Das ist eine Anzeigetafel mit Ziel 100 %, und ich mag sie sehr.

  • Sie ist auf der Startseite verlinkt: „Verwendete Design Patterns: 82 %. Sobald alle Patterns verwendet wurden, wird das Projekt gelöscht und in Rust neu geschrieben. Ohne Objektorientierung.“
  • Ich habe eine ganze Weile gesucht, sie aber immer noch nicht gefunden.