Videospiele ohne Game-Engine entwickeln (2025)

 (noelberry.ca)
33 Punkte von GN⁺ 2025-05-21 | 5 Kommentare | Auf WhatsApp teilen
  • Auch ohne kommerzielle Game-Engine lässt sich Spieleentwicklung gut und mit Spaß umsetzen
  • Die meisten Funktionen großer Engines werden nicht benötigt, und mit selbst geschriebenen Tools steigen Flexibilität und Entwicklungseffizienz
  • Mit modernem C# und Open-Source-Bibliotheken lässt sich unabhängig von der Teamgröße eine vollwertige Entwicklungsumgebung aufbauen
  • Durch die Kombination von Bibliotheken wie FMOD, SDL3, Dear ImGui und eigenen Tools lässt sich eine passgenaue Pipeline zusammenstellen
  • Im Hinblick auf plattformübergreifende Entwicklung, Wartung und Portabilität ist ein selbst aufgebautes, schlankes Framework sehr vorteilhaft

Vorwort: Rückblick eines Spieleentwicklers mit 20 Jahren Erfahrung

  • Auch 2025 entwickle ich Videospiele noch ohne kommerzielle Game-Engine
  • In meinem Umfeld sind viele überrascht, dass ich keine kommerzielle Engine nutze
  • Die Grundfunktionen großer Engines wie Unity oder Unreal sind im Vergleich zur Eigenimplementierung oft nicht zufriedenstellend, sodass man am Ende vieles doch neu baut
  • Wer kommerzielle Engines nutzt, ist häufig Problemen durch Änderungen der Geschäftspolitik oder Updates ausgesetzt
  • Es ist effizienter, kleine maßgeschneiderte Tools direkt für das jeweilige Projekt selbst zu bauen, und langfristig sind sie auch leichter wartbar

Wahl der Programmiersprache für die Spieleentwicklung

  • Seit vielen Jahren ist C# meine Hauptsprache
  • Modernes C# hat sich gegenüber früher bei Performance, Syntax und Developer Experience stark verbessert
  • Mit Hot-Reload-Funktionen wie dotnet watch lassen sich Codeänderungen in Echtzeit sehr bequem testen
  • Auch Nicht-Entwickler finden leicht Zugang, was die Aufgabenteilung und Zusammenarbeit im Team deutlich effizienter macht
  • Die eingebaute Reflection ist ein großer Vorteil beim Bau von Editoren und Tools

Plattformübergreifende Bibliotheken sowie Rendering- und Eingabe-Implementierung

  • Mit SDL3 werden alle grundlegenden Funktionen wie Fenster, Rendering, Controller und Plattformunterstützung umgesetzt
  • Durch die GPU abstraction von SDL3 wird die Unterstützung verschiedener Umgebungen wie DirectX, Vulkan, Metal deutlich einfacher
  • Eine selbst geschriebene C#-Schicht über SDL (z. B. Foster) dient als gemeinsame Utility-Ebene
  • Als letztes verbliebenes kommerzielles Audio-Tool wird FMOD verwendet, ansonsten basiert die Pipeline auf Open Source
  • Früher wurden auch OpenGL/DirectX-Implementierungen direkt umgesetzt, doch die Stabilität von SDL ist ein erheblicher Vorteil

Umgang mit Assets

  • Mit einer eigenen Engine werden einfach nur die Dateien geladen, die das Spiel tatsächlich benötigt
  • Bei kleineren Assets, etwa in Pixel-Art-Spielen, werden alle Dateien beim Initialisieren auf einmal geladen
  • In größeren Projekten werden nur benötigte Assets bei Bedarf geladen und beim Szenenwechsel wieder aus dem Speicher freigegeben
  • Wenn Konvertierung nötig ist, reicht meist ein Skript aus, das die Verarbeitung beim Build automatisch erledigt

Level-Editoren und UI-Tools

  • Open-Source-Level-Editoren wie LDtk, Tiled, Trenchbroom lassen sich leicht mit den Projektdaten verbinden
  • Meist wird für jedes Projekt ein maßgeschneiderter Editor direkt selbst implementiert
  • Die UI selbst wird nicht von Grund auf geschrieben; stattdessen wird das Immediate-Mode-GUI von Dear ImGui aktiv genutzt
  • Mit der Kombination aus Reflection in C# und ImGui lässt sich der Zustand von Spielobjekten in Echtzeit visualisieren
  • Je nach Bedarf werden externe Tools und eigene Werkzeuge gemeinsam eingesetzt

