비디오 게임 작성을 위한 실험적 신기술 Core

 (github.com/damn)
2P by GN⁺ | ★ favorite | 댓글 1개

  • coreCore는 무엇인가

    • coreCore는 Action-RPG 게임 제작 도구 및 엔진, 속성 편집기 형태로 비디오 게임을 작성하는 실험적인 방법임
    • 간단한 컴포넌트 시스템을 사용하며, 컴포넌트는 [keyword value] 형태의 clojure 벡터임
    • 다양한 엔티티는 clojure 맵으로 구성됨
    • 게임 내 부작용은 [:tx/foo param]와 같은 컴포넌트로 처리되며, 이는 datomic 구조와 유사함
    • 전체 게임 상태는 app/state라는 하나의 atom에 저장되며, 엔티티도 메인 atom 내부의 atom으로 존재함
    • 애플리케이션의 전체 내용은 resources/properties.edn에 저장되며, malli-schemas를 사용해 검증되고 GUI로 편집 가능함

  • 스크린샷

  • 개발 시작 방법

    • 다음 명령어를 입력:
      • lein dev
    • 애플리케이션이 시작되며 다음 작업도 수행됨:
      • NREPL-서버 시작
      • 애플리케이션 종료 시 (메인 메뉴에서 ESC), clojure.tools.namespace가 변경된 파일을 새로고침하고 앱을 재시작함
      • 오류 발생 시 JVM을 재시작할 필요 없이 오류를 수정하고 dev-loop/restart!를 호출하면 됨
      • VIM에서 F5 키에 다음 명령어를 바인딩하여 사용 가능: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • 코드 라이선스

    • MIT 라이선스 하에 제공됨

  • 자산 라이선스

