매니저 관련 질문이 있습니다.

Managers.Instance 초기화하는 코드를 넣어놔서 그렇습니다.또한 이전으로 가는 방법보다는 breakpoint를 걸고 하단에 있는 스택 프레임을 살펴보는 방식으로 "어떻게 여기까지 왔는지" 추적을 하면 됩니다.

언리얼 유니티

회사 단위 작업이 아니라면 개인이 하기엔 언리얼은 너무 어렵습니다.그런데 그와는 별개로 점점 더 AI가 만들어주는 방향으로 가게 될 것이라,장기적으로 엔진의 선택은 의미가 없어질 수도 있다고 봅니다.그냥 무조건 결과가 잘 나오는 쪽을 선택하는 것이 좋을 수도 있겠죠.그런 관점에서 렌더링, 네트워크 등 기본기 지식이 더 중요하다고 봅니다.

도메인, IRIS

언리얼 네트워크의 차세대 버전이라 생각하시면 됩니다.

챌린지 라이브 시간이 지나면 강의는 볼 수 없는건가요?

일반 강의로 올려놨습니다!

비쥬얼 스튜디오에서 unity연결이 없습니다.

(사진) Visual Studio Installer로 가서 [Unity를 사용한 게임 개발]dl 설치 되있는지 확인해보세요!

상위 5% vs 창업 외에 나머지 90%는 어디로 가야할까요

창업이라는게 꼭 엄청 거창한 것은 아닙니다. 특히 게임 업계에 있다면, 게임 제작이 사실 목표가 되어야 하는 것이 당연하고그렇게 인디 게임을 만들다가 각이 보이면 창업을 하면 되는 것이죠.요즘 AI 덕분에 정말 많은 것들이 가능해졌는데요.저는 1인 MMO를 만드는 취미 프로젝트를 최근에 다시 시작했는데개발도, 아트도 이젠 AI가 다 해주니 너무나도 행복한 시대가 되었습니다.조금 압박을 내려놓고 그냥 하고 싶은걸 하다 보면 길은 보인다~가 정답이라고 봅니다.3일차에 들어간 제 프로젝트 자랑이나 하고 가보겠습니다.(사진)

writeLock을 잡을때 꼭 empty 상태여야하는 이유?

당연히 문제가 됩니다.박물관에서 우리가 무엇인가를 감상하고 있는데, 내부 공사를 같이 하는 느낌이랄까요.예를 들어 C++의 연결 리스트 작업을 하느라고 불필요한 자료를 삭제하고 있는데하필 그것을 누군가가 read 하고 있었다면 난리가 날 수 있습니다.

리니지 클래식 ECS

내부 사정은 모르지만 리니지 클래식은 아마도 자체 엔진일 것 같은데요.MMO에서 주인공은 서버이고, 클라는 그냥 부하 없이 잘 돌아가기만 하면 됩니다.심지어 리니지 클래식은 2D 게임인데 2000년도에도 돌아갔던 그래픽이라뭐로 만들어도 크게 상관 없고 ECS는 오히려 과할 수도 있습니다. (그리고 NC에선 유니티를 거의 안 씁니다)

UI 기능 관련 질문이 있습니다!

1. ShowPopupUI / ClosePopupUI의 빈번한 호출 시 비용팝업의 경우 ShowPopupUI로 생성하고 ClosePopupUI로 파괴하는 구조인 것으로 이해했습니다.예를 들어 사용자가 일시 정지-설정창 이런 식으로 게임중에 기능을 수행할 때,팝업 내용이 무거울수록 매번 생성/파괴 비용이 커질 것 같은데, 이 정도 비용은 실제 플레이 중에는 크게 신경 쓰지 않아도 되는 수준인가요?-> 신경 씁니다. 강의 교안이라 간단하게 한 것이고, 일반적으로 게임마다 다르지만 로딩할 때 일단 UI들을 다 로딩하고 있다가, 껐다 켰다 하는 식으로 많이 사용합니다.2. 람다식의 이벤트 등록과 해제UI_Button의 Init 함수에서 BindEvent 호출 시 람다식으로 액션을 등록하는 것으로 보입니다.그런데 C#에서 람다로 이벤트를 등록하면, 매번 새로운 delegate 인스턴스를 생성하여 -=로 해제가 안 되는 것으로 알고 있습니다.매개변수로 람다를 넘기는 경우에도 같은 문제가 발생할 것 같아서 여쭤봅니다!이벤트는 참조값을 간접적으로 들고 있어서, 사용이 끝났으면 참조값을 -= 해줘야 하는 것이 맞긴 합니다.그런 관점에서 헷갈리지 않기 위해 기본적으로 함수로 빼서 OnDestroy, OnDisable 같은 공간에 -=을 넣어주시는게 맞습니다. Manager가 삭제되어야 하는 참조를 들고 있는 경우가 가장 큰 문제입니다. (매니저는 사라지지 않으므로). 이 경우에 UI는 한 번 만들어서 오래 쓰거나, 필요 없으면 삭제하는 경우라서 상황이 조금 다른데요. UI_Button이 소멸되면서 알아서 람다 객체도 같이 소멸될 것이고, C# 특성상 그래프 구조로 참조를 관리해서 Root에서 참조되지 않으면 알아서 해제할테니 별 문제는 없습니다. 그래도 복잡하게 생각하지 않게 위처럼 꼼꼼하게 챙기는게 좋습니다.

SpinLock과 컨텍스트스위칭에 대해 질문 남겨요.

SpinLock은 어찌보면 CPU 코어를 계속 점유하고 계속해서 끝났는지 확인하는거잖아요?-> 네 그렇습니다그렇기에 커널로 내려가는 컨텍스트 스위칭이 일어나지 않거나 최소화 될거다라고 생각하는데요.-> 최소화 되는 것이 맞습니다.근데 하나 궁금한건 결국 운영체제 내에서 스케줄링같이 코어에서 점유하고 있는 스레드를 강제적으로(?) 다른 스레드로 바꾸지 않나요?-> 물론입니다. 그게 안 된다면 모든 쓰레드에서 스핀락을 돌리면 운영체제게 뻗어버리겠죠. 기본적으로 설계 구조상, 주기적으로 타임아웃을 걸어 최소한 운영체제도 먹고 살게 해줍니다. 하지만 통상적인 상황에서 프로세스가 자발적으로 (즉, 시스템 콜 종류의 파일/네트워크 입출력 등을 호출할 때) 자신의 소유권을 내준다면 운영체제는 이 때다 하도 다른 일을 하기 때문에, SpinLock을 할 때와 안 할 때의 차이는 매우 큽니다. 언젠가는 뺏기지만 최대한 안 뺏기기 위해 발버둥하는 느낌이랄까요