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

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

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Tails Посмотреть сообщение
Вопрос с избыточностью решается очень просто. Если, например, для описания атаки требуется больше 1 свойства и это создаёт проблемы, то атака как таковая, выносится как отдельная сущность, а предмет просто ссылается на неё: Item.attackID = 5, где Attack id=5 - Могучий удар гнома с типом хаос - 74ед. (Атака: id,title,type,damage) Когда у огурца attackID = 0 - огурцом нельзя ударить, но если мы поставим ему attackID = 5, то, о чудо, огурцом можно нанести могучий удар гнома!

При этом, сам код игры никаких данных не содержит. Всю информацию о том, кто сколько и чего наносит, кто к какому типу/категории относится и т.п. он берёт из соответствующих таблиц.
Tails, я что ещё подумал. Если у нас база данных состоит из реляционных таблиц, то они на то и "реляционные", что между ними выстроены связи, причём строго определённым образом (что кстати поднимает отдельный вопрос трудозатрат на перенос схемы под новые проекты, но сейчас не об этом). Значит, в рамках программы должна быть какая-то СУБД, которая "знает", что и откуда тягать. Если не секрет и не в ломак, расскажи, как ты это реализуешь, плиз. Хотя бы на примере тех же предметов и эффектов. Каким образом ты "говоришь", что эффект - это не просто запись, а именно ссылка на другую таблицу данных?
__________________
Не сломано - не чини!

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

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Цитата:
Сообщение от Appleman Посмотреть сообщение
что кстати поднимает отдельный вопрос трудозатрат на перенос схемы под новые проекты, но сейчас не об этом.
Переносится механика: предметы дамажут, надеваются, используются. Если требуется новое поведение, то тогда да, добавляются таблицы, описывающие его, а код игры/движка обновляется.

Цитата:
Сообщение от Appleman Посмотреть сообщение
Значит, в рамках программы должна быть какая-то СУБД
Да, субд есть, очень простая: получение записи по id, кеширование данных при загрузке игры, этого хватает. Что и откуда тянуть - знает обрабатывающий код/функция, выполняющая какое-то действие. Если это надевание предмета, она запросит данные этого предмета по его id, запросит данные экипируемого слота. Проверит что-то и либо выполнит действие, либо отвалится с сообщением об ошибке. (Такого предмета не существует, был передан не экипируемый предмет, слот уже экипирован, или такого слота не существует) То-есть, в саму субд я не закладываю такого функционала, что-бы она сама подтягивала дополнительные данные из других таблиц. У меня таблица - это просто список записей, которые можно запросить по id или пройтись по всему списку целиком.

Цитата:
Сообщение от Appleman Посмотреть сообщение
Каким образом ты "говоришь", что эффект - это не просто запись, а именно ссылка на другую таблицу данных?
Мы изначально так проектируем нашу бд. У нас есть Item, у него есть поле effect. Это поле содержит id записи из таблицы Effects. На какую-то другую таблицу оно ссылаться не может. Вообще это вопрос о том, как проектировать базу данных, как выделять сущности. Можно почитать что-то на эту тему.
__________________
Дети не должны знать о своих родителях

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

Регистрация: May 2008
Адрес: Питер
Сообщений: 385
Отправить сообщение для ZergMaster с помощью ICQ Отправить сообщение для ZergMaster с помощью Skype™
крутяк
__________________
while(live()) { hope(); }

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

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

Цитата:
У меня знаешь какой ещё вопрос. Посоветуй, пожалуйста, каким образом лучше хранить подобные таблицы, с точки зрения удобства ведения, администрирования и считывания программой? Язык я весь в XML загнал, но этот формат достаточно громоздкий и не очень наглядный для ручного ввода данных.
Я использую JSON, лёгкий, простой, его относительно удобно редактировать. Когда мы делали игру для вк с очень большим количеством данных, у нас была админка на php. Все данные игры были в mysql на сервере, вручную мы их не редактировали (Почти ). XML Лично мне не нравится из-за своей громоздкости, слишком избыточное количество символов, но для человека он удобнее.

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


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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Tails Посмотреть сообщение
Что и откуда тянуть - знает обрабатывающий код/функция, выполняющая какое-то действие. Если это надевание предмета, она запросит данные этого предмета по его id, запросит данные экипируемого слота. Проверит что-то и либо выполнит действие, либо отвалится с сообщением об ошибке. (Такого предмета не существует, был передан не экипируемый предмет, слот уже экипирован, или такого слота не существует) То-есть, в саму субд я не закладываю такого функционала, что-бы она сама подтягивала дополнительные данные из других таблиц. У меня таблица - это просто список записей, которые можно запросить по id или пройтись по всему списку целиком.
Действительно здорово! Спасибо большое. Загорелся я твоим подходом, теперь активно думаю, как совместить его с наследуемой архитектурой классов Item внутри программы. Я с позволения ещё несколько вопросов задам, до сих пор не всё на 100% понятно.

