728x90
반응형

테일즈 오브 어라이즈 Beyond the Dawn Edition (Nintendo Switch 2) 리뷰

드디어 스위치2로 발매된 테일즈 오브 어라이즈

필자는 PS5용으로 플래티넘까지 획득 할 정도로 워낙 재미있게 플레이했던 작품이라
이번 Nintendo Switch 2용 테일즈 오브 어라이즈도 바로 구매하게 되었다.

결론부터 이야기하자면,
이식 자체는 생각보다 괜찮은 편이다.
다만 역시 가장 아쉬운 부분은 로딩 속도였다.

 

🎮 생각보다 괜찮은 스위치2 이식

기본적인 그래픽 퀄리티나 프레임 유지 자체는 무난한 편이다.
텍스처 품질도 휴대기 기준으로는 상당히 잘 유지되었고,
전투 연출이나 스킬 이펙트도 큰 다운그레이드 느낌은 적었다.

특히 우려했던 텍스처 스트리밍 문제는
FF7 리버스 스위치2 버전과 비교하면 훨씬 안정적인 편이다.

 

더보기

❌ 하지만 역시 가장 큰 문제는 로딩

사실 이 부분은 원작 발매 당시부터 이야기가 많았다.

테일즈 오브 어라이즈는
PS4 / PS5 양기종으로 동시에 발매되었는데,
당시에도 플랫폼에 따라 로딩 체감 차이가 상당히 컸던 작품이다.

특히 이 게임은 반복 전투 비중이 높은 RPG라
맵 이동과 전투 진입이 계속 반복된다.

PS5에서는 NVMe SSD 성능을 적극 활용해서
거의 로딩이 느껴지지 않을 정도였지만,
스위치2에서는 아무래도 체감 차이가 꽤 크게 느껴진다.

 

💾 Micro Express 메모리 채택에도 한계는 있었다

닌텐도도 스위치2에서
속도 개선을 위해 Micro Express 메모리를 채택했지만,
아직은 PS5급 SSD 체급과 비교하기엔 많이 부족해 보인다.

그래도 다행인 점은
텍스처 로딩 자체가 심각하게 깨지거나
오브젝트가 늦게 나타나는 수준은 아니라는 점이다.

반응형

🛠 PS5 버그까지 그대로 이식된 부분은 아쉬움

흥미로운 점은
PS5판에서도 있었던 버그가 그대로 남아 있다는 것이다.

대표적으로 장비 화면에서
무기 텍스처가 늦게 출력되는 현상인데,
스위치2 버전에서도 동일하게 확인된다.

단순 성능 문제가 아니라
엔진 구조 자체 문제에 가까운 느낌이다.

 


 

📌 개인적으로 가장 아쉬웠던 부분

의외로 프레임보다 로딩이 더 아쉬웠다.

  • 본 게임 30FPS
  • 이벤트 60FPS

이 구성 자체는 크게 불만이 없었다.
하지만 반복 플레이 구조상
로딩 체감은 계속 신경 쓰일 수밖에 없다.

조금이라도 로딩을 줄이고 싶다면
가능하면 본체 메모리에 설치해서 플레이하는 것을 추천한다.

 


❌ DLC 구성도 아쉬움

가장 실망했던 부분 중 하나는
늦게 발매된 이식판임에도
모든 DLC가 포함되지 않았다는 점이다.

게다가 기존 플레이 유저들을 위한
초반 그레이드샵 개방 같은 요소도 제공되지 않았다.

뒤늦게 발매된 완전판 성격의 이식이라면,
기존 유저와 신규 유저 모두에게
조금 더 편의성과 혜택을 제공했어야 하지 않았나 하는 아쉬움이 남는다.

 


🏆 PS5판 플래티넘 트로피까지 달성했던 작품

개인적으로 이 작품은 단순 클리어 정도가 아니라
PS5판에서 플래티넘 트로피까지 획득했을 정도로 인상 깊게 플레이했던 RPG다.

당시에도 전투 시스템과 연출, 캐릭터 구성은 상당히 만족스러웠고
특히 후반부까지 몰입감 있게 즐겼던 기억이 남아있다.

그래서 이번 스위치2 이식판도 기대를 가지고 구매했는데,
휴대용으로 다시 플레이할 수 있다는 점 자체는 충분히 만족스럽다.

