2분반-시그모이드 - 편집 역사

Com239: /* 향후계획 */

2024-12-20T04:52:03Z

‎향후계획

Com239: /* 향후계획 */

2024-12-20T04:47:47Z

‎향후계획

2024년 12월 20일 (금) 04:43에 Com239님의 편집

2024-12-20T04:43:25Z

Com239: /* 관련사업비 내역서 */

2024-12-20T04:43:03Z

‎관련사업비 내역서

Com239: /* 완료작품의 평가 */

2024-12-20T04:42:04Z

‎완료작품의 평가

Com239: /* 프로토타입 사진 혹은 작동 장면 */

2024-12-20T04:40:25Z

‎프로토타입 사진 혹은 작동 장면

Com239: /* 프로토타입 사진 혹은 작동 장면 */

2024-12-20T04:40:01Z

‎프로토타입 사진 혹은 작동 장면

2024년 12월 20일 (금) 04:33에 Com239님의 편집

2024-12-20T04:33:00Z

Com239: /* 프로토타입 사진 혹은 작동 장면 */

2024-12-20T04:32:42Z

‎프로토타입 사진 혹은 작동 장면

Com239: /* 상세설계 내용 */

2024-12-20T04:30:20Z

‎상세설계 내용

← 이전 판		2024년 12월 20일 (금) 04:52 판
487번째 줄:		487번째 줄:
	◇ 절차적 맵 생성 시 렌더링 과부하 문제		◇ 절차적 맵 생성 시 렌더링 과부하 문제
	절차적 맵 생성을 구현하는 과정에서 가장 큰 어려움 중 하나는 셀의 수가 과도하게 많아져 렌더링 성능에 과부하가 걸린 점이었다. 초기에는 모든 셀을 한 번에 렌더링하도록 설계하였으나, 방의 수가 증가할수록 유니티 엔진에서 처리해야 하는 오브젝트의 수가 급격히 늘어나 게임의 프레임 속도가 저하되는 현상이 발생하였다. 이는 플레이어의 몰입감을 저해하고, 실시간 게임 플레이에 불리한 영향을 미쳤다. 이를 해결하기 위해 인접 리스트(adjacency list) 를 도입하여 렌더링 최적화를 시도하였다. 구체적으로, 현재 플레이어가 위치한 방과 그 주변에 인접한 방들만을 동적으로 렌더링하고, 그 외의 방들은 비활성화하는 방식으로 접근하였다. 이러한 방법을 통해 렌더링해야 하는 셀의 수를 현저히 줄일 수 있었으며, 게임의 전반적인 성능을 향상시킬 수 있었다. 또한, 인접 리스트를 활용함으로써 방 간의 연결성을 효율적으로 관리할 수 있었고, 플레이어의 이동에 따라 필요한 방만을 선택적으로 로드하여 메모리 사용량을 최적화할 수 있었다.		절차적 맵 생성을 구현하는 과정에서 가장 큰 어려움 중 하나는 셀의 수가 과도하게 많아져 렌더링 성능에 과부하가 걸린 점이었다. 초기에는 모든 셀을 한 번에 렌더링하도록 설계하였으나, 방의 수가 증가할수록 유니티 엔진에서 처리해야 하는 오브젝트의 수가 급격히 늘어나 게임의 프레임 속도가 저하되는 현상이 발생하였다. 이는 플레이어의 몰입감을 저해하고, 실시간 게임 플레이에 불리한 영향을 미쳤다. 이를 해결하기 위해 인접 리스트(adjacency list) 를 도입하여 렌더링 최적화를 시도하였다. 구체적으로, 현재 플레이어가 위치한 방과 그 주변에 인접한 방들만을 동적으로 렌더링하고, 그 외의 방들은 비활성화하는 방식으로 접근하였다. 이러한 방법을 통해 렌더링해야 하는 셀의 수를 현저히 줄일 수 있었으며, 게임의 전반적인 성능을 향상시킬 수 있었다. 또한, 인접 리스트를 활용함으로써 방 간의 연결성을 효율적으로 관리할 수 있었고, 플레이어의 이동에 따라 필요한 방만을 선택적으로 로드하여 메모리 사용량을 최적화할 수 있었다.
		+
		+
		+	'''나. 차후 구현할 내용'''
		+
		+	◇ 다양한 분야의 도전: 이번 프로젝트에서는 ‘음성’이란 데이터만 다루는 모델을 설계하고 배포하였다. 하지만 AI는 음성 뿐만 아니라 Computer Vision, LLM 등 다양한 분야가 있다. 이런 타 분야의 논문을 읽고 직접 설계해보는 시간을 가진다면 배움의 시야가 한 층 넓어질 것이며, 향후 ‘음성 AI’ 연구를 진행할 때 타 분야의 기술들을 이용하여 설계할 수 있는 기회도 접해 볼 수 있을 것 같다.
		+	::● 추가 모델 적용
		+	::::○ 한 학기라는 시간 제한으로 인해 모델 2개 훈련 후 배포로 목표를 잡았지만 향후 구현하게 된다면 더 다양한 모델을 적용할 수 있을 것이라 생각한다. 가장 먼저 구현하고 싶은 부분은 NPC 및 몬스터들의 인게임 보이스를 Deepfake audio or TTS를 통해 직접 생성하는 것이다. 특히 성우를 고용하기 힘든 소규모 프로젝트의 경우 이런 인공지능 모델을 통해 목소리를 생성한다면 보다 완성도 있고 실감나는 게임을 완성할 수 있을 것이며, 게임 유저에게 긍정적인 경험을 줄 것이라 예상하고 있다.
		+	::● On-device 상황에서의 원활한 구동
		+	::::○ 이번 프로젝트에서 가장 예상 못한 복병은 모델과 오디오 크기로 인한 쓰레드 초과 문제였다. 연구자의 입장에선 단순히 성능 좋은 모델이 가장 좋은 결과물 일 것이다. 하지만 이런 모델을 실생활 On-device에 적용하고 사용하는 다수의 기업과 사람들은 조금의 성능은 포기하더라도 모델의 경량화 및 추론 속도에 더욱 집중할 것이다. 우리의 프로젝트도 이런 특성을 떠올려 단순 성능 위주의 모델을 채택한 것이 아니라, 약간의 성능을 포기하고 모델 경량화에 집중한 부분도 있다. 향후 Pruning(가지치기), Quantization(양자화), Knowledgedistillation(지식 증류)등의 모델 경량화 기법들을 추가로 적용하여 실시간 게임에서 더욱 빠르고 가볍게 반응하도록 모델을 재설계 예정이다.
		+
		+	◇ 미처 구현하지 못한 AI 조력자 협동 퍼즐을 완성할 것이고, 미로 퍼즐에 버튼을 추가하여 모든 버튼을 눌러야 다음 문이 열리도록 만들 것이다. 또한 세부 설계 단계에서 게임에 넣지 않기로 결정했던 LLM을 이용한 AI 조력자 시스템을 추가할 것이다.
		+
		+	◇ 최초 계획에서는 외부 시트를 활용하여 인게임 데이터를 관리하려고 했으나 데모 레벨에서는 많은 데이터가 필요하지 않아 이를 기각하였다. 하지만 아이템의 추가나 몬스터의 확장 등을 고려했을 때 데이터 관리 소스는 반드시 필요하다. 또한 게임 시스템에서 미흡한 점이 많았는데 전체적인 게임성의 향상과 사운드, 시각효과 등의 리소스들의 확장을 우선적으로 구현할 예정이다.
		+
		+	◇ 본 프로젝트의 차후 개발 단계에서는 2D 던전 생성에서 벗어나 3D 던전 제작을 구현할 계획이다. 3D 던전은 플레이어에게 더욱 몰입감 있는 탐험 경험을 제공하며, 게임의 복잡성과 다양성을 크게 향상시킬 수 있다. 이를 달성하기 위해 다음과 같은 기술적 접근과 연구가 필요하다.
		+	::● 사면체를 이용한 들로네 사각화 (Delaunay Tetrahedralization)
		+	::::○ 3D 공간에서의 절차적 맵 생성을 위해서는 2D에서 사용했던 들로네 삼각분할(DelaunayTriangulation)을 3D로 확장한 들로네 사면체화(Delaunay Tetrahedralization) 기법이 필수적이다. 이 기법은 3차원 공간 내에서 점들의 집합을 사면체로 분할하여, 각 사면체가 최대한 균일하고 균형 잡힌 구조를 가지도록 한다. 이를 통해 다음과 같은 장점을 얻을 수 있다.
		+	:::::■ 공간의 균등한 분할: 3D 공간을 균등하게 분할하여 던전의 각 구역이 자연스럽고 논리적인 배치를 가지도록 한다.
		+	:::::■ 연결성 보장: 사면체화 과정을 통해 던전 내 모든 방들이 최소 하나의 경로로 연결되도록 보장할 수 있다.
		+	:::::■ 확장성: 새로운 방이나 구역이 추가될 때 기존의 구조를 크게 변경하지 않고도 손쉽게 확장할 수 있다.
		+	::● Z축을 포함한 A* 알고리즘 탐구
		+	::::○ 3D 던전에서의 경로 탐색은 2D 던전과는 달리 Z축을 포함한 3차원 A 알고리즘*의 적용이 필요하다. 이를 위해 다음과 같은 연구와 구현이 요구된다.
		+	:::::■ 3D 공간에서의 휴리스틱 설계: A* 알고리즘의 효율성을 높이기 위해 3D 공간에 적합한 휴리스틱 함수를 설계해야 한다. 이는 플레이어의 현재 위치와 목표 지점 간의 직선 거리를 기반으로 할 수 있으며, 장애물이나 지형의 복잡성을 고려하여 조정될 수 있다.
		+	:::::■ 다층 구조의 경로 탐색: 3D 던전은 다층 구조를 가질 수 있으므로, 각 층 간의 이동 (예: 계단, 엘리베이터 등)을 고려한 경로 탐색 로직이 필요하다. 이는 경로의 최적화와 탐험의 다양성을 높이는 데 기여할 것이다.
		+	:::::■ 실시간 동적 경로 업데이트: 플레이어의 이동이나 환경 변화에 따라 실시간으로 경로를 재계산하여, 몬스터 AI나 NPC의 행동을 더욱 자연스럽고 유연하게 만들 수 있다.

