jarg

Форум для проектов, находящихся на стадии Альфа и Бета. В них ещё не реализована вся задуманная автором функциональность, а значит идёт активная разработка.

Модераторы: Sanja, Максим Кич

Siri0n
Сообщения: 31
Зарегистрирован: 19 авг 2013, 10:31

Re: jarg

Сообщение Siri0n » 22 авг 2013, 10:15

Здорово. А потыкать можно?

Аватара пользователя
Foxman
Сообщения: 246
Зарегистрирован: 19 янв 2012, 20:30

Re: jarg

Сообщение Foxman » 24 авг 2013, 06:44

Если интересно, можешь посмотреть исходники Бусикатора, тоже но OpenTK, исходники открыты. Все что касается OpenTK вынесенно в отдельную сборку
http://rlgclub.ru/forum/viewtopic.php?f=25&t=734

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: jarg

Сообщение Jesus05 » 06 сен 2013, 09:53

ishellstrike писал(а):Товарищи, я в раздумьях....
Если твоя задача именно сохранить ООП. то сделай блокам "интерфейс" в котором будут методы только для получения данных отрисовки. и пусть рисовальщик берет блоки только через этот интерфейс.

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: jarg

Сообщение Jesus05 » 06 сен 2013, 10:04

ishellstrike писал(а):Jesus05, практически так и есть, вопрос скорее в том, как хранить данные, в свойствах класса, производного, от класса блок, т.е. класс стол, класс стул. Или дальше хранить в одной большой базе, а блоки оставить одинаковыми.
Я думаю, что можно хранить и в одной большой базе.
Думаю что усложнение и разнос на классы "стол" и "стул" не нужно и оно противоречит борьбе со сложностью.

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: jarg

Сообщение Jesus05 » 06 сен 2013, 10:35

ishellstrike писал(а):Jesus05, просто меня печалят конструкции вида

Код: Выделить всё

IBlock a = GetBlock(x,y);
...=BlockDataBase.Data[a.Id].Description
if(BlockDataBase.Data[a.Id].Prototype == typeof(BlockTable)) {
...=BlockDataBase.Data[a.Id].%поле, характерное для стола%
}
где Description и т.д. -- открытые поля в статическом классе BlockDataBase, от статичности можно конечно избавиться

в ооп подходе было бы

Код: Выделить всё

IBlock a = GetBlock(x,y);
...=(a as Block).Description
if(a is BlockTable) {
...=(a as BlockTable).%поле, характерное для стола%
}
где Description и т.д. -- открытые только для чтения свойства, экземпляра нашего блока. Соответственно у винтовки нет свойств стола.
А не замучаешься все типы объектов приписывать в коде, и на каждый делать класс... а чем отличаться будут эти классы?

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: jarg

Сообщение Jesus05 » 06 сен 2013, 10:44

мои прошлые размышления на эту тему там -> http://rlgclub.ru/forum/viewtopic.php?p=8114#p8114 начиная с этого сообщения и ниже.

Аватара пользователя
Cfyz
Сообщения: 776
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: jarg

Сообщение Cfyz » 06 сен 2013, 11:39

(то, что я скажу, может быть и мимо, ведь я так и не понял что именно ты подразумеваешь под "безликим блоком": объект на карте, ячейка карты, описательный блок в базе, etc.)

tl;dr Объекты в классы 1:1 нельзя, надо делать небольшое количество фундаментально различных классов-сущностей.
ishellstrike писал(а):Да, в этом то и вся проблема, отличаться стол от стола, по сути, будут, только свойством, возвращающим их спрайт, ну и свойством-именем
Если стол и стул отличаются только спрайтом и именем, то это одна сущность ("фурнитура", скажем) и нет смысла разделять ее. Если два объекта отличаются только содержимым полей, но не их количественным или качественным составом, то это один класс объектов.
ishellstrike писал(а):Добавиться гибкости, но пропадет добавление контента без перекомпиляции
Такие аргументы меня всегда смущали. ООП это же не классы по поводу и без, это в первую очередь логическое разделение. Разные классы объектов, т. е. разные сущности, они должны вести себя по-разному. Если выходит, что они не ведут себя по-разному, не требуют фундаментально разных алгоритмов для обработки (и не требуют перекомпиляции), то это означает лишь ошибку в проектировании, и это на самом деле один класс, объекты которого отличаются только содержимым, которое обрабатывается одинаково для всех объектов этого класса. И это нормально, что программу приходится перекомпилировать из-за добавления или модификации алгоритма =).
ishellstrike писал(а):ЧТобы они сами себя рисовали и обновляли.
По-моему, тут распространненный случай over-engineering. Вот например с отрисовкой, чаще всего нет никакого смысла выносить ее в "классы", как правило отрисовка отдельных объектов алгоритмически ничем не отличается, будь это буквы ASCII, тайлы или даже 3D-модели. Внешнее оформление -- это лишь свойство объекта, но не его уникальная характеристика.

