1분반-슈팅스타

프로젝트 개요

기술개발 과제

국문 : 탑다운 전략 슈팅 게임

영문 : Top-down tactical shooting Game..

과제 팀명

슈팅스타

지도교수

안상현 교수님

개발기간

2025년 3월 ~ 2025년 6월 (총 4개월)

구성원 소개

서울시립대학교 컴퓨터과학부 20199200** 한*만(팀장)

서울시립대학교 컴퓨터과학부 20199200** 정*원

서울시립대학교 컴퓨터과학부 20209200** 박*빈

서울시립대학교 컴퓨터과학부 20209200** 임*현

서론

개발 과제의 개요

개발 과제 요약

◇ 전략적 팀플레이를 핵심으로 하는 탑다운 슈팅 게임 개발

◇ 자원의 위치와 장애물이 매 판마다 절차적으로 생성되는 전장 환경에서 전술적 협동이 가능 한 멀티플레이 시스템 구축

◇ 수집한 자원에 따라 무기에 랜덤한 성능이 부여되는 무기 제작 시스템 개발

◇ 슈팅 액션과 전략적 요소를 융합한 신개념 게임 콘텐츠 구현

개발 과제의 배경

1) 복잡한 접속 절차 기존의 모바일 멀티플레이 게임은 대부분 인터넷 접속, 로그인, 서버 매치메이킹 등의 복잡한 절차를 요구한다. 이러한 과정은 짧은 시간 동안 빠르게 게임을 즐기고자 하는 사용자에게 불편하게 느껴질 수 있다. 본 게임은 Wi-Fi Direct 기술을 활용하여, 로그인이나 인터넷 연결 없이도 주변 플레이어와 바로 연결되어 즉시 멀티플레이를 시작할 수 있는 환경을 제공한다. 이러한 접근은 ‘빠르고 간편한 게임 경험’이라는 핵심 가치를 실현한다.

2) 온라인 환경 제약 외부 환경에서 모바일 게임을 즐기려 할 때, 데이터 소모는 제약이 될 수 있다. Wi-Fi Direct 기반의 본 게임은 이러한 제약을 뛰어넘어, 인터넷이 없는 상황에서도 근거리 유저 간의 직접 연결로 언제 어디서나 함께 플레이할 수 있다. 이는 네트워크 환경에 구애받지 않고 자유로운 멀티플레이를 가능하게 하여, 실외나 일상 속에서도 쉽게 함께 게임을 즐길 수 있도록 한다.

3) 반복적인 콘텐츠 구조와 제한된 전략 선택지 기존 탑다운 슈팅 게임은 고정된 맵과 자원 구조로 인해 플레이의 반복성이 강하고 전략적 다양성이 부족하다는 한계를 가지고 있다. 본 게임은 맵과 자원을 절차적으로 생성하여, 매 경기 마다 새로운 환경을 제공한다. 플레이어는 그 안에서 자원을 채집하고, 채집한 자원의 종류와 양에 따라 다양한 무기를 제작하게 된다. 이를 통해 예측 불가능한 플레이 흐름과 전략적 유연성을 확보하였으며, 반복 플레이에서도 지속적인 신선함과 몰입감을 유지할 수 있다.

개발 과제의 목표 및 내용

◇ 플레이어는 절차적으로 생성된 맵에서 자원을 자유롭게 탐색하고 채집할 수 있다.

◇ 플레이어는 채집한 자원의 종류와 양에 따라 다양한 무기와 장비를 제작하거나 업그레이드할 수 있다.

◇ Wi-Fi Direct 기반의 P2P 연결을 통해 별도의 로그인이나 인터넷 접속 없이 주변 유저와 즉시 멀티플레이를 시작할 수 있다.

◇ 멀티플레이 시, 플레이어들은 협동 또는 경쟁을 통해 자원을 공유하거나 탈취하며 전략적으로 전투를 전개할 수 있다

개발과제의 기대효과

기술적 기대효과

◇ 사용자는 별도의 로그인이나 인터넷 접속 없이, Wi-Fi Direct 기반의 빠른 멀티플레이 환경 을 통해 즉시 게임에 참여할 수 있어 진입 장벽이 낮고, 접근성이 높다.

◇ 절차적으로 생성되는 맵과 자원 배치, 장애물 구조를 통해 매 판마다 새로운 전략적 경험을 제공하며, 플레이어는 매번 다른 전장을 탐색하고 대응해야 하는 몰입감을 느낄 수 있다.

◇ 수집한 자원을 기반으로 랜덤한 무기 성능이 부여되는 시스템은 예측 불가능성과 리플레이 가치를 높이며, 유저의 전략적 선택을 유도한다.

◇ UI는 모바일 터치 기반의 직관적인 조작 시스템으로 설계되어 누구나 쉽게 컨트롤할 수 있 으며, 다양한 디바이스 해상도에 대응하는 크로스 플랫폼 UI 시스템으로 구현된다.

경제적, 사회적 기대 및 파급효과