← 이전 판		2024년 12월 20일 (금) 04:47 판
467번째 줄:		467번째 줄:

	===향후계획===		===향후계획===
−	내용	+
		+	'''가. 어려웠던 내용들'''
		+
		+	◇ 음성인식 구현에서 가장 어려웠던 점은 ONNX파일로 변환하고 이를 Unity에 적용하는 점이었다. 우선 유니티 AI 모델 추론 기능이 나온지 약 1년 정도 밖에 지나지 않았으며, 당연히 관련 문서는 거의 존재하지 않았다. ONNX 추출 과정에서 함수가 손상되고, Unity에서 인식을 못하는 등 문제점이 많았다. 이를 해결하기 위해 모델 레이어 단위로 output tensor 차원을 출력하여 저장하고, 하나하나 계산하면서 깨진 차원을 찾아낸 후, 그 부분을 제거하거나 고쳤다. 그 결과 unity에서 성공적으로 적용할 수 있었다.
		+
		+	:[[파일:s26.png]]
		+	::● 또한 두 번째 문제는 너무 큰 모델 입력으로 인한 Unity 내부 할당 쓰레드 초과 문제였다. 우선적으로 모델의 추론은 약간의 시간이 소요되기 때문에 게임의 흐름을 끊지 않기 위해 비동기적으로 진행하게 하였다. 비동기 방식이 실시간 게임에선 필수적이지만 이런 병렬 프로세스 작업은 쓰레드를 많이 차지하게 되고 결국 할당 쓰레드 초과 문제에 직면하게 하였다. 먼저 쓰레드 할당 현황을 로그로 뽑아 확인 후, 모델의 오디오 입력이 5초를 초과하게 되면 이런 문제가 발생한다는 것을 파악했다.
		+	::● 문제 파악 후 이를 해결하기 위해선 1가지 필수 조건이 있다는 것을 파악하였다.
		+	:::○ 음성 인식 모델
		+	::::■ 입력을 5초로 제한하게 되면 그 이후에 녹음되는 음성은 인식하지 못하는 문제가 발생한다. 때문에 오디오 길이는 그대로 유지하면서 문제를 해결하는 것이 필수적이다. 이를 해결하기 위해 모델 컷팅을 진행했다. 음성 인식 모델의 경우 쓸모 없는 모델 파라미터를 제거하였고 레이어를 제거하여여 모델의 크기를 줄였다.
		+	:::○ 감정 인식 모델
		+	::::■ 감정 인식 모델의 경우 발화자의 감정만 파악하면 되기 때문에 30초의 오디오가 모두 필요하지 않다. 따라서 모델의 크기를 그대로 유지한 채, 오디오의 입력을 30초에서 랜덤으로 5초를 추출하도록 설정하여 쓰레드 부족 문제를 해결하였다.
		+
		+	◇ 절차적으로 생성된 맵에 맞춰 무작위로 생성되는 퍼즐을 기획해야 했다. 두 가지 퍼즐을 기획했는데, 하나는 미로 퍼즐이고 다른 하나는 AI 조력자 협동 퍼즐이다. 미로의 경우 무작위 생성 알고리즘이 존재했기에 이를 이용했는데, 미로가 생성될 맵의 모양이 직사각형이 아닌 다각형의 모양이여서 자칫하면 미로가 생성되지 않는 상황이 발생할 수 있었다. 그래서 미로의 벽과 통로의 생성 방법에 대해 많은 고민을 해야 했다. AI 조력자 협동 퍼즐의 경우 무작위 위치에 특정 색을 지닌 발판 버튼들이 배치되어 있으며 AI 조력자가 알려준 힌트를 보고 버튼들을 색깔 순서에 맞게 눌러야 다음 방으로 가는 문이 열리는 방식이었다. 절차적 생성 알고리즘이 완성되기 전에 베이스 코드를 만들었지만, 코드를 합치고 순서에 맞게 눌러야 하는 기능을 추가하기 시
		+	작하면서 각종 버그가 발생해서 시간이 지연되었다. 따라서 미로 생성 알고리즘의 완성을 우선시하였고 최종적으로 AI 조력자 협동 퍼즐을 완성하지 못했다.
		+
		+	◇ 음성, 감정 인식과 플레이어의 기능을 연결하는 것이 어려웠었다. 텍스트로 만든 더미 데이터로 테스트를 진행했을 때는 동작이 잘 되었지만, 음성, 감정의 리턴값을 활용하여 코드를 수정하니 많은 버그가 발생하였다. 이 버그들을 해결하는 데에 많은 시간이 소요됐었지만 최종적으로는 오류가 없는 원하는 결과를 이끌어 낼 수 있었다. 또한, 맵이 동적으로 생성되기 때문에 그에 따라 방에 맞게 navigation을 구축하는 것이 어려웠었다. 이 부분은 하나의 방 내의 navigation 시스템 전체를 관장하는 빈 오브젝트를 만들어 그 오브젝트 하위에 방 내에 있는 모든 navigation 관련 컴포넌트를 추가하여 한 번에 관리하는 방식으로 해결하였다. 이 과정에서 방에 진입했을 때 해당 방의 정보를 수집하고 이를 활용해 전투 시스템 등을 개선할 수 있는 기능들을 구현할 방안을 도출할 수 있었다.
		+
		+	◇ 절차적 맵 생성 시 렌더링 과부하 문제
		+	절차적 맵 생성을 구현하는 과정에서 가장 큰 어려움 중 하나는 셀의 수가 과도하게 많아져 렌더링 성능에 과부하가 걸린 점이었다. 초기에는 모든 셀을 한 번에 렌더링하도록 설계하였으나, 방의 수가 증가할수록 유니티 엔진에서 처리해야 하는 오브젝트의 수가 급격히 늘어나 게임의 프레임 속도가 저하되는 현상이 발생하였다. 이는 플레이어의 몰입감을 저해하고, 실시간 게임 플레이에 불리한 영향을 미쳤다. 이를 해결하기 위해 인접 리스트(adjacency list) 를 도입하여 렌더링 최적화를 시도하였다. 구체적으로, 현재 플레이어가 위치한 방과 그 주변에 인접한 방들만을 동적으로 렌더링하고, 그 외의 방들은 비활성화하는 방식으로 접근하였다. 이러한 방법을 통해 렌더링해야 하는 셀의 수를 현저히 줄일 수 있었으며, 게임의 전반적인 성능을 향상시킬 수 있었다. 또한, 인접 리스트를 활용함으로써 방 간의 연결성을 효율적으로 관리할 수 있었고, 플레이어의 이동에 따라 필요한 방만을 선택적으로 로드하여 메모리 사용량을 최적화할 수 있었다.

