아직 게임을 완성은 못해서 후기라기엔 그렇고 중기로 하겠습니다;;
아직 뭐 현업이거나 게임개발로 수익을 버는 단계는 아니라서 게임개발자 "지망생" 신분이고요. 혼자 개발합니다.

제 배경을 좀 얘기하자면 저는 10년전에 취미로 obj-c, swift로 iOS/macOS 개발에 입문하여 앱을 몇개 출시하고, 더 개발하고 싶었으나 제 아이디어를 애플 리뷰가이드라인이 받아들이지 못하여 폭망했습니다 (연속 리젝으로만 두 세달 보낸적도 있네요).

웹쪽도 좀 아는데 기초 HTTP는 파이썬으로 배웠고 (파이썬을 공부해보진 않음), HTML/CSS/JS/PHP로 앱스토어 랭킹사이트도 만들어보고 각종 백엔드 찍먹을 위해 웹프레임워크는 Node.js와 Swift Vapor, Swift IBM꺼 그 뭐더라..  그런것들을 대충 해봤습니다. 그래봤자 취미수준 Dev-ops죠.
닷넷코어는 최근에 좀 공부하다가 말았구요(이건 프레임워크 규칙이 완전 다르더군요?). 여튼 제 배경은 이렇고 

지금은 유니티 게임독학(유튜브,인강등)한지 1년 되었구요. 완성작은 아직 없습니다. 캐주얼게임 개발임에도 불구하고 아직 완성 못한이유는 위 배경에서 보듯 제가 호기심이 많아 중간에 이것저것 다른거에 눈돌리기 바쁘기도 했고, 생계를 위해 노가다를 두 세달 나가기도 했습니다.

C#과 유니티 공부시작 3개월된 뒤부터 제 게임개발을 시작했고요. 앞으로도 해야할일이 태산같이 쌓여있네요.

UI

앱개발하던 저인지라 유니티의 UI 프로그래밍 부분에 관심이 많게되었는데  uGUI가 UI 디자인(레이아웃)하기엔 매우 편했습니다.
 GUI ? WYSIWYG? 이랄까요. 포토샵하듯이 에디터에서 넣으면 되니까요. Xcode 스토리보드 생각도 나고 그랬죠. 저는 일반앱개발에서 UI디자인도 uGUI 같아야한다고 생각합니다. 직관적이고 실시간으로 보이고.. 좋더라고요.

유니티에서 UI를 구성하는 방법은 여러가지가 있는데요. 크게 방식을 나누자면
1-1) uGUI:  UI 캔버스에 UI를 전부 구성하는 가장 일반적인 방식. 그래픽디자인은 아니지만 배치하는게 그냥 눈으로 보고 마우스로 끌어다 만들면 됩니다.
1-2) uGUI를 코드로: 당연히도 유니티 API를 잘 안다면 코드만으로 UI 만들 수 있습니다. 다만 매번 RUN해봐야겠죠 ; 핫리로드 안됨, 될수도 있겠으나 에디터 프로그래밍 필요. 그러나 코드베이스는 물론이고 그렇게 하는 사람 자체가 없어서 자료찾기 불가능에 가까움


2-1) 2D 스프라이트로 : 본래 2D 스프라이트는 인게임 개체이지만 터치/드래그 이벤트 일일히 제어해가면서 평면 UI로 동작하게 가능합니다. 

2-2) 2D 스프라이트를 코드로: 당연히도 코드로만 만들 수  있습니다. 게임로직과 같기때문에 되려 이게 쉽게 느껴질 수도 있습니다.

(스프라이트 방식은 3D도 가능은 합니다만 그건 일반적으로 UI라고 하진 않겠죠. 게임환경과 구분되지 않는 UI를 시도한 게임도 있구요.)

3) UI Toolkit(UI 빌더):  전이게 첨에 뭔가 했는데 uGUI와는 다른 방식의, 유니티의 새로운 UI 디자인 방식입니다만 별다를건 없고 HTML/CSS 를 유니티만의 UnityXML / Unity SS 문법으로 해놓은 겁니다. 비슷한 변종이 닷넷의 Xaml, Style 이죠. 경험많은 프론트엔드 웹개발자들이라면 툴킷쪽이 uGUI보다 적응이 쉬울것같지만, 그럼에도 불구하고 저는 UI하기엔  uGUI가 낫다고 생각합니다. 

