많은 분들이 이사다시피 저는 서버 프로그래머입니다만, 습작이나 오픈 소스로 공개한 SDK등에서 간단한 게임들을 공개해온적이 있습니다. 기본적인 클라이언트 작업 이해도는 있는 편이지만, 실무에서 클라이언트 코딩을 해온 기간은 짧은편이지요. (렌더링을 제외한 로직 구현이나 네트워크 코드를 주로 작성해왔죠. UI와 인게임 코딩은 습작에서 해온게 대다수입니다.)
그런 제가 대략 8개월여간의 유니티를 통한 개발 경험에 대해서 정리해보고자 합니다.
- 씬과 메타 파일로 인하여, 동시 작업이 어렵다.
- 4.x대까지의 유니티는 동시 작업이 불가능한 수준으로 보면 된다. 같은 파일에 대한 동시 작업은 피하는게 좋다. 이를 위한 소통 비용이 반드시 필요한 수준.
- 이런 문제로 인하여, 구조상으로 결합도를 낮추려는 노력을 하게 되기도 하지만, 피치 못할 사정이나 소통의 오류가 발생했을 때 한명의 작업 이외에는 날려야되는 문제는 그다지 좋은 상황은 아니다.
- 결국 우리팀은 파일별 작업자를 일감 분리를 통해 분리하는 룰을 가지도록 의도해, 통일한 파일 동시 수정을 피하곤 있으나, 많은 데이터를 아우르는 작업 자체를 기피하게 되는 큰 원인이기도 하다.
- 프리팹은 가급적 동적으로 사용하는 것이 좋다.
- 씬에 올려두고 사용할 경우, 해당 프리팹 외부의 delegate도 물릴 수 있지만, 이렇게 될 경우 프리팹이 수정될 때 마다 delegate가 날라간다.[예: UIButton의 on_click]
- 그래서 애초에 동적으로 연결하게끔 코드와 UI간의 연결 정보를 관리하면 이를 유연하게 대처할 수 있다.
- 에셋 번들로 패치 시스템을 만들 때도 고려하면 이 방법이 더욱 좋다.
- NGUI나 UGUI 둘다 편하긴하나, 위의 단점들로 인해 잦은 변경에 유연하지 못하다.
- 그럼에도 불구하고 UI 작업 자체는 여러모로 편의성 기능이 많고, 대다수의 UI 기능들이 이미 존재하는 것은 확실히 장점이다.
- C#스럽기보단 스크립트언어 다루듯이 접근해야 하는 부분이 많다.
- C#의 기능들이 전부 구현되어 있는 게 아니다. 사실상 일부만 구현되어있따고 보는 것이 더 많다.
- 유니티 자의적인 해석대로 구성되어있는 요소도 꽤 있다.
- 사실상 C#의 문법만 가져왔다고 마음 먹는 것이 정신건강에 좋다.
- 코루틴은 최적화의 해결책이 아니다.
- 멀티 쓰레드 쓰듯이 코루틴을 다룰 수는 없다.
- 그렇기에 결국 블러킹함수를 많이 쓸 수록 문제가 생긴다.
- 쓰레드에서는 유니티 함수를 사용할 수 없다.
- 그래서 결국 최적화나 블러킹 상황을 줄이는 데에 한계가 있다.
- 씬과 프리팹 저장이 직관적이지 않다.
* 런타임에 변경한 정보가 바로 반영되는 점, 씬 단위로 실행 할 수 있는 점, 일시정지 할 수 있는 점등은 장점이다.
- 하지만 내가 유니티 툴에서 테스트한 상태 그대로 파일로 저장되어 있지 않을 수 있는 점은 외부 버전 관리 시스템 (git, svn 등)을 사용하는 입장에서 큰 혼란을 가져다 준다.
- 그래서 위에 언급한 대다수의 정보를 동적으로 연결하게끔 관리한다면, 많은 문제를 우회할 수 있다.
- 모든 씬에서 정상동작하게 관리하는 것은 장단이 있다.
- 모든 씬에서 기능이 정상동작하게 하기 위해서는, 코드의 선행 조건을 만족시키기 위해, 애매모호한 룰을 세우게 되는 경우가 있다.
- 특히나 패치 시스템을 사용하고, 코드와 메타 데이터를 관리하는 경우가 특히 그런데, 가급적 실행해볼 수 있는 씬을 한정지어 스크립트의 전제 조건을 줄여주는 것이 좋다.
- 예외처리 규약은 C++이나 C#으로 직접 제작할 때와 다르게 고민해봐야 한다.
- 유니티가 추상화 해놓은 레이어 위에서 예외처리 정책도 정해야 하기 때문에, 이를 감안한 예외 처리 룰을 세우는 것이 좋다.
- 특히 STL과 다른 동작을 하는 컨테이너가 많다. C++에 익숙한 사용자는 더더욱 컨테이너에 대한 레퍼런스를 다시 읽어보아야 할 것이다.
간략하게 정리해본 유니티 사용시 팁과 사견이었습니다. 아마도 한참을 더 사용하게 될 거 같은데, 그에 따른 여러 판단은 생각 날 때 마다 정리해서 공유해보록 하겠습니다.