◇ 서버를 필요로 하지 않는 P2P 멀티플레이 구조를 통해 인디 개발팀도 낮은 인프라 비용으로 멀티플레이 게임을 개발할 수 있어 개발·유지 비용을 절감할 수 있다.

◇ 기존의 데이터 기반 매치메이킹 구조 대신, 근거리 통신을 활용함으로써 온라인 매칭 없이 도 현장 중심의 이새로운 사용자 경험을 제공할 수 있다.

◇ 고정된 콘텐츠 소비에서 벗어나, 매번 달라지는 전장 구성과 무기 조합을 통해 플레이어는 반복 플레이에도 피로감 없이 지속적인 몰입과 플레이를 유도할 수 있다.

◇ Wi-Fi Direct 환경 기반의 실시간 협동 게임은 네트워크가 제한적인 지역이나 네트워크 비용 이 부담스러운 사용자에게도 적합해, 더 폭넓은 사용자층을 확보할 수 있다.

◇ 절차적 콘텐츠 구성 방식은 개발자가 수작업으로 맵을 디자인하지 않아도 되기 때문에, 콘 텐츠 생산 비용을 절감하고 라이프 사이클이 긴 게임 구조를 구축할 수 있다.

기술개발 일정 및 추진체계

개발 일정

구성원 및 추진체계

※ 구성원

◇ 한규만: 팀장, UI/UX 시스템 구현 및 인벤토리·HUD·로비 UI 개발

◇ 정진원: 절차적 맵 생성 알고리즘, 자원 및 지형지물 배치 시스템 개발

◇ 박하빈: 게임 라운드 시스템 및 서버 연동, RPC 및 클라이언트 동기화 처리

◇ 임정현: 플레이어 입력 및 전투 조작 시스템 구현, 무기 사용 및 피격 처리 담당

※ 추진 체계

◇ 매주 수요일 정기 회의를 통해 진행 상황을 공유하며, 회의록은 한규만(팀장)이 작성한다.

◇ 회의는 모든 팀원이 참여하는 것을 원칙으로 하며, 주요 결정사항은 회의록에 기록하여 투 명하게 공유한다.

◇ 전체 개발 일정은 상단에 기술된 월별 목표를 기준으로 진행하며, 일정 내 기능 구현을 우 선하고 이후 테스트 및 밸런싱에 집중한다.

◇ 1주일 단위 스프린트를 기준으로 개발 목표를 설정하고, 애자일(Agile) 프로세스에 따라 유연 하게 계획을 점검하고 조정한다.

◇ GitHub를 통해 형상 관리를 수행하며, 모든 기능은 Pull Request(PR) 단위로 리뷰 및 반영한 다.

◇ 메시지 컨벤션

기본 형식: 분류:제목

필요 시 본문은 한 줄 띄운 뒤 작성

분류 예시: 문서추가, 기능구현, 코드삭제

◇ 코딩 컨벤션

Epic Games에서 권장하는 Unreal Engine C++ 코딩 표준을 따름

◇ 에셋 네이밍 컨벤션

애셋 이름은 Unreal Engine의 권장 네이밍 규칙을 따르며, 접두어를 통해 애셋 종류를 명확하게 구분함.

예시: SM_, BP_, FX_, UI_, MAT_

설계

설계사양

제품의 요구사항

번호	요구사항	D or W	비고(중요도)
1	Wi-Fi Direct 기반의 로컬 멀티플레이 연결이 가능해야 한다.	D	대
2	절차적 방식으로 맵과 자원이 배치 되어야 한다	D	대
3	자원을 채집하고 조합하여 무기를 제작할 수 있어야 한다.	D	대
4	자원 조합 결과에 따라 무기의 성능이 다양하게 변화해야 한다.	W	중
5	플레이어 간 전투가 가능하고, 공격, 피격, 사망 등의 상태 처리가 가능해야 한다.	D	대
6	모바일 환경에 최적화된 조작 UI/UX 구성을 지원해야 한다.	D	대
7	플레이어 상태를 화면에 표시하는 UI를 지원해야 한다.	D	중
8	라운드 방식의 게임 진행과 승리 조건 처리가 가능해야 한다.	D	대
9	게임 밸런스를 조절하여 원활한 게임 환경을 제공해야한다.	W	소

개념설계안

1. 순서도 MainMenu 레벨 순서도

본 순서도는 Wi-Fi Direct 기반 멀티플레이 시스템의 초기 접속 및 매치메이킹 과정을 나타낸다. 게임은 MainMenu 상태에서 시작되며, 플레이어는 다음과 같은 세 가지 선택지를 가진다.
Join Game
- Create Game
- Search Nearby Players
Join Game을 선택할 경우, 플레이어는 특정 Tag를 입력하게 된다.
Tag를 입력한 후, 해당 태그가 존재하는지를 검사하는 조건문(Does Tag Exist?)을 통과하게 된다.
- 입력한 태그가 존재할 경우 Lobby Level로 이동하게 되며, 존재하지 않는 경우 다시 Enter Tag 입력 상태로 돌아가게 된다.
Create Game을 선택한 경우, 즉시 Lobby Level로 이동하여 새로운 게임 방을 생성하게 된다.
Search Nearby Players를 선택하면, Wi-Fi Direct 기능을 통해 주변 플레이어를 검색하는 단계인 WifiDirectDiscover Level로 이동하게 된다.

