[💬] 유니티 10년 썼다.

[유니티뽀Q먹어(116.40)]

유니티는 쓰레기가 맞다.

처음 사용했을 때 느낌은 

이 새끼들 게임 개발 경험이 없네... 라고 느낄 정도로 

대학교 학부생 졸작 정도 수준으로 조악했다.

이건 못 쓰겠다 생각하다가도

당시에는 대안이 없어서 그냥 쓰기 시작했지

한동안 유니티 엔진 안 쓰면 투자도 안 들어오고 퍼블리싱도 어려워 지면서

이 좆 같은 엔진을 계속 쓰게 됐고,  그렇게 난 유니티 지옥에 갇혔어

업데이트 될 때마다 사라졌던 버그 다시 나오고 아오.. ㅅㅂ 

버그 여기저기 뺑뺑이 도는 거 이해할 수 있어

헤드 개발자들이 능력이 딸리니 자기보다 떨어지는 애들 데리고 개발했을 거고 

뭐 그러려니 해

이 엔진의 가장 좆같은 문제는 메타  파일이야

이거 못 버리면 유니티 엔진은 얼마 못 간다.

어느날 갑자기 유니티가 프로젝트 하위의 모든 폴더의 파일마다 메타  파일이 생겼고,

그 파일을 열어봤을 때 파일 버전이랑 uid가 적힌 텍스트파일인 거 보고

머리가 띵~ 하더라 

이런 멍청한 아이디어 떠올리고 스스로 존나 뿌듯해 했을 거 아냐 ㅋㅋ

이 븅신 같은 새끼들은 자신들이 얼마나 이런 끔찍한 짓을 하고 있는지 몰랐을 거야

역시 메타파일 오류 때문에 스크립트나 라이브러리 컴파일 캐시 꼬이고, 미친 

메타 파일과  C#, 모노의 환장 콜라보 크리티컬 터지면 진짜 환장한다 환장해

원인도 모르는 버그 때문에 개고생하고, 프로젝트 열릴 때 에디터 뻑나서 롤백하고 아오...

이 개삽질을 보면서 메타 파일 버릴 줄 알았는데 이 악물고 버그잡아 가면서 유지하더라 ㅅㅂ ㅋㅋㅋㅋ

존나 또라이 같은 새끼들이 파일의 이력과 버전관리가 필요했으면 git을 넣던가 아오 또라이 새끼들

이런 븅신 같은 짓거리 때문에 프로젝트의 파일은 미친듯이 늘어나고, 뭐만 했다하면 홀드 걸고 메타파일 정리하고 

ㅅㅂ 이런  유니티 내부에서는 사장님~ 메타 파일 좆같아요~~ 라고 외치는 사람도 없는 건가?

수시로 메타 파일 체크한답시고 쓸데없이 디스크나 갈가 먹고 ㅅㅂ

유니티 수준은 다른 엔진 좋아 보이는 거 어설프게 따라 가는 정도인데 

이 좆같은  메타  파일 때문에 기본적인 형상관리도 안 되니까 

인원이 많아지고, 프로젝트가 커지면 점점 프로젝트 자체가 불안해지고,

CI, CD 구축하면 뭐하냐 프로젝트파일 맨날 뻑나는데 아오...

지금까지 맘먹고 갈아 엎어도 2~3번은 더 갈아 엎었겠다.

이 좆같은 메타  파일은 유니티 엔진의 자존심이나 현실부정 발작 버튼인가?

왜 이 좆같은 메타  파일 못 버리냐 아오...

유니티는 딱 2명이 공동작업하기 알맞고, 이상 늘어나면 지옥이다 지옥...

[수박반통(1bnmaker)]

혹시나 대박나서 개발자+디자이너=10명되면 언리얼로 갈아타려고 생각하고 있긴했는데 이 글을 보니까 그 전에 갈아타는게 좋을것 같네요 ㅋㅋㅋㅋ 대강 개발자 3명에 디자이너 3명쯤이면 갈아타는게 맞을까요?

[유니티뽀Q먹어(116.40)]

