|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Tails, у меня к тебе вопрос по поводу используемой тобой реляционной модели. Вот смотри, я загоняю справочные данные в реляционные таблицы. Например, там могут быть профили каких-нибудь атак, как в примере, который ты приводил ранее в другой ветке. Так вот, этих самых атак может быть условно пяток видов по качеству (урон огнём, водой и т.п., в т.ч сочетания), при этом цифры по каждому виду имеют какой-то разброс. Таким образом, возможных уникальных комбинаций с ходу может за сотню зашкалить.
Каким образом ты создаёшь и систематизируешь идентификаторы подобных записей, чтобы потом ориентироваться в них и не сойти с ума?
__________________
Не сломано - не чини! |
|
|||||
Например так: (Сущности и их свойства)
Тип атаки: id. Атака: id, тип, damage, cooldown Юнит: id, name, attack1, attack2 // Заполняем таблички. // Типы атак: attackTypes.add(1); // Физическая. attackTypes.add(2); // Огненная. attackTypes.add(3); // Ледяная. // Атаки: attacks.add(1, 1, 100, 2); // Физическая атака, 100 урона, 2 сек кд. attacks.add(2, 1, 500, 10); // Физическая атака, 500 урона, 10 сек кд. attacks.add(3, 2, 2000, 100); // Огненная атака, 2000 урона, 100 сек кд. // Юниты: units.add(1, "Goblin", 1, 0); // Гоблин, может лупить физ уроном. units.add(2, "Mage", 3, 0); // Маг, может лупить фаерболами. units.add(3, "Paladin", 2, 3); // Паладин, может лупить сильным физ уроном и ещё параллельно кастовать фаерболы. units.add(4, "Rabbit", 0, 0); // Безобидный кролик. Примерно такая структура в игре Warcraft 3. У них один юнит может иметь не более 2 атак. Ещё, id типа атаки можно захардкодить, так-как он не будет меняться от проекта к проекту. Это очень удобно: Потом, в коде движка оперировать константами, а не волшебными числами, в формулах расчёта урона и т.п. Хороший пример, как некоторые данные зашиты в движок (ID Типа атаки). Движок просто берёт эту структуру и просчитывает её. Всё что ему нужно знать есть в табличках. Структуру данных ты можешь взять откуда угодно, захардкодить, загрузить с диска или из сети. Юниты другие, игра другая, а код тот-же.
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Угу, более-менее ясно. Скажи, пожалуйста, какого типа переменные attackTypes, attacks и units и что делает метод add()? Здесь интерфейс используется?
Мне представлялось, что классы-парсеры - это "статики". Добавлено через 4 часа 51 минуту ...да, и если взять твой блок кода с атаками, то там теоретические может быть та самая сотня записей. Как удержать в голове, что "1" - это физическая на 100, "3" - это магическая на 2000, а "103" - это холодом на 40? В этом собственно и был исходный вопрос.
__________________
Не сломано - не чини! |
|
||||||
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Добавлено через 1 час 29 минут пс. Обычно, каждый юнит имеет собственную, уникальную запись атаки. То есть, 2 юнита не могут ссылаться на одну и ту-же запись. Если запись атаки уникальная для каждого юнита: Отношение "1 к 1", можно редактировать атаку у каждого юнита отдельно. Если запись атаки может быть общей для многих юнитов: Отношение "1 к многим", редактируя одну запись, атака меняется у всех владельцев. Это вопрос к проектированию бд, что конкретно требуется. Я привел пример "1 к многим" чисто для понимания связывания данных.
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Прости мне моё занудство. Я на принципиальном уровне идею прекрасно понимаю (и имею опыт работы с реляционными СУБД как пользователь), но чего-то никак в голову не укладывается практическая реализация в создаваемой программе.
Цитата:
Я себе как представлял твой пример. Класс атаки примерно такой: public class Attack { private var _id: uint; private var _type: uint; private var _damage: int; private var _cooldown: uint; public function Attack (id: uint) { _id = id; var jsonData: Object = JsonAttackData.getData(_id); _type = jsonData[type]; _damage = jsonData[damage]; _cooldown = jsonData[cooldown]; } который получает в конструктор требуемый id, по нему ломится в класс-парсер, обслуживающий соответствующую json-таблицу, и получает от статического метода все остальные данные из таблицы. Цитата:
Цитата:
Цитата:
__________________
Не сломано - не чини! |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Tails, огромное спасибо, тронут твоей заботой. Пример разобрал, теперь всё встало на места. Поясни ряд мелких моментов, плиз:
Я верно понял, что объявление переменных в классах AttackData, AttackTypeData и UnitData публичными - это такой коммунистичный вариант реализации дата-класса, чтобы не запариваться с приватными переменными и комплектом сеттеров-геттеров? Меня смущает, что раз данные всё-таки из таблицы переписываются в поля класса для дальнейшего использования, нет риска, что они в процессе будут изменены и тем самым поломаны? Почему всё-таки не используешь приватные? Чтобы парсер передавал значения прямо в конструктор создаваемого дата-класса, а забирать геттерами? У тебя в момент запуска приложения все данные из json-таблиц читаются, парсятся и перегоняются в объекты-списки. Больше в рантайме исходные json-таблицы не используются, все классы Модели обращаются к классам-спискам, зная id нужных им вещей. Так? Формат json-таблицы тоже весьма нестандартный у тебя. Так как это не классическая 2-мерная таблица "ключ: значение", а наборы "ключ: массив значений". Чем ты создашь их? Только самописный редактор или есть какие-то варианты заполнять комфортно вручную и потом экспортировать в подобный формат? Я пока нашёл плагин для Гугл.докс, но он по-моему так не умеет Твой вариант 100% отлично подходит для хранения справочных данных. А что ты делаешь с данными, которые меняются в рантайме? Тоже их по подобным спискам распихиваешь? Добавлено через 2 минуты P.S. Забыл... Почему обжекты хэшами называют?
__________________
Не сломано - не чини! |
|
||||||
Цитата:
Цитата:
Цитата:
Цитата:
Например, если класс UnitData описывает юнит, то представление конкретного юнита в рантайме будет что-то вроде: Unit: id - ID Юнита. (Не путать с UnitData.id) unitID - ID Описания юнита. (Ссылка на UnitData) life - Текущее здоровье этого юнита. ... Например, если на карте будет 10 гоблинов, у нас будет 10 записей Unit: { id:1, unitID:2, life:55 } { id:2, unitID:2, life:45 } { id:3, unitID:2, life:100 } ... Цитата:
https://ru.wikipedia.org/wiki/%D0%A5...B8%D1%86%D0%B0
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
__________________
Не сломано - не чини! Последний раз редактировалось Appleman; 20.10.2018 в 17:21. |
|
|||||
UnitData.life - Максимальное здоровье этого типа юнита.
Unit.life - Текущее здоровье конкретного юнита. Это разные переменные. Можно написать UnitData.lifeMax, если это вводит в заблуждение. UnitData - Описывает класс юнитов. Unit - Описывает конкретного юнита. Конкретным юнитом может быть кто угодно, Маг, Гоблин и т.д., смотря на кого он ссылается через unitID. Цитата:
world.unitAdd() world.unitKill() world.buyUnit() Ну, я тут уже не знаю. Тут уже зависит от проекта, что кому и как нужно.
__________________
Дети не должны знать о своих родителях |
Часовой пояс GMT +4, время: 06:34. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|