Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 25.09.2018, 10:16
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 1  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
По умолчанию Хранение справочных данных

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

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

Пока у меня создан отдельный пакет 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 для подобных целей мне не понравился. Тот же гемор с ручным вводом циферок в теги.
__________________
Не сломано - не чини!

Старый 25.09.2018, 13:31
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 2  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Данные хранятся в каком-то формате, из популярных - JSON. Эти данные можно получить откуда угодно: загрузить по сети, прочитать из файловой системы или вшить JSON прямо в бинарник игры при компиляции (под капотом).

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

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


Последний раз редактировалось Tails; 25.09.2018 в 13:54.
Старый 25.09.2018, 14:23
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 3  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Tails, я помню твоё разъяснение, намедни ещё раз перечитал ту ветку. Один момент хочу уточнить. Я правильно понимаю, что все таблицы должны быть строго двумерными, т.е. всегда сводиться к форме: "поле-ключ-значение"?
__________________
Не сломано - не чини!


Последний раз редактировалось Appleman; 25.09.2018 в 14:40.
Старый 25.09.2018, 14:39
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 4  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Метатег Embed.
http://www.flasher.ru/forum/showthread.php?p=1094641

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

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


Последний раз редактировалось Tails; 25.09.2018 в 15:10.
Старый 25.09.2018, 15:14
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 5  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Пардон, я изменил сообщение с вопросом, пока ты писал ответ.

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

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

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

Старый 25.09.2018, 16:18
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 6  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Просто держи все тексты локализации в одном файле, без этих динамических ключей. На каждую локализацию один файл: ключ - значение.
Фразы могут содержать вставки:
Код:
ATTRIBUTE_UP;{target} пополнил {value} {attribute}.
ATTRIBUTE_DOWN;{target} потерял {value} {attribute}.
И превращаться в:
Игрок пополнил 15.6 здоровья.
Npc потерял 16 ярости.

Если хочется иметь вариативность в выражениях, сделай свой интерпретатор чуть сложнее. Например так:
Код:
KILL;{target} {sex|убил|убила} {target2}.
Соответственно:
Маруся убила Злобная саранча.
Ваня убил Большой таракан.

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

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


Последний раз редактировалось Tails; 25.09.2018 в 16:33.
Старый 25.09.2018, 17:15
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 7  
Ответить с цитированием
Appleman
 
Аватар для Appleman

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

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

Старый 25.09.2018, 18:20
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 8  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Давай начнём с того, что составим дизайн документ. Иначе всё это бессмысленно. Максимально подробное описание, что будет в игре, как и с чем взаимодействовать. Какие могут быть диалоги, какие действия, всё.

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


Последний раз редактировалось Tails; 25.09.2018 в 18:34.
Старый 27.09.2018, 15:20
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 9  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Tails Посмотреть сообщение
Если ты всё таки хочешь создать игру, а не просто поэкспериментировать, то лучшим решением будет использование готового конструктора. Наверняка для такого жанра игр уже существует целая куча движков и конструкторов.
Угу, а ещё лучше - огородничеством заняться.

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

Старый 27.09.2018, 18:57
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 10  
Ответить с цитированием
Tails
 
Аватар для Tails

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

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

Создать новую тему Ответ Часовой пояс GMT +4, время: 12:29.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 12:29.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.