커뮤니케이션만 잘 되면 문제가 없는데 프로젝트 터지는 거 막느라 이런저런 설명해주기 시작하면 디자이너들이 많이 힘들어하더라고요. 알려주고 주의를 줘도 사고는 계속 납니다.

[유니티뽀Q먹어(116.40)]

디자이너가 배포용 메인 신에 접근을 막는다 쳐도 프리펩 건드리다가 콤포넌트 바르고 빡시게 설정한 객체들 지워지고, 계층구조 바뀌는 사고가 나기 시작하면 진지하게 고민하세요.

[수박반통(1bnmaker)]

금쪽같은 조언 감사드립니다 ㅠㅠ

[익명(183.97)]

근데 궁금한게 있는데요. 미호요에서 원신을 만들때 개발진 인원이 약 400명이라고 들었는데 그 사람들이 엔진을 선택하기 전에 지금 말씀하신 부분들을 몰랐을까요? 지금 말씀하신 글의 뉘앙스는 유니티가 큰 규모의 프로젝트로 작업하기에는 너무 치명적인 것이 많다라고 하시는데 그 400명 중에 프로그래머도 굉장히 많을텐데 그 개발자들이 멍청한것도 아닐텐데

[유니티뽀Q먹어(116.40)]

400명 정도되는 조직은 규모가 자본의 규모가 다릅니다. CI, CD 전담하는 담당자 따로 두고 있습니다. 유니티에 형상관리도 여러종류가 있는데요. 개발자 친화적인 GIT을 사용할 수 있으면 베스트인데 여러가지 문제가 많습니다. 플라스틱 쓰거나 별도의 확장기능을 만들어서 대형 프로젝트를 유지하고 있습니다.

[유니티뽀Q먹어(116.40)]

어느정도 규모가 있는 회사가 유니티를 사용할 때는 프로젝트 전용 툴을 만들어서 자원관리를 하고, 유니티는 크로스플렛폼 빌드 엔진으로 사용한다고 보시면 됩니다.

[익명(183.97)]

음 그러면 저 본문의 내용에 좀 더 추가해야 할 말이 있어야 하지 않을까요? 자본의 규모가 다른 대기업 수준에서는 괜찮은 엔진이다. 뭐 작성자님의 개인적인 생각이 난 아무리 그래도 유니티는 후진 것 같아 한다면 어쩔수없지만 저는 솔직히 원신같은 굉장히 큰 스케일도 유니티로 만드는거 보고 아직까지도 엄청 훌륭한 엔진이네 싶어서요.

[유니티뽀Q먹어(116.40)]

유니티 프로젝트에서 100명단위의 인력 널널한 조직이 아닌, 소규모 10~20명 정도의 조직에서는 xml을 이용해서 버전관리하는 방법을 많이 씁니다. scene파일과 프로젝트에 필요한 애셋의 정보를 xml파일로 저장하며 버전관리를 하고, 빌드시 xml파일을 읽어 scene파일 및 리소스 등을 배치하여 오류없는 프로젝트를 유지하는 방법을 사용하기도 합니다.

[익명(183.97)]

그럼 뭐 아직 괜찮은 엔진이네요~

[유니티뽀Q먹어(116.40)]

대기업 수준에서 괜찮은 엔진이다. 라고 생각하면 안 됩니다. 대기업이니까 그나마 성과를 내는 것이다라고 생각하셔야 합니다. 유니티는 정말 부족한 게 많은 엔진이고 본문에서 말씀드렸던 것처럼 어쩔 수 없이 유니티를 사용해야 하는 경우가 있다는 것입니다. 조직의 능력에 따라 유니티로 좋은 성과를 낼 수 있죠. 그런데 태생적 한계 때문에 프로젝트가 커지면 커질수록 팀원 전체가 힘들어집니다.

[수박반통(1bnmaker)]

xml관리하느라 두통이 늘어나겠군요....현업개발경험이 없어서 몰랐는데 좋은 내용 배우고 갑니다. ㅠㅠ 회사다녀본 분들은 유니티뽀Q먹어님이 얼마나 심각하고 우울한 문제를 지적하시는지 이해하리라고 믿어요 ㅋㅋㅋㅋ ㅠㅠ

[ㅇㅇ 1(39.115)]