Plattformübergreifende Entwicklung und Konsolen-Portabilität

  • Früher war wegen Konsolenports oft C++ nötig, doch mit C# Native-AOT hat sich dieses Problem weitgehend gelöst
  • Open-Source-Frameworks wie FNA bauen ihre Konsolenunterstützung aktiv weiter aus
  • Mit der allgemeinen Abstraktionsschicht von SDL3 lässt sich auf den meisten Systemen dieselbe Codebasis betreiben

Entwicklungsumgebung: Ein offenes Ökosystem mit Linux im Mittelpunkt

  • Die Hauptentwicklungsplattform wurde auf Linux umgestellt, was hervorragend mit Open-Source-Toolchains harmoniert
  • Es gibt zwar noch Bindungen an bestimmte kommerzielle Software (z. B. vscode, github), doch mit dem Wachstum des Open-Source-Ökosystems nimmt auch die Unterstützung zu
  • Persönlich wird dieselbe Arbeitsumgebung bereits auf verschiedenen Linux-basierten Plattformen wie dem Steam Deck genutzt

Zusätzliche Q&A und Beispiele

  • Frage zu Godot: Wenn der Bedarf an Entwicklung mit einer Open-Source-Engine im Vordergrund steht, wird Godot empfohlen; ansonsten werden eigene Tools bevorzugt
  • 3D-Arbeit: Große Engines haben Vorteile, aber für kleine spezialisierte Projekte reicht ein maßgeschneidertes Framework völlig aus
  • Anforderungen an High-End-Technik: Je nach Anforderungsniveau kann auch eine große Engine wie Unreal sinnvoll sein
  • Engine-Wechsel im Team: Besonders geeignet für kleine Teams oder Solo-Entwicklung; auch mittelgroße und große Studios wechseln zunehmend zu Custom-Engines, um langfristige Risiken zu vermeiden
  • Asset-Workflow: Aseprite-Dateien lassen sich mithilfe eingebauter Tags und Timings automatisch in Animationen umwandeln

Fazit

  • Spiele ohne kommerzielle Game-Engine zu entwickeln, ist eine Entscheidung, die vor allem von persönlichen Vorlieben und der Arbeitsweise abhängt
  • Entscheidend ist, die eigenen Anforderungen und den Spaß an der Arbeit in den Vordergrund zu stellen und die passende Methode zu wählen

Verwandte Beiträge

5 Kommentare

 
assembler 2025-05-29

Das ist eine gute Entwicklung.
Ich gehöre zur ersten Generation der Spieleentwickler.
Bevor Unreal aufkam, war es für Entwicklungsstudios selbstverständlich, ihre eigenen Engines zu entwickeln,
und genau das war ihre Wettbewerbsfähigkeit.
Bei der Engine-Entwicklung machte die Tool-Entwicklung auf Basis von Core, Kernel, Rendering und sonstiger Ein-/Ausgabe den größten Teil aus.
Damals war ich für Partikel-, Sound-, Layer- und Objekt-Tools zuständig,
und wenn man alle Teammitglieder zusammenzählte, waren es statt 7 wohl locker mehr als 20.

Irgendwann kam dann Unreal, und als massenhaft Spiele von der Stange herausströmten,
hat man nicht mehr in die Engine-Entwicklung investiert.
Ich glaube, damals haben sich viele selbstständig gemacht und Firmen gegründet.
Das ist schon 27 Jahre her.

Inzwischen bin auch ich älter geworden und arbeite heute in einem anderen Bereich, nicht mehr an Spielen.

Ich erinnere mich wehmütig an die Zeit, als ich je nach Grafikkarte Core-Arbeit für die verschiedenen DirectX- und OpenGL-Modi gemacht habe.

Gambare ...
 
chanapple 2025-05-21

In letzter Zeit habe ich lange nach einer Engine gesucht, um ein Strategiespiel zu machen, und dachte mir irgendwann: Dann ist es wohl besser, selbst eine zu bauen. Wenn ich nun ein erfolgreich umgesetztes Beispiel sehe, schöpfe ich richtig Mut.
 