다만 이미 PS5판을 경험했던 입장에서는
아무래도 SSD 기반 로딩 차이가 크게 체감될 수밖에 없었다.


⭐ 점수 (주관적)

  • 그래픽 이식 완성도: ⭐⭐⭐⭐⭐⭐⭐☆☆☆ (7 / 10)
  • 휴대성·접근성: ⭐⭐⭐⭐⭐⭐⭐⭐☆☆ (8 / 10)
  • 로딩 최적화: ⭐⭐⭐⭐☆☆☆☆☆☆ (4 / 10)
  • 추가 구성·DLC 구성: ⭐⭐⭐☆☆☆☆☆☆☆ (3 / 10)

총점: ⭐⭐⭐⭐⭐⭐☆☆☆☆ (6 / 10)

 


🧾 총평

스위치2로 어디서든
테일즈 오브 어라이즈를 즐길 수 있다는 점은 상당히 매력적이다.

다만 이 작품은 원래부터
고속 SSD 환경에서 강점을 보였던 게임인 만큼,
로딩 체감 차이는 생각보다 크게 느껴진다.

그래도 휴대성과 안정적인 이식 자체는 나쁘지 않은 편이며,
테일즈 팬이라면 충분히 소장 가치는 있는 버전이라고 생각한다.

반응형
Posted by siguma
,
728x90
반응형

이번에는 Yagudo Avatar와 Kirin의 Astral Flow 구조를 다시 정리하는 작업을 진행했다.

처음에는 Yagudos_Avatar 쪽이 제대로 동작하지 않는다고 판단해서 DB와 Lua를 이것저것 크게 건드렸는데, 결론적으로는 공용 구조를 잘못 이해한 상태에서 괜히 삽질한 부분이 많았다.

특히 가장 크게 헷갈렸던 부분은 이 구조였다.

  • Yagudo_Avatar = 본체 NM
  • Yagudos_Avatar = Astral Flow 전용 임시 소환수
  • Tzee_Xicu_the_Manifest = 소환사 타입 HNM 본체
  • Kirins_Avatar = Kirin의 AF 전용 아바타

처음에는 각 소환수마다 개별 skill_list를 만들어야 하는 줄 알고, Yagudos_Avatar에 별도의 30004 skill_list를 만들어서 아바타 필살기를 직접 등록하는 방향으로 테스트를 진행했다.

하지만 실제 LSB 구조를 다시 추적해보니 핵심은 DB가 아니라 공용 Lua mixin 구조였다.

실제 동작 흐름은 다음과 같았다.

mob:useMobAbility(734) -- Astral Flow

scripts/actions/mobskills/astral_flow.lua

mob:getID() + ASTRAL_PET_OFFSET

scripts/mixins/families/avatar.lua

즉, 아바타 모델 선택과 필살기 사용은 이미 공용 avatar mixin 안에서 처리되고 있었다.

결국 내가 만들었던 30004 skill_list는 필요 없는 테스트 데이터였고, 실제 적용도 되지 않는 상태였다.

확인 결과 원래 정상 DB 구조는 다음과 같았다.

Yagudo_Avatar      skill_list_id = 270
Yagudos_Avatar     skill_list_id = 34
Tzee_Xicu          skill_list_id = 360
Kirins_Avatar      skill_list_id = 34

특히 이번 작업에서 가장 허탈했던 부분은 Kirin이었다.

기린은 IDs.lua에 별도 pet ID 상수를 추가하지 않았는데도 Astral Flow가 정상 동작하고 있었는데, 이유는 단순했다.

mob:setMobMod(xi.mobMod.ASTRAL_PET_OFFSET, 5)

이 한 줄로:

Kirin 본체 + 5 = Kirins_Avatar

를 직접 계산하고 있었기 때문이다.

즉, 애초에 IDs.lua에 추가할 필요도 없는 구조였다.

결국 이번 작업의 결론은 이렇다.

  • 괜히 DB를 크게 건드릴 필요가 없었다.
  • 공용 families/avatar.lua 구조를 제대로 이해하는 게 우선이었다.
  • LSB는 이미 공용 구조를 만들어놨는데, 문제는 그 구조를 이해하기 어렵다는 점이다.
  • 특히 Astral Flow 관련은 DB보다 Lua 흐름 추적이 훨씬 중요했다.

