✅ What I did today

• LD Challenge : L001 : Day 5

🎯 LD Challenge : L001 : Day 5

애초에 노드 기반 에디터를 사용하지 않아도 분기가 많이 나눠지면 엑셀같은 걸로만 맥락을 파악하는 것은 불가능. export해서 엑셀로도 순서를 편하게 보며 번역할 수 있게 만든다는게 환상. 에디터에서 모든 편집을 한다고 가정하는게 맞다.

리스트로 만들면 수정 및 편집이 불편함
인덱스를 고정시킨다면 빈번한 추가 및 삭제를 한다고 할 때 비어있는 메모리가 너무 많아질 것이고 (메모리 단편화)
인덱스를 가변적으로 정리한다면 노드를 삭제한다고 했을 때 유저가 갖고 있던 세이브 데이터 (노드 참조) 와의 충돌이 일어나서 이상한 곳으로 가버릴 수도 있고, 가변적으로 정리하는 로직을 만드는 것도 복잡함.
그래서 노드를 생성할 때 랜덤 해시값을 부여한 후에 그걸 키로 해서 딕셔너리에 넣기로 함.
딕셔너리는 내부적으로 메모리 단편화도 해결해주고, 참조 관계도 해결해줄 수 있기 때문.
자료 자체에 랜덤 키를 부여할 필요도 없다. 참조 관계는 딕셔너리가 알아서 해결해주니까, 마지막 인덱스만 갖고 있으면 된다. 메모리를 부여하는 것도 아니니까 단편화도 신경쓸 필요가 없다.
라고 생각했는데, int면 65535였나 그거 넘으면 터진다는게 뭔가 기분 나쁨. 이미 오버 엔지니어링이긴 하지만.
다행히 guid라는게 있었다. 중복이 거의 불가능한 경우의 수를 갖고 있다고 함.

선택지 자체를 노드로 만들면 일반적인 비쥬얼 노벨에서처럼 해당 선지를 골랐을 때 해당되는 대화로 넘어갈 수 있다. 이건 에디터가 아니라 노드를 해석하는 게임 로직 쪽에서 구현할 문제.
언더테일처럼 선택지가 아니라 특정 조건에 따라 분기가 나눠지면 scriptable object같은 곳에 저장해뒀던 세이브 데이터를 참조하여 조건을 설정하도록 하면 됨.
내 게임은 선택지가 3개 뿐이라 enum으로 조건 감지를 대충 떼울 수도 있겠지만, 개발 시간도 얼마 차이 나지 않고 간단해서 조건 확인 로직으로 유연하게 구현하기로 함. 혹시 나중에 또 쓸 수도 있으니까.

딕셔너리를 순회하면서 노드들을 전부 그린 뒤에 한 번 더 순회하여 화살표(참조 관계)를 그려야 함.