|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Други!
Ещё раз спасибо за помощь и советы, удалось реализовать модель инвентаря. Но теперь возник следующий вопрос - создания предметов. Да, именно создания. Возможно, я усложняю опять, но он меня поставил в тупик. Вот смотрите. Есть дерево наследников класса Item: отдельно предметы в руки (HandHelded), одежда (Wearable), расходники (Consumable). Плюс каждый класс в свою очередь тоже ветвится, итого имею сейчас штук 6 классов предметов, потом будет наверное побольше. У разных наследников различный набор свойств, что естественно. Планирую сделать отдельный статический класс "ItemFactory", который будет создавать и возвращать экземпляры предметов. И вот если со значениями свойств более-менее всё понятно (сложить в обжекты, словари или XML и вытаскивать по ID предмета), то как быть с самими классами? Как фабрика "узнает", какой из наследников соответствует запрошенную ID? Как подобные вопросы обычно решаются, подскажите, плиз.
__________________
Не сломано - не чини! |
|
|||||
Так никто не делает. Предметы хранятся в какой нибудь внешней структуре: json, xml, mysql, txt.. как и все остальные сущности, слоты экипировок, расходники и т.д., в виде таблиц. Конкретный предмет в игре это не отдельный класс, это общий класс Item, заполненный из загруженной структуры данных.
Добавлено через 4 минуты Таким образом, фабрике/парсеру, создающему предметы не нужно знать о никакой там иерархий наследования или т.п. вещей. Ему только нужно знать, какие свойства есть у Item и как правильно их заполнить из предоставленной структуры данных. Добавлено через 8 минут У тебя архитектура изначально не верная. С твоим подходом остаётся только плодить каждый предмет - как отдельный класс, а фабрика будет знать какой id к какому классу относится. Здравствуйте огромные стеки из if.
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Tails, ну круто!
Нафлудили 4 страницы, в том числе и на тему грамотной иерархии подклассов Items, а теперь на тебе - неверная архитектура. Хочешь сказать, что в крутых RPG, где в распоряжении игрока может быть не один десяток типов предметов с различными игровыми свойствами и поведением, все они - экземпляры одного класса? Может в саму таблицу запихнуть нужные классы? Есть же тип данных Class...
__________________
Не сломано - не чини! |
|
|||||
Цитата:
Да и начинать изначально нужно с полного описания, а то каждый представляет себе свою задачу и решает её.
__________________
Дети не должны знать о своих родителях |
|
|||||
Я делаю. В играх, где нет никаких внешних структур. То есть как бы смысла нет делать что-то через базу данных или как-то еще на подобие. У этого подхода есть и плюсы и минусы:
Плюсы хранения всего в классах (имхо): - Труднее подменить данные и читить в игре (хотя аргумент слабоват, согласен)) - Можно сразу вшить соответствующие картинки - Предмет может отличаться от других. Допустим тебе надо, чтобы в нем было, скажем, три картинки: куртка, штаны, ботинки, а Item принимает только одну. Наследник может принимать 3 и содержать данные о том, что с ними делать Минусы хранения в классах - Для изменения / добавления чего-либо, требуется перекомпиляция всего проекта - Труднее настраивать баланс (опять же, см. пункт выше) - Как ты уже сам заметил, труднее организовать выбор нужного предмета (хотя это вполне решаемо) Если же хранить все, например, в базе данных, которая хранится на сервере, то можно легко добавлять новые предметы, и они сразу у всех появятся. Легко менять их свойства. Но если база локальная, то, как я уже сказал, в этом особого смысла нет, да еще и будет тратится время и ресурсы на работу с базой Цитата:
__________________
Ко мне можно и нужно обращаться на ты) |
|
|||||
Из минусов я бы ещё добавил:
- Возникают трудности в будущем, если требуется добавить какой-то функционал, а часть нужных данных выражена, например, в наследовании. (Принадлежность предмета к слоту) Приходится придумывать костыли что-бы всё это как-то связать. - Если требуется добавить какое либо свойство для сущности, которая выражена в наследовании, нам опять нужно придумывать костыль. (Добавить название для слота экипировки) Хотя, это частный случай первого пункта. - Возникают трудности при передаче данных по сети, например. Или для хранения в бд. Или для сохранения/загрузки игры, вообщем, как только нашу модель игры нужно вынести за рамки рантайма. Опять нужно придумывать уникальные механизмы для сериализации/десериализации объектов. - Так-как часть данных захардкодена в код игры (связи), такую модель нельзя просто взять и использовать для новой игры без переделок. Всё это делает приложение трудно поддерживаемым, запутанным, негибким. Добавлено через 6 минут Получается так, что ооп модель данных удобна на малых масштабах. Строить реляционную модель для марио будет избыточно, проще хранить всё в классах. Но если мы делаем рпг, или любую другую игру с большим количеством связей и взаимодействий, лучше вынести все данные и связи в таблицы, так гораздо удобнее, когда код игры абстрагирован от данных.
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Tails, спасибо. Аргументация понятна. С реляционной моделью тоже всё ясно, что это такое и с чем это едят. Но тогда у нас получится, что ЛЮБОЕ свойство или метод ЛЮБОГО предмета будет вынужденно распространён на все игровые предметы. Иначе реляционная модель "ляжет" из-за нарушения целостности. То есть если у оружия есть наносимый ущерб (не эффект, а свойство), а у защиты - ущерб поглощаемый, то как ни крути нас потребуется предусмотреть такие свойства для всех игровых предметов, включая мольберты и огурцы. Верно?
И у меня там ещё была реплика в "довесок" на счёт оффлайн-игр с разветвлённой системой предметов... Мне представляется, в применительно к таким проектам твой подход не покатит. caseyryan, вот так класс передавать и применять?
__________________
Не сломано - не чини! |
|
|||||
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. |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
У меня знаешь какой ещё вопрос. Посоветуй, пожалуйста, каким образом лучше хранить подобные таблицы, с точки зрения удобства ведения, администрирования и считывания программой? Язык я весь в XML загнал, но этот формат достаточно громоздкий и не очень наглядный для ручного ввода данных.
__________________
Не сломано - не чини! |
|
|||||
Регистрация: Jan 2012
Сообщений: 836
|
Appleman когда у тебя будет свыше 300+ строк, любое форматирование будет громоздким и не особо удобным. У меня на данном этапе разработки конфиг уже свыше 1000+ строк в xml. В качестве программы редактирования использую Notepad++ с плагином XML Tools. Ctrl+F лучший друг для поиска нужной секции, ибо вручную перематывать уже не варик.
|
Часовой пояс GMT +4, время: 00:13. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|