개인적으론 워크플로우상 미완성된 툴의 느낌예요. 특히 게임UI로는 아직? 쓰길 꺼려지는 방식이지만 유니티측에서는 요즘 이거 밀고 있습니다. 에디터 프로그램용 UI 로는 괜찮다대요.
전 개인적으로 CSS를 혐오하기때문에 이건 쓰지 않습니다.

물론 능력자는 전부 짬뽕도 가능하겠죠. 물론 uGUI에대한 자료가 가장 많습니다.

개인적으로 꼽는 UI가 인상적인 게임은 페르소나 5인데, 페르소나 5는 자체툴로 만들었다곤하지만 유니티도 대충 멀티윈도우 빼곤 불가능한건 없다 정도로 생각하면 됩니다. 한계는 있을 수 있지만 2D게임은 uGUI 만으로도 게임을 만들 수 있습니다.

번외로 에디터 프로그램 UI 개발도 파편화 되어있는데요. 

전통적으로는 순수하게 코딩으로만 UI를 만드는 방식이었지만 UI Toolkit과 함께 괴상한게 몇개 붙어있대요. 이건 공부하다 말아서 특별히 할 말은 아니지만 굳이 나누자면 순수코드로 vs  UI Toolkit 인데
에디터 프로그래밍은 강의 만드는 사람도 적고, 코드로 하는 방식과 툴킷으로 하는 방식이 격하게 다르고, 자료적고, 파편화된 정보속에서 잘 골라보기가 힘든면이 있습니다. 

하여튼 iOS앱의 IB, 스토리보드, 순수코드 그리고 웹의 CSS, 닷넷의 Xaml 을 겪어본 저는 UI배치, 제어에있어서는 유니티의 uGUI가 최고였습니다.

엥? UI시스템이 아무것도 없잖아?

그럼에도 불구하고 유니티가 부족한 건 아무래도 게임엔진이라서 인지 UI 시스템 API가 부실하다 못해 아예 없습니다.그러니까 앱개발에서 기본으로 갖추어진  Push,PopBack 하는 UI 내비게이션 시스템 이런게 없습니다. 자기가 직접 다 구현해야되요. 써드파티 에셋을 사던가.

(용어상으론 유니티에서 '내비게이션' 이라함은 탭 키누를 때 Selection이 버튼사이를 옮겨다니는 걸 말하므로 다릅니다만 암튼..)

iOS 앱개발에서는 당연하게 그냥 사용하던 걸 제가 직접 구현하려하니 이런걸 어떻게 만드는지 생각해본적도 없더라고요 ㅎㅎ

당연히 탭뷰, 테이블뷰, 컬렉션뷰(그리드뷰) 이런것도 없습니다. 직접 다 구현하든지 써드파티 에셋사서 공부하고 적용해야됩니다.

레이아웃 자체는 UI의 레이아웃 컴포넌트가 Horizontal, Vertical, Grid 이런건 다있어서 그렇게 배치하는 거야 uGUI에서 매우 쉬운데,
iOS예를 들자면 테이블뷰는 프로토타입셀을 만들어 그걸 재사용하는데 그런 시스템 자체가 유니티에는 없어서 직접 만들어야합니다.

생각없이 셀을 1천개 2천개 넣었다간 렉땜에 UI 못쓰니까 셀재사용 시스템을 만들어야하는데 그걸 또 만들어본 적도 그럴필요도 없었던 앱개발자로선 힘든 일이었습니다.  numberOfRowsInSection, cellForRowAtIndexPath, TableViewDataSource 이런 클래스,메서드, 델리게이트 콜백 API를 직접 하나하나 만들어야한다고 생각해보세요 ㅎㅎ 지금 제 UI내비게이션 손대기 싫을정도로 스파게티입니다. ㅠ.ㅜ

즉, 유니티에서 UI는 복잡할 수록 코딩은 지옥이 됩니다 (즐겁기도 하고요 ㅋ)

 언어 

유니티의 게임로직 언어는 C#인데요. 몇몇 언어를 사전에 접해봤지만 게임개발 처음 입문때 워낙 비장한 각오를 다지느라 C# 먼저 각잡고 공부했습니다. 그래봤자 책에나온 기초뿐이지만요. 닷넷이 참 재밌는 환경이더라고요 ㅎㅎ 

C#이 오래 발전한 만큼 별의별 기능이 다있는데 유니티개발할 때 전부 알아야하는건 아니지만 게임개발에서는 자신이 굳이 쓰려고하면 안쓸 기능이 없다는 점이예요. 

