Форум Flasher.ru - Хранение справочных данных

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - Хранение справочных данных (http://www.flasher.ru/forum/showthread.php?t=215657)

Хранение справочных данных

Друзья, поделитесь, пожалуйста, опытом.

По мере продвижения в деле написания игры программа всё больше обрастает всякими "статичными" справочными данными: параметры предметов, игровых действий, статус-эффектов и ещё много чего. Возник вопрос, как хранить всё это безобразие.

Пока у меня создан отдельный пакет collections, в котором я создаю классы-хранители, например AllItemProps. В нём созданы публичные константы типа Dictionary, по одному на каждое поле класса Item. В них записаны значения, ключами доступа к которым служат строковые ID предметов, т.е.:

Код AS3:

public class AllItemProps

{public static const PRICES: Dictionary = new Dictionary;

PRICES[ItemIDs.SMALL_HEALING_POTION] = 20;

PRICES[ItemIDs.MED_HEALING_POTION] = 30;
}

В конструкторе класса Item записан запуск protected-метода setInitialProps(), который обращается к справочнику и заполняет поля вот таким образом:

Код AS3:

if (AllItemProps.PRICES[_id]) _price = AllItemProps.PRICES[_id])

для наследников, у которых есть поля, отсутствующие в супере, данный метод переопределяется и "выдёргивает" дополнительные записи из справочников.

В принципе, всё работает, но есть ряд проблем, которые становятся тем заметнее, чем крупнее становится проект. Главная - это неудобство администрирования. Если нужно что-то подкорректировать, я вынужден лезть в эти классы, проматывать много строк текста и вводить вручную новые значения. И это я ещё не дошёл до балансировки! Наверное, свихнусь.

В общем, вопросов два. Первый, где принято хранить подобные вещи? Считается, что им не место в коде. С другой - они не предназначены для внешней редактуры и должны оставаться "под капотом".
Второй - как это правильнее делать? Возможно, кто-то покажет уже готовые наработки или поделится советом. Например, у меня сейчас приятель участвует в разработке некого приложения (не как программист), так ему разработчики сделали табличный документ в Гугле, где он вписывает текста в ячейки, из которых приложение их вытаскивает и использует в работе.

P.S. XML для подобных целей мне не понравился. Тот же гемор с ручным вводом циферок в теги.

Данные хранятся в каком-то формате, из популярных - JSON. Эти данные можно получить откуда угодно: загрузить по сети, прочитать из файловой системы или вшить JSON прямо в бинарник игры при компиляции (под капотом).

Как правильно делать, я уже распинался. Выделить все сущности и их свойства, вынести данные в таблицы, таблицы хранить в JSON/XML/и т.д. Код должен работать с абстракциями, абстракций - сущности, которые ты выделишь и заполнишь их свойства в таблицах.

Простая аналогия: Игра - музыкальный плеер, касета - данные. В плеере не должно быть зашито музыки.

Tails, я помню твоё разъяснение, намедни ещё раз перечитал ту ветку. Один момент хочу уточнить. Я правильно понимаю, что все таблицы должны быть строго двумерными, т.е. всегда сводиться к форме: "поле-ключ-значение"?

Метатег Embed.
http://www.flasher.ru/forum/showthread.php?p=1094641

Цитата:

Tails, я помню твоё разъяснение, намедни ещё раз перечитал ту ветку. Один момент хочу уточнить. Я правильно понимаю, что все таблицы должны быть строго двумерными, т.е. всегда сводиться к парам "ключ: значение"?

Нет, не совсем. Обычная реляционная модель данных, как, например в mysql. Есть таблица, в ней есть столбики. Одна таблица описывает одну сущность или связь между другими. У каждой записи в таблице есть id. Таблица предметов содержит все предметы в игре, всё это я уже описывал. По id предмета можно получить из таблицы его название, уровень, цену или id эффекта, который он "вешает на игрока". По id эффекта получить данные эффекта из таблицы эффектов и т.д.

Надо научиться проектировать базу данных. Игра - это данные изменяемые со временем. Код игры - модифицирует эти данные, но не содержит их. Ты должен представить всю свою игру в виде базы данных, а уже потом начинать программировать.

