Minecraft: Java Edition stellt Fenster- und Eingabe-Backend auf SDL3 um

 (minecraft.net)
1 Punkte von GN⁺ 23 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Minecraft 26.3 Snapshot 4 ersetzt das Backend für Fensterverwaltung, Eingabe und Plattformintegration von GLFW durch SDL3 und führt SDL-Scancodes und Keycodes für Tastatureingaben ein
  • Tastenzuweisungen verwenden statt layoutabhängiger Codes physische Tastenpositionen; unter Linux wird nach Möglichkeit Wayland bevorzugt, unter macOS werden native Eingabe-Kandidatenfenster unterstützt
  • Für benutzerdefinierte Ofen- und Braustand-Brennstoffe wurden Datenkomponenten ergänzt, mit denen Brenndauer, Nutzungsanzahl sowie Koch- und Braugeschwindigkeit per Number Provider festgelegt werden können
  • In Datenpaket 111.0 und Ressourcenpaket 92.0 ändern sich Klick-Events von Schildern, Loot-Table-Referenzen, Advancement-Trigger, Umgebungseigenschaften für Mob-Spawns, Einstellungen zur Terrain-Generierung und Shader umfassend
  • Unter Windows mit mehreren Monitoren und unter Wayland sind Abstürze im exklusiven Vollbildmodus bekannt; Testversionen können Welten beschädigen und sollten daher mit Backup oder in einem separaten Ordner ausgeführt werden

SDL3-basiertes Fenster- und Eingabesystem

  • Die Bibliothek für Fensterverwaltung, Eingabe und Plattformintegration wird von GLFW auf SDL3 umgestellt
    • Tastatureingaben verwenden SDL-Scancodes für physische Tastenpositionen
    • Für layoutabhängige Shortcuts zur Textbearbeitung werden SDL-Keycodes eingesetzt
  • Tastenzuweisungen funktionieren auf Basis physischer Tasten, nicht layoutabhängiger Tastencodes
  • Die Raw-Input-Mauseinstellung wurde entfernt; während des Gameplays wird immer der relative Mausmodus verwendet
  • Rahmenloses Vollbild ist nun der Standard-Vollbildmodus; zwischen rahmenlosem und exklusivem Modus kann ohne Neustart gewechselt werden
    • Unter macOS wird exklusives Vollbild nicht mehr unterstützt
    • Die minimale Fenstergröße beträgt 320×240 Pixel
  • Unter Linux wird Wayland nativ bevorzugt, wenn es verfügbar ist
  • Unter macOS erscheint beim Gedrückthalten einer Taste während der Texteingabe ein natives Akzent- und Kandidaten-Popup

Bekannte Vollbildprobleme

  • Exklusives Vollbild unter Windows kann in bestimmten Situationen, insbesondere in Multi-Monitor-Umgebungen, zum Absturz des Spiels führen
  • Unter Wayland stürzt das Spiel beim Wechsel in den exklusiven Vollbildmodus ab

Änderungen an Gameplay und Oberfläche

  • Spieler im Zuschauermodus können mit Portalen interagieren und sich teleportieren
  • Gürteltiere versuchen nicht, sich einzurollen, wenn sie in Flüssigkeit eingetaucht sind
  • Auf das Debug-Overlay kann eine eigene GUI-Skalierung angewendet werden
    • Einstellbar in den Debug Options unter F3 + F6
    • Der Standardwert Auto hält eine höhere Auflösung als die normale GUI; Unchanged entspricht der normalen GUI-Skalierung
    • Ergänzt wurden außerdem player_speed, das die Blockbewegungsgeschwindigkeit des Spielers pro Tick zeigt, sowie eine Anzeige der Bildwiederholrate
  • Die Reihenfolge der Erze im Kreativinventar wurde neu angeordnet: Materialien ohne Tier, unverarbeitete Tier-Materialien, verarbeitete Tier-Materialien
    • Baublöcke folgen der Reihenfolge Erze ohne Tier, verarbeitete Tier-Erze, Copper-Familie; die umfangreichen Copper-Blöcke stehen weiter hinten
    • Der Tab Natural Blocks ist in der Reihenfolge Overworld → Nether → End organisiert