솔직히 이번 작업은 결과보다도 “왜 이렇게 만들어놨는지 이해하는 시간”이 훨씬 오래 걸렸다.

공용 파일로 처리할 거였으면 최소한 구조라도 좀 더 명확했으면 좋았을 텐데, 결국 하루 종일 로그 찍고 DB 확인하고 테스트만 반복했다.

 

확인된 것:
- DB 30004 방식은 불필요했다.
- Yagudo_Avatar / Yagudos_Avatar / Tzee DB는 정상화했다.
- Kirin처럼 공용 avatar mixin 구조로 AF 자체는 동작한다.
- 문제는 “Yagudos_Avatar만 트러스트까지 데미지가 안 들어가는 원인”은 끝내 확정 못했다.

보류:
- avatar mixin / mobskill AoE / trust 대상 판정 차이
반응형
Posted by siguma
,
728x90
반응형

어느덧 FF11 LSB 개발을 시작한지도 4개월째에 접어들고 있다.

처음에는 단순히 “조금만 손보면 되겠지”라는 생각으로 시작했지만, 막상 작업을 이어가다 보니 손봐야 할 부분이 정말 많았다. 그동안 NM, HNM, 헌트 시스템, 타이머, 팝 조건, 전투 기믹 등 여러 부분을 수정하고 구현해왔다.

오늘은 그중에서도 Yagudo AvatarTzee Xicu the Manifest에 대해 이야기해볼까 한다.

 

LSB에서 NM/HNM 기믹은 직접 구현해야 하는 경우가 많다

LSB는 기본적인 일반 몬스터의 전투 로직이나 공용 시스템은 꽤 잘 갖춰져 있다.
하지만 NM이나 HNM처럼 리테일에서 특수한 조건과 연출, 전용 행동 패턴을 가진 몬스터들은 미완성으로 남아 있는 경우가 많다.

특히 75레벨 시대의 NM/HNM들은 단순히 강한 몬스터가 아니라, 각각 고유한 전투 흐름과 기믹을 가지고 있다. 이런 부분은 서버 관리자가 직접 Lua 스크립트와 DB를 확인하면서 구현해야 한다.

이번에 작업한 Yagudo AvatarTzee Xicu the Manifest도 그런 케이스였다.

 

단순한 소환사처럼 보이지만, 실제로는 다르다

겉으로 보면 두 몬스터는 단순한 야그도 소환사 계열처럼 보인다.
하지만 일반 소환사 몬스터와 다른 중요한 특징이 있다.

바로 엘리멘탈 펫을 유지한 상태에서 Astral Flow를 사용한다는 점이다.

 

더보기

일반적인 소환사 몬스터라면 소환수를 데리고 있고, 특정 타이밍에 Astral Flow를 사용하는 식으로 생각하기 쉽다. 하지만 이 두 몬스터는 평상시에는 엘리멘탈을 유지하면서 전투하다가, HP가 일정 이하로 내려가면 Astral Flow를 사용하고, 그 순간 랜덤한 소환수 형태로 바뀐 아바타가 등장해 그에 맞는 필살기를 사용한다.

리테일 기준으로는 이런 흐름이다.

평상시: 엘리멘탈 펫 유지
HP 50% 이하: 본체가 Astral Flow 사용
AF 발동 시: 랜덤 소환수 등장
소환수 모델에 맞는 필살기 사용 
전투 후 소환수 정리

말로만 보면 단순하다.
하지만 실제 구현은 전혀 단순하지 않았다.

 

가장 중요했던 조건 — 본체 2H 모션 유지

처음부터 가장 중요하게 본 부분은 본체의 2H 모션이었다.

Astral Flow는 단순히 데미지를 주는 기술이 아니라, 소환사 계열 몬스터의 상징적인 필살기다. 그런데 본체가 Astral Flow 모션을 취하지 않고, 뒤에서 스크립트로만 소환수를 강제로 띄워 데미지를 주면 “필살기” 느낌이 전혀 나지 않는다.

그래서 최종적으로는 본체가 직접 mob:useMobAbility(734)를 사용하도록 했다.

LSB 기준으로 Astral Flow는 mobskill 734이며, 본체가 이 스킬을 사용해야 2H 모션이 나온다. 이 부분은 절대 포기할 수 없는 조건이었다.

 

엘리멘탈 펫과 AF 전용 아바타를 분리