С обновлением немного сложнее, но и тут по-моему лучше посмотреть на проблему максимально широко и вычленить общее из хаоса. К примеру, то, что "стол" может сгореть (и его нужно обновлять для достижения желаемого эффекта) -- это не уникальное свойство стола, из-за одного которого его стоит выносить в отдельный класс предметов, это лишь следствие его материала. Идентичное поведение будет (или по крайней мере, должно быть) у всех деревянных предметов. С другой стороны, "ящик" он тоже может быть деревянный, но это несущественно, его поведение качественно отличается возможностью агрегировать в себе другие предметы, что уже делает его кандидатом на самостоятельную сущность "контейнер".

При этом добавление простого предмета -- это тривиальное событие, будь он деревянным или нет, будь он столом или стулом или драгоценным камнем. Это можно и в базе хранить строками. Но добавление в игру такой сущности, как "контейнер" (будь то ящик, сундук или мешок) сразу меняет логику программы -- потребуется сделать специальное окно с содержимым, пункты в меню чтобы положить/выкинуть и т. д. Вот это уже ни в какую базу, разумеется, не влезет, это придется делать кодом и, куда уж денешься, перекомпилировать.
Пытается раскуклиться

Аватара пользователя
Oreyn
Сообщения: 297
Зарегистрирован: 07 авг 2013, 14:59

Re: jarg

Сообщение Oreyn » 06 сен 2013, 12:51

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

Точно так ядовитый паук и скелет тоже экземпляры одного класса. Но у паука есть тег "ядовитый", который дает шанс отравления при атаке, а у скелета "нежить" и "костяной", который отменяют лечение и урон от дистанционных атак.
Плюс такого подхода, что изменять свойства объектов можно прямо на ходу. Некромант оживляет трупы? Бах, оживляем существо и добавляем тег "нежить" и вот уже ядовитый мертвый паук, с шансом отравить при атаке и не котого не действует лечение, марширует по полю.
Редкая магическая наковальня, положили любой предмет - бах! добавился тег "слотабл" и в предмет можно вставить драг камень, что повышает характеристики.

Аватара пользователя
kipar
Сообщения: 2120
Зарегистрирован: 10 мар 2010, 13:16
Откуда: Москва

Re: jarg

Сообщение kipar » 06 сен 2013, 13:15

Oreyn писал(а):но у первого есть тег "оружие", который позволит его взять в руку, у второго "контейнер" который позволит другим предметам ссылаться на него указывая, что они в нем лежат, а у третьего тег "квестовый" который не даст продать его у торговца.
А где будет находиться код, реализовывающий это поведение?
Если бы оружие и контейнеры были отдельными классами, все специфичное поведение можно было реализовать в этих классах. А если это задается тегами - то нужно либо делать разбросанные по всей программе проверки на эти теги, либо делать теги классами и реализовывать это поведение в них.
Конечно, система с тегами более расширяема. Но допустим у нас меч - это всегда просто оружие (которое может иметь один набор специфических свойств, вроде "тип оружия - меч", "урон огнем", "требует навык - фехтование"), а сундук - просто сундук (который может иметь свои "теги", вроде "снижает вес предметов внутри", "может хранить только - свитки").
Тогда, на мой взгляд, проще сделать классы "оружие" и "контейнер" наследуемые от класса предмет, а теги "оружие" и "контейнер" потребуют дополнительных усилий в реализации - даже если у нас никогда не появится меча-сундука, разработчику придется продумывать этот вариант, ведь формально никто не запрещает дать оба этих тега предмету.

Аватара пользователя
Jesus05
Сообщения: 1840
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: jarg

Сообщение Jesus05 » 06 сен 2013, 13:58

kipar писал(а): а теги "оружие" и "контейнер" потребуют дополнительных усилий в реализации - даже если у нас никогда не появится меча-сундука, разработчику придется продумывать этот вариант, ведь формально никто не запрещает дать оба этих тега предмету.
Мне не кажется это проблемой... мечь-сундук чем он отличается от сундука и меча? по сути ничем. им можно бить как мечем тэг оружия полностью работает как есть... в него можно засунуть предметы тэг сундука работает. другое дело если надо реализовать выпадение предметов при ударе, это да надо будет взаимдействие этих тэгов писать.