GN⁺의 정리

  • coreCore는 Action-RPG 게임을 쉽게 제작할 수 있는 도구로, 간단한 컴포넌트 시스템을 사용해 게임 상태를 관리함
  • 전체 게임 상태를 하나의 atom에 저장하고, GUI를 통해 속성을 편집할 수 있어 개발자에게 유용함
  • MIT 라이선스로 제공되지만, 사용된 자산은 독점적임
  • 비슷한 기능을 가진 도구로는 RPG Maker, Unity 등이 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 멋짐. 게임을 내본 적은 없지만, 게임 개발에 대한 서로 다른 접근을 보는 걸 항상 좋아함
    지금까지 Bevy는 처음엔 좋지만 구현상 문제가 많고 지저분해질 수 있었고, Unity는 gameobject와 조합형 컴포넌트 방식이 가장 실용적이라 엔진이 방해하지 않으며 스파게티를 피하기 쉬웠음
    Godot은 싫었음. 객체지향의 안 좋은 계층 구조, 별로인 내장 언어, 스파게티를 줄이려는 “signals”가 오히려 더 늘어났음. Pygame은 작은 프로젝트에 꽤 좋고, 절차형 기반 위에 객체지향이나 함수형 계층을 직접 얹을 수 있음
    Clojure는 모르지만, 전형적으로 객체지향에 잘 맞아 보이는 분야에 함수형 구현을 시도한 점이 흥미로움

    • Unity와 Godot 둘 다로 실제 제품을 만든 전문 게임 개발자로서, Godot과 Unity에 대한 평가는 전혀 동의하기 어려움
      Godot의 signals는 Unity 내장 클래스의 모듈성 부족에 비해 큰 발전임. Godot과 Unity는 기본적으로 같은 scene/node/component 모델을 갖지만 Godot이 더 잘한다고 봄
      Unity의 장점은 3D 렌더러, 내장 PhysX, C#용 il2cpp 백엔드, 프로파일러, 전반적인 실행 성능, 콘솔 지원임. 반면 Godot의 설계는 더 응집력 있고, Unity는 2018년쯤부터 10가지 방향으로 쪼개진 느낌임
    • 게임 개발자는 아니지만, Godot의 객체지향 설계는 내가 써본 것 중 꽤 좋은 편이었음
      요즘은 C++ 임베디드 쪽이라 객체지향을 많이 쓰진 않지만, C#으로 프로그래밍을 배워 상속에는 익숙한 편임
    • Godot은 훌륭하고, 5년쯤 뒤에는 게임 제작의 Blender가 될 거라고 봄. 4버전은 실전에 쓸 만하고 대부분의 인디 프로젝트를 감당할 수 있음
      Unity가 앞서는 영역은 “Triple I”와 “Double A”급으로, 3D/성능 기능, 도구, 애드온이 더 좋기 때문임. AAA 프로젝트에는 둘 다 최선은 아님
      2D와 단순 3D 게임에서는 이제 Unity를 쓸 이유가 없어 보이고, Godot이 천천히 앞지르며 Unity 점유율은 꾸준히 줄어들 것 같음
    • 상업 개발자로서 예전엔 Unity를 썼고 지금은 Godot을 씀. GD Script와 signals에 대한 비판은 공감되며, 나는 C# 이벤트 처리로 피해감
      노드와 에디터 버그인지 기능인지 모를 것들이 가장 답답하고, 처음에 “작은” 프로젝트용으로 만들어졌다는 느낌이 강함
      그래서 에디터는 scene 구성과 대략적인 계층 설정 외에는 거의 안 씀. 평소 도구는 Emacs+C# LSP, 디버깅은 VS Code, scene tree 조정은 Godot 에디터를 씀
    • Godot을 꽤 진지하게 써봤고 싫어할 이유도 있지만, GDScript는 그 이유가 아니라고 봄
      기본적으로 Python에 slot/emit 의미론을 붙여 에디터와 통합한 형태라 오히려 괜찮음. 빌드 시스템, 메타데이터, 외부 설정 파일로 통합하는 복잡한 방식보다 언어 안에 들어가 있는 편이 낫다

  • 게임 개발을 단순하게 만들 수 있다고 해놓고 Clojure vectors, datomics, atoms, transactions, malli schemas 같은 전문용어를 잔뜩 던짐. 누가 설명해줄 수 있나?

    • 소개문을 다듬어보면, Core는 액션 RPG 제작을 단순화하려는 실험적 도구임
      게임 요소와 속성을 단순한 자료구조로 표현하고, 전체 게임 상태를 하나의 컨테이너(app/state)에 저장해 관리와 갱신을 쉽게 함
      또 단일 파일(resources/properties.edn)에 저장된 게임 콘텐츠를 편집하는 GUI를 제공해 비프로그래머도 접근하기 쉽게 하고, Malli 스키마로 자료 검증을 해 콘텐츠 일관성과 오류 감소를 노림
    • 공정하게 말하면, 게임 개발이 단순해질 수 있느냐고 묻고 있을 뿐임. 답은 아마 “아니오”일 가능성이 높음
    • 필수로 붙는 “단순함은 쉬움과 같지 않다”: https://www.youtube.com/watch?v=SxdOUGdseq4
      Clojure vector는 기본적으로 리스트에 가까움. atom은 불변 자료구조를 가리키는 변경 가능한 참조이고, 특정 갱신 의미론을 가진 포인터처럼 볼 수 있음
      transaction은 데이터베이스 트랜잭션과 비슷하게 여러 자료구조를 동시에 바꾸되, 모든 작업이 성공할 때만 커밋하고 실패하면 롤백하거나 재시도함
      Malli schema는 동적 타입 언어에서 타입 검사를 하는 방식이고, Datomic은 불변 자료구조 기반의 비-SQL 데이터베이스 구현으로 변경을 파괴적으로 덮어쓰지 않고 추가만 해서 과거 어느 시점으로든 되감아 볼 수 있게 함
    • Clojure 언어에는 내장된 상태 관리 모델이 있고, 이 프로젝트는 그 모델을 게임 개발에 적용하려는 시도임
      이 모델을 배우는 가장 좋은 방법은 Clojure 창시자 Rich Hickey의 “Are we there yet” 강연을 보는 것이라고 봄
    • Clojure vector는 언어 내장 자료구조이며 [1 2 3]처럼 생겼음
      나는 이를 이용해 [:tx/foo 3] 같은 부수효과를 구성하고, 이를 Datomic과 비슷하게 transaction이라고 부름. 여기서 :tx/foo는 키워드이며 컴포넌트 동작을 고유하게 식별함

  • 솔직히 이 프로젝트는 실제로 실패했다고 봄. 과도하게 설계된 혼란이고 명확한 구조가 없음
    가장 큰 문제는 명세가 전혀 없다는 것임. 게임 스토리를 만들지 않았거나, 어쩌면 게임에 스토리가 필요 없다고 생각했기 때문임. 그래서 그냥 Clojure로 코딩하는 게 재밌어서 미친 듯이 코딩했음

    • 공정하게 보면, 성공한 프로젝트 중에도 과도하게 설계된 혼란이고 명확한 구조가 없는 것들이 많음
      멋진 걸 시도한 건 좋고, 많은 사람이 관심 있어 하는 영역임
    • 그냥 재미있는 취미였다는 점과, 주장한 것만큼 단순하지 않을 수 있다는 점을 인정하는 것만으로도 이미 많은 사람보다 앞서 있음. 프로젝트에서 많이 배웠길 바람

  • 게임 개발자로서는 이 GitHub가 우스꽝스럽게 느껴짐. 게임 개발자들이 싫어하는 학술적 자기몰입의 패러디에 가까움. 못생긴 스크린샷까지 화룡점정임

    • 그렇다면 이 사이트와는 잘 안 맞는 것 아닌가? Hacker News는 대체로 흥미로운 새 아이디어를 다루는 곳이지, C++와 Unity의 점진적 개선만 이야기하는 곳은 아님
      이런 이상한 학술적 자기몰입에서 나온 게임도 몇 개 떠올릴 수 있음. 형제 댓글의 Jonathan Blow도 그렇고, 이 프로젝트를 보자마자 Braid가 떠올랐음
      절차적 생성도 예전엔 상아탑 주제였고, 3D 그래픽의 모든 발전도 처음엔 학회에서 나온 완전히 비현실적인 논문으로 시작했음. 지금 게임에서 주류인 많은 것들이 한때는 틈새 학술 아이디어였음
    • 스크린샷이 “못생겼다”고는 생각하지 않지만, README가 기능적으로 쓸모없다는 데는 동의함. 문서도 예제도 없고, 왜 써야 하는지에 대한 설명도 없음
      무엇을 하는 것인지 전달하는 기본 단계에서 실패함
    • 지적으로 자극적인 걸 만드는 것도 가치가 있음. Clojure datomics를 만드는 데 100시간을 쓰고 레벨 콘텐츠 1시간만 만들더라도, 1시간은 0시간보다 큼
      지루해서 아예 만들지 않았을 거라면 오히려 이득임. 인디 개발의 Jonathan Blow가 Jai를 쓰는 논리와 비슷함
    • 실험적이라고 적혀 있긴 함

  • 이 저장소의 문서가 이렇게 적은데도 대화가 꽤 많이 나온 게 의외임. 코드를 보면 게임 엔진이라기보다는 프로젝트에 가까워 보임
    property editor는 흥미롭지만, 이 글은 내용보다 제목 때문에 추천받는 것 같음

  • 좋음. 나처럼 Clojure로 게임 개발하는 개발자를 보니 반가움. 가끔 스스로 일을 더 어렵게 만들긴 하지만 :)
    지금은 Clojure로 3D 멀티플레이어 TPS 슈터를 개발 중임. 관심 있으면 데모는 여기 있음: https://prototype-game.pages.dev
    곧 개발 여정을 담은 블로그 글도 올릴 예정임

    • 여러 사람이 가상 공간에 들어가 즉석에서 뛰어다니고 게임 내 채팅을 쓰는 순간이 인터넷에서 가장 좋아하는 장면 중 하나임

  • Clojure는 좋아하지만, 불변 자료구조를 쓰는 함수형 언어가 비디오게임 개발에 좀 이상한 선택 아닌가?

    • 충분히 가능하고 흥미로운 트레이드오프가 있음
      함수형 게임 개발과 관련해 좋아하는 글들임:
      https://prog21.dadgum.com/228.html
      https://prog21.dadgum.com/23.html
      https://prog21.dadgum.com/24.html
      https://prog21.dadgum.com/25.html
      https://prog21.dadgum.com/26.html
    • 꽤 자연스럽게 느껴짐. Clojure가 JVM 기반이라 이 프로젝트는 내부적으로 libgdx를 쓰고, 모든 플랫폼에 배포 가능하며 라이브러리도 큼
      나머지는 Lisp로 거의 뭐든 할 수 있음. Clojure의 불변 자료구조 처리 방식과 훌륭한 protocol 시스템(https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...) 덕분에 전체 게임을 별도 컴포넌트로 쉽게 나눌 수 있었음
    • Tim Sweeney도 UEFN에서 Verse를 통해 그런 방향에 걸고 있는 것 같음. Verse는 Haskell을 더 접근하기 쉽게 만든 쪽에 가까움
    • 그렇게 이상하진 않음. 다음 AA나 AAA 게임이 쓰진 않겠지만, React의 reducer나 Redux 같은 매우 상호작용적인 영역에서도 불변성은 자주 보임
      Clojure는 Ruby나 Python보다 성능 가능성이 더 좋고, 둘 다 상업 인디 게임에서 실제로 쓰인 적이 있음
    • 함수형 프로그래밍은 게임 개발에서 제대로 시도조차 거의 안 됐음. 게임 개발 업계와 학계의 겹침이 부족함
      스튜디오들은 당연히 위험 회피적이고, 객체지향이나 대규모 군집에 ECS를 쓰는 식의 익숙한 전략을 선호함
      개인적으로는 함수형 프로그래밍이 잘 맞을 수 있다고 보지만, 먼저 실제 게임 개발 문제를 푸는 아키텍처를 찾아야 함. 작은 실험부터 시작해야 하고, 게임잼이 여기에 딱 맞음

  • Unreal Engine 4 기반으로 동작하는 Core라는 상업용 게임 제작 플랫폼이 이미 있음
    https://en.wikipedia.org/wiki/Core_(video_game)

  • 이름을 잘못 고른 것 같음. 이미 이쪽에서 쓰고 있음: https://www.coregames.com/create

    • 나도 제일 먼저 그 생각이 났음. 특히 그쪽은 게임 안에서 게임을 만드는 것이어서, 게임을 작성하는 “새로운” 방식으로 볼 수도 있음

  • “게임 엔진에 들인 시간/복잡도”와 “나온 게임의 복잡도/흥미도” 데이터를 분석해보면 흥미로울 것 같음
    게임 개발자로서, 단순 템플릿/엔진 시스템에서 나오는 새로운 게임의 수익은 체감하는 로그 곡선일 것으로 예상함
    다시 말해 쿠키 찍는 기계를 더 좋게 만들수록, 쿠키의 다양성은 줄어듦

답변달기