[💬] 현업에서 고도쓰는 경우와 내가 고도에서 갈아탄 이유

요약) 엔진 선택에 절대적으로 옳고 그른 것은 없다. 남한테 뭐라 하지말고 스스로 중요한 것이 무엇인지 생각해보고 선택하자.

---

얼마전에 3N 중 하나 다니는 친구가 자기네 프로젝트 고도쓴대서 이야기를 좀 나눠봤더니,

웹게임 만들때에는 확실히 유니티보다 경쟁력있는 것 같다는 얘기하더라고.

나도 공감한게, 유니티 웹빌드보면 내부에서 자바스크립트 오류 잔뜩 나고 있고,

무슨 호환도 안되고, 뭐도 안되고 해서, itch.io에 간단히 무료 게임 올리는 정도 이상으론 힘들겠다 싶었거든.

---

참고로 난 2년 전 쯤에 고도에 진지했었는데, 결국 유니티로 갈아탔어.

진지했던 이유는, 가볍고, 오픈소스인데, 뭐가 더 필요해? 기본적인거 만들기 쉽고.

하지만 회사 그만두고, 진지하게 인디게임 만들기로 하면서 2년 전에 고민했고, 결국 유니티로 갈아타기로 함.

1. gdscript는 양날의 검

간단하게 파이썬스럽게 코드 짜는거 좋다.

웬만한 프로그래밍언어에 있을거 다 있다.

하지만 그래도 인기있고 성숙한 C++, C#보단 많이 부족하다고 느꼈었음.

특히 다른 언어의 표준 라이브러리에 당연히 있을 것 같은 기능이 없는 경우에 약간 벙찐적이 좀 있음.

gdscript에서도 C#등 된다고 하는데, 요즘엔 모르겠지만 당시에는 gdscript가 프로젝트의 메인 언어여서 다른 언어 지원은 상대적으로 느렸어.

게다가 Godot는 안그래도 사용하는 상대적이 사람이 적은데, 비주류에서 또다시 비주류(Godot에서 C# 등을 쓰는 것)로 가는 것은 문제가 생겼을 때 도움을 얻기도 힘들고, 그래서 이건 그건 좋은 선택지가 아니라고 생각해.

2. 외부 연결성 (Steamworks?)

요즘은 어떤지 몰라도 당시에는 Godot에 Steamworks API 연결하기가 참 까다로웠어.

당시에 Steamworks 연동하는 오픈소스 프로젝트가 하나 있었는데,

C++ 코드로 Steamworks API를 gdscript wrapper를 만든다음 직접 Godot 엔진을 컴파일해서 나온 런타임을 쓰는 구조.

근데 또 이게 안되는 것도 많고 내가 필요한 기능은 포팅이 안되어있는 경우도 있어서 그 프로젝트에 기여하고 막 그랬었는데,

하다보니 시간 엄청나게 쓰고, 게임만들려다 이게 뭘하고 있나 싶더라고.

3. 태생이 오픈소스

당시 Godot는 소수의 코어 컨트리뷰터들이 리딩하는 프로젝트였음.

다시 말하면 어느날 갑자기 저 사람들이 버스사고(혹은 갑자기 때려치고 싶거나)라도 나면, 갑자기 프로젝트가 망할 수 있는거야.

운이 좋다면 다른 사람이 손들고 나서서 내가 계속 프로젝트를 유지하겠다 하는 사람이 나올 수도 있겠지만...

또 코드가 오픈되어있으니까 필요한 기능 직접 만들어가며 쓸 수 있겠지.

하지만 이렇게 되면 주객전도가 되어서 게임을 만드는게 아니라 엔지 유지관리 비용이 더 커질거야.

즉, 엔진 건전성 측면에서 위험할 수 있다고 생각해.

댓글 4