Аватара пользователя
Cfyz
Сообщения: 776
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: jarg

Сообщение Cfyz » 06 сен 2013, 14:33

Jesus05 писал(а):Мне не кажется это проблемой... мечь-сундук чем он отличается от сундука и меча? по сути ничем.
Ну может такое быть, конечно, что есть только "предмет", а у него просто набор тегов-меток. Но куда вероятнее расклад, когда меч -- это экземпляр "оружия", у которого есть некоторые свойства -- скажем, вес и урон. У сундука, экзмпляра "контейнера", в свою очередь есть свойство максимальной вместимости и список вещей -- и т. д. Если попытаться обойтись без четкого разделения, так чтоб все могло быть, получится каша из полей.

Логичным шагом выглядит сделать "теги" не просто метками, а самостоятельными кирпичиками, включающими в себя необходимые тегу поля, но и это не подарок. Ломает типизацию в коде (которой, впрочем, в некоторых ЯП и нет) и ввиду чрезмерной (полной) изолированности полей отдельных тегов друг от друга приводит к постоянным проверкам, приведениям и прочему спагетти.
Пытается раскуклиться

aLeverkuhn
Сообщения: 4
Зарегистрирован: 31 авг 2013, 15:37

Re: jarg

Сообщение aLeverkuhn » 06 сен 2013, 14:51

Cfyz писал(а):По-моему, тут распространненный случай over-engineering. Вот например с отрисовкой, чаще всего нет никакого смысла выносить ее в "классы", как правило отрисовка отдельных объектов алгоритмически ничем не отличается, будь это буквы ASCII, тайлы или даже 3D-модели. Внешнее оформление -- это лишь свойство объекта, но не его уникальная характеристика.
перекомпилировать.
По-твоему, объект должен знать, как он выглядит и уметь отрисовываться? Как тогда будет достигаться абстракция относительно UI? Или она не нужна?
Если я правильно понял, ты предлагаешь дать объекту (Creature, MapObject, ... - не важно, любому, что может стоять на карте) поле "картинка" и метод "отрисоваться"? Не логичнее выделить вообще UI в отдельную сущность и дать возможность отрисовщику как части UI решать, как будет выглядеть <что угодно> в зависимости от этого <что угодно> характеристик?

aLeverkuhn
Сообщения: 4
Зарегистрирован: 31 авг 2013, 15:37

Re: jarg

Сообщение aLeverkuhn » 06 сен 2013, 14:57

Jesus05 писал(а): Мне не кажется это проблемой... мечь-сундук чем он отличается от сундука и меча? по сути ничем. им можно бить как мечем тэг оружия полностью работает как есть... в него можно засунуть предметы тэг сундука работает. другое дело если надо реализовать выпадение предметов при ударе, это да надо будет взаимдействие этих тэгов писать.
а зачем эта чрезмерная абстракция? и почему, если тебе она нужна, ты не можешь просто наследовать и меч, и сундук от одной сущности? объекты нужны для того, чтобы очертить класс сущностей, схожих по функционалу; у меча и сундука разные функционалы.
у оружия может быть десяток характеристик и, скажем, ссылка на функцию, которая дает этому оружию уникальную фишку; могут быть методы, которым нужны именно оружия. в этом случае "меч" и "сундук" как экземпляры одного класса - это, как минимум, странно?
или я не понял, о чем ты говоришь? поясни, пожалуйста, я новичок в ООП и хотелось бы послушать умных, опытных людей.

Аватара пользователя
Cfyz
Сообщения: 776
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: jarg

Сообщение Cfyz » 06 сен 2013, 15:11

aLeverkuhn, по поводу отрисовки ты или процитировал не того человека, или невнимательно прочитал мое сообщение. Как раз про абстракцию отображения от логики объекта я и говорю.
Пытается раскуклиться

aLeverkuhn
Сообщения: 4
Зарегистрирован: 31 авг 2013, 15:37

Re: jarg

Сообщение aLeverkuhn » 06 сен 2013, 15:17

Cfyz писал(а):aLeverkuhn, по поводу отрисовки ты или процитировал не того человека, или невнимательно прочитал мое сообщение. Как раз про абстракцию отображения от логики объекта я и говорю.
значит, я тебя неправильно понял =))

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя