Warum ich Spiele in C entwickle (ja, in C)

 (jonathanwhiting.com)
3 Punkte von GN⁺ 2026-02-09 | 1 Kommentare | Auf WhatsApp teilen
  • Alle Spiele meiner persönlichen Projekte werden in „reinem C“ entwickelt, was heute eine seltene Wahl ist
  • Die wichtigsten Kriterien bei der Sprachwahl sind Zuverlässigkeit, Portabilität und langfristige Nachhaltigkeit, ohne an ein bestimmtes OS oder eine Plattform gebunden zu sein
  • Geschätzt werden Einfachheit und schnelle Compile-Zeiten sowie strenge Typprüfung und ein starkes Warnsystem
  • Alternative Sprachen wie C++, C#, Java, Go und Haxe wurden geprüft, aber wegen Komplexität, GC oder erzwungenem OOP als ungeeignet bewertet
  • C ist gefährlich, aber einfach und schnell und bleibt dank breiter Plattformunterstützung und eines robusten Library-Ökosystems weiterhin die beste Wahl

Kriterien für die Sprachwahl

  • Die Grundvoraussetzung ist Zuverlässigkeit und Stabilität, damit keine Zeit mit Bugs verschwendet wird, die ich nicht selbst verursacht habe
    • Früher wurden Flash-basierte Spiele entwickelt, aber durch den Niedergang von Flash möchte ich mich statt auf die Portierung auf neue Plattformen lieber auf das Entwickeln neuer Spiele konzentrieren
    • Um nicht von einem bestimmten OS abhängig zu sein und die Möglichkeit der Konsolenentwicklung offenzuhalten, werden Portabilität und Unterstützung durch allgemeine Libraries hoch gewichtet
  • Als wünschenswerte Eigenschaften werden eine einfache Syntax und eine leicht merkbare Struktur genannt
    • So lässt sich vermeiden, ständig komplexe APIs oder Sprachfeatures nachschlagen zu müssen
  • Durch strenge Typprüfung, starke Warnungen und statische Analyse sollen Bugs reduziert werden, und mit guten Debuggern und dynamischen Analysewerkzeugen sollen Probleme leicht auffindbar sein
  • Compile-Zeiten werden als sehr wichtig angesehen
    • Lange Wartezeiten unterbrechen die Konzentration und senken die Produktivität
  • Gegenüber objektorientierter Programmierung (OOP) besteht Skepsis; bevorzugt wird eine Herangehensweise, bei der Daten und Code getrennt und je nach Situation passend behandelt werden

Bewertung wichtiger Alternativsprachen

  • C++
    • Im Game Development zwar weiterhin Standard, aber wegen Komplexität und langsamer Compile-Zeiten unbefriedigend
    • Es bietet hohe Performance und viele Features, bringt aber auch viele unerwünschte Funktionen und hohe Komplexitätskosten mit sich
  • C# und Java
    • Sie sind wortreich und komplex und bieten wegen ihrer stark OOP-zentrierten Struktur wenig Freiheit
    • Als High-Level-Sprachen verstecken sie Komplexität, verhindern die grundlegenden Probleme aber nicht
  • Go
    • Wird als moderne Neuinterpretation von C positiv bewertet, ist aber wegen stop-the-world Garbage Collection für Game Development ungeeignet
    • Außerdem gibt es zu wenige Libraries für Spiele, und es bestehen Bedenken hinsichtlich der langfristigen Beständigkeit
  • JavaScript
    • Wegen des schnellen Wandels im Web-Entwicklungsumfeld und des Endes von Flash wirkt es instabil
    • Aufgrund der lockeren Syntax wird es als ungeeignet für das Schreiben großer Software bewertet
  • Haxe
    • Für Web-Entwicklung wird es als vielversprechend eingeschätzt, aber als vergleichsweise junge Sprache bestehen Bedenken hinsichtlich ihrer Beständigkeit
  • Eine eigene Sprache entwickeln
    • Das ist ein reizvoller Gedanke, wird aber wegen des Verzichts auf bestehende Libraries und der Last, Kompatibilität aufrechtzuerhalten, als unrealistisch bewertet