Benutzerdefinierte Brennstoffe und Item-Komponenten

  • minecraft:cooking_fuel definiert Brennstoffe für Furnace, Smoker und Blast Furnace
    • burn_time gibt die Anzahl der Brenn-Ticks an, speed_multiplier die Koch- bzw. Schmelzgeschwindigkeit, jeweils als minecraft:number_provider
  • minecraft:brewing_fuel definiert Nutzungsanzahl und Braugeschwindigkeit von Brewing-Stand-Brennstoffen
    • Das bisherige Item-Tag #brewing_fuel wurde entfernt und kann nicht mehr zur Registrierung neuer Braubrennstoffe verwendet werden
  • Smoker- und Blast-Furnace-Rezepte verwenden dieselbe Kochzeit wie Furnace; die Beschleunigung übernimmt minecraft:cooking/speed_default der Brennstoffkomponente
  • Die Felder für Koch- und Brennstoffzeit von Furnace, Smoker und Blast Furnace wurden von short auf integer geändert; speed_multiplier wurde ergänzt
  • Auch BrewTime und Fuel des Brewing Stand wurden auf integer geändert; total_brew_time, total_fuel und speed_multiplier wurden ergänzt
  • Folgende Datenkomponenten wurden hinzugefügt
    • minecraft:sign_text_front, minecraft:sign_text_back: speichern Vorder- und Rückseitentext von Schildern und zeigen ihn im Item-Tooltip an
    • minecraft:waxed: ein feldloser Marker, der anzeigt, dass der Inhalt gewachst wurde
    • minecraft:cushion/color: wendet eine von 16 Färbefarben auf platzierte Cushions an
    • minecraft:villager_food: definiert Items, die Dorfbewohner essen können, sowie deren Nährwert
    • minecraft:mob_visibility: gibt als Wert von 0.0 bis 10.0 an, wie stark Ausrüstung die Erkennungsreichweite von Mobs beeinflusst; auch gestapelt überschreitet die maximale Sichtweite nicht 10.0

Schilder und Datenpaket-Kompatibilität

  • Die Datenpaket-Version steigt auf 111.0
  • Befehle und Klick-Events in benutzerdefinierten Schildtexten werden standardmäßig beim Anklicken des Blocks nicht ausgeführt; auch Textkomponenten neuer Schilder werden nicht automatisch interpretiert
    • Das neue Feld allow_op_features hat standardmäßig den Wert false; um das frühere Verhalten wiederherzustellen, muss es explizit auf true gesetzt werden
    • Auf Schilder aus früheren Versionen sowie auf minecraft:block_entity_data, das Schilddaten enthält, wird allow_op_features=true angewendet
  • Der Bearbeitungsbildschirm für Schilder nach dem Platzieren wird nur angezeigt, wenn er auch per normalem Klick geöffnet werden kann, etwa wenn das Schild nicht gewachst ist und der Vorderseitentext bearbeitet werden kann
  • Schilder übertragen die Komponenten minecraft:sign_text_front, minecraft:sign_text_back und minecraft:waxed
  • Sichere Blöcke, auf denen /spreadplayers Spieler platzieren darf, werden über das Block-Tag #entities_can_teleport_to gesteuert

Registry-Referenzen sowie Änderungen an Loot und Advancements

  • Loot-Table-Typen mit eigener Registry unterstützen Registry-Elemente und Tag-Referenzen
    • Felder für einzelne Elemente können eine Namespaced ID oder einen Inline-Wert erhalten
    • Listenfelder können Inline-Werte, einzelne oder mehrere Namespaced IDs, Listen von Inline-Werten oder #-Tag-IDs erhalten
    • Ziele sind advancement, item modifier, loot table, number provider, predicate, recipe und slot source
  • Die bisherigen reference-Typen von predicate, item modifier und slot source sind überflüssig geworden und wurden entfernt
  • Mehrere Felder von Advancement-Triggern können neben Inline-Predicates auch Namespaced Predicate IDs erhalten
    • Das bisherige implizite minecraft:all_of-Verhalten von Bedingungslisten wurde entfernt; type muss zwingend angegeben werden
    • Mehrere Felder wie block, recipe_id und loot_table wurden jeweils in die Pluralform geändert und unterstützen einzelne IDs, Listen oder Tags
  • In Loot Pool Entry wurde conditions in condition umbenannt, functions in modifier
  • In Loot Function wurde conditions in condition umbenannt; das bisher den Funktionstyp bezeichnende function heißt nun type
    • Inline-Bedingungslisten werden nicht mehr akzeptiert; für dasselbe Verhalten muss minecraft:all_of explizit angegeben werden
  • Das Typfeld condition von Predicate wurde in type umbenannt; minecraft:reference und minecraft:block_state_property wurden entfernt
    • Das neue minecraft:match_block prüft Block-ID bzw. Tag, Zustand, NBT, Komponenten und Komponenten-Predicates gemeinsam
  • Inline-Number-Provider müssen type immer explizit angeben und verwenden nicht mehr minecraft:uniform als Standard
  • Mehrere Vanilla-Number-Provider wurden ergänzt, die Brenndauer je Kochbrennstoff, Standard-Koch- und Braugeschwindigkeit sowie Brauanzahl bereitstellen

