20.07.26 개발일지

조금 조급해져 주말에 개발하려다가 지원을 고민하는 회사에 지원하기로 마음 먹어 야밤에 글을 씁니다.

 

Trap과 Puzzle의 관계에 대해서 고민을 해보았습니다.

 

제가 개발하는 게임 내에서

Trap이란 유저의 진행을 방해하는 모든 장치들을 지칭합니다.

단순히 텔레포트, 총알 발사, 몬스터 소환, 방해물 설치서부터 시작해 여러 장치들이 복잡하게 발동되기도 합니다.

 

Puzzle이란 유저의 행동으로 해제가 가능한 모든 장치들을 지칭합니다.

Puzzle은 대체로 Trap을 동반하지만, 단순한 입력도 게임 내에서는 Puzzle로 취급됩니다.

 

Trap은 여러 Trap이 복합적으로 발동되더라도 기본적으로 각각의 Trap의 발동 조건이 변하지 않습니다.

하지만 Puzzle이 지니고 있는 Trap은 발동 조건이 바뀔 수도 있습니다.

예를 들어, 범위 안에 플레이어가 존재해야 발동하는 Trap의 경우,
Puzzle에 붙으면 그 범위가 Puzzle의 범위에서 발동해야 할 수도 있습니다.

이전 구조에서도 이 문제를 고민하면서 변경을 꾀했는데 현재 이에 대해 두가지 방안을 고민 중입니다.

 

1. 이 문제는 모든 Trap과 Puzzle의 SuperClass인 THActorBase가 태생적으로 Area를 지니고 있기 때문이다.

그러니 Puzzle에서 Trap들의 Area를 자신의 Area와 동일하게 지정하여
동일한 이벤트가 발생하는 대상을 Trap의 Area에서 Puzzle의 Area로 바꾸어 보려 합니다. 

이 방법의 가장 큰 장점은 나중에 기획을 하면서

Multiple Trap에서 Trap의 발동 범위가 바뀌는 경우에도 문제 없이 적용이 가능하다는 점입니다.

단점? 아니 문제점은 정상적으로 작동할지 아직 모릅니다.

 

2. Puzzle이 가지고 있는 Trap의 이벤트 함수를 모두 지운 뒤, 자체적으로 생성해서 다시 배정하는 방식입니다.

이는 구조 변경 전에도 동일하게 적용될 수 있는 방법이라 1번 방안에 비해 비교적 적절치 못하다고 생각합니다.

 

Trap과 Puzzle의 관계를 배정하면서 몇가지 추가되어야 하는 Interface가 있습니다.

첫번째로, FSM을 관리하는 Interface가 필요합니다.

여러 Trap들이 발동 할 때, 순차적으로 발동한다는 보장이 없습니다.

지름길이 있을 수도 있고, 실패 시 다른 Sequence로 움직여야 할 수 있습니다.

그리고 이러한 흐름을 관리하려면 FSM이 필요할 것이라 봅니다.

더불어서 FSM을 효과적으로 표현할 수 있는 자료구조 방식도 구상해야 합니다.

 

두번째로, CheckAnswer Interface를 다시 되살려야 합니다.

Puzzle의 복합적인 작동을 고려하다 보니 Check Answer 과정도 유일하다고 볼 수 없습니다.

때문에 Check Answer를 하는 Object를 종류별로 제작하고, Puzzle이 상황에 맞게 1개 이상 소유하도록 하려 합니다.

 

우선은 각 Interface들을 제작하고, Trap에 적용을 한 뒤 Trap과 Puzzle을 더 기획하려 합니다.

가능하면 Check Answer Object을 3가지 정도 만들고, Trap과 조합하여 여러 종류의 Puzzle을 생성해보려 합니다.