183 혹시 문해력 낮음?

[익명(183.97)]

너무 편협하게 결론 내리시는거 아닐까요?

[유니티뽀Q먹어(116.40)]

메타파일 시스템을 긍정적으로 평가하시나요? 제가 가지고 있는 메타파일에 대한 생각이 편협하다면, 메타파일의 긍정적인 부분에 대해서 듣고 싶습니다.

[잘살어(qlqhdl08)]

꼬우면 직접 만들어쓰고, 버그 못잡는건 그냥 개발자인 너가 개못하는거다. - dc App

[익명(118.241)]

등신 ㅋㅋ 어휴 나가 뒤져라 ㅋㅋ

[유니티뽀Q먹어(116.40)]

음... 제가 코딩한 로직의 오류는 두말할 거 없이 제 문제죠. 제가 하려는 말은 엔진 버전 관리의 불안정성과 계속해서 고쳐지지 않는 에디터 버그들을 말하는 겁니다. 엔진이 지원하는 특정 기능을 욕하는 것도, 다른 엔진에는 있는데 유니티에는 이런 기능이 없네 같은 얘기를 하는게 아니고요. 유니티를 쓰면서 게임 로직과 프로젝트 운영에 신경 쓰는 것이 아니라 프로젝트 뻑 안 나도록 신경 쓰고, 시한폭탄 같은 프리펩 보이면 안전하게 해체하는 등의 불필요한 에너지를 소모하는 것들에 대한 푸념입니다.

[익명(118.241)]

근데 메타파일 말고 다른 대안이 있음? 메타파일 없이 임포트 세팅이나 다른 인스펙터 안에서의 데이터관리를 어떻게 함?

[익명(118.241)]

유니티 에디터 안에서 각종 오브젝트를 건들고 하니까, 메타파일 같이 에디터 안에서 변경한 데이터를 관리하는 파일은 필수로 나올수 밖에 없고 에디터 같이 엄청 변경이 쉬운 환경에서 메타파일이 뻑이 날 확률도 높고 뻑이 나면 ㅅㅂ 골아파지는것도 맞는데 다른 대안이 떠오르지 않는다 아니면 내가 메타파일을 잘못이해하고 있나

[유니티뽀Q먹어(116.40)]

다른 엔진들은 자체적으로 개발한 파일 레퍼런스 디비 구조들이 있습니다. 각 폴더 및 폴더 안의 파일에 1:1로 매칭하는 아스키파일을 만들어서 관리하지 않습니다. 파일 디비 만들 여력이 없으면 git 라이브러리를 써도 된다는 겁니다. 메타파일의 아스키 데이터는 yaml로 되어 있는데 이것만 봐도 에디터 개발자 편하게 개발하자고 선택했다고밖에 볼 수 없습니다. yaml 파일로 파일의 정보를 저장했다는 것은 유니티 에디터 개발자 편의 말고 다른 이유가 있을까요? 자기 코딩 좀 편하게 하자고, 다른 파트의 개발자뿐만 아니라 유니티 엔진을 사용하는 사용자한테까지 엿을 먹이는 겁니다.

[익명(118.241)]

오... 그렇군.. 내가 내공이 부족해서 파일 레퍼런스 디비 구조가 뭔지 잘 모르겠음 현재 메타파일이랑 그렇게 다름? 그거 관련 검색 키워드나 좋은 정보 사이트 있으면 알려주면 좋겠는디

[유니티뽀Q먹어(116.40)]

주로 사용하는 리눅스 맥 윈도우에서는 하나의 폴더에 같은 파일이름을 허용하지 않습니다.
"파일경로/파일명.확장명" 구조로 된 패스는 이것 자체가 유니크합니다.
파일 하나하나에 uid를 설정할 필요가 없다는 것이죠.
uid를 사용한다고 해서 사용자 입장에서는 그다지 편한 게 없습니다. 에디터 개발자만 편해지죠
버전관리 공부하시려면 git 보시면 됩니다.
https://opentutorials.org/module/2676

[익명(118.241)]

아... 까고 싶은게 uid 랑 파일 버전관리였음? ㅇㅇ... ;;; 내가 글을 대충 읽었나벼