물론, 유니티가  C# 지원버전 중 극히 일부기능은 지원을 하지 않아서 그런건 못쓰지만요. 몇가지 제한도 있습니다.  유니티 프레임워크의 클래스 MonoBehavior를 상속받는 클래스는 생성자를 못쓴다거나 하는 점말이죠.

자바도 안해봤고 C#은 처음인데 저는 전통적인 C계열 언어를 안좋아합니다. swift를 해서인지 최신언어의 간결함과 가독성을 사랑해서요. 반환타입이 앞에 있는 것부터가 코드 읽기 힘들어요. 앞에 제한자 붙고 키워드 붙고 거기다 유니티에서 C# 특성(attributes)를 많이 붙이게되느데 앞에 덕지덕지 붙어서 더 힘들더군요.

C#도 재밌는 기능이 많긴하지만 단적인 예로 swift 에서는 메서드 파라미터를 내부이름과 외부이름을 달리 할 수 있는데 C#에선 그게 안되니 이름지을때 술술 지어지지가 않네요(저는 swift 할 때 메서드 이름을 파라미터 포함해서 문장으로 짓던 편입니다)

다른 언어의 경우엔  닷넷환경이라서 다른언어로 만든 DLL도 유니티에서 쓸수 있고하니 닷넷업계분이라면 C++라이브러리도 잘 쓰고 하겠죠.

유니티가 공식 지원하지 않는 모바일 네이티브기능 쓰기위해 swfit, kotlin으로 플러그인을 만들수도 있고요(하지만 왠만한건 다 써드파티에셋이 이미 지원하고 있습니다). 

그리고 저는 관심없지만 파이썬 라이브러리를 쓰거나, 파이썬 프로그램을 실행시킬 수 있다고 하더군요.

다양한 디자인패턴 적용

Composite Pattenr (혹은 컴포넌트 패턴)은 유니티에서의 게임프로그래밍 근간이되는 패턴인데요
MVC나 MVVM이 주였던 다른 분야이다가 이패턴을 쓰다보니 참 편하더군요. 이것저것의 인스턴스가 난립하는 게임개발에서는 이처럼 좋은 디자인패턴이 있나 싶네요. 재사용성도 높고요.
게임오브젝트에 컴포넌트(클래스의 인스턴스)를 이것저것 붙이게되는데 이처럼 재사용성 높고 편리한 패턴인 줄 몰랐어요. 

이 패턴뿐만 아니라 옵저버 패턴이라거나 상태패턴등 게임개발에서는 자기가 맘만먹으면 적용가능한 패턴들이 많더라고요.  그래서 항상 고민됩니다. 어느게 가장 좋을 방식인지 개발방식을 고민하는 것도 일이예요.

앱개발에서 많이 썼던 MVC는 되려 재사용셀 그리드뷰 UI 시스템 만드는데만 쓰고 게임로직에서는 쓸일이 없는 것같고요.

델리게이트와 이벤트는 iOS앱에서 싱글뷰 끼리만 데이터가 옮겨다니는 그런 환경에서는 그냥 인스턴스 멤버를 실행하는거랑 어차피 인스턴스 참조를 갖는건 같아서 별다른 차이를 못느끼고 꼭 델리게이트 써야하나? 싶었거든요. 게임개발에서는 인스턴스가 1:N, N:N 등이 일반적인 환경이다보니 이해가 되더라고요.  델리게이트 없었으면 어쩔뻔했나 싶을 때가 많습니다.

비주얼 그래프를 이용한 코딩 

C#같은 텍스트언어가 아닌 네모에 선연결하는 그래픽의 비주얼 스크립팅 (언리얼에서는 블루프린트)도 가능한데요.  저 개인적으론 비주얼 스크립팅은 많이 회의적입니다. 

수많은 클래스,함수 API를 공부해야하듯이  어차피 그것들을 네모로 바꾼것 뿐인 비주얼 스크립팅도 마찮가지로 그만큼 공부해야합니다. 거기다 커뮤니티 환경이 폭망인게 비주얼스크립팅은 자료찾기어려움,  복잡해질 수록 알아보기 어려움, 질문하기,답변하기 어려움(묻기위해선 스샷 찍어야함, 영상을 만들까? 화면을 공유할까?), 쓰는사람 없음, 오픈소스 부재등등으로 말이죠.

이럼에도 불구하고, 유니티측과 기타 누구누구등이 왜이리 "코딩을 몰라도 게임을 만들수있다"같은 말로 입문자를 현혹하는게 전 맘에 안듭니다만.. 뭐 딱히 제가 상관할 바는 아니죠.

