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을 할 때와 안 할 때의 차이는 매우 큽니다. 언젠가는 뺏기지만 최대한 안 뺏기기 위해 발버둥하는 느낌이랄까요

TLS 질문드립니다.

tl.Value 하는 '순간' 만들어지기 때문에 그렇습니다.

게임 프로그래밍 독학 로드맵 조언 부탁드립니다.

프로그래밍 대회에서 배우는 알고리즘 전략 세트 (구종만) UE5 소스코드를 받아 가서, 실행은 못하더라도 엔진 코드를 분석하면 아주 많은 도움이 되지만 이건 좀 내공이 쌓여야 가능한 공부법이긴 합니다.뭐라도 하면 도움 안 되는 것은 없지만. 실력적으로 크게 도움이 된다고 하긴 좀 애매합니다.

Memory Pool에서 오버플로우 질문입니다.

라이브 서비스에선 절대 저런걸 하지 않습니다. 속도가 너~~무 느려지기 때문에개발 환경에서 버그를 잡을 때 쓰는 것입니다.

Unity Span

꼭 '실무'라고 특별히 다른 것은 아닙니다만.그래도 만들어서 쓰기보다는, Google Protobuf 같은외부 라이브러리를 쓰는 것이 더 일반적이긴 합니다

씬 배치 구조에서 Addressables를 어떻게 적용해야 하는지 궁금합니다.

사실 이건 선택의 영역입니다.리소스 관리는 결국 여러 가지의 목표를 갖고 있는데요.- 최종 배포에 리소스가 포함되기 위함.- 필요할 때 로딩해서 사용하기 위함.- 번외편으로 혹시라도 리소스 패치가 필요한 게임의 경우.작은 게임이라면 그냥 싹 다 Scene에 배치만 하면 되니 굳이 Addressables 등이 필요 없습니다.Addressable로 키를 관리하기 시작하면, 그 키를 가지고 데이터시트를 만들기가 용이해지는데요. (ex. Player_05를 스폰해라!)아무래도 Addressable을 활용하기로 정책을 정했다면설렁 Scene에 바로 배치하는 오브젝트라 해도,프리팹으로 만들기 Addressable 등록을 해주는 것이 통일성 있어 좋습니다.(정말 나무 같이 데코레이션 목적인 오브젝트가 아니라면)

전체적으로 코드 읽는게 굉장히 오래 걸리네요...

원래 지금이 어려운 난이도입니다.사실 저도 저 비슷한 코드를 회사에서 봤는데 그 때 좀 혼란스러웠기도 했고아마도 type, reflection, dictionary 등 C#의 종합 세트라 그렇습니다.그냥 넘어가셔도 무방하고 특히나 요즘 시대에는 AI 시대가 되어서코드를 빠르게 읽는 것이 중요해서 너무 하나 하나를 깊게 파지 않은 것이 좋을 수도 있습니다.

포토폴리오 및 진로 관련하여 고민입니다.

서버 프로그래머의 주 업무는 컨텐츠 제작이지 서버 엔진 제작이 아닙니다.사실 서버 프로그래머 중에서도 서버 엔진에 대한 이해가 있는 사람의 비중은 10%도 안 됩니다.어차피 회사 레거시 코드를 사용하고 위에 컨텐츠 제작만 하니까요.그런 관점에서 요즘 TO도 없고 서버 코어를 파봤자 특별히 누가 알아주지도 않으니올인하지 말라고 말씀드리는 것이고, 저라면 언리얼 네트워크 (데디서버)를 더 연구할 것 같네요.언리얼 데디 서버를 사용해보시면, 왜 서버만 파는게 위험하다는지 이해하시게 될 겁니다.

엔진 프로그래머?

큰 규모의 게임을 만드는 팀은 보통 클라/서버 컨텐츠 팀 외에 엔진 팀이 따로 있습니다. 그러니 수요는 당연히 있습니다. 다만 열심히 하는 정도로는 안 되고 정말 5% 이내에 들어야 해서 추천 드리지 않습니다.게임 엔진 내에는 여러 기능들이 있는데요. 사운드, 게임 플레이, 물리, 그래픽스, AI, 네트워크 등 게임을 만드는데 필요한 모든 것의 집합입니다. 그 중에 가장 찬란한 꽃이 그래픽스이기 때문에 어떻게 보면 그래픽스 프로그래머 = 엔진 프로그래머라고 봐도 무방합니다.정말 솔직히 말씀드리면, 전망을 생각하며 가시는 타입이면 그냥 하시면 안 됩니다. 이쪽은 정말 게임이나 기술이 좋아서 하는 사람들이 많고 공부다 정말 많지만, 그 공부량을 이겨낼 바에 다른 분야로 가는 것이 좋을 수도 있습니다.