시트에 적고,
런타임이 그대로 읽습니다
아이템·스테이지·밸런스는 코드보다 자주 바뀌고, 손이 더 많이 타고, 틀렸을 때 가장 늦게 드러납니다. Tabbit은 그 데이터를 기획자가 쓰는 자리에서 받아 검증하고, 파싱이 필요 없는 바이너리와 그것을 읽는 코드로 냅니다.
시트 한 장이 이렇게 됩니다
왼쪽은 기획자가 스프레드시트에 적는 그대로입니다. 특별한 도구도, 별도의 스키마 파일도 없습니 다. 오른쪽은 그것으로 만들어진 코드이고, 프로그래머는 이걸 받아 씁니다.
public string Name => _name; public int CategoryId => _categoryId; public ItemCategoryRecord ItemCategoryByCategoryId public Grade GradeField => _gradeField; await GameData.ReadAllAsync("./data"); var sword = GameData.Item.FindByIndex(1); sword.Name; // Short Sword sword.ItemCategoryByCategoryId.Name; // Weapon sword.GradeField; // Common
카테고리 이름을 아이템 시트에 다시 적지 않아도 됩니다. 타입 칸에 foreign ItemCategory라고만 적으면, 코드에서는 카테고리 자체가 따라옵니다. 카테고리 이름이 바뀌면 한 곳만 고치면 되고, 없는 카테고리를 가리키면 변환이 멈추고 어느 셀인지 알려줍니다.
왜 이걸 쓰나
데이터가 잘못됐다는 것을 게임을 띄우고 나서 알게 되면, 그때는 이미 재현 경로를 찾고 있습니다. 빌드하는 자리에서 걸러낼 수 있는 것은 최대한 걸러냅니다.
문제를 게임이 아니라 변환에서 만납니다
걸러낼 수 있는 실수는 걸러내고, 남은 것은 어느 셀인지 알려줍니다. 구글 시트라면 링크를 눌러 그 자리로 갑니다. 한 번에 모아서 보고하므로 고치고 다시 돌리기를 반복하지 않습니다.
시트로 표현할 수 없는 규칙까지
「전설 등급은 강화 재료가 있어야 한다」 같은 규칙을 C# 파일 하나로 적습니다. 검사는 무엇을 내보내기 전에 끝나므로, 규칙을 어긴 데이터는 게임에 도달하지 않습니다.
반쯤 바뀐 데이터가 나오지 않습니다
빌드가 중간에 실패해도 직전 결과가 그대로 남습니다. 새 데이터는 전부 준비된 다음에 한 번에 바뀌고, 게임이 읽는 쪽도 마찬가지입니다.
쓰던 시트를 그대로 가져옵니다
이 도구를 몰랐던 시트도 읽습니다. 이미 몇 년치가 쌓인 시트를 다시 쓰는 것은 현실적이지 않으니, 읽는 규칙을 시트마다 지정하고 새 것과 옛 것을 한 번에 변환합니다.
먼저 둘러보셔도 좋습니다
시트 한 장으로 시작해 코드가 나오는 데까지, 예제를 따라가며 읽을 수 있게 써 두었습니다. 쓰다가 막히는 자리에 대한 답도 대체로 그 안에 있습니다.
문서 읽기