GN⁺ 2025-05-21
Hacker-News-Kommentare

  • Ich entwickle seit 5 Jahren allein eine 2D-Game-Engine und arbeite auch beruflich in diesem Bereich; dabei möchte ich einen wichtigen Punkt erklären, den viele nicht kennen
    Die Engine ist der einfache Teil
    Der wirklich wichtige Teil sind die Tooling-, Content- und Asset-Pipelines rund um die Engine
    Import von Texturen, Audio und Modelldateien (gltf, fbx, Animationen usw.) aus verschiedenen Datenquellen und Formaten
    Grundlegende Editierfunktionen in einer Editor-App wie Zuschneiden, Kopieren, Einfügen, Rückgängig, Wiederholen, Speichern und Löschen
    Visualisierung und Funktionen, mit denen Entwickler im Editor echte Daten erstellen und bearbeiten können (Entities, Animationen, Szenen, Audio-Graphen, Scripting-Unterstützung usw.)
    Datenpaketierung und Vorverarbeitung wie statisches Geometrie-Baking, Shader-Kompilierung, Resampling und Packing von Texturen und Audio sowie das Erstellen von Asset-Packs für Spielinhalte
    Wenn all das erledigt ist, ist der eigentliche Runtime-Teil (also die Hauptschleife des Spiels und die Untersysteme) nur ein kleiner Teil des Gesamtsystems
    Deshalb gibt es in Spielestudios nur wenige Engine-Verantwortliche und überwiegend Programmierer, die Tools bauen
    detonator-Engine: https://github.com/ensisoft/detonator

    • Es ist wichtig, sich eher darauf zu konzentrieren, eine Engine für das eigene Spiel zu bauen, statt auf Allgemeingültigkeit
      UI, Kompression usw. lassen sich mit Bibliotheken und Frameworks lösen
      Dass der OP kleine Bibliotheken wie imGUI verwendet, ist ein gutes Beispiel
      Da man keine Engine für alle Spiele baut, fällt in der Praxis vieles weg, was man gar nicht tun muss

    • Eine Engine ist im Grunde ein kleiner Runtime-Anhang an einer Asset-Pipeline
      Heutzutage werden Shader-Compiler sogar allmählich wichtiger als 3D-APIs
      Der interessante Teil verlagert sich auf den Shader-Compiler, während die 3D-API nur noch Shader ausführt und Daten weiterreicht

    • Wenn Leute von einer Engine sprechen, meinen sie oft auch die Asset-Pipeline und den Editor mit
      Eine moderne Engine ist nicht nur eine Main Loop plus ein paar 3D-API-Funktionen
      Selbst wenn man eine Engine wie Unity verwendet, sind Entwickler, die nur Render-Code schreiben, eine sehr kleine Minderheit
      Natürlich heißt die Nutzung von Unity oder Unreal nicht, dass man nie direkt mit Asset-Tools arbeiten muss

    • Ich stimme dem sehr zu, nachdem ich kürzlich die Engine für einen Nachfolger komplett neu aufgesetzt habe
      Wie ich im Postmortem geschrieben habe, denken die meisten bei einer Engine an den Code, der im Spiel-Binary enthalten ist; tatsächlich macht aber der nicht mit dem Spiel ausgelieferte Code für Dinge wie Level-Editor, Content-Pipeline, Debugging/Profiling und Entwicklungs-Workflow den größeren Anteil aus
      Tool-Entwicklung ist langweiliger und leichter zermürbend als Engine-Entwicklung
      Deshalb bleiben viele Spielprojekte mit Custom Engine auf halbem Weg stecken
      Postmortem: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

    • Einen Editor von Grund auf neu zu bauen, ist ein erheblicher Aufwand
      Wenn möglich, nutze ich vorhandene Editoren
      Zum Beispiel die Kombination aus TrenchBroom (Quake-Editor) + func_godot, oder im 2D-Bereich Tiled
      Für die Verwaltung von Spieldaten gab es CastleDB, das inzwischen mit Hide (einem vollwertigen 3D-Editor) integriert ist
      Nachdem man die Tools gebaut hat, sind Game-Design und das Erstellen von Inhalten der nächste große Schritt

  • Vor ein paar Jahren habe ich mit SDL2 und etwas C++ eine einfache sprite-Klasse gebaut und einfache Funktionen wie Kollisionen hinzugefügt
    Wenn ich das, was ich gebaut habe, überhaupt eine Engine nennen wollte, dann war es eher eine Art E-Bike-Unterstützung
    Ein Punkt ist, dass die "Engine" oft das gesamte Projekt bzw. Spiel anführt
    Oft passt man das Spiel an die Engine an, weshalb ich große Engines wie Unity grundsätzlich meide
    Am Ende entsteht mit solchen Engines oft immer dieselbe Spielstruktur, nur mit anderen Assets
    Persönlich finde ich, dass man statt Zeit mit dem Lernen einer Engine zu verschwenden mit SDL bei einer kurzen Lernkurve anfangen kann, und SDL lässt sich auch für andere plattformübergreifende Projekte außerhalb von Spielen nutzen
    Mein Spiel: https://store.steampowered.com/app/2318420/Glypha_Vintage/

  • Es heißt zwar, eine eigene Engine zu bauen dauere lange, aber wie viel Zeit braucht man, um Unreal oder Unity wirklich so gut zu beherrschen, dass man Ideen sofort als Spiel umsetzen kann?
    Sobald meine eigene Engine fertig ist, habe ich dieses Kompetenzniveau schließlich direkt erreicht, also spare ich langfristig Zeit
    Je mehr Erfahrung man als Ingenieur sammelt, desto vorteilhafter wird es zeitlich, Dinge selbst zu bauen
    Je einzigartiger oder nischiger das Spiel ist, desto plausibler ist eine Eigenentwicklung
    Monatelang in der komplexen UI von Unreal herumzuirren und dann festzustellen, dass das Gewünschte in einer General-Purpose-Engine ohnehin kaum möglich ist, ist ineffizient
    Andererseits ist es bei einem surrealen Open-World-RPG keine gute Wahl, alles selbst zu bauen
    Die Beschränkungen einer Custom Engine können sogar Kreativität auslösen, und selbst wenn das Ergebnis nicht Spitzenklasse ist, kommen originellere Spiele dabei heraus

    • Ich habe schon einmal selbst eine Engine gebaut
      Am Anfang hat es mit unzähligen Irrtümern und Sackgassen ungefähr ein Jahr gedauert
      Ich habe fast alle Untersysteme implementiert, die man in Spielen sieht: 3D-Rendering, adaptive UI, Skeletal Animation, Save-Dateien, Smart Objects, Pathfinding, Scripting, Audio, Physik usw.
      Insbesondere habe ich eine Rückspulfunktion direkt selbst umgesetzt (ähnlich dem System aus Braid)
      Solche Funktionen benötigen Unterstützung durch alle Untersysteme der Engine, etwa Scripting und Physik
      Da ich jeden Teil meiner Engine kenne, habe ich enorme Freiheit bei der Entwicklung zusätzlicher Funktionen
      Nach einem Jahr Entwicklung kam aber allmählich Burnout auf und die Motivation verschwand

    • Unreal kenne ich nicht, aber mit Unity kann man im Vergleich zum direkten Coden mehr als 10-mal schneller entwickeln
      Eine Physikfunktion lässt sich in 1 Minute hinzufügen, während in einer selbstgebauten Engine schon die Integration einer externen Bibliothek 1 bis 2 Tage kosten kann
      Auch die internen Visualisierungsfunktionen, die Unreal-Nutzer Noel zeigt, sind in Unity eingebaut
      Editierfunktionen wie das Bearbeiten von Bounding Boxes sind ebenfalls standardmäßig vorhanden
      Falls das Standardverhalten der Engine nicht ausreicht, lässt es sich mit ImGui oder einer CSS-Engine auf Basis von Yoga leicht erweitern
      Fortgeschrittene Partikel-Editoren, vereinfachte Shader-Komplexität, modulares Daten-Streaming und viele weitere Funktionen sind vorhanden
      Theoretisch würde man das alles gern selbst bauen, aber am Ende hat die Fertigstellung aus Zeitgründen Priorität

    • Wie lange es dauert, Unreal oder Unity zu lernen und Spielideen sofort umzusetzen, ist eine andere Frage als die Zeit, die man zum Bau einer eigenen Engine braucht
      Gib mir nur grob eine Idee, und ich kann in wenigen Stunden einen spielbaren Gameplay-Prototyp bauen
      Bei Unity braucht man anfangs nur zu programmieren, und in Unreal kommt man mit Blueprints fast bis kurz vor die Veröffentlichung eines Spiels
      Siehe dieses Video, in dem in 10 Minuten ein Prototyp im Stil von Super Hexagon entsteht: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
      Das Einzige, was an Unity wirklich speziell ist, sind vielleicht Prefabs; der Rest sind allgemeine Konzepte der Spieleentwicklung
      Aus Sicht eines Unreal-Entwicklers ließe sich ein ähnlicher Prototyp in Unity ebenfalls in unter 1 Stunde bauen

    • Schon die Annahme "nach Fertigstellung der Engine" könnte unrealistisch sein
      Selbst etwas Einfaches wie GameObject.Instantiate direkt in einer Engine zu implementieren, erfordert enorme Ressourcen
      Wenn man die Komplexität von 2D-/3D-Physik, Shadern, Plattformunterstützung usw. berücksichtigt
      Wenn das Ziel die Engine ist, dann bau die Engine; wenn das Ziel ein Spiel ist, dann bau das Spiel selbst

    • Wenn man genug Wissen in der Spieleentwicklung hat, um überhaupt eine Game-Engine bauen zu können
      Dann reicht ein Tag, um Unreal oder Unity zu lernen und einen Prototypen zu bauen
      Bis zur perfekten Beherrschung dauert es zwar lange, aber die Zeit bis zu einem gewünschten Spielprototypen ist überhaupt nicht vergleichbar

  • Spiele ohne große "Alleskönner"-Engine zu bauen ist einfacher, macht mehr Spaß und ist manchmal effizienter
    Wenn man sich allerdings in bestimmte Engine-Funktionen vertieft (z. B. Inverse Kinematik oder Animation Blending in Unreal), denkt man schnell: "Gut, dass ich mich nicht lieber 2 bis 3 Wochen lang selbst damit herumgeschlagen habe"
    Minimalismus und das Vermeiden von Bloat sind wichtig, aber diese Engines sind beliebt, weil sie einem die schweren Arbeiten abnehmen

    • Früher habe ich auch so gearbeitet
      Als ich mein erstes 3D-Spiel machte, implementierte ich Eingabe, Objektverwaltung, Culling, Modellladen, Mathebibliothek, Grafik, Normal Maps, SSAA usw. – und am Ende lag die Fertigstellungsquote des eigentlichen Spiels bei 0 %
      Für Hobby-2D-Projekte arbeite ich aber weiterhin komplett ohne Abhängigkeiten nur mit dem Browser-Canvas
      Im Grunde übernimmt der Browser dort die Rolle der Engine

    • Zur Aussage "Gut, dass ich es nicht selbst gebaut habe"
      Wenn man langfristig an eine Indie-Entwicklerkarriere denkt, ist ein paar Wochen mehr Aufwand oft wertvoller, weil man das Thema tief versteht und 100 % des Source Codes besitzt und wiederverwenden kann

    • Meine Abschlussarbeit bestand darin, eine auf NeXTSTEP/Objective-C basierende Partikel-Engine nach Windows 95/Visual C++ zu portieren (OpenGL-basiert, inklusive eines Marching-Cubes-Beispiels)
      So etwas wäre in heutigen Engines nur noch ein Teil einer Ein-Zeilen-Funktion

    • Mit einer Engine kommt ein Projekt viel schneller voran, und man muss nicht so viel Zeit in Infrastrukturentwicklung stecken
      Für die meisten ist es kein großer Spaß, das Rad neu zu erfinden

    • Funktionen wie Inverse Kinematik oder Animation Blending
      Sind es wert, implementiert zu werden, wenn sie im Kern des Spiels stehen; andernfalls sind sie eine unnötige technische Falle

  • Ich mache Spiele auf meine Weise mit Lua & Love2D
    Gerade dieses selbst auferlegte Constraint ist ein zentraler Teil des Spaßes
    Wenn die Entwicklung keinen Spaß mehr macht, ist das ein Zeichen, dass etwas nicht stimmt und man nach einem besseren Weg suchen sollte
    Mein Spiel YOYOZO ist mit 39 KB winzig, stand aber zusammen mit großen Titeln auf der Liste der besten Spiele 2023 von Ars Technica
    https://news.ycombinator.com/item?id=38372936

    • Ich erinnere mich an das Spiel
      Einige Jahre nach dem Kauf meines Playdate habe ich angefangen, mit dem SDK herumzuspielen, und lerne dabei auch zum ersten Mal Lua
      Mir fehlen starke Typisierung und sprachliche Sicherheitsmechanismen, aber für den jeweiligen Kontext reicht es aus
      Bisher habe ich nur eine kleine Tech-Demo gebaut, in der Text je nach Kurbel in einem Fake-3D-Raum rotiert
      https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
      Bei diesem Projekt wurde mir klar, dass ich durch meine lange CRUD-/Web-App-Karriere fast die ganze Trigonometrie vergessen hatte
      Der größte Vorteil bei der Playdate-Entwicklung ist das feste Canvas: Man setzt die Pixelposition einmal fest, und es funktioniert auf jedem Gerät genauso – eine befreiende Erfahrung
      Nach all den Jahren mit responsiven UIs war das für mich etwas völlig Neues

  • Wenn ich versuche, mit einer Game-Engine (Godot, Unity, Unreal usw.) etwas zu bauen, ringe ich am Ende immer mit der Engine selbst
    Am Ende fühlt es sich an, als würde man nur Assets auf eine vorgegebene Spielform legen, statt wirklich das Spiel zu bauen, das man möchte
    Als Analogie zur Webentwicklung wirkt es wie ein Fertigprodukt à la WordPress
    Wenn die Grundkonfiguration nicht zur eigenen Absicht passt, braucht man enorme Hacks und Workarounds

  • Der Autor (Noel) hat das Spiel Celeste gemacht, das sich über 3 Millionen Mal verkauft hat
    https://en.wikipedia.org/wiki/Celeste_(video_game)

  • Ich stimme in weiten Teilen zu und baue selbst ein C#-basiertes Game-Framework (im Geiste ein Nachfolger von XNA/Monogame, mit Sokol statt SDL)
    https://zinc.graphics/
    Stärken von modernem C#: plattformübergreifend, NativeAOT-Kompilierung, natives Hot Reloading, Reflection usw.
    Ich persönlich habe auch Source Generators ergänzt
    Das negative Image aus der Vergangenheit ist noch da, aber die Entwicklung von CoreCLR und der Sprache in den letzten 5 Jahren ist bemerkenswert
    Das Einzige, was ich mir wirklich wünsche, sind Union Types; dazu gibt es aktuell einen Vorschlag, und ich hoffe auf eine Aufnahme im nächsten Jahr
    https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md

    • Gibt es zufällig Ressourcen, die du zum Einstieg in C# für solche Projekte empfehlen würdest?
      Ich habe C# nur unter Win32 oder in Unity verwendet und habe zwar Low-Level-Engine-Wissen aus der C/C++-Welt, aber ich dachte immer, C# sei für plattformübergreifende Ziele wie Spielkonsolen ungeeignet
      Inzwischen merke ich, dass ich damit offenbar falsch lag

  • Bei jeder Art von Software beginne ich am liebsten bei null
    Für Leute mit Erfahrung in großen Projekten mag das langsam wirken, aber in der Startup-Phase ist es oft sogar schneller
    Man implementiert nur das Nötigste, und sobald ein gewisses Maß an Abstraktion vorhanden ist, lassen sich neue Funktionen schneller hinzufügen
    Die Produktivität großer Enterprise-Software und meiner selbstgeschriebenen Mini-Engine ist völlig unterschiedlich
    Code, den ich selbst geschrieben habe, lässt sich sofort schneiden und refaktorieren, also geht alles viel schneller
    Deshalb bevorzuge ich Microservices und kleine Teams
    Wenn man alles selbst baut, muss man zwangsläufig durch Versuch und Irrtum sowie ein Minenfeld kaputter Ansätze gehen, und es dauert Jahre, die wahren Eigenschaften einer Sprache oder Plattform wirklich zu verstehen
    Aber genau dieser Prozess bleibt am Ende als innere Stärke des Entwicklers erhalten
 
kissdesty 2025-06-10

Wie wäre es statt einer Engine damit, ein Framework auf dem Niveau von MonoGame zu verwenden?~
 
lazyhack 2025-05-23

"Dass dieser Prozess selbst letztlich zur inneren Stärke des Entwicklers wird" – dem stimme ich voll und ganz zu.