나도 게임 업계를 지망하고있고, 게임 엔진을 개발하고싶고 특히 그중에 렌더링 쪽으로 관심 많은 입대 몇달 안남은 백수고. 이번에 새로운 렌더링 프레임워크를 만들려고 계획 하면서 갑자기 떠오른 생각이라 두서도 없고 말투도 오락가락 하니까 간단하게 참고하는 정도로만 봐주면 좋을 것 같음.
그리고 이미 자신만의 게임 엔진(또는 렌더링 엔진 등등)을 개발할 줄 알고 더 효율적이고, 아키텍쳐, 확장성, 고급 기술들에 관심있는 사람보다는. 처음으로 자신만의 게임 엔진을 만들어 보고자 하는 사람들을 위해 부족하나마 개인적인 생각을 글로 쓴거니까 재미로 봐줘.
일단 현재로서 자신만의 게임 엔진을 개발하는데 갖추어야할 최소한의 조건은 아래와 같다고 생각해
1. 현존하는 상용 엔진으로 최소한 1개 이상의 완전히 작동하는 튜토리얼을 진행해봄(유니티든 언리얼이든 cocos2d-x든 godot이든 종류 무관하게, 엔진에서 게임이 동작하는 과정<Update 가 어떻게 이루어지고, 렌더링은 언제 일어나고, 어떤 이벤트는 언제.. 이런 내용들에 대한 이해>)
2. 기초적인 수학 지식(유클리드 좌표계, 벡터/행렬 연산, Affine space 에서의 선형 변환에 대한 이해, 삼각함수, 기초적인 충돌 처리(Box대 Box, 원대 원 충돌 등))
3. 기초적인 그래픽스 파이프라인에 대한 이해(버퍼, 텍스쳐, 쉐이더 단계들(최소한 Vertex Shader, Pixel(Fragment) Shader), 색 이론, Alpha Blending, 각 쉐이더 단계에서의 변환들과 Homogeneous Coordinate에 대한 이해(View Matrix, Projection<Orthogonal, Perspective>, Perspective Division), 기초적인 빛 이론, 등)
4. Win32 든, glfw든 자신이 사용중인 플랫폼(Windows, Linux, OSX, 등), 에서 화면을 띄우는 법
5. 기본적으로 다룰 수 있는 주력 언어(C++, C#, Python, Rust,.. 어떤 언어를 쓰던 무관하지만, 게임 업계의 특성 그리고 오픈 소스 프로젝트나 튜토리얼이 C++이 압도적으로 많기때문에 C++ 추천)
6. 기본적인 OOP 개념에 대한 이해
---------------------------------------------------
이제 위에 있는 내용들을 전부 숙지하고나서 게임 엔진을 만들고 싶다는 생각이 들었을때, 가장 먼저 눈에 들어오는 건 아마 이때 까지 써왔던 엔진일 거임 나도 그랬고 (언리얼/유니티), 웬만하면 다른 사람들도 그럴거라고 생각함.
그래서 시작하기전에 몇 가지 사실을 이해해야 한다고 생각해
첫 번째로 일단 유니티든 언리얼이든 오래되고 거대해져서 개인이 따라하거나, 분석하기에는 무리가 있고, 그런걸 개인이 만들어 내는건 전성기 존 카맥을 데려와도 불가능할거임. (분석이 도움에 되긴하겠지만, 전체적인 틀을 이해하고, 그 세부적인 내용간의 연결고리를 만들어내는게 쉽진 않을거고, 들어가는 시간에 비해서 매우 비효율 적일거라 생각함. 최소한 개인적으론 그랬음)
두 번째로 게임 엔진(또는 프레임워크)라는 거는 게임을 만들다가 쌓인 부산물이지, 그 자체가 목표가 되버리는 주객전도가 될 가능성이 높아짐
-----------------------------------------------------
정리하자면 언리얼/유니티같은 엔진을 목표로 삼는건 오히려 역효과고 게임 엔진 자체를 목표로 잡는것도 목표가 모호하기 때문에 주객전도가 되버리고 시간만 낭비해버리는 상황이 될 수 있다.
그러면 어떻게 하란걸까? 답은 간단하게도 "게임엔진이 아닌, 게임을 만들자!"임. 언리얼 엔진도, 언리얼 토너먼트를 만들다가 자연스럽게 만들어진 프레임워크 였고, 유명한 존 카맥의 id tech 엔진은 둠, 그리고 캡콤의 MT 프레임워크, Crytek의 Cry Engine, 등. 이름만 들어도 알만한 유명 게임 엔진들은 대부분 게임을 만들면서 자연스럽게 탄생하게 됬음을 알 수 있어. 물론 유니티나 앞에는 언급하지 않은 여러 인하우스 게임 엔진들 처럼 범용성에 중점을 두고 개발된 엔진들도 있지만. 그런 엔진들은 모두 앞의 과정에서 축적된 노하우들을 집약 시킬 수 있었기에 만들어졌다는 사실을 알아야함.
결론적으로 상용 게임 엔진 없이, 자신이 직접 게임을 만들면, 그렇게 만들어진 프레임워크가 곧 게임 엔진이라는 거임.
즉 진짜로 자신만의 게임 엔진을 만들고 싶다면 큰 엔진 따라한다고 분석하는데 시간 대부분을 사용하고, 실제로 실행도 안되고, 컴파일 오류만 열심히 잡고, 콘솔 창에서 테스트만 주구장창 하면서 시간 보내지말고, 핑퐁을 만들던, 마리오를 만들던, 뭐 몬스터헌터를 만들던, 마비노기 같은 게임을 만들던간에, 필요한 기능만 구현해서, 실제로 실행이 되는 게임을 main.cpp 파일에 main 함수 적는 것에서 부터 시작해보란 것임.
-----------------------------------------------------
맨 처음에 말해준 6가지 조건을 모두 충족한다면 대부분 바로 시작해볼 수 있을테지만. 그래도 감이 안잡힌다면 기본적으로 2D 게임을 만든다 생각하고, 거기에 뭐가 필요한지 잘 생각해보면 좋을 것 같음.
예를 들어, 일단 윈도우 창을 띄우고 이걸 관리하는 Window 클래스던 Application 클래스던 무언가 있어야 할거고, 게임은 사용자가 끌때까지 계속 돌아가야 하니, 이런 무한 루프를 관리해주는 기능도 있어야 할거임. 그리고 게임은 가상의 물체들이 배치되어 있거나, 움직이는 거니까 뭔가 좌표계를 가지고 있는 Game Object 같은게 있어야 할거고. 예내를 전부 가지고 있는 가상 공간을 나타내는 Scene 같은 것도 필요하겠지.
그리고 사용자한테서 입력을 받아야하니까 Input 매니저 같은것도 있으면 좋을거같고.
2D 이미지를 그려야하니까, 화면에 2D 이미지를 띄울수 있게 사각형(Quad)도 그릴 수 있어야 겠지 그럴려면 그래픽스 라이브러리에서 Texture, Buffer가 필요할꺼고. 그리고 얘네를 그냥 GameObject가 다 가지고 있는거지. GameObject의 위치나 scale이 달라지면 그에 맞게 사각형의 크기나 위치도 변할 수 있께 해줘야하고. 띄우고 싶은 Texture를 쉐이더에서 사용할 수 있게도 만들어야 겠지.
만약에 GameObject 인데 중력 영향을 받고 싶게 하고싶다? 그러면 GameObject를 상속해서 PhysicsGameObject를 또 만들어서 Update에서 y 좌표를 -9.8*Delta Time 시켜줘.
또 뭐 2D 기반 충돌을 구현하고 싶다? 그러면 구글에 collision detection을 검색해서 그 내용들을 직접 구현해 나가면 되. 그걸또 GameObject 자체에 넣던, 또 상속해서 새로운 GameObject를 만들던 그건 너의 선택인거고.
여기서 중요한거는 뭐 요즘 엔진들에서 구현하는 ECS(Entity-Component System), Data driven(oriented) Architecture.. 이런 내용들에 신경 쓰지말고, 일단 마구잡이로 무식하게 너가 생각하고, 원하는 기능들을 만들거나, 추가하면서 천천히 직접 확장시켜보는 것. 이런 내용들이 나오게 된 배경을 직접 경험해보고, 그때 가서 관련 내용들을 찾아보고, 직접 자신의 소스코드에 적용시켜 나가보는것은 절대 시간 낭비가 아니라고 개인적으로 생각한다.
-----------------------------------------------------
이제 이렇게 간단하게나마 게임을 만들고나서, 그리고 그 이후에 자신이 계속 기능들을 추가해나가기 시작하고나면, 그때부턴 이제 다른 오픈소스 게임엔진들에서 내가 만든 기능들을 어떤 형식으로 구현했는지, 내가 직접 확장해나가면서 불편한점이 뭐였는지 생각해보고, 그걸 다른 개발자들은 어떻게 해결했는지(GDC 같은 컨퍼런스나 구글링 통해 찾아보기), 요즘 게임 엔진에서는 어떤 내용들을 구현하고 있고, 트렌드인 아키텍쳐 디자인은 무엇이고, 소비자들이 원하는 기능은 무엇인지. 를 찾아나가고 배우면서 계속해서 자신의 게임(또는 게임 엔진)을 발전시키고, 역량을 강화 해나가는게 중요하다고 생각한다.
모두가 자신의 엔진으로 자신만의 마비노기, 다크소울, 몬스터헌터, 디제이맥스, 데빌메이크라이, 크라이시스, 배틀필드, 배틀그라운드, 롤을 만드는데, 그 방향을 잡는데 조금이나마 도움이 될 수 있으면 좋을것 같네.
* 한줄 요약 : 자신만의 게임 엔진을 만드는 가장 확실한 방법은, 직접 main 함수에서 부터 게임을 만드는 것
몇학년임?
올해 졸업한 백수
군대왜안갔노
대학원 진학 생각하다 개인 사정으로
근데 유투브에 나돌아다니는 게임 학원 다렉포폴들에 대해 어떻게 생각함?
내부에서 어떤 형식으로 진행하는지는 모르겠지만 보기엔 괜찮아보이던데
근데 학원이 하나부터 열까지 다 알려주고, 기본적인 프레임워크 다 제공해준다는 기준이면 경험도나 숙련도로 따지면 위에처럼 백지에서 만들어서 쌓아올린 사람들이 더 잘 할 것 같음
난 만들어보려다 컴포넌트 시스템 어떻게 구현할지 감 잘안와서 때려쳤는데 유니티 랑 언리얼 중 어떤 방식이 더 낫다고 생각함? 성능이나 편의상 이점들 종합해서
둘다 나쁘지 않다고 생각하는데, 나는 시작을 유니티로 했어가지고 아직도 언리얼 엔진 구조는 익숙하지가 않다.. 아무래도 대학오면서 부터는 게임 보다는 CS, 이론 공부에 더 집중적으로 해서
스켈레톤 넘ㅁ 어려어워 ㅠ - dc App
이론적으론 알고있는데 구현할려니까 너무 어렵드라 Skeletal Animation..
군대에서 twigl로 glsl 작성하면서 레이마칭 은둔장인이 되기
이래저래 고민하고있다.. 뭐 어차피 가서 상황 보고 해야겠지만..
shadertoy만 알고있었는데 이런것도 있었네 고맙다
Shadertoy는 많이 무겁기도 하고, 최근에 일본쪽 트위터에서 #つぶやきGLSL 이라는 태그로 GLSL 숏코딩하는게 유행임. 트위터에선 글쓸때 280바이트가 제한인데 기존 GLSL 코드는 글자수 너무 차지해서 이를 짧게 압축해주는걸 twigl에서 지원함. (twigl에서 geekest (300 es) 세팅.)
gif로 프레임 지정해서 export하는 것도 지원하고. 츠부야키GLSL 태그에서 굉장한 작품들 많으니 관심있으면 저 태그로 검색해보길 바람
뭔가 머릿속으로는 이해되는 것 같으면서도 막상 실제 구현하려고 하면 턱 막혀서 자신을 저주하게됨. 윗댓글처럼 컴포넌트 시스템으로 만들고 싶었는데 감을 못잡겠다.
나는 매크로로 static hashmap에 default instance 저장해두고 Component 이름이나 typename으로 할당 요청오면 clone 해서 할당해주는 식으로 해뒀었음
컴포넌트는 해시보다는 배열이 더 좋지 않음?? - dc App
ECS 말하는거면 맞음, Component를 Linear 하게 저장해서 cache locality 높이는게 중요하지, 근데 처음 구조 짯을때, ECS 라기보단 유니티의 객체지향 기반 Component 시스템이랑 Node 베이스 Scene graph를 모델로 만들었어서 Entity(GameObject)가 동적할당된 Component의 포인터 리스트(벡터)를 소유하고있고, Component가 데이터만 가지고있는게아닌 프로세스도 가지고 있는 식으로 만들었었음. 이걸 데이터-프로세스(Component-System)로 분리 시켰던게 아니라
2년 지났지만 혹시 나중에라도 보는 사람 있을까봐 씀 오우거 일리히트가 주 스터디 엔진이고 자체 엔진 주로 만들떄부터 개발해온 사람인데 해시고 배열이고 범용 상용 엔진 만들거 아니라면 본인이 만들 게임 규모랑 구조에 따라 결정해서 정하는게 가장 좋음
형… 나 이 분야 지망하는데 요즘 형이 자꾸 한글로 이렇게 자세히 인트로듀스 해주니까 주지가 절절거려…
원하는 겜 그냥 첨부터 만들고싶어서 필요한것만 딱딱 만드는게 아니라 상용엔진처럼 에디터 존나 편하게 만드는건 진짜 혼자서는 말도 안되는거같음. 상용엔진은 에디터 기능이 50%는 먹고들어가는거같음
난 그냥 렌더링 외 부분은 entt, box2d, physx같은 인기 많은 라이브러리로 때우고 렌더링 구현에만 신경 쓸 생각이었는데 수학/전공지식 없이 하다보니 대가리 깨질거같음
렌더링 쪽이?
렌더링 ㅇㅇ
아무래도 조금 어렵긴하지.. 혹시 관심있으면 내 갤로그 보면 관련해서 글 써둔것도 있으니 한 번 훑어버는것도 나쁘지않을듯..