[익명(125.140)]

나는 아티스트라서 잘은 모르겠지만 .메타라는게 그런거구나 리소스 넣을때마다 폴더에 생기더라고 ㅋㅋ

[유니티뽀Q먹어(116.40)]

메타파일의 정보가 처음 생성됐을 때 그대로 유지되면 상관없는데 플렛폼 스위칭하고, 라이브러리 추가하고, reimport하면 내용이 변합니다. 그럴때 아티스트분이 본인이 작업하던 폴더 통으로 덮어 씌우면, 레퍼런스 꼬이고 난리나기 시작합니다. 레퍼런스 문제가 발생하면 유니티 에니터는 홀드 걸어 놓고 쭉 다시 정리하하는데 프로젝트가 커지면서 정리하는 시간도 점점 늘어나고, 가끔 정리에 실패하는 경우가 있어 프로젝트 뻑나면 아주 돌아버립니다. ㅠㅠ

[익명(125.140)]

뭔말인진 모르겠지만 뭐 할때 개발자한테 물어보고 함 항상ㅋㅋㅋ

[김메가(scw973108)]

고도엥진은 으때여

[유니티뽀Q먹어(116.40)]

계속 발전하고 있더라고요. 조금 더 시간이 지나면, 메이져 엔진으로 급부상할 것 같습니다. 상업적인 성공 레퍼런스가 쌓이면 사용자도 늘어나고 자연스럽게 에코시스템도 강화될 거고 고도 엔진으로 확 몰릴 가능성이 있죠. 당장 유니티처럼 상업화 수준의 활성화는 어렵다고 보고요. 블랜더처럼 재단 만들어서 운영하면, 유니티 정도는 머리끄댕이 잡고 무료화 시킬 정도의 포텐이 있다고 생각합니다.

[유니티뽀Q먹어(116.40)]

유니티보다 기본 빌드 크기도 작고 가벼워서 C#으로 크로스플렛폼 앱 만들어도 될 것 같더라고요.

[김메가(scw973108)]

고도의 진가를 알아보시니 전문가중에서도 전문가 개발자중에서도 개발자이시어라 인갤을 굽어살펴 널리 이롭게 하시옵소서 아멘

[이카루가(darklord7290)]

[익명(219.249)]

이거맞다... 작년에 뭐 윈도우 11로 업뎃하니이상하게 돌아갔따....ㅅㅂ... 이게 말이되나 코드는 같은데 - dc App

[익명(119.207)]

ㅋㅋㅋ 아무튼 쓰레기임 간증 쏟아지는거 보소

[익명(223.62)]

개발 경력 10년동안 넌 어떤 겜을 만들었는데?

[익명(222.112)]

난왜 메타파일 이슈를 이 글에서 처음 보는걸까

[익명(221.140)]

내가 보기에는 글쓴이는 게임 엔진에서의 파일의 의존성 + 속성 관리(메타 파일)와 프로젝트 형상 관리(git)의 개념조차 이해를 못하고 있는거 같다. 메타 파일의 대안을 어떻게 생각하면 git을 넣으라는 거냐? ㅋㅋㅋㅋ 이거 하나만 읽어 봐도 글쓴이의 수준이 보인다.

[유니티뽀Q먹어(116.40)]

제가 글을 너무 띄엄띄엄 써서 혼선을 드린 것 같네요. 본문은 유니티 메타파일에 관한 문제를 말씀드린 겁니다. 파일과 1:1 대응하는 메타파일을 만들어 놓고 파일 관리하는 경악스러운 부분을 지적한 내용이죠. 다른 엔진에서 하는 것처럼 자체 관리 디비를 만들어 관리하는 것이 필요하다는 저의 주장인 거고 그럴 능력 안 되면 git처럼 관리하라는 걸 말하는 겁니다. 좀 더 풀어서 말씀드리죠. 폴더에 메타파일 때려 박지 말고 .git 라이브러리라도 넣어서 관리라도 하라는 겁니다. 댓글에 잠깐 언급된 고도엔진의 경우 .godot 폴더에 ui나 파일 레퍼런스를 관리하고 있습니다. 이런 방법론 적인 부분을 말씀드리는 건데 메타파일과 형상관리 개념조차 이해하지 못한다고 말씀하시나요?

