[💬] 하.. a* 최적화 넘나 빡쳐욧...

[익명(115.143)]

타일 기반으로 유니티 써서 게임 만들고있습니당...

대충 학교에서 배웠던 a*로 

길찾기 만들어서 쓰고있는데..

요게 타일이 1만개 가량 되니까 너무 무리가 가기 시작하네요.

최적화를 위해서 타일을 크게 몇개씩 묶어서 한번 계산하고, 

그 후에 묶은거 내에서 다시 길을 찾게 하려고하는데 넘나 힘드네요

다 때려치고 navMesh를 쓸까 고민인데...

혹시 비슷한 문제를 해결하신 분이 있으신가요?

[Cogito(cogito83)]

에셋에 보시면 a* 최적화 잘되있는 에셋 많아여 원하는 기능 구현이 힘들면 그거 사서 뜯어 보면서 만들어 보시는것도 나쁘지 않은 선택 같아요 ㅇㅇ

[익명(115.143)]

쪼금만 더해보고 안되면 사서 뜯어보던 가져다 쓰던 해야겠어요 흑흑

[익명(39.7)]

어차피 a* 알고리즘은 유니티API안쓰니까 멀티쓰레드 이용하세요. 스토어의 A* 에셋들도 멀티쓰레드씁니다.

[익명(115.143)]

유니티 객체를 쪼끔 섞어 쓰고있었어서 빼서 정리해보고 쓰레드로 해봐야겠네여

[익명(118.47)]

지형을 쪼개서 중요 지점에 웨이 포인트를 지정해주고 웨이 포인트 끼리의 경로를 미리 계산해서 저장해 놓고 길찾기를 할 때는 시작지점에서 가까운 웨이 포인트 까지 경로를 찾고 도착지점에서 가까운 웨이포인트 까지 경로를 찾으면 좀 더 가벼워질거임.

[산적대왕(125.137)]

지형이 고정식이라면 쿼드트리 추천. 지형이 변하는 식이라면 답이 없음. 길찾기를 한번 하면 캐싱해두고 가급적 재활용하거나, A* 쓰지말고 직선으로 주욱 달려서 앞에 뭐가 있으면 때려부시고 계속 가려는 남자다운 AI도 고려해봐야 함. 나도 유닛 많이 나오는 겜 제작중이라 길찾기 지옥에서 허우적거리는 중인데 온갖 꼼수를 들이부어야 할 거 같음. 리얼리티를 포기해서라도 쪽수를 늘릴 것이냐의 고민인듯.