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

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

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Други!

Ещё раз спасибо за помощь и советы, удалось реализовать модель инвентаря. Но теперь возник следующий вопрос - создания предметов. Да, именно создания. Возможно, я усложняю опять, но он меня поставил в тупик.

Вот смотрите. Есть дерево наследников класса Item: отдельно предметы в руки (HandHelded), одежда (Wearable), расходники (Consumable). Плюс каждый класс в свою очередь тоже ветвится, итого имею сейчас штук 6 классов предметов, потом будет наверное побольше. У разных наследников различный набор свойств, что естественно.

Планирую сделать отдельный статический класс "ItemFactory", который будет создавать и возвращать экземпляры предметов. И вот если со значениями свойств более-менее всё понятно (сложить в обжекты, словари или XML и вытаскивать по ID предмета), то как быть с самими классами? Как фабрика "узнает", какой из наследников соответствует запрошенную ID? Как подобные вопросы обычно решаются, подскажите, плиз.
__________________
Не сломано - не чини!

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

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Так никто не делает. Предметы хранятся в какой нибудь внешней структуре: json, xml, mysql, txt.. как и все остальные сущности, слоты экипировок, расходники и т.д., в виде таблиц. Конкретный предмет в игре это не отдельный класс, это общий класс Item, заполненный из загруженной структуры данных.

Добавлено через 4 минуты
Таким образом, фабрике/парсеру, создающему предметы не нужно знать о никакой там иерархий наследования или т.п. вещей. Ему только нужно знать, какие свойства есть у Item и как правильно их заполнить из предоставленной структуры данных.

Добавлено через 8 минут
У тебя архитектура изначально не верная. С твоим подходом остаётся только плодить каждый предмет - как отдельный класс, а фабрика будет знать какой id к какому классу относится. Здравствуйте огромные стеки из if.
__________________
Дети не должны знать о своих родителях

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Tails, ну круто!

Нафлудили 4 страницы, в том числе и на тему грамотной иерархии подклассов Items, а теперь на тебе - неверная архитектура. Хочешь сказать, что в крутых RPG, где в распоряжении игрока может быть не один десяток типов предметов с различными игровыми свойствами и поведением, все они - экземпляры одного класса?

Может в саму таблицу запихнуть нужные классы? Есть же тип данных Class...
__________________
Не сломано - не чини!

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

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Цитата:
Сообщение от Appleman Посмотреть сообщение
Хочешь сказать, что в крутых RPG, где в распоряжении игрока может быть не один десяток типов предметов с различными игровыми свойствами и поведением, все они - экземпляры одного класса?
Да, класс Item - абстрактный, он описывает любой возможный предмет в игре. Если у предмета есть эффект - это отдельный класс Effect, который описывает любой возможный эффект в игре. Внешний код знает об этом и умеет обрабатывать такую структуру. (Логику лучше вынести на уровень выше, а не держать в самих Item или Effect) Как Item и Effect связаны, я уже не раз говорил и приводил примеры.

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

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

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Сообщение от Tails Посмотреть сообщение
Так никто не делает.
Я делаю. В играх, где нет никаких внешних структур. То есть как бы смысла нет делать что-то через базу данных или как-то еще на подобие. У этого подхода есть и плюсы и минусы:
Плюсы хранения всего в классах (имхо):
- Труднее подменить данные и читить в игре (хотя аргумент слабоват, согласен))
- Можно сразу вшить соответствующие картинки
- Предмет может отличаться от других. Допустим тебе надо, чтобы в нем было, скажем, три картинки: куртка, штаны, ботинки, а Item принимает только одну. Наследник может принимать 3 и содержать данные о том, что с ними делать
Минусы хранения в классах
- Для изменения / добавления чего-либо, требуется перекомпиляция всего проекта
- Труднее настраивать баланс (опять же, см. пункт выше)
- Как ты уже сам заметил, труднее организовать выбор нужного предмета (хотя это вполне решаемо)


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

Цитата:
Может в саму таблицу запихнуть нужные классы? Есть же тип данных Class...
Можно
__________________
Ко мне можно и нужно обращаться на ты)

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

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Из минусов я бы ещё добавил:
- Возникают трудности в будущем, если требуется добавить какой-то функционал, а часть нужных данных выражена, например, в наследовании. (Принадлежность предмета к слоту) Приходится придумывать костыли что-бы всё это как-то связать.
- Если требуется добавить какое либо свойство для сущности, которая выражена в наследовании, нам опять нужно придумывать костыль. (Добавить название для слота экипировки) Хотя, это частный случай первого пункта.
- Возникают трудности при передаче данных по сети, например. Или для хранения в бд. Или для сохранения/загрузки игры, вообщем, как только нашу модель игры нужно вынести за рамки рантайма. Опять нужно придумывать уникальные механизмы для сериализации/десериализации объектов.
- Так-как часть данных захардкодена в код игры (связи), такую модель нельзя просто взять и использовать для новой игры без переделок.

Всё это делает приложение трудно поддерживаемым, запутанным, негибким.

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

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Tails, спасибо. Аргументация понятна. С реляционной моделью тоже всё ясно, что это такое и с чем это едят. Но тогда у нас получится, что ЛЮБОЕ свойство или метод ЛЮБОГО предмета будет вынужденно распространён на все игровые предметы. Иначе реляционная модель "ляжет" из-за нарушения целостности. То есть если у оружия есть наносимый ущерб (не эффект, а свойство), а у защиты - ущерб поглощаемый, то как ни крути нас потребуется предусмотреть такие свойства для всех игровых предметов, включая мольберты и огурцы. Верно?

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

caseyryan, вот так класс передавать и применять?

Код AS3:
public static function generateItem(itemID: String, itemClass: Class) : Item
{
var newItem: Item = new Item(itemID) as itemClass;
return newItem;
}
__________________
Не сломано - не чини!

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

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

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

Добавлено через 3 минуты
При этом, сам код игры никаких данных не содержит. Всю информацию о том, кто сколько и чего наносит, кто к какому типу/категории относится и т.п. он берёт из соответствующих таблиц.

Добавлено через 9 минут
Сегодня у тебя дамагают огурцы, завтра ты будешь делать игру про коров и пришельцев, просто подставишь новую структуру и код будет обрабатывать её.

Добавлено через 16 минут
Реляционная модель подойдёт для любого проекта любой сложности. Вообщем, 99% баз данных в мире построены на такой модели. Поправьте меня, если я не прав.
__________________
Дети не должны знать о своих родителях


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

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

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

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

Регистрация: Jan 2012
Сообщений: 836
Appleman когда у тебя будет свыше 300+ строк, любое форматирование будет громоздким и не особо удобным. У меня на данном этапе разработки конфиг уже свыше 1000+ строк в xml. В качестве программы редактирования использую Notepad++ с плагином XML Tools. Ctrl+F лучший друг для поиска нужной секции, ибо вручную перематывать уже не варик.

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

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

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


 


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


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