코루틴 헬퍼
문제 1
: 호출 잘못하니 다른 객체에서 찍히더라
분석
: 코루틴 객체가 아니여도 Managers.instance.helper로 가능하던데 굳이 왜 코루틴 헬퍼를?
- 코루틴할거니 건들지말라는 목적성을 위해 분리하는 것.
- 언제 어떻게 돌아갈, 어떤 결과를 초래할 지 모르기 때문이다.
- 다른 함수를 실행 시킬 지도? 오브젝트가 사라질 지도?
- 인스턴스가 실행시킨 코루틴이 자기만 멈출 수 있기 때문은 아님
- 전달만 되면 어디서든 관리가 됨.
- 물론 실행 주체를 넘기고 요청이 나왔을 때 관리하면 되는데, 그렇게 까지 할 필요 있는지는 ㅁㄹ?
코루틴과 Update
문제 2
: 모노비헤비어 땡겨서 쓸때, 상속 안 받고 쓸떄 값어치가 있는가?
: 업데이트vs코루 에서 일정 시간만 실행되고 그 이후 trigger로 꺼버릴 때 코루틴이 더 나은지
분석 2
- 안정성을 위해서는 경우에 따라 골라 써야함.
- 일정 상황만 돌아갈 때는 언제 어디서 할지를 정할 수 있으니 코루틴이 이득
- 근데 사실 프로젝트 쓰면서 코루틴을 그렇게 많이 안씀
- 멈춤 없이 시간 흐르는 것들은 Update 처리
- a에서 b까지 움직이거나, 체력이 깍이는 등의 처리는 코루틴으로 처리
- 코루틴 사이의 공백으로 인한 오류를 방지하기 위해서 무분별한 코루틴 사용은 지양하셈.
DataManager에서 프리팹과 SO의 캐싱
문제
- 지금 key를 string인 경로 값으로 넣어두었음
- 따라서 enemy + 000 등의 형식으로 상수를 결합해야하는데 문제 ㄴㄴ함?
분석
- 경로로 하는건 좋은데 그럴거면 앵간하면 int가 용량면에서 개꿀이니까 string은 좀…
- string으로 해야 접근할 수 있다 생각하는 것 같은데
- enum으로 타입해서 줬는데 연관 짓기 힘들더라고요.
- 데이터를 바로 불러오려해서 그런데
- 어쨋던 int로 관리하고 불러올거자늠?
- 그러면 id만 있다고 할때 프리팹의 이름 등은 데이터에서 불러올 수 있겠지?
- 프리팹도 item을 기반으로 관리하는 거 아님?
- ㄴㄴ enemy라는 오브젝트에서 거미나 슬라임등의 SO를 받는 형식임
- int를 연관 짓기 힘들어서 그런 것 같은데
- ex. enemy000을 01001, 01002, 01003등으로 치환해서 카테고리화 해서
- 아예 ResourceId를 두는 느낌이군요 EnemyId랑 ItemId를 넘어선
- 10000 아래로는 id 비워둘 예정이니 쓰면 될 듯.
- 예시 코드 찾아서 내일 즈음 불러서 분석하세
- int를 연관 짓기 힘들어서 그런 것 같은데
세부 분석
- 호출할 전에 넘겨주는 거라 상관 없지 않음?
- 그게 궁금한게 왜 const면 괜찮은지 모르겠음
- parameter면 일반화과정이니까
- const는 상수처럼 처리된다고
- 컴파일 과정에 처리되니까 그건 맞음
- 김영호T가 딕셔너리 내부에서 정해줄거다라고 말해주긴 했는데
- 뭐가 맘에 안들긴 함.
- SO쪽에 Upcasting면에서 데이터 손실이 없을까?
- 그럼 괜찮을 듯
- 형변환을 해주나?
- Upcasting을 해줌.
- 이건 봐야할 듯.
- Null이 뜨면 밑에서 덮어쓰는 방식임.
- 결국 모든 애들마다 연결을 안해줘도 되니 편하긴한데
- 캐싱을 매니저에서 한다는게 좋은데
- 사실 string도 어차피 상관 없어 보이는데
- 어차피 똑같음.
- string을 key로 했을 때가 문젠데
- 첫 접근이 string이라 과정이 사실 hash자늠
- 여기서 뭔가 첨가하는게 무의미해보임.
- string을 안심하려고 넣는게 아닌가?
- 그래서 걱정안해도 된다?
- 그게 Resorces로 깡 Load하는 것 보다만 빠르면 ㄱㅊㄱㅊ
- 그러면 Mission Completed ㅇㅇ
- 무조건 빠를듯 그리고
- Global Load MAnager를 둔거라 성능 구려도 이점은 확실함.
- 데이터를 다 옮기려다
- 추가로 리버스 딕셔너리가 있더라고요
- int,string이 아니라 string int의 형식으로 진행되는 듯한.
게임오브젝트의 파괴 방지
문제
: 게임 오브젝트가 파괴되지 않는 다는 것을 명시 할 수 있나?
- ex.씬전환? 그건 destroyOnload일테고 Manager에서는 인스턴스를 가정하고 할텐데
- 다른 곳에서 디스트로이를 조져버리면 어떻하지 하는 걱정?
분석
YeomT : 너무 걱정이 많이 간 것 같아 보임.
파괴 방지의 목적성
문제
: 서비스 중개자로 구현하고 싶었던게 메플월드 플랫폼에서 느낀게 서비스가 엄청 개꿀이던데 싱글턴 처럼 전역호출 가능한 서비스 집합이더라고요, 이 느낌이 너무 좋아서 이 시스템을 프로젝트에 구현하고 싶었어요
- 싱글턴이 너무 위험하니깐 남발을 방지하기 위해 안전하고 숨기고 싶었다.
분석
- 근데 이건 기능이 개많음.
- 프로젝트가 충분히 커지면 이렇게 보일 것.
- 관련된 기능을 집합시켜놔서 코어한 기능끼리 묶어놔서 이렇게 보이는 거임.
- 싱글턴은 논란이나 고민할 점이 많음.
- 저희가 4~5년차가 아니잖음.
- 그걸 고민해서 최적화하는 것보다 다른 기능을 추가하는게 가성비 좋음.
- 이건 ㄹㅇ 지식의 저주
- 차라리 다른 +요소 들을 처리하도록
- 나중에 면접관이 이것에 관하여 쿠사리 놓거든
- “이런 문제들을 인지는 했으나 차라리 경험적으로 다른 기능들을 처리하는게 기한적으로 나은 방법이라 판단하였습니다. 차후 해결해 나가겠습니다.”라고 하면 ㄱㅊ
- 이렇게 지엽적으로 파고드는게 좋은 습관이라고 생각하지만 절제할 포인트를 잘 잡아야함.
- 개발은 끝 없어서 타고타고 들어가면 근본적인 곳에 들어갈 수 있음.
- 중간에 끊을 수 있어야함.
- 시간이 남을 때 옵션이나 인터페이스로 파괴하지 말아야 할것들을 지정하는 것이 좋을 것
- IDontDestroy라는 인터페이스로 파괴될 놈과 안 될 놈을 인터페이스로 지정하고
- Release에서 체크해서 있으면 해제
- 암튼 여기까지도 지금 단계 + 지금 기한에선 에바쎄바임.
추가로
- Rider를 라이트 모드로 왜씀?
- 그래야 화면 공유할때 님들한테 코드가 잘보임.
Uploaded by N2T
