5년 동안 혼자 2D 게임 엔진을 개발하고 관련 유료 업무를 하면서 사람들이 잘 모르는 중요한 점을 설명하고 싶음
엔진은 쉬운 부분임
진짜 중요한 부분은 엔진 주변의 툴링, 콘텐츠, 애셋 파이프라인임
다양한 데이터 소스와 포맷에서 텍스처, 오디오, 모델 파일(gltf, fbx, 애니메이션 등) 임포트
에디터 앱에서 자르기, 복사, 붙여넣기, 실행취소, 다시실행, 저장, 삭제 같은 기본 편집 기능
개발자가 에디터로 실제 데이터를 만들고 조작할 수 있게 하는 시각화와 기능(엔티티, 애니메이션, 씬, 오디오 그래프, 스크립팅 지원 등)
정적 지오메트리 베이킹, 셰이더 컴파일, 텍스처·오디오 리샘플링 및 패킹, 게임 콘텐츠 애셋 팩 만들기 같은 데이터 패키징 및 전처리
이 모든 게 끝나면 실제로 런타임 부분(즉 게임 메인루프와 하위 시스템)은 전체 시스템 중 작은 부분임
그래서 게임 스튜디오에서는 엔진 담당자는 소수고, 툴을 만드는 프로그래머가 대다수인 이유임
detonator 엔진: https://github.com/ensisoft/detonator
범용성보다는 내 게임에 맞는 엔진을 만드는 것에 집중하는 게 중요함
UI, 압축 등은 라이브러리와 프레임워크로 해결 가능
OP가 imGUI처럼 소형 라이브러리를 이용하는 것도 좋은 예시
모든 게임을 위한 엔진을 만드는 게 아닌 만큼, 사실상 안 해도 되는 일이 많아짐
엔진은 애셋 파이프라인에 달린 작은 런타임 덧붙이기 같은 존재임
요즘 셰이더 컴파일러도 3D API보다 점점 더 중요해지는 상황
흥미로운 부분은 셰이더 컴파일러에 집중되고, 3D API는 셰이더 실행과 데이터 전달 역할에 그침
사람들이 엔진이라 하면 자주 애셋 파이프라인과 에디터까지 포함해서 말하는 경향
오늘날의 엔진은 메인 루프 + 3D API 함수만 있는 게 아님
Unity 같은 엔진을 쓴다고 해서 렌더링 코드만 쓰는 개발자는 매우 소수임
물론 Unity/Unreal 쓴다고 직접 애셋 툴을 쓸 일이 완전히 없는 건 아님
최근 후속작용 엔진을 갈아엎으면서 이 점에 매우 동의
포스트모템에 적었듯이 대부분 엔진이라 하면 게임 실행파일에 포함된 코드를 떠올리지만, 실질적으론 레벨 에디터, 콘텐츠 파이프라인, 디버깅/프로파일링, 개발 워크플로우처럼 게임과 함께 배포되지 않는 코드의 비중이 더 크다고 생각
툴 개발은 엔진 개발보다 지루하고 지치기 쉬운 작업
이런 이유로 많은 커스텀 엔진 게임 개발이 중간에 멈추는 현상 발생
포스트모템: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
에디터를 처음부터 만드는 일은 상당한 작업
가능하다면 이미 있는 에디터를 활용함
예를 들면 TrenchBroom(Quake 에디터) + func_godot 조합, 2D에선 Tiled
게임 데이터 관리는 CastleDB도 있었지만, 이제는 Hide(본격 3D 에디터)랑 통합된 상태
툴 만들고 나선 게임 설계하고 콘텐츠 만드는 일이 또 주요 단계
몇 년 전 SDL2와 약간의 C++로 간단한 "sprite" 클래스를 만들고 콜리전 등 간단 기능 추가
내가 만든 걸 굳이 엔진이라 부르자면 일종의 전기자전거 보조 정도였음
"엔진"이 프로젝트/게임 전체를 리드하는 상황이 자주 발생한다는 점
게임을 엔진에 맞추게 되는 경우가 많아 Unity 같은 대형 엔진 사용을 항상 피함
이런 엔진들은 결국 같은 게임 구조만 만들게 되고, 자산만 다를 뿐임
개인적으로는 엔진을 배우느라 시간 낭비하는 것보다 SDL로 짧은 러닝커브로 시작할 수 있고, SDL은 게임 외 다른 크로스플랫폼 프로젝트에도 활용 가능
내 게임: https://store.steampowered.com/app/2318420/Glypha_Vintage/
엔진을 직접 만드는 게 오래 걸린다지만, Unreal이나 Unity를 제대로 익혀 아이디어를 바로 게임으로 구현할 수 있을 정도가 되려면 어느 정도 시간이 필요한지 질문
결국 내 엔진 제작이 끝나면 바로 그 레벨의 전문성을 확보하므로 장기적으로 시간 절약
엔지니어 경력이 쌓일수록 직접 만드는 쪽이 시간 관점에서 유리해짐
게임이 독특하거나 틈새시장일수록 직접 만드는 쪽이 더 타당
Unreal의 복잡한 UI에서 몇 달 헤매고 애초에 원하는 게 범용 엔진에선 거의 불가능한 걸 알게 되는 경험은 비효율
반면 초현실적 오픈월드 RPG라면 직접 제작은 좋은 선택이 아님
커스텀 엔진의 제약이 오히려 창의성을 불러오고, 최고 수준이 아니더라도 더 독창적인 게임이 나옴
직접 엔진을 만들어 본 적 있음
처음에는 수많은 시행착오와 막다른 길을 겪으며 1년 정도 걸렸음
3D 렌더링, 적응형 UI, 스켈레탈 애니메이션, 세이브 파일, 스마트 오브젝트, 경로 탐색, 스크립팅, 오디오, 물리 등 게임에서 볼 수 있는 거의 모든 서브시스템 구현
특히 되감기 기능(Braid의 시스템처럼)을 직접 구현
이런 기능은 엔진의 모든 서브시스템(스크립트, 물리 등)의 지원 필요
내가 만든 엔진의 모든 부분을 알고 있어 추가 기능 개발에 엄청난 자유로움
하지만 1년 개발 후 점점 번아웃이 와서 의욕이 사라짐
Unreal은 모르지만 Unity는 직접 코딩과 비교해 10배 이상 빠르게 개발 가능
물리 기능은 1분이면 추가 가능하지만, 직접 엔진이면 외부 라이브러리 연동만 해도 하루 이틀 소요
Unreal 유저 Noel이 보여주는 내부 시각화 기능도 Unity엔 내장
바운딩 박스 조작 같은 편집도 기본 탑재
만약 엔진의 기본 동작이 부족하다면 ImGui나 Yoga 기반 CSS 엔진으로 쉽게 확장 가능
고급 파티클 에디터, 복잡성 해소된 셰이더, 모듈형 데이터 스트리밍 등 수많은 기능 제공
이론상 다 직접 만들고 싶지만 결국 시간 문제로 완성 우선
Unreal이나 Unity를 익혀 게임 아이디어를 바로 구현하는 데 걸리는 시간과, 직접 엔진 만드는 데 걸리는 시간은 다른 질문
조금만 아이디어 주면 몇 시간 안에 게임 플레이 가능한 프로토타입 제작 가능
Unity는 초기에 프로그래밍만 하면 되고, Unreal은 블루프린트만으로도 거의 게임 출시 직전까지 가능
10분 만에 슈퍼 헥사곤 스타일 게임 프로토타입 완성하는 영상 참고: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
유니티의 고유 요소는 프리팹 정도고 나머지는 게임개발 일반 개념
Unreal 개발자 입장에서라면 Unity로도 1시간 이내 비슷한 프로토타입 제작 가능
“엔진 완성 이후”란 가정 자체가 비현실적일 수도 있음
GameObject.Instantiate 같은 간단한 동작도 엔진에서 직접 구현하려면 어마어마한 리소스 필요
2D/3D 물리, 셰이더, 플랫폼 지원 등 복잡도 감안
엔진이 목표면 엔진을 만들고, 게임이 목적이면 게임 자체를 만들라는 의견
게임 엔진을 만들 만큼의 게임개발 지식이 충분하다면
Unreal이나 Unity를 익혀 프로토타입 만드는 데 하루면 충분
완벽한 숙련까지 오래 걸리지만, 원하는 게임 프로토타입 완성 시간은 비교 불가
"모두 다 하는" 대형 엔진 없이도 게임 만들기는 더 쉽고, 더 재밌고, 때론 더 효율적
다만 엔진의 특정 기능(예: Unreal의 역운동학, 애니메이션 블렌딩) 파고들다 보면 "차라리 직접 2~3주 고생 안 하길 잘했다"는 생각
미니멀리즘이나 비대화 방지도 중요하지만, 이런 엔진들이 무거운 일을 대신 해주니 인기가 많음
예전엔 나도 이런 방식이었음
첫 3D 게임 만들 땐 입력, 오브젝트 관리, 컬링, 모델 로딩, 수학 라이브러리, 그래픽스, 노멀맵, SSAA 등 다 구현하다가 정작 게임 완성률은 0%
그래도 취미 2D 프로젝트에선 여전히 브라우저 캔버스만으로 무의존 개발
사실상 브라우저가 엔진 역할
“차라리 직접 만들지 않은 게 다행”이라는 의견에 대해
장기적으로 인디 개발자 커리어를 생각한다면, 몇 주 걸리더라도 주제 깊이 이해+100% 소스코드 소유 및 재사용 가치가 더 큼
내 졸업 논문은 NeXTSTEP/Objective-C 기반 파티클 엔진을 Windows 95/Visual C++로 이식하는 주제(OpenGL 기반, marching cubes 샘플 포함)
이런 테마도 요즘 엔진에선 그냥 한 줄짜리 기능 중 일부
엔진을 쓰면 프로젝트 진행 속도가 훨씬 빨라지고, 인프라 개발에 시간 소진하지 않아도 됨
바퀴를 또 만드는 일은 대부분에게 큰 재미가 아님
역운동학이나 애니메이션 블렌딩 같은 기능은
만약 게임의 핵심이라면 구현할 가치가 있고, 아니면 불필요한 기술적 함정임
Lua & Love2D를 활용해 내 방식대로 게임을 만듦
자체 제약 걸기라는 점 자체가 재미의 핵심
개발이 재미없어지면 뭔가 잘못됐다는 신호이니 더 나은 방법 탐색
내 게임 YOYOZO는 39KB로 작지만 Ars Technica 2023 최고의 게임 목록에 대작들과 함께 올랐음 https://news.ycombinator.com/item?id=38372936
그 게임 기억 남
Playdate 구입한 지 수년 만에 SDK로 놀기 시작했는데, Lua도 처음 익히는 중
강 타입과 언어적 안전성 바람이 있지만 상황에 맞는 충분함
텍스트가 크랭크에 따라 가짜 3D 공간에서 도는 작은 기술 데모 만든 게 전부 https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
이 프로젝트를 하며 오래 전 CRUD/웹앱 경력으로 삼각법 거의 다 까먹은 것 깨달음
Playdate 개발의 최고 장점은 고정 캔버스라서 픽셀 위치만 정하면 모든 기기에서 그대로 동작한다는 해방감
지난 개발 경력에선 반응형 UI만 만들다 이런 경험 매우 새로움
게임 엔진(Godot, Unity, Unreal 등)으로 뭔가를 만들려고 하면 항상 엔진이랑 씨름하게 됨
결국 정해진 게임 형식에 에셋을 얹는 느낌이라 내가 원하는 게임 제작이 어려워짐
웹 개발에 비유하면, 워드프레스 같은 완제품 느낌
기본 구성이 의도와 다를 때는 엄청난 해킹과 우회 작업이 필요함
Google Play에서 모든 게임이 똑같이 보이고, 긴 로딩, 렌더링 문제, 텍스트 깨짐, 오디오 버그 등 Unity 특유의 문제점 발생
모바일 광고용 "idle RPG" 게임이라면 이런 게 용인될 수 있겠지만, VR 분야에서 Unity 쓴다는 건 정말 이해하기 힘들었음
Meta Quest Store 성능 충족하려면 Unity 엔진의 많은 부분을 뜯어고쳐야 함
성능 맞추기 힘들고, 일처리 방식도 구식
퀄리티 높은 소프트웨어를 만들고 싶다면, 처음부터 믿을 수 없는 엔진으론 불가능함
혹시 이런 프로젝트에 C# 입문하는 데 참고 자료가 있는지 궁금함
C#은 Win32나 Unity에서만 써봤고, C/C++ 쪽 저수준 엔진 지식은 있지만, 게임 콘솔 등 크로스플랫폼에 C#은 불가능하다고 생각했음
내 생각이 틀렸다는 걸 이제 깨달음
어떤 소프트웨어든 처음엔 무에서 시작하는 걸 선호
대형 프로젝트 경험 있는 사람에겐 느리게 느껴질 수 있지만, 스타트업 단계에선 오히려 더 빠름
최소한만 구현하고, 추상화가 들어서면 새로운 기능 추가 속도가 더 빨라짐
기업용 대형 SW와 내가 직접 쓴 미니 엔진의 생산성은 완전히 다름
직접 쓴 코드는 바로 커팅, 리팩터링이 쉬워 훨씬 빠름
이런 이유로 마이크로서비스와 소규모 팀을 선호
직접 만들 땐 시행착오와 망가지는 지뢰밭을 반드시 거쳐야 하며, 언어나 플랫폼의 진짜 특성을 익히는 데도 수 년 소요
하지만 그 과정 자체가 결국 개발자의 내공으로 남음
Hacker News 의견
5년 동안 혼자 2D 게임 엔진을 개발하고 관련 유료 업무를 하면서 사람들이 잘 모르는 중요한 점을 설명하고 싶음
엔진은 쉬운 부분임
진짜 중요한 부분은 엔진 주변의 툴링, 콘텐츠, 애셋 파이프라인임
다양한 데이터 소스와 포맷에서 텍스처, 오디오, 모델 파일(gltf, fbx, 애니메이션 등) 임포트
에디터 앱에서 자르기, 복사, 붙여넣기, 실행취소, 다시실행, 저장, 삭제 같은 기본 편집 기능
개발자가 에디터로 실제 데이터를 만들고 조작할 수 있게 하는 시각화와 기능(엔티티, 애니메이션, 씬, 오디오 그래프, 스크립팅 지원 등)
정적 지오메트리 베이킹, 셰이더 컴파일, 텍스처·오디오 리샘플링 및 패킹, 게임 콘텐츠 애셋 팩 만들기 같은 데이터 패키징 및 전처리
이 모든 게 끝나면 실제로 런타임 부분(즉 게임 메인루프와 하위 시스템)은 전체 시스템 중 작은 부분임
그래서 게임 스튜디오에서는 엔진 담당자는 소수고, 툴을 만드는 프로그래머가 대다수인 이유임
detonator 엔진: https://github.com/ensisoft/detonator
범용성보다는 내 게임에 맞는 엔진을 만드는 것에 집중하는 게 중요함
UI, 압축 등은 라이브러리와 프레임워크로 해결 가능
OP가 imGUI처럼 소형 라이브러리를 이용하는 것도 좋은 예시
모든 게임을 위한 엔진을 만드는 게 아닌 만큼, 사실상 안 해도 되는 일이 많아짐
엔진은 애셋 파이프라인에 달린 작은 런타임 덧붙이기 같은 존재임
요즘 셰이더 컴파일러도 3D API보다 점점 더 중요해지는 상황
흥미로운 부분은 셰이더 컴파일러에 집중되고, 3D API는 셰이더 실행과 데이터 전달 역할에 그침
사람들이 엔진이라 하면 자주 애셋 파이프라인과 에디터까지 포함해서 말하는 경향
오늘날의 엔진은 메인 루프 + 3D API 함수만 있는 게 아님
Unity 같은 엔진을 쓴다고 해서 렌더링 코드만 쓰는 개발자는 매우 소수임
물론 Unity/Unreal 쓴다고 직접 애셋 툴을 쓸 일이 완전히 없는 건 아님
최근 후속작용 엔진을 갈아엎으면서 이 점에 매우 동의
포스트모템에 적었듯이 대부분 엔진이라 하면 게임 실행파일에 포함된 코드를 떠올리지만, 실질적으론 레벨 에디터, 콘텐츠 파이프라인, 디버깅/프로파일링, 개발 워크플로우처럼 게임과 함께 배포되지 않는 코드의 비중이 더 크다고 생각
툴 개발은 엔진 개발보다 지루하고 지치기 쉬운 작업
이런 이유로 많은 커스텀 엔진 게임 개발이 중간에 멈추는 현상 발생
포스트모템: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
에디터를 처음부터 만드는 일은 상당한 작업
가능하다면 이미 있는 에디터를 활용함
예를 들면 TrenchBroom(Quake 에디터) + func_godot 조합, 2D에선 Tiled
게임 데이터 관리는 CastleDB도 있었지만, 이제는 Hide(본격 3D 에디터)랑 통합된 상태
툴 만들고 나선 게임 설계하고 콘텐츠 만드는 일이 또 주요 단계
몇 년 전 SDL2와 약간의 C++로 간단한 "sprite" 클래스를 만들고 콜리전 등 간단 기능 추가
내가 만든 걸 굳이 엔진이라 부르자면 일종의 전기자전거 보조 정도였음
"엔진"이 프로젝트/게임 전체를 리드하는 상황이 자주 발생한다는 점
게임을 엔진에 맞추게 되는 경우가 많아 Unity 같은 대형 엔진 사용을 항상 피함
이런 엔진들은 결국 같은 게임 구조만 만들게 되고, 자산만 다를 뿐임
개인적으로는 엔진을 배우느라 시간 낭비하는 것보다 SDL로 짧은 러닝커브로 시작할 수 있고, SDL은 게임 외 다른 크로스플랫폼 프로젝트에도 활용 가능
내 게임: https://store.steampowered.com/app/2318420/Glypha_Vintage/
엔진을 직접 만드는 게 오래 걸린다지만, Unreal이나 Unity를 제대로 익혀 아이디어를 바로 게임으로 구현할 수 있을 정도가 되려면 어느 정도 시간이 필요한지 질문
결국 내 엔진 제작이 끝나면 바로 그 레벨의 전문성을 확보하므로 장기적으로 시간 절약
엔지니어 경력이 쌓일수록 직접 만드는 쪽이 시간 관점에서 유리해짐
게임이 독특하거나 틈새시장일수록 직접 만드는 쪽이 더 타당
Unreal의 복잡한 UI에서 몇 달 헤매고 애초에 원하는 게 범용 엔진에선 거의 불가능한 걸 알게 되는 경험은 비효율
반면 초현실적 오픈월드 RPG라면 직접 제작은 좋은 선택이 아님
커스텀 엔진의 제약이 오히려 창의성을 불러오고, 최고 수준이 아니더라도 더 독창적인 게임이 나옴
직접 엔진을 만들어 본 적 있음
처음에는 수많은 시행착오와 막다른 길을 겪으며 1년 정도 걸렸음
3D 렌더링, 적응형 UI, 스켈레탈 애니메이션, 세이브 파일, 스마트 오브젝트, 경로 탐색, 스크립팅, 오디오, 물리 등 게임에서 볼 수 있는 거의 모든 서브시스템 구현
특히 되감기 기능(Braid의 시스템처럼)을 직접 구현
이런 기능은 엔진의 모든 서브시스템(스크립트, 물리 등)의 지원 필요
내가 만든 엔진의 모든 부분을 알고 있어 추가 기능 개발에 엄청난 자유로움
하지만 1년 개발 후 점점 번아웃이 와서 의욕이 사라짐
Unreal은 모르지만 Unity는 직접 코딩과 비교해 10배 이상 빠르게 개발 가능
물리 기능은 1분이면 추가 가능하지만, 직접 엔진이면 외부 라이브러리 연동만 해도 하루 이틀 소요
Unreal 유저 Noel이 보여주는 내부 시각화 기능도 Unity엔 내장
바운딩 박스 조작 같은 편집도 기본 탑재
만약 엔진의 기본 동작이 부족하다면 ImGui나 Yoga 기반 CSS 엔진으로 쉽게 확장 가능
고급 파티클 에디터, 복잡성 해소된 셰이더, 모듈형 데이터 스트리밍 등 수많은 기능 제공
이론상 다 직접 만들고 싶지만 결국 시간 문제로 완성 우선
Unreal이나 Unity를 익혀 게임 아이디어를 바로 구현하는 데 걸리는 시간과, 직접 엔진 만드는 데 걸리는 시간은 다른 질문
조금만 아이디어 주면 몇 시간 안에 게임 플레이 가능한 프로토타입 제작 가능
Unity는 초기에 프로그래밍만 하면 되고, Unreal은 블루프린트만으로도 거의 게임 출시 직전까지 가능
10분 만에 슈퍼 헥사곤 스타일 게임 프로토타입 완성하는 영상 참고: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
유니티의 고유 요소는 프리팹 정도고 나머지는 게임개발 일반 개념
Unreal 개발자 입장에서라면 Unity로도 1시간 이내 비슷한 프로토타입 제작 가능
“엔진 완성 이후”란 가정 자체가 비현실적일 수도 있음
GameObject.Instantiate 같은 간단한 동작도 엔진에서 직접 구현하려면 어마어마한 리소스 필요
2D/3D 물리, 셰이더, 플랫폼 지원 등 복잡도 감안
엔진이 목표면 엔진을 만들고, 게임이 목적이면 게임 자체를 만들라는 의견
게임 엔진을 만들 만큼의 게임개발 지식이 충분하다면
Unreal이나 Unity를 익혀 프로토타입 만드는 데 하루면 충분
완벽한 숙련까지 오래 걸리지만, 원하는 게임 프로토타입 완성 시간은 비교 불가
"모두 다 하는" 대형 엔진 없이도 게임 만들기는 더 쉽고, 더 재밌고, 때론 더 효율적
다만 엔진의 특정 기능(예: Unreal의 역운동학, 애니메이션 블렌딩) 파고들다 보면 "차라리 직접 2~3주 고생 안 하길 잘했다"는 생각
미니멀리즘이나 비대화 방지도 중요하지만, 이런 엔진들이 무거운 일을 대신 해주니 인기가 많음
예전엔 나도 이런 방식이었음
첫 3D 게임 만들 땐 입력, 오브젝트 관리, 컬링, 모델 로딩, 수학 라이브러리, 그래픽스, 노멀맵, SSAA 등 다 구현하다가 정작 게임 완성률은 0%
그래도 취미 2D 프로젝트에선 여전히 브라우저 캔버스만으로 무의존 개발
사실상 브라우저가 엔진 역할
“차라리 직접 만들지 않은 게 다행”이라는 의견에 대해
장기적으로 인디 개발자 커리어를 생각한다면, 몇 주 걸리더라도 주제 깊이 이해+100% 소스코드 소유 및 재사용 가치가 더 큼
내 졸업 논문은 NeXTSTEP/Objective-C 기반 파티클 엔진을 Windows 95/Visual C++로 이식하는 주제(OpenGL 기반, marching cubes 샘플 포함)
이런 테마도 요즘 엔진에선 그냥 한 줄짜리 기능 중 일부
엔진을 쓰면 프로젝트 진행 속도가 훨씬 빨라지고, 인프라 개발에 시간 소진하지 않아도 됨
바퀴를 또 만드는 일은 대부분에게 큰 재미가 아님
역운동학이나 애니메이션 블렌딩 같은 기능은
만약 게임의 핵심이라면 구현할 가치가 있고, 아니면 불필요한 기술적 함정임
Lua & Love2D를 활용해 내 방식대로 게임을 만듦
자체 제약 걸기라는 점 자체가 재미의 핵심
개발이 재미없어지면 뭔가 잘못됐다는 신호이니 더 나은 방법 탐색
내 게임 YOYOZO는 39KB로 작지만 Ars Technica 2023 최고의 게임 목록에 대작들과 함께 올랐음
https://news.ycombinator.com/item?id=38372936
Playdate 구입한 지 수년 만에 SDK로 놀기 시작했는데, Lua도 처음 익히는 중
강 타입과 언어적 안전성 바람이 있지만 상황에 맞는 충분함
텍스트가 크랭크에 따라 가짜 3D 공간에서 도는 작은 기술 데모 만든 게 전부
https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
이 프로젝트를 하며 오래 전 CRUD/웹앱 경력으로 삼각법 거의 다 까먹은 것 깨달음
Playdate 개발의 최고 장점은 고정 캔버스라서 픽셀 위치만 정하면 모든 기기에서 그대로 동작한다는 해방감
지난 개발 경력에선 반응형 UI만 만들다 이런 경험 매우 새로움
게임 엔진(Godot, Unity, Unreal 등)으로 뭔가를 만들려고 하면 항상 엔진이랑 씨름하게 됨
결국 정해진 게임 형식에 에셋을 얹는 느낌이라 내가 원하는 게임 제작이 어려워짐
웹 개발에 비유하면, 워드프레스 같은 완제품 느낌
기본 구성이 의도와 다를 때는 엄청난 해킹과 우회 작업이 필요함
여기엔 "게임 템플릿"들이 기름을 붓는 역할
타이틀 화면과 모델만 교체하면 완제품 게임처럼 보이게 만들어주는 템플릿을 살 수 있음
Steam의 신작 중 거의 절반이 Unity/Unreal 템플릿 게임에 스킨만 살짝 바꾼 수준
각종 예시:
https://assetstore.unity.com/packages/templates/…
https://store.steampowered.com/app/2488370/Cash_Cleaner_Simulator/
https://store.steampowered.com/app/2073910/A_Webbing_Journey/
https://store.steampowered.com/app/3498270/Better_Mart/
https://store.steampowered.com/app/2625420/Drive_Beyond_Horizons/
https://store.steampowered.com/app/3163790/Toy_Shop_Simulator/
https://store.steampowered.com/app/3023600/Horse_Farm_Simulator/
https://store.steampowered.com/app/3124550/Liquor_Store_Simulator/
Google Play에서 모든 게임이 똑같이 보이고, 긴 로딩, 렌더링 문제, 텍스트 깨짐, 오디오 버그 등 Unity 특유의 문제점 발생
모바일 광고용 "idle RPG" 게임이라면 이런 게 용인될 수 있겠지만, VR 분야에서 Unity 쓴다는 건 정말 이해하기 힘들었음
Meta Quest Store 성능 충족하려면 Unity 엔진의 많은 부분을 뜯어고쳐야 함
성능 맞추기 힘들고, 일처리 방식도 구식
퀄리티 높은 소프트웨어를 만들고 싶다면, 처음부터 믿을 수 없는 엔진으론 불가능함
저자(노엘)는 Celeste라는 게임을 만들었으며 3백만 장 이상 판매
https://en.wikipedia.org/wiki/Celeste_(video_game)
나도 상당 부분 동의하며, 코드 기반의 C# 게임 프레임워크를 만들고 있음(XNA/Monogame의 정신적 후계, SDL 대신 Sokol 사용)
https://zinc.graphics/
현대적 C#의 강점: 크로스플랫폼, NativeAOT 컴파일링, 네이티브 핫리로딩, 리플렉션 등
개인적으로 소스 제너레이터도 추가
과거 부정적 이미지 남아 있지만, 최근 5년간 CoreCLR과 언어 발전은 놀라운 수준
딱 한 가지 바라는 건 Union Types인데, 현재 제안되어 내년에 추가 기대
https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md
C#은 Win32나 Unity에서만 써봤고, C/C++ 쪽 저수준 엔진 지식은 있지만, 게임 콘솔 등 크로스플랫폼에 C#은 불가능하다고 생각했음
내 생각이 틀렸다는 걸 이제 깨달음
어떤 소프트웨어든 처음엔 무에서 시작하는 걸 선호
대형 프로젝트 경험 있는 사람에겐 느리게 느껴질 수 있지만, 스타트업 단계에선 오히려 더 빠름
최소한만 구현하고, 추상화가 들어서면 새로운 기능 추가 속도가 더 빨라짐
기업용 대형 SW와 내가 직접 쓴 미니 엔진의 생산성은 완전히 다름
직접 쓴 코드는 바로 커팅, 리팩터링이 쉬워 훨씬 빠름
이런 이유로 마이크로서비스와 소규모 팀을 선호
직접 만들 땐 시행착오와 망가지는 지뢰밭을 반드시 거쳐야 하며, 언어나 플랫폼의 진짜 특성을 익히는 데도 수 년 소요
하지만 그 과정 자체가 결국 개발자의 내공으로 남음