타르코프 최적화로 화날 때마다 와서 조사하고 작성하는 글
타르코프란? (Escape from Tarkov)
2016년 8월 4일 알파 테스트를 시작으로 아직 개발(정식 출시 X)하고 있는 유니티 엔진 FPS 게임. 유니티에서 '우리 엔진을 사용하시면 이런 게임도 제작이 가능합니다.'고 홍보하는 게임 중 하나.
2016년부터 지금까지도 공식 포럼에 엔진 변경을 고려해야 하지 않냐고 종종 글이
올라오는 게임이다.
공식 포럼에 운영자가 남긴 엔진 교체 관련 답변
최적화와 각종 버그 및 프리징(멈추는 현상)으로 고통받는 건 기본사양이고 어느 정도 해결돼도 다음 패치에서 어떤 식으로 다시 버그와 멈춤 현상이 발생할지 아무도 모른다. (실제로 몇 번 재발생)
출처: https://youtu.be/h2hyZkzgHPc?t=415
이런 문제를 인지하고 유니티에서 제시한 방법은 점진적 GC(Garbage Collection) 도입인데 근본적인 해결방안이라기보단 임시방편.
타르코프는 유니티 5를 시작으로 유니티 2018까지 순차적으로 업그레이드 작업을 진행했으며 2021년 여름 유니티 2019 업그레이드를 목표로 하고 있다.
아래는 유니티 엔진의 문제점을 알아보면서 발견한 자료들
유니티는 2021년 4월 포럼에 '2021.1 릴리스부터는 이전 시스템(엔티티 기반)에 대한 호환성이 없어져서 2020 LTS 버전에 머물러 있어야 한다. 최대한 빠르게 정보를 제공하겠다.'라고 공지를 올렸다.
링크: https://forum.unity.com/threads/notice-on-dots-compatibility-with-unity-2021-1.1091800/
'크게 우려할 상황은 아니다.', '자세한 설명이 없는 일방적인 소통방식이다.'는 것과 같은 다양한 반응들이 쏟아지고 있는데 이제 발표하고 사용한 지 겨우 1~2년 된 기술 스택을 다시 크게 바꾸는 정책이나 지금도 이 순간에 개발되고 있는 다양한 프로젝트에 대한 고려가 충분히 논의되고 있는지 의심스럽다.
유니티는 2018년 11월 ESC 시스템을 발표했다. 멀티스레딩을 위한 잡 시스템(Job System) 등등 최적화와 관련된 기술들을 발표했다.
발표영상 - https://www.youtube.com/watch?v=j4rWfPyf-hk
아래는 이를 적용한 사례 발표 영상
유니티 엔진 게임 리스트
https://en.wikipedia.org/wiki/List_of_Unity_games
언리얼 엔진 게임 리스트
https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games
유니티와 OpenGL을 사용해 간단한 게임을 만든 뒤 비교한 영상
총알 오브젝트 개수당 100개의 프레임을 그려내는 데 사용한 시간 그래프
총알 오브젝트 개수당 CPU 사용량
총알 오브젝트 개수당 GPU 사용량
총알 오브젝트 개수당 RAM 사용량
유니티 코드 라인수: 542
OpenGL 코드 라인수: 2619
유니티 개발자가 2019년 언리얼 개발에 들어가면서 객관적으로 비교하기 위해 작성하고 있는 글
https://gametorrahod.com/objectively-comparing-unity-and-unreal-engine/
에픽 CEO 팀 스위니는 C#의 단순함을 좋아하지만 데이터가 실제 C++ 구현에 연결되어야 하는 것은 마음에 들지 않는다고 말했습니다. 실제로 유니티가 C++ 데이터베이스 기반의 MonoBehaviour를 사용하고 있기에 빠져있는 함정입니다. 유니티 CTO 또한 MonoBehaviour가 나빴다는 점을 인정했습니다. 이제 유니티는 모든 객체(Entity)에 C# 기반의 데이터베이스를 가지고 있는 ECS를 이용해 이를 제거하고 있습니다.
Joachim Ante(유니티 CTO): 게임 객체 기반은 OO(object oriented)가 유행하던 시절부터 14년 동안 만들어졌으며 궁극적으로 그 비용이 얼마인지에 대한 명확한 시각이 없었습니다. 또한 우리는 14년 전에 지금과 같이 성능을 우선시하지 않았습니다.
- 끔찍한 어셈블리/도메인 리로드 타임
유니티를 멀리해야할 이유가 있다면 바로 이것
- 확장 문제
추가된 많은 스크립트로 인해 도메인 리로드가 길어지고 플레이 모드로 들어가는 시간이 길어진다. 스크립트를 자유롭게 추가하는 것을 두려워 하게 된다.
- TypeCache API
2019.2 유니티에서 이 문제를 해결하기 위해 UnityEditor.TypeCache API를 도입
https://forum.unity.com/threads/unityeditor-typecache-api-for-fast-extraction-of-type-attributes-in-the-editor-tooling.687682/
- 그렇다면 언리얼은?
많은 사람이 블루프린트를 유니티의 Prefabs와 비교하지만, 그 이상이다. 디자인한 그래프를 개별적으로 C++ 코드로 컴파일 할 수 있다. 개별적으로 컴파일되기 때문에 유니티처럼 컴파일 시간이 기하급수적으로 확장되지 않음을 의미한다. 좋아 컴파일 시간은 유니티의 스피너와 같지만 그 이후에 대해 말해보자. 언리얼 엔진에서 리로드할 도메인이 없다고 생각한다. Play 모드로 들어가는 것이 너무나 빠르다. 2019.3에 추가된 도메인 재로드 비활성화는 이것에 비하면 기껏해야 반창고 붙이기다.
- 버그 보고서 절망의 QA 벽돌 벽
나는 유니티가 축적한 나쁜 평판에는 QA 직원에서 비롯된 것이라고 굳게 믿고 있다. 발견한 버그를 고치게 하는 것은 매우 어렵다. 나는 아직도 그들에게 도달하지 못한 버그 묘지가 너무 많지만 계속 버그와 같이 살아가야 한다. 언리얼에서는 모든 엔진의 소스를 볼 수 있기 때문에(매우 어렵지만) 궁극적인 해결책을 가지고 있다. 유니티에는 엔진 코드에 대한 접근 권한이 없어서 개발자 측면에서 블랙박스를 만들고 사용자 측면에서 에러를 만드는 트리거를 생성한다.
- 프로젝트 재작업의 광기(Project-breaking, reworking madness)
유니티는 너무 많은 구조 변경이 이뤄지고 있다. 유니티를 고수하려면 지속적으로 앞으로 나가야 한다.(LTS 버전을 사용하지만 프로젝트 수명 내내 불안전하다. 내 프로젝트는 단단한 구조에서 변경에 준비된 구조(agile)로 변경됐다. 하지만 결과적으로 너무 많은 시간을 잃었다.)
다음 블로그 글은 2019.3 릴리스 후보가 어떤 소란을 만들어 내는지 볼 수 있다.
(유니티 공식 블로그로 댓글에 개발자들이 남긴 장문의 불만 글을 볼 수
있습니다. 수정-현재는 없어졌습니다.)
https://blog.unity.com/technology/2019-3-is-now-in-the-final-stages-of-beta-testing
마이크로소프트가 마인크래프트 회사를 인수한 후 자바로 만들어진 마인드 크래프트를 C++로 재개발한 '베드락 에디션' 벤치마크 영상 (Optifine은 최적화 모드)
댓글 없음:
댓글 쓰기