[유니티뽀Q먹어(116.40)]

yaml 형식의 메타파일에 정보 때려 넣고 리소스의 변경이나 레퍼런스가 달라질 때마다 Serialize와 Deserialize를 반복하는 어처구니 없는 상황을 말하고자 하는 겁니다. 그렇게 관리할 거라면, 관리하기 힘들게 같은 폴더에 생성하지 말고, 차라리 git이나 godot가 하는 것처럼 프로젝트 최상위에 폴더 만들어서 바이너리 데이터로 만들어서 관리하는 게 더 낫다는 말을 하는 겁니다.

[유니티뽀Q먹어(116.40)]

메타파일이 얼마나 골때리는 상황인지 단편적인 예를 들어보겠습니다. png 파일의 메타파일을 보면 유니티 버전마다 다르겠지만, 통상적으로 3kb 정도 합니다. 이 안에 실제 필요한 정보보다 yaml 구조 텍스트가 대부분입니다. 달라지는 건 숫자 정도인 거죠. 제대로 관리한다면, 어딘가에 해당 이미지 파일에 대한 데이터 값만 따로 뽑아서 바이너리로 저장하면 파일 용량도 줄이고, 불필요한 IO도 줄어들죠 한 폴더에 이미지가 100개 들어있으면 100개의 메타파일이 만들어지는 것이고 이 메타파일들은 80%는 동일하고 나머지 일부분의 값만 다른 거죠 생각만 해도 골때리는 상황인 겁니다. 값만 뽑아서 바이너리로 만들면 지금 유니티 사용자들이 겪고 있는 고통이 줄어들겠죠.

[익명(221.140)]

이런 병신이 있나.... 글쓴이 유니티 10년차 맞음? 혹시 글쓴이의 경력이 유니티 부터 시작해서 지금까지 10년차인거임? 글쓴이는 지금 글쓴이가 무슨 소리를 하는지도 모른다에 5천원 걸수 있음 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

[유니티뽀Q먹어(116.40)]

메타파일로 파일의 정보를 각각의 폴더에 따로 저장해 놓는다는 말은 바꿔 말해서 중앙관리하지 않겠다는 말이고 실제로도 하지 않습니다. 필요할 때마다 하드디스크 랜덤 액세스해서 리소스 단위로 읽고 쓰겠다는 말인 겁니다. 3kb 그거 얼마나 한다고 이렇게 난리냐? 라고 생각하실 수 있습니다만, OS 파일 관리 차원에서도 문제가 될 수 있고 실제로 문제가 자주 발생합니다. 유니티 파일 처리는 스크립팅(매크로) 방식을 사용하며 파일과 관련된 기능은 병렬처리하지 않고 일괄처리합니다. (순서대로 하나씩 처리합니다.) 이때 OS는 메모리 블럭을 생성하고, 파일 버퍼 매핑하고, 파일 닫으면 메모리 블럭 정리하는 것을 빠르게 반복하게 됩니다.

[익명(221.140)]

유니티에서 메타 파일은 바이너리로도 생성 할 수 있음.. 지금도 여전히 메타 파일은 바이너리로 생성 할 수 있는 옵션이 있음...

[유니티뽀Q먹어(116.40)]

OS가 파일 메모리 블럭의 생성과 반환를 반복하다 이상(교착상태)이 발생하면, 유니티의 파일 매크로가 홀드되며 멈춥니다. 있으나마나한 cancel 버튼 누르며 기다리거나, 유니티 강제종료하거나 선택해야 합니다. 한참 개발 중에 이러면 정말 힘 빠집니다. 바이너리로 만들어서 한번에 메모리에 올리면 불필요한 블럭 낭비 없이 빠르게 처리할 수 있으면서도 기존에 파일 매크로 창 띄워야 하는 엿같은 상황도 백그라운드 프로세싱할 수 있는데 이걸 할 생각이 없으니 빡이 치는 겁니다.

[유니티뽀Q먹어(116.40)]