Lobby 레벨 순서도

본 순서도는 로비에서 플레이어가 선택 가능한 행동들과, 2v2 게임 시작 조건을 포함한 진행 흐름을 나타낸다.
게임은 Lobby 상태에서 시작되며, 플레이어는 다음 네 가지 선택지 중 하나를 고를 수 있다.
- Start Game
- Blue Team
- Red Team
- Exit
Blue Team 버튼을 선택하면 플레이어는 Blue Team Section으로 이동하게 된다.
Red Team 버튼을 선택하면 플레이어는 Red Team Section으로 이동하게 된다.
Exit을 선택할 경우, 현재 로비를 떠나 MainMenu Level로 복귀하게 된다.
Start Game 버튼을 선택하면, 현재 로비에 있는 플레이어들이 2대2(2v2) 매치를 시작할 준비가 되었는지를 확인하는 조건 분기(Are 2v2 Players Ready?)로 이동하게 된다.
조건이 충족되지 않은 경우에는 다시 로비 상태로 복귀한다.
조건이 충족된 경우, 즉 2v2 구성이 완료된 경우에는 Competitive Level로 전환되며 본격적인 게임이 시작된다.

Wifi Direct 레벨 순서도

본 순서도는 Wifi Direct 기반 P2P 통신을 활용하여 플레이어들이 그룹을 생성하고, 로비로 진입하기까지의 흐름을 나타낸다.
시작 상태는 WifiDirectDiscover 레벨이며, 플레이어는 두 가지 선택지를 가질 수 있다.
- Connect Device
- Exit
Connect Device를 선택할 경우, 주변 디바이스와의 Wifi Direct 연결을 시도하게 된다.
연결이 완료되면, 자동으로 Create Group 단계로 진입하여 Wifi Direct 그룹을 구성한다.
그룹이 생성된 이후에는 Assign Host 단계를 통해 해당 그룹 내에서 호스트(Host) 역할을 수행할 디바이스가 자동으로 지정된다.
호스트 할당이 완료되면, 모든 플레이어가 Lobby Level로 이동하게 되어 본격적인 로비 대기 상태로 진입한다.
반면, 플레이어가 Exit을 선택한 경우에는 Wifi Direct 연결을 시도하지 않고 바로 MainMenu Level로 복귀하게 된다.

2. 스테이트 다이어그램 라운드 흐름 스테이트 다이어그램
[[파일: Shooting star state diagram round.png]]

본 다이어그램은 게임의 라운드 진행 방식 및 승리 조건을 상태(State) 기반으로 표현한 상태 전이 다이어그램이다.
게임은 RoundStart 상태에서 시작되며, 이 상태는 각 라운드의 시작을 나타낸다.
RoundStart 이후에는 Playing Round 상태로 진입하며, 각 라운드는 고정된 시간(3분) 동안 진행된다. 3분이 경과하면 Check Kill Count 상태로 진입하여, 양 팀의 킬 수를 비교하여 승패 또는 연장 여부를 판단한다.
킬 수가 다른 경우에는 일반적인 승리 조건으로 간주되며, Check Winner 상태로 전이된다.
킬 수가 동일한 경우, 즉 무승부일 경우에는 Death Match 상태로 진입한다.
Death Match 상태에서는 한 팀이 전멸할 때까지 전투가 계속되며, 승자가 결정되면 Check Winner 상태로 이동한다.
Check Winner 상태에서는 승리한 팀의 라운드 수를 확인하며, 특정 팀이 3라운드를 승리하지 못한 경우, 다시 RoundStart 상태로 돌아가 다음 라운드를 시작한다.
반대로, 3라운드를 먼저 승리한 팀이 존재할 경우, 게임은 End Game 상태로 전이되며 최종 승부가 결정된다.
전체적으로 이 상태 전이 다이어그램은 라운드 중심 구조와 데스매치 조건을 모두 포괄하여, 게임 진행 로직의 핵심 흐름을 나타낸다.

Wi-Fi Direct 멀티플레이어 스테이트 다이어그램