Mob-Spawns und Weltgenerierung

  • Die neue Umgebungseigenschaft minecraft:gameplay/natural_mob_spawns definiert gewichtungsbasierte Mob-Spawns nach Kategorie sowie Spawn-Kosten je Entität
    • Während der Platzierung bei der Weltgenerierung wenden nur Dimension und Biome diese Eigenschaft an
    • Der overlay-Modifier priorisiert die Kategorieeinstellungen höherer Ebenen sowie Spawn-Kosten derselben Entität
  • minecraft:gameplay/creature_world_gen_spawn_probability gibt die Wiederholwahrscheinlichkeit für Mob-Spawns der Kategorie creature während der Weltgenerierung als Wert größer oder gleich 0 und kleiner als 1 an; Standardwert ist 0.1
  • spawners, spawn_costs und creature_spawn_probability von Biome wurden entfernt und in neue Umgebungseigenschaften verschoben
  • Die Umgebungseigenschaft für Umgebungspartikel interpoliert Wahrscheinlichkeiten zwischen Timeline-Keyframes und unterstützt den append-Modifier, der Einträge an Partikellisten untergeordneter Ebenen anhängt
  • In Noise Settings wurden Aquifer- und Ore-Vein-Einstellungen als optionales Objekt aquifers bzw. als Liste ore_veins neu strukturiert
    • Fehlen die Einstellungen, wird der jeweilige Aquifer oder Ore Vein nicht erzeugt
    • Zugehörige Density-Function-Felder wurden aus noise_router in die neue Struktur verschoben
  • Density Function erhält sub, div, negate, lerp, floor, round, ceil, truncate und beardifier
    • Mehrere bestehende Argumentnamen wurden in value, left, right, input und noise geändert
    • invert wurde in reciprocal umbenannt
    • Zu final_density wird der beardifier nicht mehr implizit addiert

Grafik und wichtige Fehlerbehebungen

  • Die Ressourcenpaket-Version steigt auf 92.0
  • Shader mit Unterstützung für order-independent transparency sowie die Definition OIT_ALWAYS_WRITE_DEPTH wurden ergänzt
  • core/integrate_depth.fsh integriert den Tiefenpuffer des 3D-HUDs und von immer oben angezeigten Gizmos in den Haupt-Tiefenpuffer
  • Die wichtigsten behobenen Probleme sind:
    • Probleme mit Tastenzuweisungen und Eingaben bei Nicht-QWERTY-Layouts sowie macOS- und CJK-Eingaben
    • Absturz beim Rendern von Karten in Improved Transparency sowie Anzeigeprobleme bei Glas, halbtransparenten Objekten, Partikeln und Weltgrenzen
    • Abstürze durch Projektile außerhalb der Welthöhe und durch Platzierung von Bienenstöcken auf der niedrigsten Höhe
    • Probleme beim Speichern und Laden von Heightmaps in der Weltgenerierung sowie Positions-Desynchronisierung von Mobs nach Tick-Sprint
    • Probleme mit Cushion-Platzierung, Farbe, benutzerdefiniertem Namen, Brennstoffzeit und Kollisionserkennung
    • Probleme mit Schaden und Flug des Ender Dragon, Portalnutzung durch Zuschauer und Ermittlung sicherer Blöcke durch /spreadplayers

Installation und Testhinweise

  • Der Snapshot ist für Minecraft: Java Edition und wird installiert, indem im Tab Installations des Minecraft Launcher Snapshots aktiviert werden
  • Testversionen können Welten beschädigen und sollten daher mit Backup oder in einem anderen Ordner als die Standardwelten ausgeführt werden
  • Ein plattformübergreifendes Minecraft server jar ist ebenfalls verfügbar
  • Bugs können im Minecraft issue tracker, Feedback auf der Feedback-Website eingereicht werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 23 시간 전
