SeoHwiDo

9월 21~27일에는 길드본부의 모집 화면에 모험가 후보 생성·특성 표시·고용 요청을 연결하고, 같은 날 후보를 다시 뽑는 기능을 추가했다. 기능이 늘면서 여러 클래스에 흩어져 있던 화면 생성과 입력 전환도 UIManager로 모았다.진행 내용모험가 후보와 고용 흐름모집 화면을 먼저 후보 카드, 선택한 후보의 상세 영역, 이름 입력, 직업 선택으로 나눴다. 현재 화면에는 후보 3칸이 표시되며 카드에서 HP·MP와 특성 칩을 확인할 수 있다. 후보를 선택하면 이름과 직업을 정해 고용 요청을 보낸다.화면이 고용 가능 여부와 명단 변경을 직접 결정하지 않도록 했다. 모집 페이지는 후보 ID·이름·직업을 전달하고, AdventurerManager가 후보 존재 여부와 직업 선택을 검사한다. 성공하면 후보 목록에서..

상호작용 HUD 구현기존 고민 방식→컨트롤러에 HUD를 달아두고 캐릭터 빙의시 이관하여 사용책임소재가 꼬이고 로직이 복잡해짐해결 방식→ GMBaseCharacter에 위젯컴포넌트와 HUD WBP를 할당해둠캐릭터마다 WBP가 생긴다는 단점이 있지만 한번에 생성되어있는 캐릭터의 수도 적고 WBP의 리소스 소모량도 크지 않아서 해결하고 다음 스텝으로 넘어감ZoomInOut에 따라서 HUD의 위치를 가변적으로 조절해서 캐릭터를 가리지 않도록 함if (FollowCamera){ // 최대확대→1, 최대축소→0 (범위는 컨트롤러에서 전달) const float Alpha = FMath::Clamp((MinZoom - FollowCamera->OrthoWidth) / (MinZoom - MaxZoom),0.0f..

게임 기획최초 구상한 게임은 다키스트던전의 시스템을 차용한 모험가 길드 경영 게임이였다.그러나 최근 명일방주:엔드필드라는 게임을 즐기면서 전투에서는 최근 서브컬처 오픈월드게임의 방식을 차용하면 재밌을것 같아서 전투 방식을 변경했다.최종 게임기획은 다음과 같다. GuildMaster는 중세 판타지 기반의 길드 경영과 실시간 파티 전투를 결합한 RPG다.플레이어는 길드 마스터가 되어 모험가를 고용하고 직업·장비·치료 상태를 관리한다.마을의 시설과 자원을 운영하고 최대 4명의 파티를 의뢰와 몬스터 토벌에 파견한다.전투에서는 모험가들을 직접 조작하며 숫자키로 조작 대상을 전환하고, 나머지 동료는 자율적으로 행동한다.전투 보상을 길드와 마을의 성장에 다시 투자하는 반복 구조가 현재 핵심 플레이 범위다. 진행 내용..

Unreal Engine 프로젝트에서 Codex를 사용하면 C++ 코드를 작성하는 것뿐만 아니라, Unreal Editor 안의 Actor나 에셋을 조사하고 자동화 테스트를 실행하는 작업까지 맡길 수 있다.이를 위해서는 성격이 다른 두 개의 MCP 서버를 연결해야 한다.Rider MCP Server: 코드 분석, 심볼 검색, 빌드와 실행 담당Unreal MCP Server: Unreal Editor, Actor, 에셋과 자동화 테스트 담당여기에 Rider와 Unreal Editor를 직접 연결하는 UnrealLink/RiderLink가 추가된다.이름이 비슷해 혼동하기 쉽지만, RiderLink와 Rider MCP는 서로 다른 기술이다.전체 연결 구조전체 구조를 단순화하면 다음과 같다. ..

지난 5회차까지는 전투 매니저와 오브젝트 풀링, 카메라, UI, 보상 상자처럼 던전 플레이를 구성하는 개별 시스템을 구현했다.이번 개발에서는 이 시스템들을 실제 게임의 시작부터 종료까지 이어지는 하나의 플레이 흐름으로 확장했다. 타이틀·마을·던전·결과 화면을 분리하고, 스켈레톤 보스의 전투 패턴과 사망 연출을 구현했다. 이와 함께 게임 데이터를 JSON으로 통합하고 오디오·로그·디버그 기능을 보강하여 반복 테스트가 가능한 구조를 만드는 데 집중했다.1. SceneManager를 이용한 게임 흐름 분리기존에는 main.cpp가 게임 초기화부터 업데이트, 렌더링까지 대부분의 흐름을 직접 처리하고 있었다. 기능이 늘어나면서 타이틀 화면과 던전 로직이 같은 실행 흐름에 섞였고, 장면을 다시 진입할 때 이전 객체..

Arrow a Row의 핵심 흐름을 참고하되, 게임 규칙과 플레이 흐름만 재해석해 만든 Windows용 개인 프로젝트입니다. 원작의 코드·리소스·문구는 사용하지 않았으며, Unreal Engine 5.7.4의 Blueprint만으로 이동, 타일 재활용, 적·투사체 오브젝트 풀링, 전투, 강화, HUD와 메뉴 흐름을 구성했습니다.프로젝트 한눈에 보기https://git.seohwido.site/shd/Runner_Demo.git Runner_DemoConfig [mod]프로젝타일 속도 미적용 버그 수정 2026-09-02 10:21:37 +09:00 Content [mod]프로젝타일 속도 미적용 버그 수정 2026-09-02 10:21:37 +09:00 Docs [del]미사용 에셋 제거 2026-09-0..

이번 5회차 개발에서는 이전 단계에서 개별적으로 구축한 물리 연산, 객체 풀링, 전투 매니저들을 통합하는 메인 게임 루프를 구성했다. 또한 플레이어의 시각을 담당하는 카메라 제어 시스템, 해상도 번짐 현상을 해결한 UI 시스템, 그리고 방 클리어 이후의 보상 상호작용 로직을 신규 구현했다.1. 단일 게임 루프 통합 및 파이프라인 동기화 (main.cpp)설계 의도: 다수의 매니저 클래스가 동시에 동작하면서 발생할 수 있는 물리 연산 간섭과 프레임 지연 이슈를 방지하기 위해, main.cpp 내부의 실행 흐름을 엄격하게 통제했다.방 전환과 같은 화면 이동이 발생할 경우 기존 방의 몬스터와 투사체를 즉시 풀링 매니저에 회수시키며, 모든 물리 보정이 완료된 최종 좌표를 기준으로 카메라와 UI를 렌더링하도록 실..

이번 4회차 개발에서는 매니저 클래스의 과도한 책임을 분리하고, 전투 판정과 객체 생명주기 관리를 독립적인 모듈로 재구성했다. 핵심 로직인 CombatManager와 ObjectPoolingManager를 중심으로 전체 프레임의 흐름과 세부 설계 의도를 정리한다.1. 프레임 전체 처리 순서도 (Game Frame Flowchart)1프레임 동안 실행되는 게임 전체의 업데이트 및 렌더링 파이프라인 흐름이다. 각 모듈은 자신에게 할당된 단일 책임만을 수행하며 다음 단계로 연산을 넘긴다.2. 전투 판정 및 객체 처리 순서도 (Combat & Object Flowchart)CombatManager가 ObjectPoolingManager와 연동하여 근접 및 원거리 공격, 투사체 충돌을 처리하는 세부 순서도이다.3..

오늘 한 일 (Today I Learned)오늘은 액터(Actor), 몬스터, 타일맵, 충돌, 장비 등 게임의 핵심 요소들을 전반적으로 정리하고 서로 연동하는 대규모 업데이트를 진행했다.특히, 기존에 덩치가 커지고 복잡해진 MapManager, MonsterManager와 관련 실행 코드들을 과감히 덜어내고, 핵심 로직들의 작동을 명확하게 검증하기 위해 NewMapManager 브랜치에서 구조를 단순화한 테스트 환경을 재구축했다. 이를 통해 타일맵 물리 충돌과 몬스터 AI, 장비 조준 시스템이 완벽하게 맞물려 돌아가는 것을 확인했다.핵심 개발 내용1. 정점 배열(VertexArray) 기반 타일맵과 Collision 분리맵의 렌더링 최적화와 물리 충돌 처리를 위해 타일맵 시스템을 새롭게 설계했다.타일맵(..

2026.08.04 - [SFML] - [SFML/C++] 던그리드 모작 개발 (1) - 클래스 아키텍처 설계 및 텍스처 아틀라스 리소스 매니저 구현 [SFML/C++] 던그리드 모작 개발 (1) - 클래스 아키텍처 설계 및 텍스처 아틀라스 리소스 매니저 구현Git: https://github.com/SeoHwiDo/Dungreed_SFML.git GitHub - SeoHwiDo/Dungreed_SFML: sfml을 활용한 던그리드 게임 모작sfml을 활용한 던그리드 게임 모작. Contribute to SeoHwiDo/Dungreed_SFML development by creating an account on GitHub.baeksa01.tistory.comhttps://github.com/SeoHwi..