이전 게시글 : https://gall.dcinside.com/mgallery/board/view/?id=game_dev&no=70309&exception_mode=recommend&page=1

사용한 엔진 

GMS2

--------------------------------------------------------------------------------------

안녕.

오늘은 내가 적 알고리즘 만든 방법을 되짚으면서 Context map 알고리즘을 설명하려고 해.

우선 내가 참고한 자료들은

유튜브 영상이랑 논문

http://www.gameaipro.com/GameAIPro2/GameAIPro2_Chapter18_Context_Steering_Behavior-Driven_Steering_at_the_Macro_Scale.pdf

이렇게 두개 참고했어.

Context map의 개념은 생각보다 간단해.

물체를 기준으로 모든 방향에 가중치를 두고, 가장 높은 가중치를 가진 방향으로 이동하는게 끝이야.

갑자기 가중치라고 해서 어렵게 느껴질 수 있어.

그림으로 보면 쉽게 이해할 수 있을거야.

내 게임에서 프로토타입으로 쓴 개체가 슬라임이라 앞으로 알고리즘이 적용되는 개체를 슬라임이라고 부를게.

A, B 모두 슬라임이 쫓을 적이고 검은 사각형은 벽이야. 

슬라임 기준으로 A와 B가 있는 방향은 이상적인 방향 일거야.

반면에 벽이 있으면 그 방향으로 이동할 수 없으니 벽으로의 방향은 피해야 해.

이 두 가지 원초적인 개념으로 가중치를 계산해.

이 사진은 유튜브 영상에서 가중치를 계산하는 방식을 보여준 예시야.

선의 중심은 슬라임의 위치, 초록색 원은 쫓아야 되는 적을 나타내.

여기서 선의 길이는 각 방향마다의 가중치를 나타내.

쫓아야 되는 적과 일직선이 되는 방향이 가장 높은 가중치를 갖게 되지.

이 상황에서는 슬라임은 적을 향해 일직선으로 나아갈거야.

이번엔 아까 상황에서 빨간 원이 생겼어. 빨간 원은 벽 같이 피해야할 대상을 나타내.

슬라임은 벽을 피해서 적을 쫓아야 하기 때문에 벽을 피하려고 하는 가중치가 생겨.

결과적으로 전 상황에서 '적을 쫓을 방향을 고르는 가중치'말고도 '벽을 피할 방향을 고르는 가중치'가 생겨.

이 둘을 더하고 노멀라이징해서 계산한 가중치가 그림에 나와있어.

이 이후에는 적을 추가하거나 벽을 추가해도 비슷한 맥락에서 흘러가.

원리는 간단해서 이해하는데는 크게 문제 없을거야.

여기까지의 내용이 영상에서 설명해주는 AI 알고리즘의 제작 방식인데

실제로 위에 개념대로 구현해보니까 여러 문제가 생기더라고?

https://gall.dcinside.com/mgallery/board/view/?id=game_dev&no=69387&s_type=search_subject_memo&s_keyword=context&page=1

그 때 썼던 질문글이야. 

요약하면

1. 피할 대상, 쫓을 대상이 많아지면 메모리 소모가 너무 크다.

2. 가중치를 계속 더하다 보니 특정 상황에서 뜻밖의 결과가 나온다.

2번 문제에서 말한 특정 상황이 이런 상황인데, 벽이 엄청 많아지면 방향을 이상하게 인식하는 문제가 생겨.

그래서 두 문제를 해결하려면 방향 가중치를 계산할 때 벽을 고려하면 안될거 같다고 생각했어.

다른 방법을 찾아야 겠다고 생각했지.

위에 참고한 논문을 조금 응용해서 레이케스팅을 쓰자고 생각했지.

Interest 배열에는 '적을 쫓을 방향을 고르는 가중치'를 저장하고

Danger 배열에는 '그 방향에 벽이 있는지'를 True/False로 저장해.

그 이후에는 최대 가중치를 갖는 방향을 찾을 때 Danger 배열을 참고해서