Hacker-News-Kommentare

  • Die LWJGL-Implementierung dieses Bindings wurde von einem Teammitglied des GTNH-Modpacks geschrieben und hat damit den Kreislauf vanilla→modded→vanilla wieder vervollständigt https://github.com/LWJGL/lwjgl3/pull/1033

    • Etwas übertrieben könnte man sagen, dass GTNH mehr zu Minecraft beigetragen hat als Microsoft. Das sage ich nicht nur, weil ich selbst ein wenig beigetragen habe; das Maß an Hingabe und Arbeitsaufwand ist erstaunlich
    • Ich frage mich, wie viele der aktuellen Minecraft-Entwickler früher Modder waren oder immer noch als Modder aktiv sind

  • Ich habe vor Kurzem das Spiel Tribal Trouble(https://github.com/bondolo/tribaltrouble) von GLFW auf SDL3 umgestellt, und das Refactoring verlief insgesamt recht reibungslos. Es gab ein paar Probleme mit exklusivem Vollbild und Desktop-Vollbild, aber die konnten letztlich gelöst werden
    Ich habe auch eine Demo geschrieben, um das knifflige Handling von Bildschirmmodi zu testen und zu dokumentieren. Das Spiel ist wie Minecraft in Java, aber für die Demo habe ich C verwendet, um sie möglichst einfach zu halten

    • Tribal Trouble, das ist wirklich ein Name, den ich lange nicht gehört habe. Ich erinnere mich, dass die Entwickler Java gewählt hatten, weil sie für die Spieleentwicklung eine seltsame oder ungewöhnliche Sprache verwenden wollten
    • Ich frage mich, ob es Probleme mit GLFW gab und warum man sich für den Wechsel zu SDL3 entschieden hat

  • Exklusives Vollbild unter Windows kann Spiele vor allem bei mehreren Monitoren zum Absturz bringen, und unter Wayland gibt es ein bekanntes Problem, bei dem schon das Betreten dieses Modus zum Absturz führt. Beides wirkt normalerweise wie ein Blocker-Bug, der einen Snapshot verzögern würde, daher hoffe ich, dass das vor dem offiziellen Release behoben wird

    • Ein Snapshot ist die unveränderte Auslieferung des aktuellen Zustands des Main-Branches, einschließlich Blocker-Bugs
      Das erwartete Stabilitätsniveau sehe ich ungefähr in dieser Reihenfolge: LTS-Version, Release-Version, Release Candidate, Beta, Alpha, Snapshot, gerade eben gemergter Commit, nicht gemergter PR, Entwurfs-PR. Bei einem großen Bug würde man einen Release Candidate oder eine Beta verschieben, bei einem kritischen Bug schon den Merge selbst verhindern, aber wegen eines Bugs, der CI bestanden hat und gemergt wurde, gibt es keinen Grund, einen Snapshot aufzuschieben
      Ein Snapshot ist eher ein regelmäßig ausgeschnittener und veröffentlichter Stand des aktuellen Zustands, damit Nutzer ihn ausführen und Feedback geben können, ohne Main selbst bauen zu müssen
    • Ein offizielles Release könnte man verschieben, aber es gibt keinen Grund, einen Snapshot zu verzögern. Man sollte ihn im aktuellen Zustand veröffentlichen, um per Telemetrie zu sehen, wie häufig bekannte Probleme tatsächlich auftreten, und damit vor dem offiziellen Release auch noch unbekannte Probleme entdeckt werden können
      Ein Snapshot hat nie versprochen, fehlerfrei zu sein; eher das Gegenteil ist die Grundannahme
    • Minecraft dürfte schon seit Langem standardmäßig randloses Vollbild verwenden, sofern man es nicht separat umstellt. In den letzten zehn Jahren haben viele Plattformen, Dienste und Apps exklusives Vollbild abgeschafft
    • Heutzutage ist das Rendern in einem Vollbildfenster üblicher als exklusives Vollbild. Fenster-Manager wenden auf das vorderste Vollbildfenster meist dieselben Optimierungen an, die früher nur dem exklusiven Modus vorbehalten waren
    • Es ist ein Snapshot, also kann so etwas passieren, und es wird wahrscheinlich im nächsten Snapshot behoben sein

  • Ich frage mich, wie ein technikaffiner Vater, der überhaupt nichts von Minecraft versteht, 2026 einen Familienserver aufsetzen sollte. Die Kinder spielen derzeit auf iPads und gelegentlich auf einem alten MacBook oder Windows-PC

    • Minecraft gibt es in Java- und Bedrock-Edition. Mobile-, Konsolen- und Windows-Store-Versionen basieren auf Bedrock, während die direkt von der Website geladene Version die Java-Edition ist
      Man kann einen normalen Java-Server betreiben und mit Geyser das Bedrock-Protokoll in Echtzeit umsetzen. Für stark eingeschränkte Bedrock-Clients braucht man eventuell Workarounds, aber man kann die Verwaltung auf einen Java-Server ausrichten, der mehr Möglichkeiten bietet
    • Online kursierende JVM-Tuning-Anleitungen für Minecraft sind oft veraltet oder falsch, daher ignoriert man sie besser
      Es reicht, eine aktuelle JVM zu verwenden, den maximalen Speicher so hoch zu setzen, wie es vertretbar ist, und ZGC zu nutzen. Manche Anleitungen drehen ohne Grundlage an zahlreichen Flags oder kombinieren widersprüchliche Einstellungen wie Eden-Größe und Ziel-Pausenzeiten
      ZGC hat sehr geringe Latenzen und verliert bei größerem Heap weniger an Leistung, aber um komprimierte Objekt-Header beizubehalten, bleibt man besser unter 32 GB. Eine moderne JVM verbessert auch Speicherverbrauch und Gesamtleistung
    • Folge einfach der Anleitung zum Einrichten eines Vanilla-Servers für die Java-Edition. Die Java-Edition läuft nur unter Windows, macOS und Linux, hat aber meiner Meinung nach weniger Bugs und ist besser als die Bedrock-Edition
      Wenn du mehr Leistung brauchst, installiere fabric und lithium. Mods wie Paper, Spigot oder Purpur können Automatisierungsanlagen kaputtmachen, daher würde ich sie meiden
    • Minecraft auf Handy und Tablet ist geschlossener und stärker eingeschränkt als die Java-Edition, daher hat man weniger Optionen
      Ich nutze itzg/docker-minecraft-server seit Jahren zuverlässig, und es war angenehm, dass das Image alles übernimmt, ohne jede Abhängigkeit einzeln installieren zu müssen. Es gibt auch ein Bedrock-Server-Image, aber ich habe es nicht richtig zum Laufen gebracht
      Am einfachsten ist der Betrieb, wenn alle auf Windows, Mac oder Linux die Java-Edition nutzen; andernfalls kann man auch den gehosteten Serverdienst Realms bezahlen
    • Wenn man berücksichtigt, dass die Kinder am liebsten auf dem iPad spielen, ist Realms ebenfalls einen Blick wert. Soweit ich weiß, bietet es für etwa 7 Dollar einen Server für 10 Personen, aber Java- und Bedrock-Abos sind getrennt, und die Tarifstruktur ist über mehrere Stufen zersplittert
      Je nach Ziel eines Familienservers passt das vielleicht nicht, aber für schnelles und einfaches gemeinsames Spielen der Kinder ist es wohl der unkomplizierteste Weg. Ich habe auch Kinder erlebt, die lange stur bei Bedrock blieben, dann zu Java wechselten und bereuten, nicht früher umgestiegen zu sein

  • Icculus hat ein großartiges Video veröffentlicht, in dem er ein Spiel von SDL2 auf SDL3 portiert; das Video zur Doom-Portierung gibt es hier: https://www.youtube.com/watch?v=ixdeGhsoxy8

    • Mir war nicht klar, dass Chocolate Doom auf SDL3 portiert wird und Icculus selbst daran arbeitet. Unter den Doom-Ports, die ich kenne, ist Woof! bereits umgestiegen: https://github.com/fabiangreffrath/woof

  • Es ist erstaunlich, wie Minecraft immer mehr einer eigenständigen Game-Engine ähnelt statt nur einem einfachen Spiel

  • Ich frage mich, ob dokumentiert ist, warum man GLFW verlassen hat. Ich habe ein Projekt, das GLFW nutzt, daher frage ich mich immer, ob SDL die bessere Wahl ist

    • Mit diesem Update funktioniert Wayland-Unterstützung ohne separate Arbeit. Früher brauchte man Workarounds, und selbst dann traten ständig neue Probleme auf, aber die meisten waren zufrieden damit, einfach über XWayland zu laufen, daher hat es kaum jemanden groß gekümmert.
      SDL3 hat von Haus aus eine solide Wayland-Unterstützung. In Minecraft wurde GLFW nur für Fenstererstellung, Taskleisten-Symbol, Vollbild und Eingabe verwendet, der Rest lief über rohes OpenGL, daher war der Wechsel auch einfach. Jetzt wird sogar Vulkan unterstützt, sodass man auf Linux-Desktops und dem Steam Deck einen vollständig modernen Stack nutzen kann
    • SDL unterstützt Mobilplattformen, GLFW hingegen nicht, daher könnte es darum gehen, plattformspezifische Codebasen zu vereinheitlichen
      SDL3 läuft sogar auf Android 4.2, und ich habe schon einmal eine App nur mit SDL3 und ImGui ohne Java gebaut
    • Ein Grund ist die Unterstützung für Eingabemethoden (IME)
    • SDL ist fast eher eine Plattformschicht, die man nahezu überall einsetzen kann. Es bietet Fenster, Grafik, Audio, Eingabe, Netzwerk und Threads, während GLFW nur Fenster, Grafikkontexte und Eingabe bietet, sodass man den Rest der Bibliotheken selbst bereitstellen muss
      Für nicht jedes Projekt macht das einen großen Unterschied, aber SDL bietet mehr Funktionen und ist portabler
    • Man kann auch ohne OpenGL oder Vulkan ein vollständiges 2D-Spiel nur mit der SDL-API erstellen

  • Auch das Rhythmusspiel osu! ist kürzlich von SDL2 auf SDL3 umgestiegen, wodurch sich Leistung und Latenz deutlich verbessert haben. Die Einführung von SDL3 wirkt etwas langsam, und es überrascht auch, dass Minecraft bisher GLFW verwendet hat
    Besonders nach dem Umstieg auf SDL3 verschwanden bei osu! die Verzögerungen, die auftraten, wenn der Discord-Client während des Spielens geöffnet war; ich meine, das in einem YouTube-Entwicklervideo gesehen zu haben

    • In einigen Linux-Distributionen sind sdl2-compat und sdl12-compat die Standardimplementierung für SDL2 bzw. 1.2, sodass viele bereits indirekt SDL3 nutzen. Dadurch laufen mehr Apps nativ auf Wayland mit geringerer Latenz als unter XWayland, und auch die Controller-Unterstützung wird besser
      Ubuntu 24.04 enthielt SDL3 anfangs nicht, und weil SDL3 neuer ist als gedacht, scheint das einer der Gründe zu sein, warum die Einführung langsamer verläuft als erwartet
    • osu! unterstützt alle drei großen Desktop-Betriebssysteme sowie iOS und Android und wollte Funktionen wie Wayland nativ beibehalten, daher hat der Umstieg auf SDL3 etwa zwei Jahre gedauert. Dieser Wechsel scheint nun zum ersten Mal wirklich die Endphase erreicht zu haben
    • In SDL3 wurden mehrere APIs geändert, was die Einführung schwieriger macht, vor allem über Binding-Bibliotheken

  • Bei SDL2 zeigte sich besonders bei der Abstraktion von GPU-APIs einschließlich Vulkan und Metal das Alter, daher ist der Umstieg auf SDL3 sinnvoll. Ich frage mich auch, ob sich damit die langjährigen Probleme der Java-Edition unter Linux mit Eingabelatenz und Alt+Tab durch den Wechsel der Fenster-/Eingabeschicht lösen lassen

    • Das eigentliche Migrationsziel war nicht SDL2, sondern GLFW, daher würde man sich bei einer Neuwahl natürlich für SDL3 entscheiden

  • Wenn man Mods aktiv unterstützen will, scheinen Sprachen wie Java oder C#, die sich leicht dekompilieren und zur Laufzeit modifizieren lassen, oder alternativ JVM und .NET CLR sinnvoller zu sein
    Wenn man interne Änderungen vornimmt und dabei auch Modder mitdenkt, bekommt man praktisch ohne Zusatzkosten eine hervorragende Modding-API

    • Was ein Spiel mit sehr vielen Mods wirklich braucht, ist vor allem eine ausreichend große Nutzerbasis. Für engagierte Modder sind ein wenig Binary-Patching oder DLL-Injection kein Hindernis