← 이전 판		2024년 12월 20일 (금) 04:43 판
467번째 줄:		467번째 줄:

	===향후계획===		===향후계획===
−	내용
−
−	~~===특허 출원 내용===~~
	내용		내용

@@ 459번째 줄: / 459번째 줄: @@
 ===관련사업비 내역서===
-내용
 ===완료작품의 평가===

@@ 462번째 줄: / 462번째 줄: @@
 ===완료작품의 평가===
-내용
 ===향후계획===

@@ 410번째 줄: / 410번째 줄: @@
 ◇ 압축파일을 풀면 위와 같은 구성을 확인할 수 있다.
 ◇ Capstone.exe를 실행시키면 게임이 실행된다.
 ◇ Output : 빌드 시 자동으로 생성되는 파일들이며 각 파일들은 아래와 같다.
 :- Capstone_BurstDebugInformation_DoNotShip : 개발 및 디버깅 단계에서 필요한 폴더이며, 실행 시에는 필요하지 않음.

← 이전 판		2024년 12월 20일 (금) 04:40 판
404번째 줄:		404번째 줄:

	[[파일:s16.png]]		[[파일:s16.png]]
		+
		+	'''나. 설치'''
		+
		+	[[파일:s17.png]]
		+
		+	◇ 압축파일을 풀면 위와 같은 구성을 확인할 수 있다.
		+	◇ Capstone.exe를 실행시키면 게임이 실행된다.
		+	◇ Output : 빌드 시 자동으로 생성되는 파일들이며 각 파일들은 아래와 같다.
		+	:- Capstone_BurstDebugInformation_DoNotShip : 개발 및 디버깅 단계에서 필요한 폴더이며, 실행 시에는 필요하지 않음.
		+	:- Capstone_Data : 게임 및 애플리케이션의 주요 데이터 파일들이 저장된 폴더이며 씬 데이터, 텍스처, 모델, 스크립트 번들, 설정 파일, 리소스 등 Unity 프로젝트의 실행에 필요한 모든 리소스를 담고 있음.
		+	:- MonoBleedingEdge : Unity의 Mono 런타임 환경을 제공함. Mono는 C# 코드 실행을 위해 필요한 런타임이며, 최신 버전의 Mono 라이브러리와 함께 제공됨.
		+	:- Capstone.exe : 실행파일
		+	:- UnityCrashHandler64.exe 게임이 실행 중 충돌하거나 오류가 발생했을 때 이를 감지하고 로그를 생성하는 Unity의 크래시 핸들러.
		+	:- UnityPlayer.dll : Unity의 런타임 라이브러리로, 게임의 실행을 위한 렌더링, 입력 처리, 물리 엔진 등의 내용이 담겨있음
		+
		+	'''다. 실행'''
		+
		+	[[파일:s18.png]]
		+
		+
		+	1. 최초 입장 시 스폰 방(0번 방)에서 플레이어가 스폰된다. WASD로 이동을, 스페이스바로 점프를 할 수 있다. 최적화를 위해 현재 방과, 연결된 다음 방만 렌더링을 하고 이동을 하면서 점진적으로 렌더링을 하는 방식을 채택했다.
		+
		+
		+	[[파일:s19.png]]
		+
		+
		+	2. 방 내의 통로에서 다른 방으로 이동할 수 있다. 통로는 벽에 횃불이 설치되어 있어 횃불이 설치된 벽을 따라가면 다음 방으로 들어갈 수 있다.
		+
		+
		+	[[파일:s20.png]]
		+
		+
		+	3. 통로를 따라 이동하면 미로 방(퍼즐 방) 혹은 전투 방 중 하나의 기믹을 해결해야한다. 위 사진은 미로 방으로서 미로를 탈출하여 다음 방으로 이동할 수 있다.
		+
		+
		+	[[파일:s21.png]]
		+
		+
		+	4. 위 사진은 전투 방으로서, 입장 시 제한 시간이 활성화 되고 통로가 막히게 된다. 제한 시간 내에 일정한 수의 몬스터를 퇴치해야한다. 미션을 성공하면 막힌 통로가 다시 열리게 되어 다음 방으로 이동할 수 있다.
		+
		+
		+	[[파일:s22.png]]
		+
		+
		+	5. 마우스 좌클릭으로 기본공격을 할 수 있다. 또한 좌측 Ctrl키를 누른 채로 말을 하면 주문을 인식할 수 있으며 만약 올바른 주문이 인식될 경우 스킬이 활성화되어 스킬을 사용할 수 있다. 또한, 말에서 인식한 감정에 따라 몬스터에게, 혹은 플레이어에게 상태효과가 추가로 적용된다.
		+
		+
		+	[[파일:s23.png]]
		+
		+
		+	6. 제한 시간 내에 모든 몬스터를 퇴치하면 위에서 언급했듯이 통로가 열리게 되어 다음 방으로 이동할 수 있다. 하지만 제한 시간 내에 미션을 성공하지 못하면 플레이어에게 불꽃이 활성화되어 몇 초 뒤에 죽게 된다. 재시작 버튼을 누르면 처음부터 다시 시작할 수 있다.

	===관련사업비 내역서===		===관련사업비 내역서===