그 방향에 벽이 있으면 그 방향을 차단하는 방식을 사용했어.

그런데 다음에 생긴 문제가 오브젝트의 크기가 고려가 안되는거야.

레이캐스팅 할 때 오브젝트 크기랑은 무관하게 방향만을 가지고 해서 생긴 문제야.

그래서 크기를 고려할 수 있게 아래 사진처럼 레이캐스팅을 추가로 했어.

진행방향에 오브젝트 크기만큼 너비차이를 두고 레이캐스팅을 해서

좌측에 벽이 있으면 우측으로 가게끔, 우측에 벽이 있으면 좌측으로 가게끔 방향을 보정했어.

이렇게 하니까 약간의 버그들이 있긴 하지만 잘 움직이긴 하더라고.

슬라임이 적을 쫓는 알고리즘은 이렇게 완성이 됐는데

영상의 적처럼 상황에 따라 도망가기도 하고 빙글빙글 도는 AI를 만들고 싶더라고.

구체적으로

player_diff : 슬라임과 플레이어의 거리

strafe_range: 빙글빙글 도는 거리

만약에 player_diff > strafe_range 이면 슬라임이 플레이어를 쫓고

player_diff == strafe_range 이면 슬라임이 플레이어를 중심으로 빙글빙글 돌고

player_diff < strafe_range 이면 슬라임이 플레이어한테서 도망가게 만들었어.

그 방법은 가중치를 주는 방식을 다르게 해서 만들었어.

if(state == ai_state.chase) contextMap[i] = 1.0 - (dot);

if(state == ai_state.backward) contextMap[i] =  (1.0 - abs(dot - 0.9)) * 2;

내가 소스에 사용했던 코드인데, 순서대로 쫓기 빙글빙글돌기 도망가기 순이야.

dot값은 슬라임에서부터 플레이어까지의 방향을 노말벡터로 두고 각 방향값과의 도트곱을 구해서

0~1값으로 일반화시킨 값이야.

이렇게 하니까 새로운 문제점이 생기더라고.

빙글빙글 도는 상황일 때 슬라임 기준으로 좌우대칭이다 보니까

아주 약간 우측으로 움직이면 좌측이 가중치가 높고

반대로 아주 약간 좌측으로 움직이면 우측이 가중치가 높아서

결국 저렇게 지터링이 생겨.

이걸 막을려고 좌, 우측중 한 쪽에서만 방향을 고르도록 바꿨어.

그리고 좌측으로만 갈지 우측으로만 갈지를 결정하기 위해서

'좌 우측 모두 고려했을 때 최대 가중치'와 '한 측면만 고려했을 때 최대 가중치'의 차이가 0.75이상 나면

고려하는 방향을 바꾸게 만들었어.

이제 내가 원하는대로 움직이네.

정리하면서 내가 생각하는 Context map의 장점을 말해줄게.

1. A* 알고리즘같이 맵 전체를 고려할 필요가 없어. 메모리의 사용량이 늘 가능성이 없다는 얘기지.

2. 레이캐스팅에 벽 뿐만 아니라 적을 추가하면 서로서로를 피하려고 해.

또 장점만 있는건 아니고, 단점도 있어.

1. 잔 버그가 많아. 아마 오브젝트 크기 고려를 내가 제대로 못해서 생긴거 같아.

그래서 사실 Context map의 문제인지 내가 문제인지 잘 구분이 안가..

2. 상황에 따라 메모리 변동이 적은 대신 메모리를 덜 써도 될 상황에서도 생각보다 많은 메모리를 먹어.

아무래도 모든 방향에 대해 레이캐스팅을 쏘고 가중치값을 계산해서 그런거 같아.

그래도 이 단점들이 치명적이지는 않아서 예외처리나 약간의 수정으로 고칠 수 있더라고.

여기까지 긴 글 읽어줘서 고맙고, 혹시나 피드백해줄 거 있으면 자유롭게 해줘.

언제나 도움되는 충고는 환영이야!