과연 그 상황이 같을까요?

이 세상에 성공이 담보된 시작은 재벌가의 손자로 태어나는 것 말고는 없을 것입니다. 저는 강의를 들은 사람은 아니지만 강의 소개와 수강 후기를 보건데, 실패를 최소화하여 성공에 이를 수 있도록 도와주는 강의라는 생각이 들던데요.그 어느 곳에서도 "본인을 따라오면 성공을 보장해주겠다"라고 한 적은 없는 것 같네요. 압도적 다수는 성공을 향해 달려가는 거지 보장된 성공 가도를 달릴 수 없습니다. 생각부터 바꾸셔야 할 것 같네요.

화살과 몬스터 버그와 관련한 질문입니다

문제는 해결했습니다.제가 가진 질문과 궁금증은 강의를 끝까지 듣고 나서 다시 생각해보고 필요하면 다시 질문하겠습니다.

화살과 몬스터 버그와 관련한 질문입니다

아..강사님 코드에서는 버그가 없네요..

FANTASTIC UI STARTER PACK이 없네요..

자문자답합니다.강의 자료의 유니티 프로젝트를 열어서 Export Package로 해서 제 프로젝트로 Import 하니까 문제 없이 됩니다.

코드 관련한 몇 가지 질문입니다!

1, 2번 질문은 자체적으로 해결했습니다.

3d 프로젝트 이동 동기화 관련

반대편 클라이언트에서 다른 플레이어를 렌더링하는 부분을 보셔야 하지 않을까요?

안녕하세요 도저히 알 수 없는 오류가 나와서 질문드려요,,

더 자세한 정보가 필요할 것 같은데요..올리신 이미지만 보고 오류를 잡는 건 예수가 재림해도 힘들 것 같습니다.이미지로 보이는 로직은 에러가 끼어들 틈이 거의 없을 것 같고, 직렬화/역직렬화 하는 부분에서 메모리 문제가 발생하기 쉬울 것 같습니다.

Player GameObject의 name이 이상해요.

루머의 루머의 루머를 잇는 루트의 루트의 루트군요

(오류정정요청) Awake 설명

설명하시면서 약간 말씀이 꼬인 것 같은데 오브젝트 비활성화가 아니라 스크립트 비활성화를 했을 때 Start()는 호출되지 않지만 Awake()는 호출됩니다.

switch문과 딕셔너리 효율 질문입니다.

링크에 나와있는 설명 중에 switch-case가 if-else if로 해석된다고 되어 있는데 실제로는 완전히 다릅니다. switch-case는 점프 테이블을 만들거나 다른 최적화 방법 등을 통해 해당 case문으로 한 번에 갑니다. 그리고 그 최적화가 컴파일 단계에서 수행되기 때문에 빠릅니다. if문은 true를 만날 때까지 모든 조건을 다 검사해야 돼요. 컴파일 최적화도 어렵고요.case가 그렇게 많지 않으면 Dictionary를 안 써도 되겠지만 계속 기능이 확장될 여지가 있을 때는 유지보수성과 가독성을 생각해 Dictionary가 더 나은 선택이라고 생각합니다.