ㅇㅇ(221.140) 메타파일 자체가 아스키냐 바이너리냐의 문제가 개별 파일로 나눠지면서 발생하는 문제가 포커스입니다.

[유니티뽀Q먹어(116.40)]

ㅇㅇ(221.140) 원색적인 비난만하지 마시고, 제가 얘기한 git이 무슨 의미였는지 이해하셨다면 그에 대한 답을 해주시면 됩니다.

[익명(221.140)]

무슨 근거로 메타파일의 정보를 중앙 관리 하지 않는다고 생각함?한 예로 내가 메인 캐릭터의 머터리얼 정보를 수정 했어.... 그런데 이 머터리얼의 폴더가 이상한데 있네?그래서 정상적인(?)위치의 폴더로 머터리얼을 옯겼어?글쓴이의 경험상에서 머터리얼의 폴더 위치를 옯기면 그 머터리얼을 참조 하고 있는 다름 캐릭터들이 정상작동 안함?이게 왜 정상 작동 하는 걸까? 이게 uid의 필요성과 엔진에서 에셋의 관리하고 있다는 거야..그게 파일의 절대 경로가 아닌 uid일 뿐.. uid가 없으면 무슨일이 벌어 질까?

[익명(221.140)]

그리고 참고로 이야기 하지만 유니티에서 메타 파일은 처음부터 존재 했었음... 갑자기 나온게 아니라....

[익명(221.140)]

그리고 나는 여전히 엔진에서 메타파일과는 상관없이 git을 고려 해야 되는지를 모르겠다. 엔진 단에서 git서버를 구축해주는 엔진이 있나?

[익명(119.192)]

아재 메타파일 바이너리로 변환하는 옵션 어딨음?

[유니티뽀Q먹어(116.40)]

ㅇㅇ(119.192) 프로젝트 셋팅 에디터에 보시면 Asset serialization에 있습니다.

[유니티뽀Q먹어(116.40)]

ㅇㅇ(221.140) 메타파일이 처음부터 있었나요? 말씀 듣고 생각해보니... 정확히 몇버전부터 나왔는지 떠오르지 않네요. 제가 착각했나봅니다. 혼란을 드려 죄송합니다.

[유니티뽀Q먹어(116.40)]

ㅇㅇ(221.140) 그리고 제가 하고자 하는 말은 왜 uid로 파일을 관리함? 이 아니라 uid를 왜 파일마다 따로 관리함? 인 겁니다. 유니티는 파일의 정보를 중앙관리하지 않고, 메타파일로만 관리합니다. 예를 들어서 메터리얼을 만들고 머터리얼에 텍스쳐를 설정했다고 가정하겠습니다. 그때 텍스쳐의 메타파일을 열어서 uid 일부를 수정하고, 다시 유니티로 돌아오면, 메터리얼에 걸었던 텍스쳐가 풀리게 됩니다. 이런 문제는 각자 컴퓨터에서 동기화 되지 않고, 생성되는 메타파일과 각종 캐쉬들이 겹치게 될 경우 혼란이 생긴다는 겁니다.

[유니티뽀Q먹어(116.40)]

이미지나 눈에 보이는 데이터에서 컨플릭트가 발생하면, 최신버전 확인해서 넣을 거 넣고 뺄 거 빼면 되는데 신파일이나 메타파일에서 uid 컨플릭트가 발생하면 골치아파집니다. 단순 파일 생성일로 최신데이터 여부를 판단할 수 없고, 해당 리소스가 어떤 신 또는 프리펩에서 사용되는지 확인하고, 머지할 브렌치의 신파일을 같이 비교하면서 판단해야 합니다.

[유니티뽀Q먹어(116.40)]

어느 정도 규모 있는 조직에서 버전관리는 필수인데 작업자가 uid 관련 충돌은 더 많아지며, 팀즈 콜라보를 사용하더라도 아티스트 애셋 모으는 정도로 사용하고, 실제 버전 관리는 깃이나 플라스틱 등으로 해야 하기 때문에 본질적인 문제 해결은 아닙니다. 팀원들 git 개념 잡고 잘 교육하고 fork 같은 클라이언트 사용해서 최대한 쉽게 위험성을 낮추는 것뿐이지 유니티 기본 시스템만으로도 해결되지 않는 문제입니다.

