▲

C로 게임을 만드는 이유 (네, C로요)

 (jonathanwhiting.com)
1P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • 개인 프로젝트의 모든 게임을 ‘순수 C’로 개발하며, 이는 현재 드문 선택임
  • 언어 선택의 핵심 기준은 신뢰성, 이식성, 장기적 지속 가능성으로, 특정 OS나 플랫폼에 종속되지 않음
  • 단순성과 빠른 컴파일 속도, 그리고 엄격한 타입 검사와 강력한 경고 시스템을 중시함
  • C++·C#·Java·Go·Haxe 등 대안 언어들을 검토했으나, 복잡성·GC·OOP 강제 등으로 인해 적합하지 않다고 판단함
  • C는 위험하지만 단순하고 빠르며, 폭넓은 플랫폼 지원과 견고한 라이브러리 생태계 덕분에 여전히 최적의 선택임

언어 선택의 기준

  • 필수 조건은 신뢰성과 안정성으로, 내가 만들지 않은 버그에 시간을 낭비하지 않기 위함
    • 과거 Flash 기반 게임을 개발했으나 Flash의 쇠퇴로 인해 새로운 플랫폼으로의 이식 대신 새로운 게임 제작에 집중하고자 함
    • 특정 OS에 종속되지 않고, 콘솔 개발 가능성을 열어두기 위해 이식성과 범용 라이브러리 지원을 중시함
  • 바람직한 조건으로는 단순한 문법과 기억하기 쉬운 구조를 꼽음
    • 복잡한 API나 언어 기능을 계속 찾아보는 과정을 피하고자 함
  • 엄격한 타입 검사, 강력한 경고, 정적 분석을 통해 버그를 줄이고, 좋은 디버거와 동적 분석 도구로 문제를 쉽게 찾고자 함
  • 컴파일 속도를 매우 중요하게 여김
    • 긴 대기 시간은 집중력을 깨뜨리고 생산성을 떨어뜨림
  • 객체지향(OOP) 에 회의적이며, 데이터와 코드를 분리해 상황에 맞게 처리하는 방식을 선호함

주요 대안 언어 평가

  • C++
    • 게임 개발에서 여전히 표준이지만, 복잡성과 느린 컴파일 속도로 인해 불만족
    • 높은 성능과 다양한 기능을 제공하지만, 원하지 않는 기능이 많고 복잡도 비용이 큼
  • C#과 Java
    • 장황하고 복잡하며, 강한 OOP 중심 구조로 인해 자유도가 낮음
    • 고수준 언어 특성상 복잡성을 숨기지만, 근본적인 문제를 막지는 못함
  • Go
    • C의 현대적 재해석으로 긍정적으로 평가하지만, stop-the-world 가비지 컬렉션이 게임 개발에 부적합
    • 게임용 라이브러리 부족과 장기적 지속성에 대한 우려 존재
  • JavaScript
    • 웹 개발 환경의 빠른 변화와 Flash의 종말로 인해 불안정하게 느껴짐
    • 느슨한 문법으로 인해 대규모 소프트웨어 작성에 부적합하다고 판단
  • Haxe
    • 웹 개발 시 유망하다고 평가하지만, 상대적 신생 언어로 지속성에 대한 우려 존재
  • 자체 언어 개발
    • 매력적인 발상이지만, 기존 라이브러리 포기와 호환성 유지 부담으로 인해 현실적이지 않다고 판단