위 다이어그램은 초기 상태부터 피어 검색 및 연결, 그룹 형성 과정과 상태 전이를 나타낸 스테이트 다이어그램이다.
우선 최초로 게임을 실행하면 Clear 상태로, 이 상태에서는 어떠한 WiFi Direct 관련 작업이 진행되지 않으며 상태 진입시 진행 중이던 WiFi Direct 작업이 있다면 즉시 중지한다.
- 이 상태는 플레이어가 메인 메뉴에 있는 경우 유지된다.
Clear상태에서 게임 검색을 요청하면 BroadcastAndDiscovering 상태로 전이하며, 주변 ShootingStar 앱을 주기적으로 검색하고 자신의 기기도 광고한다.
- 필요 권한이 부여되지 않은 경우, 지원되지 않는 OS 버전이거나 기기인 경우 Clear 상태로 전이한다.
- 정상적인 상황에서도 플레이어가 메인 화면으로 이동하는 등 검색을 취소하면 Clear 상태로 전이한다.
- 오류가 발생하거나 플레이어의 추가적인 요청이 없는 경우 해당 상태를 계속 유지한다.
BroadcastAndDiscovering 상태에서 검색된 다른 피어에 대해 연결을 요청하면 Connecting 상태로 전이한다.
- 검색된 피어가 더 이상 유효하지 않게 되어 연결에 실패했다면 다시 BroadcastAndDiscovering 상태로 전이한다.
Connecting 상태에서 성공했거나, BroadcastAndDiscovering 상태에서 다른 피어가 먼저 해당 기기로 연결한 경우 GroupFormed 상태로 전이한다.
- 최근 P2P 연결하지 않은 기기라면 GroupFormed로 전이하기 전에 안드로이드 OS가 추가적인 연결 수락 여부를 묻는 팝업을 띄울 수 있다.
- GroupFormed 상태 진입시 WiFi Direct 표준에 의해 호스트가 정해지며, 멀티플레이가 가능하다.
GroupFormed 상태에서 세션을 종료하면 Clear 상태로 전이한다. 만약 호스트가 세션을 종료했다면 모든 클라이언트가 Clear 상태로 전이한다.

플레이어 상태 스테이트 다이어그램

최초 스폰 시 비무장 상태로 스폰
비무장 상태에서도 공격 가능
플레이어는 채집을 통해 아이템 획득
이후 검이나 총을 장착한 상태로 변경
해당 상태에서 공격을 통해 전투
플레이어의 체력이 0 이하가 될 경우 사망 판정
게임이 끝나지 않았다면 사망한 후 리스폰

3. 시퀀스 다이어그램 전투처리흐름 시퀀스 다이어그램

플레이어가 총을 가지고 있을 시 Attack 함수에서 weapone 클래스에 ProjectileFire함수를 요청
Weapon은 발사체를 발사 한 뒤 발사체에서 OnComponentBeginOverlap함수를 사용하여 충돌 감지
충돌이 감지될 경우 ApplyDamage함수를 통해 적에게 데미지 요청
적은 TakeDamage 함수를 통해 자신에게 데미지 적용
플레이어가 총을 가지고 있지 않을 시 Attack 함수에서 Weapon 클래스에 바로 OnComponentBeginOverlap 함수를 요청
무기에 충돌이 감지될 시 ApplyDamage 함수를 통해 적에게 데미지 요청
적은 TakeDamage 함수를 통해 데미지 적용

Wi-Fi Direct 모듈 시퀀스 다이어그램

위 다이어그램은 WiFi Direct의 모듈 동작 방식을, 유저가 다른 기기에 대해 Connect()를 요청하고 성공 결과를 받는 과정을 예로 들어 설명한 시퀀스 다이어그램이다.
최초로 유저가 언리얼 엔진의 클래스 형태로 구현된 UWifiDirectInterface의 Connect()를 호출한다.
Connect()에서는 Java로 제공되는 안드로이드의 API를 호출하기 위해, C언어 라이브러리 형식으로 제공되는 Java Native Interface의 메소드 검색 함수와 호출 함수를 호출한다.
gameActivity에 정의된 connect() 함수가 호출되어, 안드로이드의 WiFi Direct API가 호출된다. 해당 API는 비동기 함수이므로, 콜백 함수를 등록하고 즉시 반환된다.
연결이 성공하면Java의 native 키워드로 선언해 놓은 함수가 호출된다. 이 함수는 C언어 규격으로 정의해 놓은 JNI 함수와 링크되어 있다.
JNI 함수가 콜백에서 발생한 Java 형식 인자들을 C++와 언리얼 엔진 제공 타입으로 변환한 후, UWifiDirectInterface의 OnConnected() 콜백을 호출한다.
최종적으로 유저는 UWifiDirectInterface로부터 OnConnected()를 통해 연결 성공을 확인한다.

상세설계 내용

전체 게임 세션
[[파일: Shooting star class diagram entire.png]]

