치킨 날다

오늘은 크게 무언가를 하지는 않고 간단하게 구현만 조금 했습니다.

우선 어제 새벽에 작성한 내용들을 담을 수 있는 Interface를 새로 선언했습니다.

가능하면 함수 선언도 해두려고 했으나 기능 구현에 대해
포괄적으로 적용 할 수 있는 형태를 아직 확립하지 못해 몇몇 부분을 보류하고 있습니다.

그리고 일전에 선언 해두었던 InRangeCharacter와 IObjectActivity Interface를 ActorBase와 Character에 적용하였습니다.

아무래도 내용이 많다보니 이 부분이 의외로 시간을 꽤 잡아먹었습니다.

마지막으로 Melee Attack의 판정을 개선했습니다.

Notify 발생 위치를 조절하고,
왼손 오른손을 햇갈려 했던 것을 명확히 하여 수정한 결과 비교적 만족스럽게 작동하고 있습니다.

가능하면 FSM을 관리하는 Sequential Interface도 미리 선언해두고 싶으나, 시간이 오래 걸릴 것 같습니다.

저번처럼 밤에 생각이 나면 맞춰보겠지만, 우선은 후순위로 미뤄두려고 합니다.

일단은 CheckAnswer 부분을 구현을 해볼까 합니다.

현재 생각나는 것은 물건 부착, 피격, Widget에 텍스트 입력을 생각하고 있습니다.

그 다음에는 Climb 기능을 먼저 구현하고자 합니다.

Trap보다는 아무래도 이미 완성된 기능들이다 보니 Climb를 먼저 정리하는 편이 더 적절하다고 생각합니다.

하면서 생각이 뚫리면 장애물을 넘어가는 기능도 조심스래 건드려볼 계획입니다.

그 다음에 Trap을 구현하고, Puzzle을 제작해보려 합니다.

https://www.acmicpc.net/problem/3300

이전에 짰던 코드가 입력되는 String에 반복적인 알파뱃이 존재 할 때
Shift 과정에서 오류가 발생한다는 점을 깨달았습니다.

더 큰 문제는 추가적인 복잡한 구조나 대량의 메모리가 없이는 개선을 할 수 없다는 점이었습니다.

그래서 구조를 다시 짜보고 있습니다.

처음에는 struct를 이용한 Graph를 이용해보려 했습니다.

runtime 상에서 메모리를 잡는 거은 큰 부하가 걸리므로 Stack Object들로 관리를 하였습니다.

하지만 Graph라고 해도 Directed Graph라서 흐름을 역행하는 케이스를 검색하는 것에 문제가 발생하였습니다.

현재는 여기까지 개발을 한 상태입니다.

그리고 일지를 적다가 Graph를 Array로 표현하는 방법을 떠올렸습니다.

입력된 Machine에서 모든 State를 Vector에 순차적을로 담고,
각 State가 어떤 State로 갈 수 있는지 index 값을 Vector로 담고 있는 방식입니다.

여기서 문제가 될 수 있는 부분은 두가지입니다.

하나는 하향식이든 상향식이든 일대 다 관계가 발생할 수 있다는 점.

다른 하나는 State가 많아질수록 기하급수적으로 Graph 정보가 많아진다는 점입니다.

우선은 이 구현하던 것을 지우고 Array 식으로 변경해서 새로 구현을 해보려 합니다.

아무래도 Vector보다는 부하가 적을 것 같아서입니다.

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

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을 생성해보려 합니다.