Пардон, я изменил сообщение с вопросом, пока ты писал ответ. :)

Конкретный пример. У меня в пакете Вью есть класс, который, получив от Модели событие изменения определённого свойства персонажа, оценивает направление и меру этого изменения и кодирует в строку, по которой будет подбираться итоговая фраза, выводимая игроку. Например, при изменении здоровья итоговое сообщение игроку будет зависеть не только от направления и динамики (слегка поправил: "plus1" или круто потерял: "minus3"), но и от того, кем является персонаж (игрок: "Вас ранили" или NPC: "Вы ранили").

Пока всё понятно, раскладываю на таблицы. Поля (колонки) - это ID классов: игрок или NPC, а записи (строки) - это сгенерированные коды динамики: "plus1", "minus3". На пересечениях - ID фраз, по которым из XML-файла нужного языка будет найдена фраза.

Но чуть только появляется ещё один уровень вложенности (например, в зависимости от пола персонажа: свои пакеты фраз для мужчин и женщин), я начинаю тупить. Как встроить такой вариант в реляционную модель?

Просто держи все тексты локализации в одном файле, без этих динамических ключей. На каждую локализацию один файл: ключ - значение.
Фразы могут содержать вставки:

Код:

ATTRIBUTE_UP;{target} пополнил {value} {attribute}.

ATTRIBUTE_DOWN;{target} потерял {value} {attribute}.

И превращаться в:
Игрок пополнил 15.6 здоровья.
Npc потерял 16 ярости.

Если хочется иметь вариативность в выражениях, сделай свой интерпретатор чуть сложнее. Например так:

Код:

KILL;{target} {sex|убил|убила} {target2}.

Соответственно:
Маруся убила Злобная саранча.
Ваня убил Большой таракан.

Я специально написал название цели2 в именительном падеже и с большой буквы. Чем круче будет твой текстовый интерпретатор, тем более правильными будут сообщения. (Падежи, время и т.д.) Всё это - проблемы вью, а не модели.

Вообще, это не самая простая задача даже для опытного человека, сгенерировать идеально правильное сообщение на всех языках. Для простоты советую использовать только именительный падеж и не слишком париться, в случае русского языка. Там где возможно, пиши в правильном падеже. Игровые условности никто не отменял.

В выбранной мной механике (текстовый квест) выдаваемые игроку сообщения - это основной способ обратной связи и источник информации для игрока, поэтому придётся попотеть и сделать по уму.

Пока допёр до отдельной таблицы соответствий класса и пола, которая будет выдавать ID сочетания, а затем по нему уже лезть в таблицу с идентификаторами фраз. Как-то так...

Давай начнём с того, что составим дизайн документ. Иначе всё это бессмысленно. Максимально подробное описание, что будет в игре, как и с чем взаимодействовать. Какие могут быть диалоги, какие действия, всё.

Если ты всё таки хочешь создать игру, а не просто поэкспериментировать, то лучшим решением будет использование готового конструктора. Наверняка для такого жанра игр уже существует целая куча движков и конструкторов.

Цитата:

Сообщение от Tails (Сообщение 1205943)

Если ты всё таки хочешь создать игру, а не просто поэкспериментировать, то лучшим решением будет использование готового конструктора. Наверняка для такого жанра игр уже существует целая куча движков и конструкторов.

Угу, а ещё лучше - огородничеством заняться. :)

На редкость безболезненно получилось интегрировать таблицы json в свою программу, спасибо за ссылку. Очень полезным оказалось замечание, что json - это по факту строка, которая парсится в обжект. Вопрос такой. Я правильно понимаю, что для каждой таблицы нужно создавать свой класс, который, "зная" имена полей и типы содержащихся в них данных, будет вытаскивать инфо. проверять её и выдавать в пристойном виде? Выходит, одна таблица - один класс?

Да, правильно. Одна таблица - один класс, представляющий её. В идеале, конечно, парсер тоже лучше вынести в отдельный класс:
JSON -> Parser -> Игровая модель данных.

Parser знает как создать модель данных из переданного JSON. Сама модель не должна знать о формате данных, JSON там, XML или ещё что..