본 클래스 다이어그램은 하나의 게임 세션을 구성하는 클래스들을 나타낸 다이어그램이다.
ACompetitiveGameMode와 그것을 구성하는 컴포넌트들은 플레이어 연결 상태 관리, 게임의 시작과 종료, 맵과 오브젝트의 생성, 점수 관리와 같은 공통 게임 로직을 담당하며, UServerComponent로부터 전달받은 클라이언트의 RPC 호출의 실제 판정 및 동작을 담당한다.
- 이 클래스들의 인스턴스들은 원본 컴퓨터, 즉 서버 역할을 진행하는 플레이어에게만 존재하며, 자동으로 게임의 상태를 동기화하는 ACompetitiveGameState 클래스를 제외하면 이 클래스들에 의존하는 클래스는 오직 UServerComponent만이 존재함을 알 수 있다.
개별 플레이어들의 상태 관리와 동작은 ACompetitivePlayerController와 그것을 구성하는 클래스들이 담당한다. 이들은 입력 처리, 게임 상태값 UI 출력, RPC를 이용한 송수신과 같은 입출력을 구현하며, 인벤토리 등의 플레이어별 상태값 관리도 담당한다.
ACompetitivePlayerController를 비롯한 클래스들이 논리적인 로직을 구성한다면, ACompetitiveCharacter와 구성 클래스들은 개별 플레이어의 물리적인 로직을 구성한다고 할 수 있다.
- ACompetitiveCharacter는 플레이어의 입력을 받아 캐릭터를 이동시키는 동작을 담당하며, 공격이나 자원 채집 등의 액션 입력이 발생하였을 때 실제 판정을 위한 대상으로서의 역할도 담당한다.
- 특히 공격 판정의 경우, 캐릭터의 위치와 더불어 부착된 UTeamComponent의 팀 값을 참조하여 진행하게 된다.
이외에도 별도로 분리된 무기 시스템 클래스들을 확인할 수 있다. 무기들의 공통 인터페이스 IWeaponBase와 이것을 구현하는 슈퍼클래스 AGunBase, AKnifeBase가 정의되어 있으며, 각각은 원거리 무기와 근접 무기 클래스들의 기반 클래스이다.
- 다이어그램에서 UInventoryComponent가 다수의 무기 시스템 클래스에 의존하는 대신 UWeaponFactory에만 단일 의존 관계를 가지는 구조로, 잦은 확장과 변동이 발생할 수 있는 무기 시스템에 대한 외부 의존성이 최소화되었음을 명확히 확인할 수 있다.

절차적생성 컴포넌트 다이어그램

위 컴포넌트도는 본 프로젝트에서 구현 중인 절차적 맵 생성 시스템의 대략적인 구성 요소와 이들간의 상호작용을 시각적으로 나타낸다. 해당 시스템은 ProceduralMapGenerator, ObstacleGenerator, SubObstacleGenerator, FenceGenerator, Resource Generator, DecorationGenerator, Pattern Generator로 구성된다.
Procedural Map Generator 컴포넌트는 Competitive 씬 진입시 맵 속성을 초기화하고 다른 주요 컴포넌트들을 호출하여 절차적 생성을 시작한다. 우선 Obstacle Generator를 호출하여 가장 크기가 큰 Static Mesh Actor들을 생성한다.
다음으로 SubObstacleGenerator, FenceGenerator, Resource Generator, DecorationGenerator를 순차적으로 호출하여 각각 상대적으로 크기가 작은 장애물, 울타리, 플레이어와 상호작용(채굴)가능한 자원들, 맵에 시각적 효과를 추가해주기 위한 데코레이션 액터들을 생성한다. 각 과정에서 생성된 Static Mesh Actor들의 정보는 동일한 좌표 배열 상에서 관리되어 적절한 거리를 유지하도록 하여 부자연스러운 배치를 방지한다.
Fence Generator 컴포넌트는 울타리의 생성,Decoration Generator컴포넌트는 꽃, 풀, 덤불 등 장식물들의 생성을 담당한다. 이러한 액터들의 생성은 독립적으로 한 번 수행되는 것이 아닌. 일정한 모양이나 군집을 형성하도록 생성해야 한다. 따라서 특정 패턴의 생성 작업을 Pattern Generator에 위임하여 특정 액터의 반복적인 생성을 효과적으로 처리할 수 있도록 한다.
최종적으로, 각Static Mesh는 Competitive 씬에서 개별적인 Static Mesh Actor로 생성되어 배치된다.해당 과정을 통해 매판마다 플레이어들이 새로운 구조의 맵에서 게임을 진행하게 됨으로써,반복적이지 않으며 독창적인 플레이어 경험을 창출해낼 수 있게 된다.

절차적생성 클래스 다이어그램