1. Я правильно понимаю, что если предмет должен "жить своей жизнью" внутри программы, то "чистый" реляционный подход уже не сработает? Например, если каждое использование аптечки снижает её ресурс на 20%, то остаток по-любому придётся хранить в самом экземпляре. В таком раскладе использовать внутри программы одни только ID точно не выйдет. Верно? Как такие вопросы ты решаешь?
2. Рассматриваю вариант, как мне скрестить ежа и ужа (реляционную модель хранения статических данных с наследуемой ООП-архитектурой внутри программы). Что если указывать прямо в таблице имя присваиваемого предмету класса, чтобы в момент создания вытягивать его по ID и присваивать через getDefinitionByName? А дальше при заполнении свойств проверять на наличие такого свойства у данного класса. Если есть - заполняем, если нет - не заполняем (и выдаём предупреждение).
3. В качестве альтернативы вижу ещё один подход. ВСЕ свойства прописать в классе Item, тем самым решив раз и навсегда проблему наличия/отсутствия свойств, а наследников оставить как маркеры.

Насколько такие "гибридные" подходы применимы и в чём, по твоему мнению, их главные минусы? Плюсы и так понятны. Спасибо.

Добавлено через 27 минут
...ещё забыл, хотел уточнить.\

4. Скажи, пожалуйста, я правильно понимаю, что если нет комплексной СУБД, "знающей", что откуда нужно подтягивать, то получается, что для каждой таблицы нам придётся делать свой персональный класс-парсер, который как раз и будет "знать", что и как мы из неё вытаскиваем?
__________________
Не сломано - не чини!

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

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Цитата:
Сообщение от Appleman Посмотреть сообщение
1. Я правильно понимаю, что если предмет должен "жить своей жизнью" внутри программы, то "чистый" реляционный подход уже не сработает? Например, если каждое использование аптечки снижает её ресурс на 20%, то остаток по-любому придётся хранить в самом экземпляре. В таком раскладе использовать внутри программы одни только ID точно не выйдет. Верно? Как такие вопросы ты решаешь?
У меня есть таблица, которая описывает текущие предметы: (Инвентарь)
id,player,item,quantity
id - ID Записи.
player - ID Игрока.
item - ID Предмета.
quantity - Количество предмета у игрока.

Есть таблица, которая содержит текущие кулдавны предметов у игроков:
id,player,item,cooldown
id - ID Записи.
player - ID Игрока.
item - ID Предмета.
cooldown - Оставшееся время перезарядки предмета.

И т.д. для всех игровых аспектов. Всё что есть в игре, всё разложено по таблицам, "сам по себе" никто не живёт.

Цитата:
Сообщение от Appleman Посмотреть сообщение
2. Рассматриваю вариант, как мне скрестить ежа и ужа (реляционную модель хранения статических данных с наследуемой ООП-архитектурой внутри программы). Что если указывать прямо в таблице имя присваиваемого предмету класса, чтобы в момент создания вытягивать его по ID и присваивать через getDefinitionByName? А дальше при заполнении свойств проверять на наличие такого свойства у данного класса. Если есть - заполняем, если нет - не заполняем (и выдаём предупреждение).
На твой страх и риск Лучше делай как уже начал, как тебе самому понятнее. Просто будешь знать, что есть и альтернативный способ.

