Типы данных
Table of contents
Зачем нужны разные типы данных
- Валидация и верификация: Ввод разных типов данных позволяет добавить валидацию, которая проверит правильность вводимых значений. Это помогает обнаруживать и исправлять ошибки на ранних этапах, что особенно важно в процессе разработки и тестирования игр.
- Улучшение читаемости и управления данными: Типы данных помогают лучше организовать и визуализировать информацию. Например: удобнее считать глазами “04.07.2024, 22:00:00” (тип Дата и время (см.ниже), чем “1720112400” (те же дата и время, но по Unix - формат, который чаще всего используют в геймдеве).
Автоматическая колонка “id”
Эта колонка содержит уникальные идентификаторы строк данных, поэтому создается и заполняется автоматически при добавлении новых строк.
Значения этой колонки нельзя редактировать, так как от их неизменности зависит корректная работа типа Relation (см.ниже). Колонка id в экспорте представлена как keyName: “value”.
Auto
Свободный формат колонки. Удобен, когда вы делаете набросок таблицы, ещё полностью не решив, что и в каком виде будете заполнять.
В дальнейшей работе вы сможете заменить тип Auto на конкретный тип данных, если все значения ячеек соответствуют новому типу или все ячейки пусты.
Колонка Auto в экспорте представлена как keyName: “data”.
Number
Тип колонок для чисел. Можно вносить целые числа, значения с точкой, положительные и отрицательные числа, и конечно 0.
| Когда использовать | Значения характеристик персонажа, вероятности, количество предметов, цены (в таблице красивых цен), уровни, количество этапов |
| Когда лучше выбрать другой тип | Даты и время (есть отдельный тип); Если параметр характеризуется наличием или отсутствием, то вместо 0/1 можно использовать тип Switch. Когда в одной ячейке должно быть 2 и более чисел (в зависимости от кейса можно использовать Map или Virtual Table). |
Text
Основное предназначение - хранение игровых текстов, а также внутренних комментариев к данным, которые в игру не пойдут.
| Когда использовать | Игровые тексты (в таблице с локализациями); Внутренние комментарии к данным |
| Когда лучше выбрать другой тип | В остальных таблицах игровые тексты размещать с помощью типа Relation, с отсылкой на таблицу локализаций (см. кейс “Локализация”). Если неигровой текст можно представить в виде таблицы, JSON, пар “ключ-значение” - выберите соответствующий тип данных и следуйте правилам формата. |
JSON
Эта колонка предназначена для хранения данных в формате JSON. При её выборе, в ячейках базовый редактор заменится на специальный, в котором удобно как составить JSON, так и проверить его на корректность.
| Когда использовать | При работе со сложными данными |
| Когда лучше выбрать другой тип | Практически любой JSON можно заменить, скомбинировав типы Virtual table, Map и Relation. |
Колонка JSON в экспорте представлена как keyName: {json}.
Switch
Стандартное булево значение: true / false, да / нет, 0 / 1. Удобно применять для параметров, которые либо присутствуют, либо отсутствуют. Например, Switch можно использовать для тестовой разработки, чтобы отобразить, что строка должна быть доступна только в dev версии игры.
Колонка Switch в экспорте представлена как keyName: “true”/”false”.
Select & Set
Колонка с выпадающим списком вариантов. Удобно применять, если количество значений в ячейках ограничено и известно. Вы прописываете все варианты в настройках колонки и отмечаете возможность множественного выбора, если она нужна.
| Когда использовать | Список вариантов значений ячеек известен и его нужно ограничить. |
| Когда лучше выбрать другой тип | Если варианты ответа - это текст, который должен идти в игру, то лучше добавить их в таблицу локализаций и использовать Relation. Если варианты ответа - это данные, которые нужно будет переиспользовать в других местах, то лучше создать отдельную таблицу с этими данными и также использовать Relation. |
Колонка Select&Set в экспорте представлена как:
- keyName: [”value1”, “value2”….., “valueN”] - множественный выбор;
- keyName: [”value1”] - одиночный выбор.
Date & Time
По сути это тоже числовая колонка, но она визуализирована специально для хранения даты и времени. В таком виде данные будет легко воспринимать.
При создании колонки с этим типом:
- Выберите вариант отображения данных:
- время и дата
- только дата
- только время
- Выберите, по какому часовому поясу вам будет удобнее указывать время. Выбранный часовой пояс будет применен ко всем ячейкам колонки.
Relation
Колонка, непосредственно в которой нет данных, есть отсылка к данным из другой таблицы. Вы выбираете с какой таблицей установить связь, из какой колонки брать данные и как их отображать.
Благодаря такому типу вы будете видеть в таблицах не идентификаторы, а сами сущности (валюты, ивенты, персонажей, оферы и т.д.).
Подробнее узнать о применении Relation на практике можно в кейсах 1, 2, 3.
Колонка JSON в экспорте представлена как keyName: [”value1, value2, value3….].
Subtable
Subtable или виртуальная таблица - это вложенная в ячейку таблицы подтаблица. В виртуальной таблице реализован тот же функционал, что и в основной, поэтому в ней могут быть колонки разного типа, в том числе и ещё одна вложенная виртуальная таблица.
| Когда использовать | При работе со сложными данными |
| Когда лучше выбрать другой тип | Если содержимое виртуальной таблицы - это данные которые нужно будет переиспользовать в других местах, то лучше создать отдельную таблицу с этими данными и использовать Relation. |
Колонка Virtual table в экспорте представлена как keyName: [{}, {}].
Map
Колонка для данных формата ключ-значение. Ключи это строки, а типы значений могут быть любыми.
Колонка Map в экспорте представлена как {”key” : value}.
