뭐 작은 프로젝트 할 일이 있어서 사람 모이고 게임 뭐만들지 정하고 했는데
엔진 정할때 내가 언리얼 써보고 싶다고 밀어붙였음
그래서 개발 엔진으로 언리얼 결정
처음에는 아는게 없어서 그냥 유니티식으로 주먹구구 만들려고 했는데
이게 뭔가 유니티랑은 완전히 다른 차원의 엔진이었음
더 좋고 나쁘다 그런 말이 아니라 설계 사상 자체가 다름
예를 들어서 유니티에서는 게임오브젝트라는 객체에 우리가 만든 스크립트를 컴포넌트를 붙일 수 있고
게임오브젝트간의 트랜스폼 계층구조를 활용하기 쉽고, 프리팹이 있어서 객체의 재사용도 쉬운데
언리얼에서는 액터라는 객체에 스크립트를 컴포넌트로 붙일 수 있는건 유니티랑 같은데
내가 원하는 액터를 커스텀으로 새로 만들 수 있음 거기서부터 일단 혼동이 일어났고
컴포넌트간의 트랜스폼 계층구조가 존재함 물론 액터간의 트랜스폼 계층구조도 존재하는데
액터간의 계층구조는 뭔가 활용하기가 어려움 엔진 자체적으로도 이런 액터 계층 구조를 권장하지 않는 느낌
게다가 유니티의 프리팹에 해당하는 블루프린트는 (언리얼 2까지만 해도 이름이 프리팹이었다고 함)
액터로 계층 구조 만들어놓은거는 블루프린트화가 안됨
엄밀히 말하자면 되긴 되는데 구조가 좀 웃김
액터와 액터로 계층구조가 저장되는게 아니라
액터와 액터를 스폰해주는 컴포넌트로 계층구조가 저장이 되더라
간단히 말하자면 "블루프린트를 만든다 = 비주얼 스크립팅 가능한 커스텀 액터를 만든다" 임
근데 블루프린트의 비주얼 스크립팅은 정말 강력하더라
손꾸락으로 타이핑 하면서 코딩하는 것 보다는 생산성이 월등함 일단 프로토타이핑용으로 좋고
외국 유튜브 보니까 보통은 C++ 스크립트로 구조 짜놓고 그 위에 블루프린트로 재정의 해서 기능을 구현한다고 하더라
그리고 좀 빡치는점 있음 OnTriggerStay()랑 OnCollisionEnter(), OnCollisionExit()에 해당하는 함수가 없음
OnTriggerStay()는 뭐 쓸 일 많이 없고 직접 Update()에다 기능 구현하면 그만인데
OnCollisionEnter(), OnCollisionExit()가 없으니까 미치겠더라
그거 빼면 물리쪽은 정말 근사하게 작동함 물체가 너무 빨라서 벽 뚫는 그런거 없음
그리고 엔진 자체적으로 무슨무슨 매니저 같은거 극혐하는 분위기임
싱글톤 패턴 자체를 부정함 만드는게 가능하긴 한데
공식적으로 "너 싱글톤 패턴 쓸거야? 알겠어. 근데 나도 책임 안질거임" 이런 입장임
일단 엔진 내부적으로 무슨무슨 매니저가 대부분 구현되어있긴 하고, 그거 가져다 쓰면 되긴 함
굳이 싱글톤 같은 기능 필요하면 GameInstance 라는 클래스를 재정의 해서 거기에 올려놓고 쓰면 됨
GameInstance는 게임이 켜지고 꺼질때까지 삭제되지 않는, 개발자가 활용가능한 유일한 싱글톤 객체임
그리고 런타임에 어떤 액터나 컴포넌트, 객체를 삭제시키고 싶은 경우가 있을거임
유니티면 그냥 신경 안쓰고 Destroy() 함수에 인자값 넣으면 끝임
근데 언리얼은 신경써야 할게 좀 있음
일단 언리얼은 C++로 스크립팅을 하지만 언매니지드가 아님 언리얼 자체적인 GC가 있음
우리가 어떤 객체를 포인터로 관리를 하다가 놓치는 경우에 메모리 누수가 발생하는데
언리얼 엔진에서는 놀랍게도 포인터로 관리하는 객체는 앞에 UPROPERTY()라는 키워드를 붙여주기만 하면
자동적으로 관리됨 메모리 누수 그런거 없음
그런데! 여기서 언리얼의 GC로 관리중인 객체를 삭제할 때는 한가지 문제가 발생함
언리얼의 Destroy()함수로 객체를 삭제하게 되면 바로 즉시 삭제되는게 아님
내부적으로 PendingKill이라는 키워드가 붙어서
GC가 동작하는 주기가 있는데 한 이게 10초마다 한 번씩 동작하는걸로 앎
10초 아닐 수도 있는데 일단 매 프레임마다 동작하진 않음 세팅에서 조절 가능
암튼 2초 전에 GC가 동작했다면 다음 주기가 올 때 까지 8초는 기다려야 객체가 삭제됨
여기서 생기는 문제. 삭제시켜둔 객체가 완전히 죽을 때 까지는 같은 이름의 객체를 생성할 수가 없음
쓰다보니 좀 기네 말하고 싶은게 더 있긴 한데 다음편을 쓸 마음이 생긴다면 말하겠음
질문 있으면 질문 받음
매니저라고 모호하게 이름 짓는 거 자체가 OOP에서는 안티패턴으로 취급하는 사람이 많음
선진문명 배워보고싶누
말리진 않겠음. 좋은 경험이 될거임
Verse에 대해선 어케 생각하심? 최근에 나왔던데. 나는 게임 개발자는 아니고, 후디니나 마야, 블렌더, 언리얼, Zbrush 같은 아트 툴쓰며 작업하는 아트쪽에 가까운데 언리얼 되게 좋던데, 금번 기회에 블루프린트랑 verse도 좀 많이 익히듯 배워야할듯... Node Base가 아트 친화적인 동시에 엄청 똑똑한 방식의 작업방식이라 매우 좋더라. 원래 VFX쪽에서는 오래전부터 영화급 프로젝트에선 엄청 쓰였는데 윗세대들은 잘 몰라서 한국 내부교육으론 잘 없는듯
Houdini 라는 VFX 툴의 node 방식이 매우 좋은데 언리얼도 최근 애니메이션 챌린지 (전세계적으로 진행한 것인데 한국에선 거의 모르는분들이 많은듯) 같은 거 진행하며 많이 두드려 보았는데 애니메이션도 많이 좋아졌고, 애니메이션을 위한 Controller 만드는 리깅 블루프린트도 매우 잘 되어있는편 같더라. 오히려 Maya나 블렌더 같은데 보다 더 진일보한 느낌. 그런데 블루프린트 외에 쉐이더같은 거나 Houdini vex 같은 걸 쓰려면 Verse를 최근 에픽이 엄청 밀어서 이걸 써야할 거 같은데 커뮤니티 근사하게 있지만 정보 너무 적음... 우연히 검색하다 들어왔는데 암튼 언리얼 상당히 맘에 듬. 디퍼드 렌더 - 소위 실시간 렌더도 아마 세계에서 퀄이 제일 좋은 그래픽도구일듯
벌스는 언리얼에서 쓰인다기보다는 언리얼 엔진의 파생 게임메이킹 툴인 포트나이트 에디터에서만 쓰이는 프로그래밍 언어임. 물론 언리얼 엔진이나 포트나이트 에디터나 구조는 또이또이 한데, 벌스도 뭐 문법 배우는거 자체는 그렇게 어려운건 아니지. 문제는 기존 프로그래밍 언어들과 다른 개념이 있을 경우인데, 벌스는 그런게 별로 없는걸로 앎. 블루프린트로 비주얼 스크립팅 하는거는 프로그래밍 아닌 직군에게 강력한 도구로써 작용한다고 생각함. 학원이나 대학같은곳에서 언리얼 교육 좀 늘렸으면 좋겠음
그리고 좀 특이한 자기만의 구조를 가졌다는 말씀에 상당히 동의. 얘들은 캐릭터 액터도 BP로 묶어다가 관리하는 방식 선호하더라. 블루프린트로 대부분의 작업을 최적화 하려고 했으나, 와중에 스파게티 코딩의 혐오스러움과 최적화 이슈 그리고 한계를 맞딱들인건지 아니면 이 반대급부 충족을 위해선지 Verse 내놨던디 관련 정보 공유 많이 늘었음 좋겠구먼유.
ㄹㅇ 언리얼 되게 좋은듯. 유니티는 잘 모르지만 애니메이션 모캡 데이터 빼올때 좀 섞어썼는데 언리얼, 유니티 각각 장단이 있겠지만 왜 언리얼이 어렵다는 편견이 있는지 모르겠던데... 실제로 언리얼에 거부감 느끼는 사람이 더 많던데 쓰면서 이해가 별로 안 되던. 물론 코딩 자체쪽에서 더 어려븐 언어를 쓴다지만 ㄹㅇ 잘 들여다보면 줄래 똑똑하고 편한 거 많던. 문제는 대형엔진?이고 상용엔진중에 사람들이 가장 접근하기 좋은 제일 진일보한 툴이지만, 마켓플레이스도 오래 보다보면 퀄리티 되게 한정되어있고 유저풀도 생각보다 엄청 넓지 않음.
Verse 포르나이트에서만 쓰임??? 나중에 Verse 자체가 언리얼에 들어온다는 얘기로 생각했는데 착각했나.. 훔... 포나에서만 쓰이면 별로 쓸 이유가 없는딩... 암튼 글 잘봤셈.
아 벌스 영상 보니까 언리얼 엔진에도 들여올 생각이 있는걸로 보이긴 하더라. 다만 아직까지는 포트나이트 에디터에만 쓰인다는거
oncollisionenter랑 exit 있는데 - dc App
엥 있어??? 티치미!!!
게이 블루프린트 얼마 안써보고 이런글 쓰는기가.. 뭐 스태틱메쉬나 콜리전 클릭하고 맨 하단에보면 " 컴포넌트 오버랩 시작 시" 눌러보면 댐 이거 c++도 당연히 있다 - dc App
오버랩 시작시 그거 OnTriggerEnter()임... 오버랩이 겹치다라는 뜻인데...
오버랩 뜻은 당연히 알지 근데 너가 말하는 건 유니티에선 이게 두개로 나눠져있으니까 그런거 아님? 언리얼에선 그냥 하나로 너가 어캐 구현하냐에 따라서 TriggerEnter나 CollisionEnter나 같은 걸텐데 아니면 컴포넌트 히트 시로 구현되고 정확히 뭘 구현할려는 건지? - dc App
물론 아주 살짝 더 큰 콜라이더를 씌워가지고 그걸로 CollisionEnter용으로 써먹는 방법도 있긴 한데 그건 좀 방법이 별로고, Hit 이벤트가 언리얼 엔진에서는 물체의 표면에 닿아있을 때 계속 호출이 되는데, 나는 그게 물체의 표면에 처음 닿았을 때 딱 한번만 호출되고, 그 물체의 표면을 떠날 때 딱 한번만 호출되는 별도의 이벤트 같은걸 원하는거지.
? 한번 호출되는데.. 방금 엥 내가 잘못알았나 하고 실험했더니 닿아있는 상태인데도 그대로임 - dc App
그거 Hit 이벤트가 참 간악한게 계속 호출되다가 어느 순간 지나면 호출이 멈춤. 해회 영상 찾아다가 바로 대령할테니까 기다려보셈
https://youtu.be/PGhng3ARVS4?t=29
처음 부딪힌 순간부터 계속해서 포지션이 움직이니까 히트된 입장에선 계속 물리연산가동해서 그런 듯. 키 누를 때마다 가동되고 키 떼니까 작동안됨 - dc App - dc App
근데 굳이 유니티처럼 무거운 물리연산에 collision exit까지 나뉠 이유가 딱히 있나 싶다 - dc App
있으면 편하니까 유니티에서는 썼는데 언리얼에서는 없으니까 일단 내가 만들어서 쓰고있는중
덕분에 오랜만에 언리얼 갖고 실험해봤네 재밌었음 ㅋㅋ - dc App
유니티만 하다 최근 언리얼 입문중인데 글 잘 봤음
궁금한거 있으면 질문해도 ok. 뭔가 다른거 알고 있으면 기술 제휴좀 합시다
무지성 엔진까/빠 글보다가 이런글 보니까 좋네
반응 좋으면 후속편도 쓸 생각임
유니티를 만질 줄 알아서 그 갭 때문에 조금씩 불편한 점이 있었던 거 같아보이네.. 그럼 입문 자체를 언리널로 하는 건 어떻게 생각해??
입문 자체를 언리얼로 하게 되면 일단은 블루프린트 위주로 배우게 될거고, 뭐 아무튼 생각을 해보자면, 언리얼을 하고 나서 유니티를 쓰니까 유니티가 굉장히 쉬움. 편의성도 뛰어나고. 언리얼은 그냥 말 그대로 날것 그대로의 뭔가를 보는 것 같음. 블루프린트 위주로 배운다면 개발자 되는 사람이 유니티만큼 남겠지만, 거기에 C++까지 얹어서 배운다고 하면 남는 사람이 한 2 ~ 3명 되지 않을까
다음편 꼭 "해줘"
왜 언리얼이 싱글톤 패턴을 부정하지? 대놓고 Subsystem이라는게 있는데... 언리얼 기본 구조에서도 AssetManager 같은 싱글톤 클래스도 종종 보이고
그리고 엄밀히 말하자면 액터는 유니티 게임오브젝트와 달리 그냥 컴포턴트를 묶는 껍데기 같은 개념이라 액터간 계층 구조는 루트컴포넌트의 계층구조로 구현되어 있음. 그래서 유니티와 달리 BP 클래스 내에 액터를 바로 추가할 수가 없음
일단 서브시스템은 내가 오늘 처음 앎. 찾아보니까 예제가 별로 없기도 하고, 게임인스턴스 오버라이드 해서 쓰는 경우가 보이길래 그런걸로 알았는데, 덕분에 한수 배움. 그래도 유니티 같은 static 키워드를 사용한 싱글톤 패턴은 권장 안하는게 사실이잖음. 언리얼 자체가 자기네들이 다 안전한거 만들어 놨으니까 허튼수작 부리지 말라는 입장 아니겠어
싱글턴 패턴은 프로그래밍 구현에 좋지 않은 패턴임. 그래서 가급적 사용하지 말아야 함.
그리고 GC 처리 시점은 GC를 가지고 있는 managed 랭귀지에서 동일함. 우리가 알수 없고, 내부적으로 자기가 메모리 해제시점을 찾아서 함.