비주얼 그래프는 게임로직에서 뿐만 아니라 쉐이더와 VFX(이펙트: 파티클 효과)에서도 쓰이는데요.이쪽은 게임로직과는 경향이 다르기때문에 비주얼그래프가 유용하더라고요. 

셰이더의 경우 두가지로 나뉘는데
-비주얼그래프 방식 : 셰이더 그래프

-셰이더 언어 방식:  유니티 셰이더 언어 사용 .CG/HLSL, GLSL 등의 업계 셰이더 언어와 비슷하지만 또 다른 유니티만의 셰이더언어를 씁니다.

이펙트의 경우 

-파티클 시스템 (성능 낮음. 사용제한이 낮음): 게임오브젝트에 붙는 컴포넌트 (클래스 인스턴스)로서 그냥 체크박스, 프라퍼티값등을 인스펙터에서 조정하거나 C# 코드로 API 제어. 파티클 자체에 물리충돌 컬라이더를 포함할 수 있어서 재밌는것들을 많이 할 수 있습니다. 다만 CPU연산이주라서 성능이 낮습니다.

-VFX (성능 높음, 사용제한이 높음) : 셰이더 그래프처럼 비주얼 그래프 사용 (코드 언어는 뭘 쓰는지 모르겠네요). 컬라이더는 사전에 정해진 위치, 정해진 모양에만 되어 매우 제한적입니다. 그럼에도 불구하고 GPU연산이 주라서 가능한 파티클수가 많아 매우 화려한 이펙트를 꾸밀 수 있더군요.

방대한 엔진의 기능

엔진기능이 정말 많습니다.  그에따라 API도 많죠. 그런데 어떤게임을 만들거냐에 따라 대개는 필요없죠 (포토샵에 기능이 많아도 Crop만 쓰는 본인). 그래서 배울게 정말정말 많습니다. 알아야할게 너무많아요.  공부다하고 겜만들어야지 하면 3년뒤에나 시작가능했을거같아요.

3개월 공부만하다가 안되겠다 이제 실전으로 부딛히며 알아내는게 최고다하고 시작했는데 고작 제 게임만드는데 필요한 기능을 익히는데도 정말 많이 공부해야되었습니다.

게임개발에서 프로그래밍 능력의 비중?

이건 비단 유니티로만 한정하긴 그렇고 다른 엔진까지 포함해서 얘기해야하는데요. 게임분야로 와서 재밌었던게 필요한 프로그래밍 능력범위가 굉장히 넓다는 것였습니다.  기준은 '어떤 게임을 만들 것인가'에 따라 다르다는 거죠.

비주얼 노벨이나 텍스트위주의 게임의 경우 유니티를 쓸 것도 없고 언어를 알 필요도 없더군요. 

만들려는 게임에따라서는 언어를 가장 등한시 할 수 있는 분야가 게임분야더라고요. 다른분야는 코딩공부 빼면 진행이 안되는데 유니티 게임개발입문자들은 C#이고 C고 몰라도 일단 유니티부터 배우는걸로 시작해서 게임완성까지 하는 사람이 많더라고요. (물론 유니티게임개발은 C# 모르면 애로사항이 꽃피고 3개월걸릴거 1년걸리게 생겼습니다만...)

프로그래밍 쌩초보입장에, 언어공부를 하기 싫어하는 마음 + 많은 초보대상 강좌가 많은 유니티 커뮤니티환경이 합해져서 거꾸로 배워도 결국 잘 해내는 사람들이 종종 있더라고요.

그런데 조금 복잡한 것들이 들어가면 프로그래밍 능력이 당연히 중요해지죠. 게다가 한없이 높은 능력자는 한없이 높아질 수 있는게 게임분야의 프로그래밍이 아닐까 합니다.  특히 성능문제가 걸리게되는 단계에선 더욱 중요하고요.

그리고 소규모 인디게임 (혹은 1인개발)에 있어서 플레이어에게 크게 어필되는 부분이 그래픽이죠. 어떤땐 스토리기도 하고요. 그러다보니 그럴땐 프로그래머 비중이 쪼그라드는 느낌이예요. 가장 중요한건 게임성을 결정짓는 기획인 건 어쩔 수 없고요 (그럼에도 불구하고 기획자 무용론은 소규모 게임개발 분야에도 만연하더라고요 ㅎㅎ)