[유니티뽀Q먹어(116.40)]

ㅇㅇ(221.140) 다양한 언어로 Git Library는 공개되어 있습니다. 유니티 에디터에 포함해서 파일 관리를 git으로하면 더 안정적인 레퍼런스 관리가 될 수 있고, Git으로 형상관리하는 조직에서는 환영할 업데이트입니다. 기존의 개발 프로세스를 유지한 상태에서 유니티를 도입할 수 있고, 버전관리가 지금보다 더 안전해진다면, 개발팀 스케일아웃이 더 용이할 것입니다.

[유니티뽀Q먹어(116.40)]

유니티 불편하고 자시고, 없는 기능은 만들어 쓰면 되고, 버그는 피하면 되는데 파일 레퍼런스 문제로 신파일 작살나고, 심한 경우 메인 브렌치에 머지는 됐는데 머지는 잘 됐어도 막상 메인브렌치의 유니티 프로젝트 띄워보면 뻑나있고, 이런 개빡치는 것만이라도 해결 돼야 앞으로 비벼볼 수 있다는 겁니다.

[익명(182.230)]

[ㅇㅇ 1(39.115)]

결론 221 개병신

[익명(211.220)]

선생님 저는 요즘에 스크립트 컴파일러하면 자꾸 유니티 크래쉬 나는데, 크래쉬 로그 잘보는 꿀팁 있나요?? 모바일 로그캣은 크리티컬 이렇게 표시되기라도 하는데 메모장만 봐서는 통 모르겠어요

[유니티뽀Q먹어(116.40)]

상황이 다양해서 크래시 리포트 눈 빠지게 보는 거 말고는 꿀팁은 모르겠어요. 가장 최근 스크립트 빌드만하면 죽는 경우는 유니티에 NAudio 사용해야하는 경우가 있었는데 Play 후 NAudio가 포함된 스크립트를 수정만 하면, 스크립트 빌드 중에 에디터가 죽는 일이 발생했었습니다.

[익명(7hvc5bphs4sv)]

그거말고도 유니티 문제 되게많지않나?? 나도 기억은안나는데 엔진에서 존나심각한문제 3개정도 있다고 들었엇는데 물론난 언리얼이라 몰?루

[익명(125.133)]

유니티는 쓰레기지만 쓸모있는 쓰레기라고 결론짓자

[dd(59.10)]

git쓰면됨. svn은꼬일수도있고

[dd(59.10)]

근데 그게 유니티의문제는 아니지 버젼관리 문제지

[더벅(221.151)]

글쓴이님은 유니티 vs 겜메이커스튜디오 vs 언리얼 중에 젤 좋은 엔진은 뭐라고 생각하시나용?

[1234(14.35)]

유니티로 게임 출시 3개했는데 도대체 뭐가 그렇게 불만이건지 이해가 안가네 ㅋㅋ

[익명(58.239)]

아니 근데 인디 뜻 모름? 여기서 팀인원 많아봤자 3~4명이고 5명 넘어가면 존나 큰회사지 요새 개발자 3명 이상에 기타인원으로 플젝굴리면 연매출 10억씩 뽑아야 겨우 유지나 하는 사이즌데 뭔 메타 땜에 형상관리가 힘드네 시발ㅋㅋ 좀 공감할만한걸 들고와야 우쭈쭈라도 해주지 10년찹니다 깔아놓고 시작부터 권위에 호소하면서 정작 핵심적인건 개소리만 하고 있으니

[익명(182.210)]

10년차 만든게임 인증 없으면 뭐다? ㅋㅋ

[익명(211.243)]

플레이스토어 매출1위 = 유니티

[익명(59.187)]

그럼 엔진 쓰지 말던가 ㅋㅋㅋㅋ 엔진이 가진 수많은 장점은 다 뭉개버리고

[익명(59.187)]

이런게 단점이다 그래서 쓰레기다? ㅋㅋㅋㅋ 그럼 안쓰면 되는거 아님? 대안을 내놓아보셈 10년이나 했으면

[익명(211.114)]

갉아먹고*