본 시스템은 중심 클래스인AProceduralMapGenerator와 생성 책임 분리 클래스, 보조 클래스 등으로 정의된다.
AProceduralMapGenerator의 BeginPlay() 함수를 통해 Level 진입 시 맵 생성 루프가 시작된다.이 주요 클래스에서는 생성 책임을 분리한 각 GeneratorClass를 순차적으로 호출하여 맵 생성을 수행하게 된다.객체 위치 충돌 검사(HasObjectAtArray, CheckLocationValid)를 통해 생성 대상 객체의 위치가 유효한지를 판단하며,만약 유효하지 않은 위치값이라면 최근접 유효 위치 탐색 기능(FindNearestValidLocation)을 통해 가장 가까운 유효 위치가 대상 객체가 생성될 수 있도록 하였다.
생성 책임 분리 클래스들은 각기 별도의 Generator 클래스로 위임받는다. 각 클래스는 AObstacleGenerator, ASubObstacleGenerator, AFenceGenerator, AResourceGenerator, ADecorationGenerator이며 각각 장애물, 서브장애물, 울타리, 자원, 장식물 등의 실제 생성 작업을 담당한다. 이 클래스들은 모두 별도의 Static Mesh 리스트, 생성 객체의 수량및 최소 간격을 속성으로 포함한다. 특히 AFenceGenerator, ADecorationGenerator와 같이 동일한 Static Mesh의 재귀적 생성이 포함될 수 있는 클래스들의 경우 GPU의 부담을 줄일 수 있도록 엔진에서 제공해주는 Instanced Static Mesh Component 기능을 활용하였다. 동일한 Mesh 에셋을 사용하는 각 액터들을 개별적으로 렌더링하는 것이 아닌,개별적인 위치값만을 저장하여 드로우콜을 효과적으로 줄일 수 있었다.
APatternGenerator 클래스는 특정 패턴 배치를 전담한다. 재귀적인 생성이 필요한 객체들에 대하여 해당 객체를 생성할 원점을 입력받으면,그 원점을 중심으로 미리 정의된 패턴(사각형, U자 모양, L자 모양 등)을 3차원 벡터 배열의 형태로 반환해준다.
열거형 EPatternType, EObjectMask는 공통 자료구조로써 각각 패턴의 종류 정의, 객체 타입 식별 및 필터링에 활용된다.
위와 같은 클래스 구조로 정의함으로써, 확장성과 유지보수성을 높이고자 하였다. 새로운 Generator 클래스를 추가하거나 새로운 패턴을 정의하는 등의 확장을 고려하였고, 위치 검증, 마스크 필터링, 최근접 위치 탐색 로직 등의 주요 로직은 중앙에서 일괄적으로 관리할 수 있도록 설계하였다.

플레이어 클래스 다이어그램

플레이어
- 플레이어는 체력과 장착된 무기와 같은 전투에 관련한 데이터를 갖고 있음
- 애니메이션이나 사운드와 같은 컴포넌트들을 보유하며 상황에 따라 재생
- 채집은 주변에 있는 자원 액터를 찾아 채집 애니메이션 재생 후 획득하도록 설계
- 장착하고 있는 무기에 공격을 요청하여 전투하도록 설계
WeaponBase
- WeaponBase는 데미지 및 메시를 갖을 수 있도록 설계
- 무기가 검인지 총인지를 구별할 수 있도록 구현
- 무기가 플레이어에게 장착될 수 있도록 SpawnToHand와 같은 함수들을 설계
GunBase
- WeaponBase를 상속받도록 설계되며 사격 시 총구 화염과 같은 Flash가 나타날 수 있도록 언리얼의 UParticleSystem을 이용하여 설계한다.
- ProjectileBase에 총알을 발사하도록 요청할 수 있도록 설게
ProjectileBase
- ProjectileBase는 GunBase에서 요청 받으면 발사체를 스폰하여 발사
- 해당 발사체는 OnComponentBeginOverlap 함수를 이용하여 충돌을 감지한 후 충돌체가 플레이어일 시 ApplyDamage함수를 이용하여 데미지를 적용
KnifeBase
- KnifeBase는 WeaponBase를 상속받도록 설계되며 GunBase와 달리 무기 자체에서 충돌체를 감지하여 해당 충돌체가 플레이어일 시 데미지를 적용
- 충돌체 감지 및 데미지 적용은 ProjectileBase와 동일하게 함수를 사용하여 설계

인벤토리 동작 순서도

본 플로우차트는 인벤토리 UI 내에서 플레이어가 자원을 선택하고 무기를 제작하거나, 무기를 장착 및 해제하는 과정 전반을 나타낸다.
플레이어가 Inventory Button을 클릭하면 인벤토리 UI가 활성화되며, 다음과 같은 초기 작업이 수행된다.
- Fetch Inventory Data : 플레이어가 보유한 자원 정보를 불러온다.
- Generate Player Resource Slots : 플레이어의 자원 정보를 기반으로 자원 슬롯을 생성한다.
- Sync Equipped Weapon Info : 현재 장착 중인 무기 정보를 동기화한다.
- Display Craftable Weapon List : 제작 가능한 무기 목록을 UI에 표시한다.
이후 인벤토리 UI 상태에서는 플레이어의 행동에 따라 다음과 같은 동작들이 수행된다.
- Craft Button : 선택한 자원의 개수를 계산한 후, 요구 자원 수량이 충족되면 무기를 제작 및 장착한다.
- Cancel Button : 장착 상태가 아닐 경우 선택 자원을 초기화하고 장착 상태로 변경한다.
- Click Resource Slot : 자원 선택 시, 요구 자원 미만일 경우 선택 자원을 추가한다.
- Click Weapon Slot : 선택한 무기가 현재 선택된 무기와 동일하지 않다면, 선택 자원을 초기화하고, 무기 선택 처리 및 필요한 자원을 다시 선택하게 한다.
- Exit Button : 장착 상태 여부에 따라 선택 자원을 초기화 후 인벤토리 UI를 바로 받는다.

인벤토리 유저 인터페이스 클래스도

BP_Inventory : 인벤토리 UI의 핵심 클래스이며, 플레이어가 보유한 자원을 표시하고, 무기를 제작하거나 장착하는 기능을 담당한다.
BP_ResourceSlot : 자원 슬롯 UI 클래스이며, 개별 자원 정보를 표시하고 선택 시 BP_Inventory에 선택 정보를 전달한다.
BP_WeaponSlot : 무기 슬롯 UI 클래스이며, 제작 가능한 무기 정보를 표시하고 무기 선택 시 BP_Inventory에 선택 정보를 전달한다.

평가 기준

게임 시스템이 요구사항에 맞게 명확하게 구현되었는가?
사용자(플레이어)의 관점에서 기능 이용이 직관적이고 자연스러운가?
각 기능 및 시스템이 정상적으로 동작하며, 게임 진행에 문제가 없는가?
구현된 기능이 기획 의도에 부합하고, 게임 내에서 효과적으로 활용되는가?
다양한 상황 및 환경(멀티플레이, 전투, 자원 수집 등)에서도 안정성과 일관성이 유지되는가?
수집된 데이터가 게임 밸런스 조정이나 플레이 분석에 활용 가능한 형태로 제공되는가?

평가 내용

Wi-Fi Direct를 이용해 별도의 로그인이나 서버 접속 없이 주변 사용자가 멀티플레이에 참여할 수 있는가?
플레이어가 게임 방을 생성하고, 주변 사용자가 해당 방에 정상적으로 접속 및 참가할 수 있는가?
게임 시작 시, 맵과 자원이 절차적으로 랜덤 생성되어 새로운 플레이 환경이 제공되는가?
플레이어가 맵 내 자원을 채집하고, 자원 획득 시 정상적으로 인벤토리에 추가되는가?
플레이어가 수집한 자원을 이용해 무기를 제작할 수 있으며, 조합된 자원에 따라 무기의 성능이 변화하는가?
플레이어가 다른 플레이어와 전투를 수행할 수 있으며, 공격, 피격, 사망 등의 전투 로직이 정상적으로 동작하는가?
플레이가 진행되는 동안 라운드 시스템이 정상적으로 동작하며, 승리 및 패배 조건 충족 시 게임 결과가 처리되는가?
플레이어의 상태 정보(HP, 무기 상태 등)가 HUD를 통해 정상적으로 표시되는가?
게임 플레이 로그 수집 및 자원/무기 관련 밸런스 데이터 확인이 가능하며, 이를 통해 게임 내 데이터 분석이 가능한가?

결과 및 평가

완료 작품의 소개

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

가. 프로토타입 사진
MainMenu Level

IP 주소로 직접 플레이 팝업

우측 상단 도움말 버튼 팝업

Lobby Level

닉네임 변경 버튼 팝업

Wifi Direct Discover Level

절차적 맵 생성

플레이어 모바일 조작

자원 채집 1단계, 2단계, 3단계 - 돌

스코어 보드 UI

인벤토리 UI

킬로그 UI

게임 상태 표시 UI - 전투 시작

게임 상태 표시 UI - Round 승리

게임 상태 표시 UI - Game 패배/승리

플레이어 무기 - 칼, 라이플, 샷건

보급 시스템 - 보급의 위치를 나타내는 UI (현재 상태로는 우하단 보물상자)

보급 시스템 - 보물 상자, 로켓런처 획득

장애물 반투명화

자기장

부쉬 은신

무기 재료별 VFX 효과 - 나무, 돌, 철, 우라늄

트레일러 및 설치 방법

◇ itch.io
https://ripepixel.itch.io/shootingstar

위 링크 접속 후, Download Now 버튼 클릭, zip 파일 다운로드 후 실행.

완료작품의 평가

평가 항목	평가방법	적용기준	개발 목표치	비중 (%)	평가결과
1. 로컬 멀티플레이어 연결	애플리케이션 시연	Wi-Fi Direct 연결 성공 여부	완전 구현	10%	구현 완료
2. 절차적 맵 생성	애플리케이션 시연	맵 생성 성공 여부	완전 구현	10%	구현 완료
3. 자원 채집 기능	애플리케이션 시연	자원 수집 성공 여부	완전 구현	10%	구현 완료
4. 무기 제작 시스템	애플리케이션 시연	제작에 따른 무기 생성 여부	완전 구현	10%	구현 완료
5. 무기 성능 다양화	애플리케이션 시연	무기별 성능 차이 구현 여부	완전 구현	10%	구현 완료
6. 유저간 상호작용	애플리케이션 시연	유저간 충돌 및 상호작용 구현 여부	완전 구현	10%	구현 완료
7. 플레이어간 전투 시스템 구현	애플리케이션 시연	타격 동작 여부 및 사망 로직 구현 여부	완전 구현	10%	구현 완료
8. 라운드 및 승리 조건 처리	애플리케이션 시연	라운드 종료 및 승리팀 판단 여부	완전 구현	10%	구현 완료
9. UI/UX 구성	애플리케이션 시연	아이템창, 자원 현황 여부	완전 구현	10%	구현 완료
10. 팀 플레이 및 밸런스 조정	애플리케이션 시연	내부 시뮬에 의한 승률 분석	완전 구현	10%	구현 완료

향후계획

가. 어려웠던 내용들
◇ Wi-Fi Direct 기반 멀티플레이 연결 시 기기 간 호환성 문제로 안정적인 세션 유지
◇ 절차적 맵 생성 알고리즘에서 맵의 연결성과 균형을 동시에 확보하는 데 시간 소요
◇ 전투 시스템에서 공격 판정과 피격 판정 간의 동기화 오류 발생 및 반복 디버깅
◇ 다양한 해상도/화면비율을 지원하는 UI 배치 및 스케일 조정
◇ 자원 수집 → 무기 제작 → 전투 흐름을 자연스럽게 연결하는 UX 구성에 반복적인 수정
◇ 테스트 단계에서 예상치 못한 버그가 다수 발견되어 디버깅 및 코드 리팩터링에 어려움을 겪음

나. 차후 구현할 내용
◇ 싱글플레이 전용 PvE 콘텐츠 강화

   → 혼자서도 충분히 몰입 가능한 웨이브 방어 모드, 보스 사냥 모드 등을 설계
   → 플레이어 실력을 기반으로 적 난이도 자동 조절 (Dynamic Difficulty Adjustment)

◇ 로컬 멀티플레이 전용 PvE 협동 모드 추가

   → Vampire Survivors 스타일의 쏟아지는 적을 함께 막는 생존형 모드 구현
   → 무기 시너지 조합 및 역할 분담 (ex. 범위 공격 / 회복 / 방어 등) 도입

◇ 게임 모드 확장: 아케이드/스토리/챌린지 모드 분기 구현

   → 기본 루프 외에 짧고 명확한 목표가 있는 미션 기반 싱글/멀티 모드 도입
   → 적 AI와 환경이 유기적으로 변화하는 미션형 구조

참고문헌 및 참고사이트

한국콘텐츠진흥원 2024 게임 이용자 실태

https://www.kocca.kr/kocca/bbs/view/B0000147/2007554.do?menuNo=204153

[HOW TO 마케팅] 모바일 게임 비즈니스, 핵심은 ‘광고 수익 다각화’, 디지털 인사이트,

https://ditoday.com/how-to-%EB%A7%88%EC%BC%80%ED%8C%85-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EA%B2%8C%EC%9E%84-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%ED%95%B5%EC%8B%AC%EC%9D%80-%EA%B4%91%EA%B3%A0-%EC%88%98%EC%9D%B5/

Unreal Engine Documenation,

https://dev.epicgames.com/documentation/en-us/unreal-engine/using-ad-mob-for-in-game-ads-on-android-with-unreal-engine

https://docs.unrealengine.com/en-US/ProgrammingAndScripting/GameFramework/index.html 

https://docs.unrealengine.com/en-US/InteractiveExperiences/Networking/index.html

Appodeal’s internal eCPM performance data from January 2020,

https://wafour.tistory.com/entry/%EB%AA%A8%EB%B0%94%EC%9D%BC-%EA%B4%91%EA%B3%A0-%ED%98%95%ED%83%9C%EC%97%90-%EB%94%B0%EB%A5%B8-%EA%B5%AD%EA%B0%80%EB%B3%84-%ED%8F%89%EA%B7%A0-eCPM

오퍼월에 대한 4가지 오해와 진실, Unity Blog,

https://unity.com/kr/blog/4-offerwall-myths-debunked

Android Developers – Wi-Fi Direct (P2P) Overview

https://developer.android.com/guide/topics/connectivity/wifip2p

구분	항목 (품명, 규격)	수량	단가	금액(단위: 천원)		비고
구분	항목 (품명, 규격)	수량	단가	계	현금	비고
직접개발비	Location 2 Western - Low Poly 3D Models Pack	1	14.5	14.5	14.5
	Toon Soldiers	1	40.3	40.3	40.3
	Lowpoly Mine Assets	1	96.9	96.9	96.9
	C++ 소프트웨어 디자인	1	28.8	28.8	28.8
	Effective Modern C++	2	25.2	50.4	50.4
	게임 서버 프로그래밍 교과서	1	31.5	31.5	31.5
	게임 프로그래밍 패턴	2	31.5	63.0	63.0
	아무도 알려주지 않은 C++ 코딩의 기술	2	27.0	54.0	54.0
	언리얼 엔진 5로 개발하는 멀티플레이어 게임	1	38.0	38.0	38.0
	유니티로 배우는 AI 프로그래밍 콕북 2/e	1	29.7	29.7	29.7
	이득우의 언리얼 C++ 게임 개발의 정석	2	47.0	94.0	94.0
	합계			541.1