Warum ich mich für C entscheide

  • Als gefährliche, aber vertrauenswürdige Sprache ist C dank seiner einfachen Struktur bei sorgfältiger Nutzung stabil
    • Sie wird mit einem „scharfen Messer“ verglichen: schwer zu handhaben, aber als geübte Person ein mächtiges Werkzeug
  • Compile-Zeiten sind sehr schnell, und Programme lassen sich auf nahezu jeder Plattform ausführen
    • Auch der Portierungsprozess ist vergleichsweise einfach, und langfristig ist die Sprache sehr nachhaltig
  • Unterstützung durch Libraries und Tooling ist stark und wird kontinuierlich gepflegt
  • Persönlich besteht bereits viel Erfahrung mit „reinem C“-Code, daher ist die Sprache vertraut
  • Die Nutzung von C wird anderen nicht empfohlen; es ist eine auf persönliche Vorlieben und die eigene Arbeitsweise optimierte Wahl

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-09
Hacker-News-Kommentare

  • Ich schreibe Code meistens im C-Stil, nutze aber C++-Features nur dann, wenn ich sie wirklich brauche
    Deshalb sieht es auf den ersten Blick manchmal sogar wie Rust-Code aus
    Leute, die sagen, sie schreiben Spiele in C, hassen oft C++-Features und implementieren dann am Ende virtuelle Interfaces selbst oder bauen riesige switch-Anweisungen, um dasselbe zu erreichen
    Wenn man Features einer Sprache nicht nutzen will, kann man sie einfach weglassen — sich schon über ihre bloße Existenz zu beschweren, halte ich für wenig sinnvoll
    C++ wird nicht langsam beim Kompilieren, solange man Templates nicht exzessiv missbraucht

    • Allein mag das funktionieren, aber in langlebigen Projekten, die über Jahre im Team gepflegt werden, sieht die Lage anders aus
      Mit der Zeit wechseln Teammitglieder und Leads, und die Menge der verwendeten Features wächst immer weiter
      Einmal gewachsene Feature-Nutzung wieder einzudampfen, ist sehr schwierig
      Außerdem muss man womöglich Bibliotheken verwenden, die Features einsetzen, die man selbst nicht will
      Ich mag zum Beispiel implizite Aufrufe nicht, etwa Destruktoren oder Operator Overloading, aber wenn eine Bibliothek das nutzt, muss man letztlich doch mitziehen
    • Wenigstens kann man switch-Anweisungen lesen
      Eines der schlimmsten Dinge an C++ ist die enorme Menge an automatisch erzeugtem verstecktem Code
    • Dynamischer Dispatch in C++ funktioniert so, dass an jeden Typ eine vtable gehängt wird
      Selbst wenn der Großteil des Codes mit konkreten Typen wie Goose oder Duck arbeitet, trägt jedes Objekt einen vtable-Zeiger mit sich herum
      Rust dagegen nutzt vtables nur dort, wo sie tatsächlich gebraucht werden, und spart so Speicher
      C-Programmierer implementieren nur die Funktionen, die sie wirklich benötigen, und sind deshalb weniger an von der Sprache erzwungene Strukturen gebunden
    • C++ ist auch ohne exzessiven Template-Einsatz langsam
      Schon wenn man nur <vector> einbindet, holt man Zehntausende Zeilen Code ins Projekt
      Wenn man dann die Standardbibliothek nicht nutzt, beginnt sofort die Debatte, warum man „das Rad neu erfindet“
      Wenn diese Diskussion ständig wiederkehrt, ist es einfach viel angenehmer, gleich zu C zurückzukehren
      Ich selbst bin ungefähr 2017 zu C gewechselt, und bis heute ermüdet mich fast jede C++-Bibliothek, die ich benutze
      Dear ImGui ist eine Ausnahme, aber selbst dort bevorzuge ich C-Bindings
    • Ich habe tatsächlich schon C++-Dateien geschrieben, ohne auch nur ein einziges C++-Feature zu verwenden
      Als ich die Dateiendung in .c geändert habe, halbierte sich die Kompilierzeit

  • Ich mag den rauen, einfachen Charakter von C, nur den Präprozessor kann ich nicht ausstehen
    Deshalb wirkt Zig für mich wie ein Geschenk des Himmels — einfacher als C und zugleich sprachlich präziser entworfen
    Zig unterscheidet zum Beispiel zwischen Single-Pointern und Array-Pointern
    Man kann C-Bibliotheken importieren und sie leichter benutzbar machen, was für die Spieleentwicklung sehr nützlich ist
    Die meisten C++-Bibliotheken liefern auch C-Header mit
    Bei zig-gamedev gibt es viele solcher in Zig überführten C-Bibliotheken
    Anstelle eines Präprozessors ist Zigs comptime deutlich besser, und im Grunde ist es einfach nur „Zig-Code, der zur Compile-Zeit ausgeführt wird“

    • In der Praxis gibt es unter C++-Bibliotheken aber viel zu wenige, die überhaupt C-Header exportieren

  • Ich kann die Gedanken des Autors ebenfalls nachvollziehen
    Der wichtigste Grund, warum man eine Sprache mögen lernt, ist Einfachheit
    Deshalb bevorzuge ich Sprachen wie C, Go, Odin und Zig
    Aber auch Sprachen, die mit notwendiger Komplexität elegant umgehen können, sind wichtig
    Für Netzwerkcode, bei dem Speichersicherheit, Nebenläufigkeit und funktionale Muster nötig sind, fühlt sich Rust natürlich an
    Für einfachen, schnellen Code wie bei Indie-Games passen dagegen C oder Odin sehr gut
    Odin fühlt sich an wie eine Kombination aus Gos Einfachheit und Cs Performance, deshalb würde ich es empfehlen
    Auch mit Raylib lassen sich leicht Spiele bauen

    • Interessanterweise beschreibe ich Zig oft als Mittelweg zwischen Go und C
      Mich würde interessieren, ob du meinst, dass Odin diese Rolle besser erfüllt als Zig
    • Nur zur Klarstellung: Die Sprache heißt Go, golang ist lediglich der Domainname

  • Im Originaltext hieß es, Go habe wenig Unterstützung durch Game-Bibliotheken, aber das wirkt wie ein Text von etwa 2015
    Heute könnte die Lage bereits anders sein

    • In der Wayback Machine gibt es einen Snapshot von Januar 2016
      Dort kann man auch Screenshots der damals entwickelten Spiele sehen
      Zum Beispiel hat Knossu einen eigenständigen 3D-Stil

  • 2026 Spiele in C zu schreiben, ist vielleicht ein bisschen verrückt, aber ich mache es auch
    Zum Beispiel habe ich Chrysalis in C entwickelt (mit GLFW3 und FMOD)

    • Ich arbeite seit zwei Jahren mit der Jedi-Academy-Codebasis (C & C++)
      Sie basiert auf idTech3, und das Kampfsystem ist so fein austariert, dass schon kleine Änderungen das gesamte Balancing zerstören
      Sogar ein zusätzliches i++ kann das Timing verändern
      Deshalb verwenden wir bis heute denselben Compiler wie vor 22 Jahren
      Es gibt modernisierte Forks, aber sie haben das ursprüngliche Spielgefühl verloren
      idTech3 ist wirklich eine Engine, die die Essenz von C zeigt

  • Tausende Spiele wurden in C geschrieben, und Grafik-APIs wie OpenGL, Vulkan oder DX basieren ebenfalls komplett auf C
    Deshalb ist das überhaupt nichts Ungewöhnliches
    Die meisten Game-Engines werden ebenfalls in C/C++ geschrieben

    • Die Khronos-APIs sind C, DirectX basiert auf COM/WinRT in C++, und Metal ist eine Mischung aus Objective-C und C++
      Bei Konsolen ist es je nach Generation unterschiedlich
    • SDL3 ist ebenfalls in C geschrieben, und auch die aktuelle Version von Box2D wurde zurück nach C portiert
    • DirectX ist C++, und die meisten Game-Engines ebenfalls
      Anders als bei Linux-Programmierung ist die Spieleentwicklung seit über 30 Jahren stark von C++ geprägt

  • Ich bin grundsätzlich jemand, der C liebt
    Ich arbeite seit Jahrzehnten gut damit, aber wenn man C-Code im Team verwalten muss, wird es zunehmend schmerzhaft
    Außerdem ist die Entwicklung damit langsamer als mit modernen Sprachen
    Trotzdem bleibt der Reiz der Einfachheit bestehen

    • Mich würde interessieren, warum eine C-Codebasis in der Teamarbeit mehr Schmerzen verursacht
      Meiner Erfahrung nach war C weniger schmerzhaft als C++
    • „Weniger sagen, aber mehr bedeuten“ — also ist Knappheit der Kern
    • Am Linux-Kernel haben allein 2025 insgesamt 2.134 Entwickler mitgewirkt
      Diese Tatsache schwächt das Argument über die Grenzen von Zusammenarbeit in C ab

  • Die Aussage „Niemand entwickelt Spiele in C“ ist übertrieben
    Es ist heute zwar nicht der Mainstream, aber noch immer entwickeln viele Leute Spiele in C

    • Formulierungen wie „niemand“ oder „alle“ sind meist nicht absolut gemeint
      Du bist dann einfach die Ausnahme, und statistisch bleibt die Aussage trotzdem zutreffend

  • Ich mag C
    Man hat die vollständige Kontrolle über das Speichermanagement und erhält vorhersehbares Verhalten
    In Umgebungen, die Voraballokation verlangen, etwa wegen MISRA-Regeln, ist das besonders nützlich
    Auch Hardware-nahe Ausnahmen oder Fehler lassen sich direkt behandeln
    Unit-Tests zu schreiben ist ebenfalls einfach

  • C hat eine niedrige Einstiegshürde, aber Wissen über Speichermanagement ist unverzichtbar
    Als Java-Entwickler musste ich einmal schnell einen Connector bauen, obwohl nur .h- und .so-Dateien gegeben waren, und habe dafür C statt C++ gewählt
    Wenn C ein scharfes Messer ist, dann ist C++ eher eine rotierende Säulenkonstruktion aus Messern — wenn man nicht aufpasst, verletzt man sich
    Die String-Verarbeitung ist in C allerdings so schmerzhaft, dass ich mir manchmal gern das String-System von C++ ausleihen würde

    • Das Gute an C++ ist, dass man Features, die man nicht will, einfach nicht verwenden muss