jarg
Модераторы: Sanja, Максим Кич
Re: jarg
Здорово. А потыкать можно?
Re: jarg
Если интересно, можешь посмотреть исходники Бусикатора, тоже но OpenTK, исходники открыты. Все что касается OpenTK вынесенно в отдельную сборку
http://rlgclub.ru/forum/viewtopic.php?f=25&t=734
http://rlgclub.ru/forum/viewtopic.php?f=25&t=734
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: jarg
Если твоя задача именно сохранить ООП. то сделай блокам "интерфейс" в котором будут методы только для получения данных отрисовки. и пусть рисовальщик берет блоки только через этот интерфейс.ishellstrike писал(а):Товарищи, я в раздумьях....
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: jarg
Я думаю, что можно хранить и в одной большой базе.ishellstrike писал(а):Jesus05, практически так и есть, вопрос скорее в том, как хранить данные, в свойствах класса, производного, от класса блок, т.е. класс стол, класс стул. Или дальше хранить в одной большой базе, а блоки оставить одинаковыми.
Думаю что усложнение и разнос на классы "стол" и "стул" не нужно и оно противоречит борьбе со сложностью.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: jarg
А не замучаешься все типы объектов приписывать в коде, и на каждый делать класс... а чем отличаться будут эти классы?ishellstrike писал(а):Jesus05, просто меня печалят конструкции видагде Description и т.д. -- открытые поля в статическом классе BlockDataBase, от статичности можно конечно избавитьсяКод: Выделить всё
IBlock a = GetBlock(x,y); ...=BlockDataBase.Data[a.Id].Description if(BlockDataBase.Data[a.Id].Prototype == typeof(BlockTable)) { ...=BlockDataBase.Data[a.Id].%поле, характерное для стола% }
в ооп подходе было быгде Description и т.д. -- открытые только для чтения свойства, экземпляра нашего блока. Соответственно у винтовки нет свойств стола.Код: Выделить всё
IBlock a = GetBlock(x,y); ...=(a as Block).Description if(a is BlockTable) { ...=(a as BlockTable).%поле, характерное для стола% }
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: jarg
мои прошлые размышления на эту тему там -> http://rlgclub.ru/forum/viewtopic.php?p=8114#p8114 начиная с этого сообщения и ниже.
- Cfyz
- Сообщения: 776
- Зарегистрирован: 30 ноя 2006, 10:03
- Откуда: Санкт-Петербург
- Контактная информация:
Re: jarg
(то, что я скажу, может быть и мимо, ведь я так и не понял что именно ты подразумеваешь под "безликим блоком": объект на карте, ячейка карты, описательный блок в базе, etc.)
tl;dr Объекты в классы 1:1 нельзя, надо делать небольшое количество фундаментально различных классов-сущностей.
С обновлением немного сложнее, но и тут по-моему лучше посмотреть на проблему максимально широко и вычленить общее из хаоса. К примеру, то, что "стол" может сгореть (и его нужно обновлять для достижения желаемого эффекта) -- это не уникальное свойство стола, из-за одного которого его стоит выносить в отдельный класс предметов, это лишь следствие его материала. Идентичное поведение будет (или по крайней мере, должно быть) у всех деревянных предметов. С другой стороны, "ящик" он тоже может быть деревянный, но это несущественно, его поведение качественно отличается возможностью агрегировать в себе другие предметы, что уже делает его кандидатом на самостоятельную сущность "контейнер".
При этом добавление простого предмета -- это тривиальное событие, будь он деревянным или нет, будь он столом или стулом или драгоценным камнем. Это можно и в базе хранить строками. Но добавление в игру такой сущности, как "контейнер" (будь то ящик, сундук или мешок) сразу меняет логику программы -- потребуется сделать специальное окно с содержимым, пункты в меню чтобы положить/выкинуть и т. д. Вот это уже ни в какую базу, разумеется, не влезет, это придется делать кодом и, куда уж денешься, перекомпилировать.
tl;dr Объекты в классы 1:1 нельзя, надо делать небольшое количество фундаментально различных классов-сущностей.
Если стол и стул отличаются только спрайтом и именем, то это одна сущность ("фурнитура", скажем) и нет смысла разделять ее. Если два объекта отличаются только содержимым полей, но не их количественным или качественным составом, то это один класс объектов.ishellstrike писал(а):Да, в этом то и вся проблема, отличаться стол от стола, по сути, будут, только свойством, возвращающим их спрайт, ну и свойством-именем
Такие аргументы меня всегда смущали. ООП это же не классы по поводу и без, это в первую очередь логическое разделение. Разные классы объектов, т. е. разные сущности, они должны вести себя по-разному. Если выходит, что они не ведут себя по-разному, не требуют фундаментально разных алгоритмов для обработки (и не требуют перекомпиляции), то это означает лишь ошибку в проектировании, и это на самом деле один класс, объекты которого отличаются только содержимым, которое обрабатывается одинаково для всех объектов этого класса. И это нормально, что программу приходится перекомпилировать из-за добавления или модификации алгоритма =).ishellstrike писал(а):Добавиться гибкости, но пропадет добавление контента без перекомпиляции
По-моему, тут распространненный случай over-engineering. Вот например с отрисовкой, чаще всего нет никакого смысла выносить ее в "классы", как правило отрисовка отдельных объектов алгоритмически ничем не отличается, будь это буквы ASCII, тайлы или даже 3D-модели. Внешнее оформление -- это лишь свойство объекта, но не его уникальная характеристика.ishellstrike писал(а):ЧТобы они сами себя рисовали и обновляли.
С обновлением немного сложнее, но и тут по-моему лучше посмотреть на проблему максимально широко и вычленить общее из хаоса. К примеру, то, что "стол" может сгореть (и его нужно обновлять для достижения желаемого эффекта) -- это не уникальное свойство стола, из-за одного которого его стоит выносить в отдельный класс предметов, это лишь следствие его материала. Идентичное поведение будет (или по крайней мере, должно быть) у всех деревянных предметов. С другой стороны, "ящик" он тоже может быть деревянный, но это несущественно, его поведение качественно отличается возможностью агрегировать в себе другие предметы, что уже делает его кандидатом на самостоятельную сущность "контейнер".
При этом добавление простого предмета -- это тривиальное событие, будь он деревянным или нет, будь он столом или стулом или драгоценным камнем. Это можно и в базе хранить строками. Но добавление в игру такой сущности, как "контейнер" (будь то ящик, сундук или мешок) сразу меняет логику программы -- потребуется сделать специальное окно с содержимым, пункты в меню чтобы положить/выкинуть и т. д. Вот это уже ни в какую базу, разумеется, не влезет, это придется делать кодом и, куда уж денешься, перекомпилировать.
Пытается раскуклиться
Re: jarg
Как по мне, вообще можно обойтись несколькими очень общими классами, а различия между ними реализовать тегами.
Так меч, мешок и ключ это один класс предмет, но у первого есть тег "оружие", который позволит его взять в руку, у второго "контейнер" который позволит другим предметам ссылаться на него указывая, что они в нем лежат, а у третьего тег "квестовый" который не даст продать его у торговца.
Да, опережая вопрос - что-ли хранить для предмета весь набор параметров на все случаи тегов, типа "урон", "прочность" и "вместительность", "от какой двери ключ"?
Такие параметры лучше хранить в виде динамического ассоциативного массива ключ-значение, и добавлять при появлении соответствующего тега.
Точно так ядовитый паук и скелет тоже экземпляры одного класса. Но у паука есть тег "ядовитый", который дает шанс отравления при атаке, а у скелета "нежить" и "костяной", который отменяют лечение и урон от дистанционных атак.
Плюс такого подхода, что изменять свойства объектов можно прямо на ходу. Некромант оживляет трупы? Бах, оживляем существо и добавляем тег "нежить" и вот уже ядовитый мертвый паук, с шансом отравить при атаке и не котого не действует лечение, марширует по полю.
Редкая магическая наковальня, положили любой предмет - бах! добавился тег "слотабл" и в предмет можно вставить драг камень, что повышает характеристики.
Так меч, мешок и ключ это один класс предмет, но у первого есть тег "оружие", который позволит его взять в руку, у второго "контейнер" который позволит другим предметам ссылаться на него указывая, что они в нем лежат, а у третьего тег "квестовый" который не даст продать его у торговца.
Да, опережая вопрос - что-ли хранить для предмета весь набор параметров на все случаи тегов, типа "урон", "прочность" и "вместительность", "от какой двери ключ"?
Такие параметры лучше хранить в виде динамического ассоциативного массива ключ-значение, и добавлять при появлении соответствующего тега.
Точно так ядовитый паук и скелет тоже экземпляры одного класса. Но у паука есть тег "ядовитый", который дает шанс отравления при атаке, а у скелета "нежить" и "костяной", который отменяют лечение и урон от дистанционных атак.
Плюс такого подхода, что изменять свойства объектов можно прямо на ходу. Некромант оживляет трупы? Бах, оживляем существо и добавляем тег "нежить" и вот уже ядовитый мертвый паук, с шансом отравить при атаке и не котого не действует лечение, марширует по полю.
Редкая магическая наковальня, положили любой предмет - бах! добавился тег "слотабл" и в предмет можно вставить драг камень, что повышает характеристики.
Re: jarg
А где будет находиться код, реализовывающий это поведение?Oreyn писал(а):но у первого есть тег "оружие", который позволит его взять в руку, у второго "контейнер" который позволит другим предметам ссылаться на него указывая, что они в нем лежат, а у третьего тег "квестовый" который не даст продать его у торговца.
Если бы оружие и контейнеры были отдельными классами, все специфичное поведение можно было реализовать в этих классах. А если это задается тегами - то нужно либо делать разбросанные по всей программе проверки на эти теги, либо делать теги классами и реализовывать это поведение в них.
Конечно, система с тегами более расширяема. Но допустим у нас меч - это всегда просто оружие (которое может иметь один набор специфических свойств, вроде "тип оружия - меч", "урон огнем", "требует навык - фехтование"), а сундук - просто сундук (который может иметь свои "теги", вроде "снижает вес предметов внутри", "может хранить только - свитки").
Тогда, на мой взгляд, проще сделать классы "оружие" и "контейнер" наследуемые от класса предмет, а теги "оружие" и "контейнер" потребуют дополнительных усилий в реализации - даже если у нас никогда не появится меча-сундука, разработчику придется продумывать этот вариант, ведь формально никто не запрещает дать оба этих тега предмету.
- Jesus05
- Сообщения: 1840
- Зарегистрирован: 02 дек 2009, 07:50
- Откуда: Норильск, сейчас Санкт-петербург.
- Контактная информация:
Re: jarg
Мне не кажется это проблемой... мечь-сундук чем он отличается от сундука и меча? по сути ничем. им можно бить как мечем тэг оружия полностью работает как есть... в него можно засунуть предметы тэг сундука работает. другое дело если надо реализовать выпадение предметов при ударе, это да надо будет взаимдействие этих тэгов писать.kipar писал(а): а теги "оружие" и "контейнер" потребуют дополнительных усилий в реализации - даже если у нас никогда не появится меча-сундука, разработчику придется продумывать этот вариант, ведь формально никто не запрещает дать оба этих тега предмету.
- Cfyz
- Сообщения: 776
- Зарегистрирован: 30 ноя 2006, 10:03
- Откуда: Санкт-Петербург
- Контактная информация:
Re: jarg
Ну может такое быть, конечно, что есть только "предмет", а у него просто набор тегов-меток. Но куда вероятнее расклад, когда меч -- это экземпляр "оружия", у которого есть некоторые свойства -- скажем, вес и урон. У сундука, экзмпляра "контейнера", в свою очередь есть свойство максимальной вместимости и список вещей -- и т. д. Если попытаться обойтись без четкого разделения, так чтоб все могло быть, получится каша из полей.Jesus05 писал(а):Мне не кажется это проблемой... мечь-сундук чем он отличается от сундука и меча? по сути ничем.
Логичным шагом выглядит сделать "теги" не просто метками, а самостоятельными кирпичиками, включающими в себя необходимые тегу поля, но и это не подарок. Ломает типизацию в коде (которой, впрочем, в некоторых ЯП и нет) и ввиду чрезмерной (полной) изолированности полей отдельных тегов друг от друга приводит к постоянным проверкам, приведениям и прочему спагетти.
Пытается раскуклиться
-
- Сообщения: 4
- Зарегистрирован: 31 авг 2013, 15:37
Re: jarg
По-твоему, объект должен знать, как он выглядит и уметь отрисовываться? Как тогда будет достигаться абстракция относительно UI? Или она не нужна?Cfyz писал(а):По-моему, тут распространненный случай over-engineering. Вот например с отрисовкой, чаще всего нет никакого смысла выносить ее в "классы", как правило отрисовка отдельных объектов алгоритмически ничем не отличается, будь это буквы ASCII, тайлы или даже 3D-модели. Внешнее оформление -- это лишь свойство объекта, но не его уникальная характеристика.
перекомпилировать.
Если я правильно понял, ты предлагаешь дать объекту (Creature, MapObject, ... - не важно, любому, что может стоять на карте) поле "картинка" и метод "отрисоваться"? Не логичнее выделить вообще UI в отдельную сущность и дать возможность отрисовщику как части UI решать, как будет выглядеть <что угодно> в зависимости от этого <что угодно> характеристик?
-
- Сообщения: 4
- Зарегистрирован: 31 авг 2013, 15:37
Re: jarg
а зачем эта чрезмерная абстракция? и почему, если тебе она нужна, ты не можешь просто наследовать и меч, и сундук от одной сущности? объекты нужны для того, чтобы очертить класс сущностей, схожих по функционалу; у меча и сундука разные функционалы.Jesus05 писал(а): Мне не кажется это проблемой... мечь-сундук чем он отличается от сундука и меча? по сути ничем. им можно бить как мечем тэг оружия полностью работает как есть... в него можно засунуть предметы тэг сундука работает. другое дело если надо реализовать выпадение предметов при ударе, это да надо будет взаимдействие этих тэгов писать.
у оружия может быть десяток характеристик и, скажем, ссылка на функцию, которая дает этому оружию уникальную фишку; могут быть методы, которым нужны именно оружия. в этом случае "меч" и "сундук" как экземпляры одного класса - это, как минимум, странно?
или я не понял, о чем ты говоришь? поясни, пожалуйста, я новичок в ООП и хотелось бы послушать умных, опытных людей.
- Cfyz
- Сообщения: 776
- Зарегистрирован: 30 ноя 2006, 10:03
- Откуда: Санкт-Петербург
- Контактная информация:
Re: jarg
aLeverkuhn, по поводу отрисовки ты или процитировал не того человека, или невнимательно прочитал мое сообщение. Как раз про абстракцию отображения от логики объекта я и говорю.
Пытается раскуклиться
-
- Сообщения: 4
- Зарегистрирован: 31 авг 2013, 15:37
Re: jarg
значит, я тебя неправильно понял =))Cfyz писал(а):aLeverkuhn, по поводу отрисовки ты или процитировал не того человека, или невнимательно прочитал мое сообщение. Как раз про абстракцию отображения от логики объекта я и говорю.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 42 гостя