![]() |
Цитата:
|
Цитата:
|
действительно странно,вроде скрывать методы в суперклассах штатными средствами никак нельзя,но зато можно так:
Код AS3:
|
Я в итоге проще придумал. Просто проверяю
Код AS3:
|
Потому что класс Object динамический.
Этот путь какой то странный, зачем по нему идти? Ты как-то невероятно представляешь себе программу, что она НЕ ЗНАЕТ что хочет. Я не понимаю, в какой ситуации программа может обращаться к длине бороды, не зная что ей нужна именно длина бороды. Не надо нам таких программ, не пиши их. |
Цитата:
|
Цитата:
Вот слегка почиканый для удобочитамости класс, выдающий словесные описания подсказок. Код AS3:
Там на самом деле уже штуки 3 открытых методов: один просто возвращает словесное описание, другой возвращает само значение в виде NN/100, ещё один сразу упаковывает это удовольствие для вставки в текст в виде: [борода: 88/100, военнопленный]. Зачем всё переписывать дважды для свойств Character и Gender? |
Цитата:
|
Друзья!
У меня ещё вопрос про бороду и талию. Поправил гендерные классы, как советовал Wolsh. В частности, сеттеры и геттеры мужских свойств "уехали" в GenderMale, а женских - в GenderFemale. Если в классе GenderMale имеем такой код: Код AS3:
Код AS3:
|
потому что сеттер/геттер - это не простые методы, к ним нужно обращаться как к переменным, без скобок
Код AS3:
|
Цитата:
Код AS3:
Error: Access of possibly undefined property beardLength through a reference with static type Gender. |
Цитата:
|
Цитата:
Добавлено через 5 минут Цитата:
И ведь они правы, нет. |
Цитата:
|
Цитата:
|
Цитата:
Но в любом случае не понимаю, на кой ляд он ломится в Гендер, если в public переменной character.gender на момент присвоения значения свойства уже хранится экземпляр класса GenderMale, т.е. именно подскласса, а не самого Гендера? Объясни плиз. |
Тогда почему тип свойства не GenderMale? Ага, чтобы там мог храниться экземпляр GenderFemale? Ну и как с бородой у неё?
Цитата:
|
Цитата:
Выходит, возвращаемся к тому, с чего начинали: в Гендере прописываем и бороды, и |
А почему ты решил, что у женщины не может быть свойства "длина бороды"? Напиши beardLength = 0;
В твоем случае разделение можно сделать немного по-другому. Добавь в Gender свойство beardLength, которое будет задавать длину бороды, но в GenderFemale сделай его перезапись Код AS3:
Я бы, на твоем месте, лучше сделал класс Human, и добавил ему свойство gender. А где надо просто проверял бы Код AS3:
п.с. У нашей училки по русскому в школе, была борода. При чем очень даже окладистая :D |
Цитата:
Выходит, что проще оставить просто класс Gender безо всяких подклассов, туда свалить все свойства: и бороды, и талии, и гениталии, а потом анализировать уже внутри класса, например, проверяя GenderID каждого экземпляра перед всеми дальнейшими действиями. Тогда встаёт вопрос, выигрываем ли мы что-нибудь, используя подклассы Gender? Я закладывал, что например, в случаях, где какие-то элементы механики обрабатываются по-разному для мужских и женских персонажей, мы можем создавать абстрактные классы и расширять их с использованием полиморфизма, передавая в них экземпляр подкласса Gender. |
Полиморфизм строится на переопределении, а то о чем говоришь ты — наличие одних свойств и отсутствие других — не имеет к нему отношения.
Полиморфизм это когда и мальчик и девочка имеют метод piss(), но реализуют его по-разному. В твоем случае ты мог бы спокойно обращаться к .gender и вызывать этот метод, и если бы .gender хранил ссылку на экземпляр подкласса GenderMale, то выполнялся бы его метод, а GenderFemale делала бы это по-другому. И тебе НИГДЕ не нужно было бы разбираться, мальчик там или девочка. Добавлено через 20 минут И еще. Когда ты пишешь "Wolsh сказал делать так, Wolsh сказал делать сяк" — Wolsh отвечает на ТВОИ вопросы. Я же не знаю всю подноготную. Мне, например, не кажется полезным разделение Гендера на Мужской и Женский, вроде как 1 и 0 было достаточно (к тому же позволяет расшириться, введя 2, 3 и 100500). А если бы в игре были еще и расы? Эльфы там, с "длиной ушей", орки с клыками, гномы — женщин которых никто никогда не видел? Как справедливо заметил Кейси, и у женщины может быть борода, нет — значит ее длина ноль; и у мужчин есть и талия и грудь. Я бы не стал из-за ЭТИХ свойств делать разводку на два подкласса, НО. Я ведь не знаю предысторию этого разделения. Может как раз и подразумевалось переопределение методов в дальнейшем, чтобы мальчики и девочки делали одно и то же по-разному. |
Цитата:
Цитата:
Цитата:
|
Какая-то у вас товарищи абсурдная абстрактная задача Gender, никто в здравом уме не будет её таким образом решать. ООП не нужно делать ради ООП, нужно делать от задачи: удобства, расширяемости, управляемости, устойчивости, простоты, раскрепощенности, определенности, жесткости, все остальное лишь пыль, если не исполняет цели задачи
|
Цитата:
Еще раз, этот мой спич касался полиморфизма. Полиморфизм это не всё ООП, это один из принципов, который можно также грубо переформулировать, как "класс-наследник может замещать суперкласс, используя свою реализацию". Наследник замещает суперкласс, но не наоборот! И если ты завел у наследника новые свойства и методы, для работы с ними ты должен обращаться с наследником конкретно, а не абстрактно. Возможно, ты как-то по-своему понял термин "расширяет", как будто наследник ИЗМЕНЯЕТ свой суперкласс, добавляя что-то к НЕМУ. Но нет, он добавляет только СЕБЕ, но добавляет к тому, что досталось ЕМУ в наследство, в этом смысле он "расширяет". Но "старая версия" остается как есть. Вобщем, из всего этого хотя бы вынеси понимание полиморфизма, уже плюс к скиллам :) |
Цитата:
Цитата:
Цитата:
|
Други!
Возвращаюсь в эту тему с очередным концептуальным вопросом. Каждый раз, когда мне требуется реализовать очередную функцию, я дико мучаюсь, куда её, пардон, вставлять. С одной стороны, имеем понятие "single responsibility", что несомненно есть благо. Но в пределе такой подход означает - "один метод - один класс" (причём иногда именно так и происходит). Поэтому мой вопрос - о критериях выделения каких-то функций/методов в самостоятельные классы или, напротив, группировки их в один класс. И если с первым хоть как-то интуитивно понятно, то со вторым - полная каша в голове. Вот например, обсуждаем в соседней теме вопросы многоязычности приложения. Понятно, что весь функционал загрузки данных из XML лучше выделить в отдельный класс и наладить с ним простое как грабли взаимодействие: ты ему ID-шник, он тебе обратно - фразу (в моём случае массив фраз, но это неважно). Никаких вопросов. Но вот, например, есть функционал (также обсуждавшийся в этой теме выше) подбора словесных расшифровок для свойств персонажа, типа "дурак - умный - гениальный". Там уже не просто запрос варианта, но и некая логика, основанная на текущих значениях свойств персонажа, таким образом, он взаимодействует с классом Character. Его можно выделить в полностью самостоятельный класс, можно создать что-то типа CharacterModel и поместить туда вместе с другими методами обработки свойств персонажа... Или ещё пример. Для построения удобочитаемых фраз имеем алгоритм подстановки в полученный кусок текста имени собственного в нужном падеже. Он получает фразу из XML, плюс "знает" что должно быть в него подставлено вместо *$a1. Другой метод получает на входе оценку двух частей сложносочинённого предложения и выдаёт связующий союз (типа "ему охота, и ей охота" и "ему охота, но ей не хочется"). Вроде метод тоже языковой... Имеет смысл объединять их вместе или нет? Какая логика? Не чувствую её. :( |
Чувствую, скоро дойдет до того, что нужен будет метод, который должен будет определять, написать "поребрик" или "бордюр" в зависимости от текущей локации игрока)
Для игры, которая не имеет целью учить игрока русскому языку, всё это абсолютно излишне. Лучше сделать хороший и интересный гейплей, чем сделать скучную и унылую игру, но зато с правильным правописанием диалогов. Которые, по многочисленным личным наблюдениям, всё равно почти никто не читает. Диалоги в играх вообще должны сводиться к минимуму, это наводит на игрока скуку. Меньше текста, больше действия. Все предложения должны быть максимально короткими и простыми |
Цитата:
Цитата:
Пока сам надумал немного. Есть мысль №1 о том что поскольку условий может быть много, и точное их количество неизвестно для различных случаев, это должен быть некий массив, который будет передаваться на входе в метод-определитель доступности, чтобы он - метод - пробегал по всем и давал итоговое заключение на выходе: либо всё соблюдено, либо № элемента, который "не проходит". Мысль №2, что если у нас все характеристики персонажей (и не только персонажей) заданы через строковые идентификаторы типа "character.intelligence", то их можно и запихивать в массив с условиями, чтобы быстро обратиться за соответствующим значением. А вот всё остальное (запись и хранение целевых значений, операторов сравнения и т.п.) пока не находит ответов. |
Цитата:
Не приходилось такого делать, но представляю это себе примерно так: Диалог представляет из себя объект, приблизительно такого вида Код AS3:
Код AS3:
|
Цитата:
На самом деле я тружусь над игрой в редком нынче жанре текстового квеста, как в Космических рейнджерах были. Мне явно пороху не хватит сейчас на более серьёзную реализацию. Поэтому вопрос качественных текстов имхо не менее важен, чем хорошие арты. Цитата:
|
квадратные скобки — массив; а в нем лежат Обжекты.
|
Цитата:
Цитата:
Есть возможность каким-то образом так формулировать условия в этих самых обжектах, чтобы они сразу были указателями на нужные свойства и типы сравнения? Например, у нас есть строковые идентификаторы свойств персонажей, которые совпадают с именами переменных класса Character. Таким образом, если нам нужно "вытащить" значение свойства intelligence, которое хранится в нашем списке условий в переменной prop1:String = "intelligence", то мы просто обратимся character[prop1 as String] (если я ничего не путаю в синтаксисе по неопытности). Я думаю, понятно, что имеется в виду. |
Код AS3:
Лучше делать так: Код AS3:
Код AS3:
|
Друзья!
Я с разработкой своей игрушки продолжаю неспешное движение вбок (по тому анекдоту про аспиранта, которому двигать науку вперёд мозгов не хватает, а назад - научный руководитель не позволяет :)). Возникло ещё несколько вопросов. Помимо собственных игровых свойств, у персонажа есть свойства, получаемые от других объектов. Самый простой пример из RPG-жанра - всякие модификаторы от экипировки. Например, надетый на голову шлем "Толоконный лоб" даёт +1 к интеллекту, понятно. Раздумываю, как организовать это дело в программе. Явно напрашивается отдельный класс для шмоток Item, и наш шлем будет храниться в какой-нибудь переменной данного типа или его наследника (например ItemHat). Вопросы: Во-первых, насколько хорошей практикой считается создание "раскидистых" деревьев наследования для случаев, подобных описанному? Ведь игровых предметов может быть десяток-другой разнообразных типов, некоторые могут также ветвиться ещё дальше... Преимущества - в том, что во-первых, можно чётко разграничивать, какие типы куда применимы, а во-вторых, при создании интерфейса пользователя в распоряжении будет уже готовая структура. Верно ли я рассуждаю? В чём недостатки такого подхода? Во-вторых, чтобы "надеть" шлем на персонажа, его объект должен содержать соответствующий "слот". В моём понимании, это свойство hatUsed:ItemHat класса Character. Соответственно, оно может быть либо пустым, если ничего не надето, либо туда будет помещаться один из экземпляров класса ItemHat. Вопрос, правильно ли я рассуждаю и правильно ли я представляю, что подобные вещи прорабатываются сразу в пакете data (а не model). В-третьих, создав классы для предметов, где-то в программе необходимо создать и сами предметы, т.е. экземпляры классов. Где и каким образом обычно это делается? Я пока прямо в Main нафигачил несколько для теста, но это не комильфо. Плюс встаёт вопрос идентификации этих экземпляров. Если мы говорим не о "генерёнке", а об "именных" предметах или NPC, то для них сразу резервируется некая переменная нужного типа, в которую записывается экземпляр, верно? В-четвёртых, возник ещё любопытный вопрос. Допустим, у персонажа может быть свойство, принимающее одно из заранее определённых значений (отвлечённо - это знак зодиака, чтобы было понятно, о чём идёт речь). Присвоенное персонажу значение учитывается игровой механикой в определённых ситуациях. Здесь можно было бы по аналогии создать класс Zodiac с 12 экземплярами по числу знаков и присваивать персонажу один из них. Но в описанной ситуации кроме собственно имени экземпляра для корректной работы больше ничего не требуется, и городить целый класс кажется излишним. С другой стороны, коллега wolsh предостерегал от замены Strong-типизации на String-типизацию. Где истина? Спасибо! |
Цитата:
Код AS3:
Цитата:
|
В Скайриме например считается, что на голову может быть надет только один предмет — надеваешь капюшон, обруч снимается, надеваешь шлем — снимается капюшон.
Но когда добавили расширения с новыми миссиями и новыми предметами, кто-то лоханулся и получилось так, что предметы из этой новой коллекции можно надеть "поверх" других. В частности, фалмерский шлем можно надеть поверх обруча или капюшона. Казалось бы ну и фиг с ним, баг и баг. Но фишка в том, что предмет это не просто предмет. На него можно накладывать зачарования, которые дают нехилые бонусы к навыкам или статам. И, нацепив на голову два предмета, повышающих искусство Лучника, ты завалишь целого дракона одной ржавой стрелой. Так что не надо тут))) Система должна быть четкой и не давать преференций свыше правил. Добавлено через 4 минуты Цитата:
Другое дело, если у предметов есть свой жизненный цикл, если они изнашиваются при каждом применении и т.п. То есть МЕНЯЮТСЯ свойства конкретных экземпляров. |
Цитата:
Цитата:
Цитата:
|
В чем его ответственность, этого экземпляра хорошей старой банданы?
Что он вообще должен уметь делать? Не слишком ли много чести создавать для него класс? Другими словами, что это вообще? Когда ты говоришь про этот экземпляр, что ты видишь? Что имеешь в виду? |
Цитата:
Цитата:
Код AS3:
|
Я имел ввиду как то так
Код AS3:
|
| Часовой пояс GMT +4, время: 18:35. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.