Цитата:
Сообщение от Appleman Посмотреть сообщение
3. В качестве альтернативы вижу ещё один подход. ВСЕ свойства прописать в классе Item, тем самым решив раз и навсегда проблему наличия/отсутствия свойств, а наследников оставить как маркеры.
Тут только надо понимать, где заканчивается одна сущность и начинается другая. Например, может показаться, что использование предмета - относится к самому предмету. Но, использование, как таковое, может быть и самостоятельной, отдельной сущностью, на которую предмет будет ссылаться. Вообщем, это уже зависит от самого проекта. Или вот ещё пример: приложение по знакомству. Парень и девушка познакомились. Знакомство может быть выделено как отдельная сущность, которая будет включать в себя свойства:
id, id парня, id девушки, дата знакомства, уровень взаимной симпатий.
То есть, связь между парнем и девушкой - это тоже отдельная сущность, отдельная таблица.

Цитата:
Сообщение от Appleman Посмотреть сообщение
4. Скажи, пожалуйста, я правильно понимаю, что если нет комплексной СУБД, "знающей", что откуда нужно подтягивать, то получается, что для каждой таблицы нам придётся делать свой персональный класс-парсер, который как раз и будет "знать", что и как мы из неё вытаскиваем?
Вытаскиваем куда? Вообще, да, есть отдельный парсер, который читает JSON и заполняет все таблицы. Может быть, он ещё будет уметь записывать таблицы обратно в JSON. (Например, для сохранения игры) Но это ввод/вывод данных из игры. Если ты имеешь ввиду работу логики самой игры, то, функция выполняющая конкретное действие сама получает нужные ей данные из таблиц. Я это организовываю в виде апи игровой модели, где у главной модели есть все необходимые методы для работы с данными:
Код AS3:
playerItemEquip(playerID, itemID):Void;
playerItemUnequip(playerID, itemID):Void;
playerItemUse(playerID, itemID):Void;
playerItemBuy(playerID, itemID):Void;
playerItemSell(playerID, itemID):Void;
...
Сами игроки и предметы - это просто записи в таблицах, у них нет функционала. (Почти, кроме там диспетчеризации событий и может ещё за редким исключением)
__________________
Дети не должны знать о своих родителях


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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Tails Посмотреть сообщение
У меня есть таблица, которая описывает текущие предметы: (Инвентарь)
id,player,item,quantity
id - ID Записи.
player - ID Игрока.
item - ID Предмета.
quantity - Количество предмета у игрока.
Значит, тебе приходится записывать новое значение quantity в таблицу? То есть таблицы не read-only? Если игрок приобрёл предмет, то ты записываешь новое кол-во в таблицу.

Цитата:
Если ты имеешь ввиду работу логики самой игры, то, функция выполняющая конкретное действие сама получает нужные ей данные из таблиц.
Да, я имею в виду именно игровую логику. Я наверное плохо сформулировал, что хочу спросить. Давай с терминами определимся. Под "таблицей" ты подразумеваешь внешний файл с данными (JSON, XML) или всё-таки некий внутренний объект (экземпляр класса), который считывает данные из внешнего файла и уже держит их в себе, выдаёт, изменяет?
__________________
Не сломано - не чини!

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

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Цитата:
Сообщение от Appleman Посмотреть сообщение
Значит, тебе приходится записывать новое значение quantity в таблицу? То есть таблицы не read-only? Если игрок приобрёл предмет, то ты записываешь новое кол-во в таблицу.
Да, какие-то таблицы статичны (Описания юнитов, предметов) какие-то обновляемые. (Текущие юниты на карте) Различие между ними разве что такое, что динамичные будут диспатчить события.

Цитата:
Сообщение от Appleman Посмотреть сообщение
Давай с терминами определимся. Под "таблицей" ты подразумеваешь внешний файл с данными (JSON, XML) или всё-таки некий внутренний объект (экземпляр класса), который считывает данные из внешнего файла и уже держит их в себе, выдаёт, изменяет?
И то и другое. Изначально, таблица - место, где мы храним данные по конкретным сущностям. Сущностью может быть описание предмета, или связь предметов (Пример с приложением знакомств). Как конкретно будет представлена таблица там или тут, дело второе, в коде она может выглядеть так:
Код AS3:
var table:Object = new Object;
table[1] = new Item(); // Предмет id=1
table[2] = new Item(); // Предмет id=2
Но, конечно, мы создаём свой класс обёртку, куда добавляем типизацию, более удобное апи и некоторый функционал, диспатчинг событий, например.
__________________
Дети не должны знать о своих родителях

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

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

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


 


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


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