[💬] FixedUpdate 직후에 body 의 좌표를 캐싱하는 것은

[익명(124.54)]

많이 무리가 가는 작업이였음

개체가 150~200개만 깔려도 죽을라그러네

Repository 패턴이 어울리는게 있고 안어울리는게 있다는 것을 깨달은 삽질이였음

[태보미(taebomi)]

뭐 어디 리스트에 넣고 그러는거아님?

[글쓴 ㅇㅇ(124.54)]

무려! Dictionary에! 넣었습니다 ㅋㅋ

[태보미(taebomi)]

rigidbody를 딕셔너리에 넣어두고 쓰면 안대나? 사실 리포지토리패턴을 모름... ㅠ

[글쓴 ㅇㅇ(124.54)]

유닛의 플레이 스크립트 (플레이어 조작/ AI) 을 거쳐서 나온 Direction 유닛의 상태에 따른 이동 가능 여부 유닛의 현재 버프/너프 결과로 나온 Speed 3 값을 가지고 다음 유닛의 이동을 결정해야 하고 AI 의 판단, 공격의 유도 판정 등에 활용하기 위해 Position 정보를 쉽게 접근하고 싶은 욕심이 있었는데요.

[글쓴 ㅇㅇ(124.54)]

그래서 게임을 시작 할 때 Initialize 스크립트에서 Repository 라는 객체를 만든 뒤 게임 로직 측에선 위 3 조건에 따라 값을 갱신하고 각 유닛이 FixedUpdate 로 움직이기 직전에 위 값을 참조해 다음 움직임을 결정 후, Position 을 Repository 에 업데이트하는 과정이였어요

[글쓴 ㅇㅇ(124.54)]

굳이 이렇게 한 이유는 AOE 나 AI 같은 스크립트를 짤 때 Repository 만 참고하면 사양에 따른 행동정의를 쉽게하고 싶어서였구요.

[글쓴 ㅇㅇ(124.54)]

실제 Dictionary 의 참조시간은 O(1) 로 매우 짧지만 Hash 연산을 수행하는 시간이나 여러차례 Record 를 생성해서 갱신해주는 시간이 종합적으로 걸려서 0.020 ~ 0.060 ms 까지 시간이 소요되었는데요. 부하가 큰 것은 아니지만 FixedUpdate 에서 호출하기엔 부담이 큰 작업이라는 결론입니다. 제가 만들고 싶은 게임은 유닛이나 투사체가 많이 등장하는 게임이기도 하고요.

[태보미(taebomi)]

감사합니다. 설계 뉴비인지라 도움을 드리지 못해 아쉽네요 ㅠㅠ 저보다 고수신지라 뭐라 더 생각을 덧붙이지는 못할 것 같네요. 그 욕심 이해하는지라 나중에 불현듯 더 좋은 방법 떠오르시길 기원하는거에요 !

[글쓴 ㅇㅇ(124.54)]

> rigidbody를 딕셔너리에 넣어두고 쓰면 안대나? 제가 잘못 생각 한 것 같습니다. 이렇게 하면 병목이 많이 줄어들 것 같아요. GameObject 를 포함하기 싫다는 욕심은 별도의 Repository 를 만드는 것으로 해결이 가능할 것 같고요.

[태보미(taebomi)]

와 벌써 해결되었다니 넘나 기쁜거에요.

[글쓴 ㅇㅇ(124.54)]

조언 감사드립니다