UnhandledException 으로 서버 터지는 경우

와우 잘 찾으셨습니다.강의에선 누락 되었으나 C# 네트워크 관련 함수 호출할 땐싹 다 try-catch를 해주시는 것이 맞습니다.M2 프로젝트에서는 저런 부분 보완 처리 코드도 추가 되었던 것으로 기억합니다.

프로퍼티 강의 질문 있습니다.

왜냐하면 Hp 앞에 'int'가 있기 때문입니다!그러니 내부적으로는 같은 타입의 데이터를 아무 이름으로 만들어서 관리하는 것이죠.

바이너리 직렬화

질문이 조금 애매한데 바이너리 직렬화도 분석을 하려면 데이터 원형을 알아야 합니다.고전적인 방식은 패딩 없는 struct를 만들어서 그대로 보내고 받는 방법이 있긴 했으나가변 데이터 처리가 힘들어 별로 좋진 않고Protobuf를 사용하는 것이 거의 대세입니다.

Null Crash 에러 문의

살짝 혼동이 있으신데요.PlayerIndex 개념 강의을 다시 복습해보시기 바랍니다.서버 입장에서는 모든 클라의 PlayerController를 관리하기 때문에0 1 2 인덱스는 서버에서 이해하는 클라의 번호이고 (순차적으로 관리).클라 입장에서는 타인의 PlayerController는 관리하지 않아0번이 자기 자신의 것이고 남들 것은 없습니다. (즉 1 2는 존재하지 않음.)

락프리의 실무에서 사용 질문

LockFree도 내부적으로는 CAS 등을 활용한거라 이름만 LockFree지 실제로 꼭 그렇다 보기도 애매합니다.그리고 Lock은 말 그대로 큐에 일감을 넣고 분배할 때만 살짝 사용하는 것이고,일감을 실행할 때는 Lock을 걸고 하는 것은 아니라서 생각하시는 것처럼 병목이 많진 않습니다.

AI 시대의 새로운 기회..

솔직히 어떤 답변을 기대하시는지 모르겠지만어차피 안 될 사람은 안 될 이유를 찾느라 바쁘고,될 사람은 그런 고민을 할 시간에 일단 뛰어들어 시작합니다.기술력이 부족하시면 공부를 하면 되고,사업이 하고 싶으면 뭐라도 해보고 망한 다음 고민을 해보면 됩니다.사업을 하겠다고 마음을 먹는다고 사업 아이템은 떠오르는 것도 아니고기술 공부를 하다 보면 자연스럽게 길이 보입니다.실제로 저는 대학교 1~2학년에 앱 창업을 해서 차 한대 값을 날려 먹었는데,그 경험이 공부 방향성에 많은 도움이 되었습니다.제가 느끼기에 지금 보여주시는 스탠스가 정확하게 한국에서 시험 위주의 입시 공부했을 때 나오는 안 좋은 케이스의 표본입니다.미국 대학교 입학관들이 한국 유학생을 싫어하는 이유이기도 하고요.항상 정해진 길이 있고, 모르면 학원 선생님들이 길을 알려주는 것은 대학 입시 때나 통용되는 것이고그 이후부터는 정해진 답이 있지도 않고 누군가 길을 알려주지도 않습니다.하지만 오히려 그러니까 더 흥미롭고 마치 미지의 세계를 탐험하는 콜롬버스처럼 도전을 즐기면 됩니다.이미 남들이 나보다 먼저 그 길을 갔으니, 실패할 확률이 높아서 망설여진다면사실 그 순간 이미 아무것도 할 수 있는 것은 없습니다.다만 최소한 한 분야 기술의 정점을 찍으면 보이는 것도 많아지고,포착할 수 있는 기회도 많아지는 것은 분명한 사실입니다.아무런 지식도 없는 본인한테도 보이는 기회라면그야말로 남들한테도 다 보이는 뻔한 길이기 때문이죠.

컨텐츠 단, 엔진 단

엔진은 기능적으로 돌려 쓰는 부분 (ex. 서버 엔진, 언리얼 엔진 등)을 모아둔 코어 라이브러리고,컨텐츠는 게임을 만들 때의 특수 사양들입니다. (ex. 만드는 게임마다 상이한 기능들)

코딩이 왜 수학적 재능에 영향을 많이 받는다고 생각하시나요?

수학을 잘하는 사람 중에 코딩을 못하는 사람은 없습니다.코딩도 이산수학의 한 분야이기 때문이죠.그런데 이런 의견들이 딱히 중요하진 않고 결과가 말해주는 것이니, 각자 판단대로 생각하면 된다고 봅니다.그리고 코딩이 꼭 알고리즘만이 전부는 아니고, 하다 보면 단순 기능 조합인 경우도 있어서 이런 때는 또 별개입니다.

게임 로직 루프에서 게임 틱 누락으로 인한 높은 CPU 사용 문제

그 부분은 Job 기반으로 후반부에 수정하게 됩니다.

유니티 데이터 저장객체 ScriptableObject에 대해 의견 여쭤보고 싶습니다

SO 방식의 가장 큰 장점은 다른 에셋의 참조가 가능해서 관리가 손쉽다는 점입니다.그러나 반대로 베이스 C# 클래스가 변경되면 기존에 작업한 결과물이 날라가는 문제도 빈번해작은 프로젝트에서만 좋은 전략이라고 봅니다.특히 데이터가 아주 많아지면, 각자 별개의 파일로 관리되기 때문에기획자들 입장에서 관리가 굉장히 힘듭니다.기획자들은 엑셀을 제일 선호하기 때문에 사실 엑셀을 원본으로 관리하는게 일반적이고, 그것을 Json으로 변환해서 배포하는 경우가 많습니다.엑셀이나 Json으로 관리하면, 에셋을 경로나 Addressable 키값 등으로 참조하게 되는데혹시라도 누락이 된 것을 개발 단계에서 꼼꼼히 체크를 해줘야 합니다.이런 부분은 SO가 확실히 편리하죠.그리고 는 얘기는 데이터시트 다룰 때 나올 고려되어야 하는 얘기가 아닙니다.어차피 Json으로 하나 SO로 하나 로딩하는데 드는 시간은0.00000000000001%로 아주 귀여운 수준이라 뭐가 더 빠른지는 크게 상관 없습니다.