두 몬스터는 평상시에는 엘리멘탈을 유지해야 한다.
그래서 기본 펫은 +1 위치의 엘리멘탈로 유지했다.

반면 Astral Flow 전용 아바타는 +2 위치를 사용하도록 구성했다.

 

Yagudo Avatar
+0 본체
+1 Yagudos_Elemental
+2 Yagudos_Avatar

Tzee Xicu the Manifest 
+0 본체
+1 Tzee_Xicu_Elemental
+2 Tzee_Xicu_Avatar_Pet

이 구조 덕분에 평상시 전투에서는 엘리멘탈을 유지하고, Astral Flow 시점에는 별도의 아바타를 불러오는 방식이 가능해졌다.

처음에는 일반 소환사 몬스터처럼 job_special mixin만으로 처리할 수 있지 않을까 생각했다. 하지만 엘리멘탈 펫을 유지한 상태에서 AF 전용 아바타를 정확히 제어해야 했기 때문에, 결국 본체 쪽에서 HP 조건을 직접 체크하고 734를 호출하는 방식으로 정리했다.

 

랜덤 소환수와 필살기 매칭

리테일에서는 Astral Flow 사용 시 랜덤한 소환수가 등장하고, 그 소환수에 맞는 필살기를 사용한다.

예를 들면 이런 식이다.

 

Carbuncle → Searing Light
Fenrir    → Howling Moon
Ifrit     → Inferno
Titan     → Earthen Fury
Leviathan → Tidal Wave
Garuda    → Aerial Blast
Shiva     → Diamond Dust
Ramuh     → Judgment Bolt

이 부분은 Yagudos_Avatar.lua 쪽에서 랜덤 테이블을 만들어 처리했다.

소환수 모델과 필살기가 서로 어긋나면 안 되기 때문에, 모델 ID와 스킬 ID를 한 쌍으로 묶어서 관리했다. 테스트 중에는 카벙클 모델이 다른 소환수의 필살기를 쓰는 상황도 있었고, 라무가 정상적으로 나왔지만 실제 사용 기술이 엉뚱하게 출력되는 경우도 있었다.

결국 모델과 필살기 매칭을 강제하는 방식으로 정리했다.

중복 사용 문제

또 하나 골치 아팠던 부분은 필살기가 두 번 나가는 문제였다.

처음에는 아바타가 필살기를 사용한 뒤 일정 시간 후에 AI를 끄는 방식으로 처리했다. 하지만 그 짧은 시간 동안 엔진 AI가 다시 한 번 같은 스킬을 사용하는 경우가 있었다.

그래서 최종적으로는 필살기 사용 직후 즉시 AI를 잠그는 방식으로 바꿨다.

 

필살기 사용
→ 즉시 mobAbility OFF
→ AutoAttack OFF
→ MagicCasting OFF
→ TP 0

이렇게 처리하니 중복 사용 문제는 해결됐다.

가장 큰 난관 — 데미지 처리와 전투 로그

이번 작업에서 가장 힘들었던 부분은 역시 Astral Flow의 데미지 처리와 전투 로그 문제였다.

처음에는 공용 Astral Flow 스킬만 제대로 호출하면 끝날 줄 알았다.


하지만 실제로는 주 대상에게는 정상적으로 필살기 모션과 데미지 로그가 나오더라도, 파티원이나 트러스트 쪽 데미지 판정이 원하는 방식으로 들어가지 않는 문제가 있었다.

그래서 Yagudos_Avatar.lua에서 Astral Flow 사용 전에 파티와 트러스트 목록을 미리 캡처하고, 주 대상 외 멤버에게는 별도로 보정 데미지를 넣는 구조로 정리했다.

 

 

useMobAbility 전에 partyMembers / primaryTargetId 캡처
→ 소환수 AF 모션은 useMobAbility로 유지
→ useMobAbility 직후 AI 즉시 잠금
→ 200ms 뒤 주 대상 외 파티/트러스트에게 보정 데미지 적용

 

이 과정에서 여러 테스트를 했다.
전투 로그에 트러스트 데미지를 표시하기 위해 messageBasic()도 테스트했지만, Lua 호출 자체는 성공해도 클라이언트 전투 로그에는 원하는 형태로 표시되지 않았다. 그래서 해당 코드는 남겨두되 현재는 사용하지 않는 방식으로 정리했다.