← 이전 판		2024년 12월 20일 (금) 04:33 판
404번째 줄:		404번째 줄:

	[[파일:s16.png]]		[[파일:s16.png]]
−
−	~~====포스터====~~
−	내용

	===관련사업비 내역서===		===관련사업비 내역서===

@@ 401번째 줄: / 401번째 줄: @@
 ===완료 작품의 소개===
 ====프로토타입 사진 혹은 작동 장면====
-내용
+'''가. 프로토타입 작동장면'''
 ====포스터====
 내용

@@ 314번째 줄: / 314번째 줄: @@
 ===상세설계 내용===
-'''컴포넌트 다이어그램'''
+'''가. 컴포넌트 다이어그램'''
 ◇ 맵 절차적 생성의 컴포넌트 다이어그램
@@ 326번째 줄: / 326번째 줄: @@
-'''시퀀스 다이어그램'''
+'''나. 시퀀스 다이어그램'''
 ◇ 주문 발동 시스템의 시퀀스 다이어그램
@@ 353번째 줄: / 353번째 줄: @@
-'''클래스 다이어그램'''
+'''다. 클래스 다이어그램'''
 ◇ AI_system의 클래스 다이어그램
@@ 385번째 줄: / 385번째 줄: @@
 ::● MazeTileMapGenerate 클래스는 게임 씬에 미로를 실제로 생성한다. Awake() 함수는 변수를 초기화하는 함수다. GenerateMap() 함수에서 미로를 게임 씬에 생성하게 된다. 이 때,ChoosePrefabForCell() 함수를 통해 특정 칸에 어떤 프리팹을 생성할 지, 어떤 방향으로 회전해야 하는지 정한다. returnOppositeDirection() 함수는 MazeGenerate 클래스의 함수와 동일한 역할을 한다.
 ::● MazeCell 클래스는 각 칸마다 미로를 생성할 때 필요한 정보들을 담은 자료구조다. 어떤 방향으로 통로가 존재하는지 여부, 벽이 아예 없는지 여부, 칸의 타입이 무엇인지, 유니티 게임 상에서 어떤 좌표에 위치해 있는지 등에 대한 변수들이 있다. setPathFlagTrue() 함수는 특정 방향에 통로가 존재한다고 저장하는 함수다. getPathFlag() 함수는 특정 방향에 통로가 존재하는지 bool값을 반환하는 함수다. getRandomFlagIndex() 함수는 벽이 존재하는 방향 중 무작위로 한 방향을 선택해서 반환하는 함수다.
 ==결과 및 평가==