부족한 엔진부심 ㅋ

저는 구형 맥에서 개발하느라 언리얼은 선택하지 못했는데요. 좀 아쉬운면은 있습니다. 1인개발로써 AAA급 그래픽 만들것도 아니라서 유니티로도 차고 넘치지만 언리얼로 만들었다고하면 유저들도 내심 기대하는데 유니티는 별로 자랑거리가 되진 못해서요 ㅎㅎ 언리얼 5나왔을땐 아이고 컴 새로사서 저걸로 할껄..할 정도였죠.

그리고 늘 성능에대한 괜한 근심이 있습니다. 유니티 2D개발이어도 (실제는 3D환경) 성능문제가 생기곤하는데 그럴때마다 언리얼이었다면 이쯤에서 문제가 안되지 않았을까하는 괜한 견물생심?이 생기기도 합니다.

그러면서도 한편으론 언리얼로 시작했다면 여기까지 올 수 있었을까? 싶어요. 유니티의 개발방식이 쉽고 자료도많고 질답도 활발하고 커뮤니티 발달이 잘 되어있어서요.

macOS(인텔)에서의 개발환경에대한 아쉬움 

저는 맥 쓴뒤로 10년넘게 맥만 써왔거든요. 유니티개발시작하고 난뒤로 MS와 합작으로 저를 괴롭히곤 하는데 macOS보다는 윈도우환경이 더 좋습니다. 

다른 코드에디터가 가능한지는 모르겠는데 유니티가 공식지원하는건 Visual Studio이고 VS Code도 가능한데요.
맥용 VS는 개인적으로 사용이 어려운 정도입니다. 지원기능 자체도 애초에 부실해요. 저는 VS Code써서 그나마 나은데 개발환경 세팅이나 디버깅등 애로사항이 꽃핍니다.

맥용 VS에서는 맥사용자들이 많이 쓰는 (이젠 업데이트가 없는) 구름입력기를 쓰면 한글입력상태에서 숫자나 특문쓰면 키입력이 Insert 모드로 동작하는 문제가 있고, 맥용 VS의 코드를 복사해서 다른 노트앱에 붙여넣으면 신텍스하이라이트같은 텍스트스타일은 날려먹은채 복사해주고요. 윈도우용 VS는 확장설치도 자유로운데 맥용은 안됩니다. 흔한 테마변경도 어려워요.

VS Code는 그나마 나은데 코드자동, 힌트주는 확장프로그램이 무거워서 느리고 오류도 납니다. 두번째창(탭아님)에서는 아예 동작하지를 않고요(클래스/메서드 정의 보기 불가능...) 

그리고 결정적으로 맥이 그래픽 윈도우컴퓨터에 비해 딸려서 (가성비 폭망) 윈도우 컴 사는게 낫겠더라고요. 저는 인텔맥인 상황에 업글을 하려고해도 맥이 M1, M2 나오는데.. 맥미니부터 맥 스튜디오등 역대급 애플 잔치인 시기에 정작 저는 업글을 위해 윈도우컴터 사야겠는 이 심정이 참담해요 ㅎㅎ

끝나지 않는 고민과 선택장애

게임개발이 처음이라는 이 상황이, 현업의 경험이 전무하고 물어볼사람도 없다는 제 상황이... 저를 많은 고민으로 이끕니다. 단순히는 C# 문법을 어떤걸 쓸까부터 이런 상황에는 어떤 패턴을 써야할지등.. 어떻게든 되면 그게 맞는 방법이라곤 하지만 뭐가 더 나은 선택일지 설계고민으로 일주일을 보낼때도 있었어요. 아는게 많아질수록 더 선택이 힘들어졌고요.

게임완성이 중요하지 코딩을 어떻게했든 문제없이 돌아가기만 하면 되는데도, 다른 프로그래머분들은 그러시곤하겠지만 괜한 코드 고민많이 하잖아요. 뭐 그런거죠. 당연히 클래스,메서드,변수 이름짓는게 젤 어려운건 마찮가지고요. 게임개발은 거기다가 스프라이트이름,몬스터이름, 오브젝트 이름, 에셋 파일이름, 씬이름, 스테이지이름등등등 이름이름이름이름!! 작명소가 옆에 있었으면 싶습니다.

너무 장문의 글을 쓰게되어 이만 줄입니다. 이걸 다 읽으셨다면 게임개발에 대단한 관심이 높으신 것이므로 어서 입문하시어 저와같은 고통을 공감해주세요.