또 파티 전체를 적대 리스트에 넣는 방식도 시도했지만, 이 경우 공용 AF의 AoE 판정이 꼬이면서 0 데미지 로그가 먼저 뜨는 문제가 있었다. 결국 이 방식도 폐기했다.

 

최종적으로는 소환수 AF 모션은 유지하고, 불필요한 0 데미지 로그는 제거하며, 트러스트 데미지 판정은 실제 HP 감소로 처리하는 방식으로 마무리했다.

 

완벽하게 전투 로그까지 리테일처럼 출력되지는 않지만, 전투 흐름과 연출, 실제 피해 판정은 만족할 수 있는 수준까지 맞출 수 있었다.

Dagourmarche에서 얻은 힌트

 

이번 작업에서 큰 힌트를 준 것은 이전에 구현했던 Dagourmarche였다.

Dagourmarche도 Astral Flow와 아바타 연출을 사용하는 몬스터였기 때문에, 본체가 2H를 사용하고, 이후 아바타가 필살기를 사용하는 흐름을 참고할 수 있었다.

물론 구조가 완전히 같지는 않았다.
하지만 “본체 2H 모션을 유지하면서 아바타를 제어해야 한다”는 방향을 잡는 데 큰 도움이 됐다.

기존에 작업해둔 기믹이 다음 작업의 힌트가 되는 걸 보면, 서버 개발은 확실히 하나씩 쌓아가는 작업이라는 생각이 든다.

현재 마무리 상태

 

현재까지 정리된 상태는 다음과 같다.

 

Yagudo Avatar
- 엘리멘탈 유지
- HP 50% 이하 Astral Flow 사용
- 본체 2H 모션 유지
- 랜덤 아바타 등장
- 모델과 필살기 매칭
- 소환수 AF 모션 유지
- 중복 사용 방지
- 소환수 cleanup 처리
- 파티/트러스트 보정 데미지 적용
- 불필요한 0 데미지 로그 제거

Tzee Xicu the Manifest
- Yagudo Avatar와 동일한 구조로 정리
- 엘리멘탈 유지
- Astral Flow 전용 아바타 처리
- 사망 시 타이틀 지급 및 NextPop 갱신

아쉬운 점은 데미지 로그 처리다.

현재 상태에서 전투 흐름과 연출은 리테일에 상당히 가까워졌지만, 데미지 로그까지 완벽하게 맞추려면 전용 mobskill 액션 처리가 필요해 보인다. 이 부분은 나중에 여유가 생기면 다시 도전해볼 생각이다.

마무리

 

이번 작업은 정말 단순해 보였지만 생각보다 훨씬 까다로웠다.

처음에는 “엘리멘탈 유지하고, HP 50%에서 Astral Flow 쓰게 하면 끝 아니냐?” 정도로 생각했다. 하지만 실제로는 본체 2H 모션, 소환수 모델, 필살기 매칭, 중복 사용 방지, 데미지 대상 처리, 전투 로그, cleanup까지 모두 신경 써야 했다.

FF11의 NM/HNM 기믹은 겉으로는 단순해 보여도, 실제로는 꽤 섬세하게 짜여 있다는 걸 다시 느꼈다.

요즘은 FF11 서버 개발에 대부분의 시간을 쓰고 있어서 다른 게임은 거의 손을 대지 못하고 있다.
쌓여 있는 게임들도 플레이해야 하는데, 서버 작업을 하다 보면 하루가 금방 지나간다.

그래도 이런 기믹이 하나씩 구현될 때마다 서버가 조금씩 리테일에 가까워지는 느낌이 들어서, 힘들어도 계속 손을 대게 된다.

 

완벽한 전투 로그까지는 아직 과제로 남았지만,
Yagudo Avatar와 Tzee Xicu the Manifest의 핵심 Astral Flow 연출은 구현 완료.

드디어 Tzee Xicu the Manifest의 Astral Flow 연출이 정상적으로 확인된 장면. 엘리멘탈을 유지한 상태에서 Yagudo's Avatar가 등장해 Howling Moon을 사용했고, 테스트 캐릭터는 그대로 바닥행.

 

반응형

'파이날 판타지11 > LSB서버 개발일지' 카테고리의 다른 글

FF11 LSB 서버 개발기 #1  (0) 2026.03.07
Posted by siguma
,