C를 선택하는 이유

  • 위험하지만 신뢰할 수 있는 언어로, 단순한 구조 덕분에 주의 깊게 사용하면 안정적
    • “날카로운 칼”에 비유하며, 다루기 어렵지만 숙련되면 강력한 도구임을 강조
  • 컴파일 속도가 매우 빠르며, 거의 모든 플랫폼에서 실행 가능
    • 이식 과정도 비교적 간단하고, 장기적으로도 지속 가능성이 높음
  • 라이브러리와 툴링 지원이 강력하고 꾸준히 유지되고 있음
  • 개인적으로는 이미 많은 ‘순수 C’ 코드 경험이 있어 익숙함
  • 다른 사람에게 C 사용을 권장하지 않으며, 이는 개인적 취향과 작업 방식에 최적화된 선택임
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • 나는 주로 C 스타일로 코드를 작성하지만, 필요할 때만 C++ 기능을 사용함
    그래서 얼핏 보면 Rust 코드처럼 보이기도 함
    게임을 C로 쓴다는 사람들은 C++ 기능을 싫어하면서 결국 가상 인터페이스를 직접 구현하거나 거대한 switch문을 만들어서 비슷한 일을 함
    언어에 있는 기능을 안 쓰면 그만인데, 그 존재 자체를 불평하는 건 의미 없다고 생각함
    C++은 템플릿을 남용하지 않으면 컴파일이 느려지지 않음

    • 혼자 개발할 때는 그럴 수 있지만, 팀 단위로 장기간 유지되는 프로젝트에서는 상황이 다름
      시간이 지나며 팀원이 바뀌고 리더가 바뀌면, 사용되는 기능의 집합이 점점 커짐
      한 번 늘어난 기능을 줄이기는 매우 어려움
      또, 원치 않는 기능을 사용하는 라이브러리를 써야 할 수도 있음
      예를 들어, 나는 암묵적인 호출(소멸자, 연산자 오버로딩 등)을 싫어하지만, 라이브러리가 그걸 쓰면 결국 따라가야 함
    • 적어도 switch문은 읽을 수 있음
      C++의 가장 나쁜 점 중 하나는 자동으로 생성되는 숨은 코드가 너무 많다는 것임
    • C++의 동적 디스패치는 모든 타입에 vtable을 붙이는 방식임
      코드 대부분이 구체 타입(Goose, Duck 등)을 다루더라도, 모든 객체가 vtable 포인터를 들고 다님
      반면 Rust는 필요한 곳에서만 vtable을 사용해서 메모리를 절약함
      C 프로그래머는 필요한 기능만 직접 구현하므로, 언어가 강제하는 구조에 덜 묶임
    • C++은 템플릿을 남용하지 않아도 느림
      <vector> 하나만 포함해도 수만 줄의 코드가 포함됨
      그래서 표준 라이브러리를 안 쓰면 “왜 다시 바퀴를 발명하냐”는 논쟁이 생김
      이런 논쟁이 반복되면 그냥 C로 돌아가는 게 훨씬 편함
      나도 2017년쯤 C로 전환했고, 지금도 C++ 라이브러리를 쓸 때마다 피로함
      예외적으로 Dear ImGui는 괜찮지만, 그마저도 C 바인딩을 선호함
    • 실제로 C++ 파일을 작성했는데 C++ 기능을 하나도 안 쓴 적이 있음
      확장자를 .c로 바꾸자 컴파일 시간이 절반으로 줄었음

  • 나는 C의 거칠고 단순한 성격을 좋아함, 다만 전처리기는 싫어함
    그래서 Zig는 정말 신의 선물 같음 — C보다 단순하면서도 더 정확한 언어 설계를 가짐
    예를 들어 Zig는 단일 포인터와 배열 포인터를 구분함
    C 라이브러리를 가져와 더 사용하기 쉽게 만들 수 있고, 게임 개발에서 매우 유용함
    대부분의 C++ 라이브러리도 C 헤더를 함께 제공함
    zig-gamedev에는 이런 Zig화된 C 라이브러리가 많음
    전처리기 대신 Zig의 comptime 기능이 훨씬 낫고, 단지 “컴파일 시점에 실행되는 Zig 코드”일 뿐임

    • 하지만 실제로는 C++ 라이브러리 중 C 헤더를 내보내는 경우가 너무 적음

  • 나도 글쓴이의 생각에 공감함
    언어를 좋아하게 되는 가장 큰 이유는 단순함임
    그래서 C, Go, Odin, Zig 같은 언어를 선호함
    하지만 필요한 복잡성을 우아하게 다루는 언어도 중요함
    메모리 안전성과 동시성, 함수형 패턴이 필요한 네트워크 코드에서는 Rust가 자연스러움
    반면, 인디 게임처럼 단순하고 빠른 코드에는 C나 Odin이 잘 맞음
    Odin은 Go의 단순함과 C의 성능을 결합한 느낌이라 추천함
    Raylib로 게임 만들기도 쉬움

    • 흥미롭게도 나는 Zig를 Go와 C의 중간 지점으로 설명하곤 함
      Odin이 Zig보다 그 자리에 더 잘 맞는다고 생각하는지 궁금함
    • 참고로 언어 이름은 Go이고, golang은 단지 도메인 이름임

  • 원문에서 Go의 게임 라이브러리 지원이 부족하다고 했는데, 그건 2015년쯤 글로 보임
    지금은 상황이 달라졌을 수도 있음

    • Wayback Machine에 2016년 1월의 스냅샷이 있음
      당시 만든 게임들의 스크린샷도 볼 수 있음
      예를 들어 Knossu는 독특한 3D 스타일을 가짐

  • 2026년에 C로 게임을 만드는 건 약간 미친 짓일 수도 있지만, 나도 그렇게 함
    예를 들어 Chrysalis를 C로 개발했음 (GLFW3, FMOD 사용)

    • 나는 2년째 Jedi Academy 코드베이스를 다루고 있음 (C & C++)
      idTech3 기반인데, 전투 시스템이 너무 정밀해서 작은 변경도 전체 밸런스를 깨뜨림
      심지어 i++ 하나 추가해도 타이밍이 달라짐
      그래서 22년 된 컴파일러를 그대로 사용 중임
      현대화된 포크들도 있지만, 원래의 감각을 잃었음
      idTech3는 정말 C의 정수(精髓) 를 보여주는 엔진임

  • 수천 개의 게임이 C로 작성되었고, OpenGL, Vulkan, DX 같은 그래픽 API도 전부 C 기반임
    그래서 전혀 이상하지 않음
    대부분의 게임 엔진도 C/C++로 작성됨

    • Khronos API는 C, DirectX는 C++ 기반 COM/WinRT, Metal은 Objective-C와 C++ 혼합임
      콘솔은 세대마다 다름
    • SDL3도 C로 작성되었고, Box2D의 최신 버전도 C로 다시 작성됨
    • DirectX는 C++이고, 대부분의 게임 엔진도 C++임
      리눅스 프로그래밍과 달리, 게임 개발은 30년 넘게 C++ 중심이었음

  • 나는 근본적으로 C를 사랑하는 사람임
    수십 년 동안 잘 써왔지만, 팀 단위로 C 코드를 관리하면 고통이 커짐
    또, 현대 언어에 비해 개발 속도가 느림
    그래도 단순함의 매력은 여전함

    • 왜 C 코드베이스가 팀 작업에서 더 아픈지 궁금함
      내 경험상 C++보다 C가 덜 고통스러웠음
    • “적게 말하고 더 의미 있게” — 즉, 간결함이 핵심임
    • 리눅스 커널에는 2025년에만 2,134명의 개발자가 참여했음
      그 사실이 C의 협업 한계를 약화시킴

  • “아무도 C로 게임 안 만든다”는 말은 과장임
    지금은 주류는 아니지만 여전히 많은 사람이 C로 게임을 만듦

    • “아무도”나 “모두” 같은 표현은 보통 절대적인 의미가 아님
      당신은 예외일 뿐이고, 그 말은 여전히 통계적으로 맞음

  • 나는 C가 좋음
    메모리 관리를 완전히 통제할 수 있고, 예측 가능한 동작을 얻을 수 있음
    MISRA 규칙처럼 사전 할당을 요구하는 환경에서는 특히 유용함
    하드웨어 수준의 예외나 오류를 직접 다루기에도 좋음
    단위 테스트 작성도 쉬움

  • C는 진입 장벽이 낮지만, 메모리 관리 지식은 필수임
    Java 개발자인 내가 .h와 .so만 주어진 상황에서 빠르게 커넥터를 만들어야 했을 때, C++보다 C를 선택했음
    C가 날카로운 칼이라면, C++은 회전하는 칼기둥 같음 — 방심하면 다침
    다만 문자열 처리는 C에서 너무 고통스러워서 C++의 문자열 시스템을 빌려오고 싶음

    • C++의 좋은 점은 원하지 않는 기능은 안 써도 된다는 것임
답변달기