|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Хранение справочных данных
Друзья, поделитесь, пожалуйста, опытом.
По мере продвижения в деле написания игры программа всё больше обрастает всякими "статичными" справочными данными: параметры предметов, игровых действий, статус-эффектов и ещё много чего. Возник вопрос, как хранить всё это безобразие. Пока у меня создан отдельный пакет collections, в котором я создаю классы-хранители, например AllItemProps. В нём созданы публичные константы типа Dictionary, по одному на каждое поле класса Item. В них записаны значения, ключами доступа к которым служат строковые ID предметов, т.е.: public class AllItemProps {public static const PRICES: Dictionary = new Dictionary; PRICES[ItemIDs.SMALL_HEALING_POTION] = 20; PRICES[ItemIDs.MED_HEALING_POTION] = 30;} для наследников, у которых есть поля, отсутствующие в супере, данный метод переопределяется и "выдёргивает" дополнительные записи из справочников. В принципе, всё работает, но есть ряд проблем, которые становятся тем заметнее, чем крупнее становится проект. Главная - это неудобство администрирования. Если нужно что-то подкорректировать, я вынужден лезть в эти классы, проматывать много строк текста и вводить вручную новые значения. И это я ещё не дошёл до балансировки! Наверное, свихнусь. В общем, вопросов два. Первый, где принято хранить подобные вещи? Считается, что им не место в коде. С другой - они не предназначены для внешней редактуры и должны оставаться "под капотом". Второй - как это правильнее делать? Возможно, кто-то покажет уже готовые наработки или поделится советом. Например, у меня сейчас приятель участвует в разработке некого приложения (не как программист), так ему разработчики сделали табличный документ в Гугле, где он вписывает текста в ячейки, из которых приложение их вытаскивает и использует в работе. P.S. XML для подобных целей мне не понравился. Тот же гемор с ручным вводом циферок в теги.
__________________
Не сломано - не чини! |
|
|||||
Данные хранятся в каком-то формате, из популярных - JSON. Эти данные можно получить откуда угодно: загрузить по сети, прочитать из файловой системы или вшить JSON прямо в бинарник игры при компиляции (под капотом).
Как правильно делать, я уже распинался. Выделить все сущности и их свойства, вынести данные в таблицы, таблицы хранить в JSON/XML/и т.д. Код должен работать с абстракциями, абстракций - сущности, которые ты выделишь и заполнишь их свойства в таблицах. Простая аналогия: Игра - музыкальный плеер, касета - данные. В плеере не должно быть зашито музыки.
__________________
Дети не должны знать о своих родителях Последний раз редактировалось Tails; 25.09.2018 в 13:54. |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Tails, я помню твоё разъяснение, намедни ещё раз перечитал ту ветку. Один момент хочу уточнить. Я правильно понимаю, что все таблицы должны быть строго двумерными, т.е. всегда сводиться к форме: "поле-ключ-значение"?
__________________
Не сломано - не чини! Последний раз редактировалось Appleman; 25.09.2018 в 14:40. |
|
|||||
Метатег Embed.
http://www.flasher.ru/forum/showthread.php?p=1094641 Цитата:
Надо научиться проектировать базу данных. Игра - это данные изменяемые со временем. Код игры - модифицирует эти данные, но не содержит их. Ты должен представить всю свою игру в виде базы данных, а уже потом начинать программировать.
__________________
Дети не должны знать о своих родителях Последний раз редактировалось Tails; 25.09.2018 в 15:10. |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Пардон, я изменил сообщение с вопросом, пока ты писал ответ.
Конкретный пример. У меня в пакете Вью есть класс, который, получив от Модели событие изменения определённого свойства персонажа, оценивает направление и меру этого изменения и кодирует в строку, по которой будет подбираться итоговая фраза, выводимая игроку. Например, при изменении здоровья итоговое сообщение игроку будет зависеть не только от направления и динамики (слегка поправил: "plus1" или круто потерял: "minus3"), но и от того, кем является персонаж (игрок: "Вас ранили" или NPC: "Вы ранили"). Пока всё понятно, раскладываю на таблицы. Поля (колонки) - это ID классов: игрок или NPC, а записи (строки) - это сгенерированные коды динамики: "plus1", "minus3". На пересечениях - ID фраз, по которым из XML-файла нужного языка будет найдена фраза. Но чуть только появляется ещё один уровень вложенности (например, в зависимости от пола персонажа: свои пакеты фраз для мужчин и женщин), я начинаю тупить. Как встроить такой вариант в реляционную модель?
__________________
Не сломано - не чини! |
|
|||||
Просто держи все тексты локализации в одном файле, без этих динамических ключей. На каждую локализацию один файл: ключ - значение.
Фразы могут содержать вставки: ATTRIBUTE_UP;{target} пополнил {value} {attribute}. ATTRIBUTE_DOWN;{target} потерял {value} {attribute}. Игрок пополнил 15.6 здоровья. Npc потерял 16 ярости. Если хочется иметь вариативность в выражениях, сделай свой интерпретатор чуть сложнее. Например так: Соответственно: Маруся убила Злобная саранча. Ваня убил Большой таракан. Я специально написал название цели2 в именительном падеже и с большой буквы. Чем круче будет твой текстовый интерпретатор, тем более правильными будут сообщения. (Падежи, время и т.д.) Всё это - проблемы вью, а не модели. Вообще, это не самая простая задача даже для опытного человека, сгенерировать идеально правильное сообщение на всех языках. Для простоты советую использовать только именительный падеж и не слишком париться, в случае русского языка. Там где возможно, пиши в правильном падеже. Игровые условности никто не отменял.
__________________
Дети не должны знать о своих родителях Последний раз редактировалось Tails; 25.09.2018 в 16:33. |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
В выбранной мной механике (текстовый квест) выдаваемые игроку сообщения - это основной способ обратной связи и источник информации для игрока, поэтому придётся попотеть и сделать по уму.
Пока допёр до отдельной таблицы соответствий класса и пола, которая будет выдавать ID сочетания, а затем по нему уже лезть в таблицу с идентификаторами фраз. Как-то так...
__________________
Не сломано - не чини! |
|
|||||
Давай начнём с того, что составим дизайн документ. Иначе всё это бессмысленно. Максимально подробное описание, что будет в игре, как и с чем взаимодействовать. Какие могут быть диалоги, какие действия, всё.
Если ты всё таки хочешь создать игру, а не просто поэкспериментировать, то лучшим решением будет использование готового конструктора. Наверняка для такого жанра игр уже существует целая куча движков и конструкторов.
__________________
Дети не должны знать о своих родителях Последний раз редактировалось Tails; 25.09.2018 в 18:34. |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
На редкость безболезненно получилось интегрировать таблицы json в свою программу, спасибо за ссылку. Очень полезным оказалось замечание, что json - это по факту строка, которая парсится в обжект. Вопрос такой. Я правильно понимаю, что для каждой таблицы нужно создавать свой класс, который, "зная" имена полей и типы содержащихся в них данных, будет вытаскивать инфо. проверять её и выдавать в пристойном виде? Выходит, одна таблица - один класс?
__________________
Не сломано - не чини! |
|
|||||
Да, правильно. Одна таблица - один класс, представляющий её. В идеале, конечно, парсер тоже лучше вынести в отдельный класс:
JSON -> Parser -> Игровая модель данных. Parser знает как создать модель данных из переданного JSON. Сама модель не должна знать о формате данных, JSON там, XML или ещё что..
__________________
Дети не должны знать о своих родителях |
Часовой пояс GMT +4, время: 04:59. |
|
« Предыдущая тема | Следующая тема » |
|
|