ещё больше мне нравится коммент парня на оф. сайте:
"Господи, я ж только вчера купил подписку!!!"
да, для некоторых людей данная новость просто подстава..)
Подписчикам выдали 30 баксов на покупку ассетов. Тем, кто купил подписку буквально недавно, это даже выгодней.
alexprey, начитавшись примеров по SOLID (которому в определенной мере должен следовать мой код на работе), я изначально предположил, что интерфейсы обычно придумываются так, чтобы был смысл создавать объект, реализующий только этот интерфейс. То есть, если у меня есть методы А, B и C, и у меня вряд ли будут объекты, которым будет нужен исключительно метод B или C, то нет смысла создавать отдельно интерфейс на каждый из них. Поэтому я решил, что для этих четырех случаев (объект использует только метод А, объект использует методы A и B, объект использует методы A и C, объект использует все методы) лучше всего сделать базовый интерфейс с обозначением метода А (сам по себе подходит для первого случая), от него создать интерфейсы с методами B и C (подходят для второго и третьего случаев), а для четвертого случая оптимально будет наследовать класс от второго и третьего интерфейса.
Но это было вчера, я с того времени существенно поменял "мировоззрение", и теперь у меня методы B и C, все же, в отдельных интерфейсах, независящих от интерфейса с методом А.
И это не меняет суть вопроса, который был не "стоит ли это использовать", а "как это работает". На который мне, кстати, уже давно дали ответ.
GeneralElConsul, понятно. Просто мало работал с интерфейсами, и не особо понятно, если у меня класс наследуется от трех интерфейсов с одинаково названным методом, то какой из них будет реализован в классе.
Ну, куратор на работе сказал, что задание надо делать с учетом этих принципов, ибо это необходимый опыт для командной разработки. Вот я и пытаюсь разобраться.
S - один класс на одну задачу, сложные задачи разбиваются до подзадач и, соответственно, получаем один класс на большую задачу и по классу на подзадачу. Условно можно выразить так "если класс занимается выпеканием хлеба, то он не должен заниматься его доставкой". Важно не увлекаться дроблением сверх меры на этапе проектирования - если видишь что класс начинает разбухать и обрастать группами не связанных методов, то самое время использовать этот принцип.
Так суть принципа - уменьшить количество методов в классе, или инкапсулировать различные обязанности? Если в пекарне сделали отдельно отдел доставки и отдел выпечки, всё равно придется обращаться и к тому, и к тому (если я в примере в классе PointOfSaleTerminal вынесу в отдельный класс методы Scan и Reset, так как они отвечают за менеджмент списка покупок, всё равно надо будет оставить методы, которые будут вызывать Scan и Reset с нашего подкласса). prog:
D - суть в том, чтобы разорвать связи между объектами, находящимися на разных уровнях абстракции. Применяется в обоих направлениях - и для менее абстрактных объектов, включенных в более абстрактный и наоборот, более того - применяется не только при прямом включении, но и к любым другим ссылкам. Предположим нам нужно составить програмную модель кирпичной стены, класс стены не должен ничего знать о конкретных реализациях кирпичей и работать с любыми кирпичами, какие ему дадут, а кирпичи не должны напрямую зависеть от конкретных реализаций стены и быть пригодны к использованию в любой стене (или другой конструкции, если модель подразумевает не только стены).
Грубо говоря, использовать в классах не прямые типы в ссылочных переменных, а интерфейсы? Чтобы туда можно было всунуть экземпляр любого класса, реализующего интерфейс?
Ладно, куратор потом всё равно сказал, что не страшно, если не всё будет подчиняться этим принципам. Правда, теперь непонятно, зачем я два дня сидел практически без дела.
Чтобы упростить задачу, перегружу немного дополню вопрос своими соображениями (как я понял аспекты SOLID)
Насколько я понял, L - просто концепция, при которой в программе экземпляр класса можно заменить экземпляром его дочернего класса, без ущерба программе; O - по сути, не должно быть классов, выполняющих "избыточную" работу, то есть, если мне надо выполнять некоторые базовые действия, и в некоторых случаях, кроме базовых выполнять еще дополнительные, то надо создать базовый класс с базовыми действиями, а дополнительные прописывать уже в классе, наследующем базовый; I - если методы класса можно разделить на тематические группы, то лучше всего каждую группу делать отдельным интерфейсом.
Немного непонятно, что требуется в D. Если у нас класс A включает в себя экземпляр класса B, то соответственно этому принципу, лучше взять какой-то интерфейс I, наследовать класс B от этого интерфейса, и переменную в классе A тоже стоит сделать в виде интерфейса I?
Принцип S говорит "не надо нагружать класс методами, выноси функционал в отдельные классы", однако, с этим можно дойти до того, что на каждый метод надо будет делать отдельный класс. Или тут надо выделять определенные категории, как в принципе I?
Если не говорить о конкретной задаче выше, вы можете подтвердить или опровергнуть мои соображения?
Археология - комментирование практически неактуальных ресурсов. Я думаю, пока проект имеет статус "активен", его главную страничку негоже считать неактуальным ресурсом. Или вы уже похоронили проект? =)
girvel, вот мне, кстати, стало интересно - нужны ли программисту, отвечающему за алгоритм генерации, какие-либо познания в левел-дизайне, чтобы уровни в итоге получались внятными.
А вообще называть треугольники полигонами - это из модмейкинга Warcraft 3
Как бы, довольно много движков работает именно с треугольными полигонами. Когда я работал в UDK, там было условие - модель на импорт должна состоять именно из треугольников.
PhysCraft, одна из моих старых идей была похожей, события происходили в мире, заселенном одними роботами, а для апгрейдов надо было собирать наномашины с останков других роботов. Идея, на самом деле, не такая уж и сложная. Но, мне вообще нужна не столько идея, сколько художник :D И я имел ввиду "идею придумаем сообща с художником" :D NixEon, вообще, как только найду художника, и мы набросаем хотя бы какую-то концепцию, по которой можно сделать что-то играбельное, так сразу. Ну, или в ближайшее свободное время (надо понимать, что это пока не больше, чем хобби, и что у меня есть основная работа, так что я не требую полного акцентирования на проекте).
ZLOI_DED, для тех, кто не совал свой нос в Unity, объясняю: GUI в Unity - класс, который позволяет программно рисовать интерфейс, эту систему еще называют Legacy GUI, но когда говорят GUI в контексте Unity - подразумевают именно ее. Когда говорят о новой системе, чаще всего говорят uGUI, но это еще не прижилось, поэтому много кто до сих пор просто называет ее "новой системой UI".
Надеюсь, когда вы фейспалмили, вам было больно.
если у геймдевелопера нет левел-дизайнера, то левел-дизайном ему приходится заниматься самому.
Значит он и есть в данном случае левел-дизайнер.
То, что человек сам себе готовит еду, не делает его поваром.
А вообще, любой аспект может быть сделан без участия специалиста в этой области. Другое дело - вероятность того, что на выходе получится качественный результат.
Лучше эту ссылку выложите. И вообще, можно оформить ее. Замените ссылку на что-то типа этого
__Ссылка на проект на Greenlight__ (http://steamcommunity.com/sharedfiles/filedetails/?id=389589555)
На некоторых скринах в обилии видно округлые объекты. Та же Monument Valley, к примеру. Круглая поверхность - много полигонов. Разве это не перечит основному принципу лоу-поли?
Почему, когда выкладываешь тот же материал на фейсбуке, люди лайки ставят, говорят, мол, продолжай, дай поиграть потом, удачи... а тут все сразу учительствовать начинают.
Если ты пришел по плюсики да хвалебные оды, и любой другой фидбек тебя раздражает, то да, этот сайт не очень подходит для подобного.
Как и многие другие, кстати. На ГД ты получил бы еще более жесткую критику, на Гамине твой проект начали бы обсуждать с точки зрения оригинальности.
NixEon, позже будут условия прохождения уровня, как обязательные, так и необязательные. Да и когда контента будет больше, и баланс будет отточен, боевка может стать интересней.
» Unreal Engine / Unreal Engine 4 - теперь условно бесплатно!
» Unreal Engine / Unreal Engine
Отредактирован lentinant
» lentinant'ов блог / Микрообзор: Класс Убийц (Ansatsu Kyoushitsu)
Отредактирован lentinant
» Программирование / Реализация нескольких интерфейсов с общим родителем
» Программирование / Реализация нескольких интерфейсов с общим родителем
Отредактирован lentinant
» Программирование / Реализация нескольких интерфейсов с общим родителем
Отредактирован lentinant
» Программирование / Принципы SOLID
prog:
Отредактирован lentinant
» Программирование / Принципы SOLID
перегружунемного дополню вопрос своими соображениями (как я понял аспекты SOLID)Насколько я понял, L - просто концепция, при которой в программе экземпляр класса можно заменить экземпляром его дочернего класса, без ущерба программе; O - по сути, не должно быть классов, выполняющих "избыточную" работу, то есть, если мне надо выполнять некоторые базовые действия, и в некоторых случаях, кроме базовых выполнять еще дополнительные, то надо создать базовый класс с базовыми действиями, а дополнительные прописывать уже в классе, наследующем базовый; I - если методы класса можно разделить на тематические группы, то лучше всего каждую группу делать отдельным интерфейсом.
» Unreal Engine / Unreal Engine
Отредактирован lentinant
» Low-Poly Art в игровой индустрии / Сложности игровой разработки
» Low-Poly Art в игровой индустрии / Сложности игровой разработки
» Low-Poly Art в игровой индустрии / Техники моделирования Low-Poly Art'a
» Dead Eternity / Пиксель Арт
Отредактирован lentinant
» lentinant'ов блог / Ищу художника
NixEon, вообще, как только найду художника, и мы набросаем хотя бы какую-то концепцию, по которой можно сделать что-то играбельное, так сразу. Ну, или в ближайшее свободное время (надо понимать, что это пока не больше, чем хобби, и что у меня есть основная работа, так что я не требую полного акцентирования на проекте).
» Mental State / Mental State. "Система мыслей" и новые игровые элементы.
Надеюсь, когда вы фейспалмили, вам было больно.
» Low-Poly Art в игровой индустрии / Сложности игровой разработки
А вообще, любой аспект может быть сделан без участия специалиста в этой области. Другое дело - вероятность того, что на выходе получится качественный результат.
» Mental State / Mental State. "Система мыслей" и новые игровые элементы.
Отредактирован lentinant
» Beyond Despair / OWSP на Greenlight!
__Ссылка на проект на Greenlight__ (http://steamcommunity.com/sharedfiles/filedetails/?id=389589555)
» Beyond Despair / Главная страница
Отредактирован lentinant
» Low-Poly Art в игровой индустрии / Что такое Low-Poly Art?
Отредактирован lentinant
» Block Temple Advanced / Недоновость: переработка интерфейса
» Secrets Rooms / Новые видео по "Secrets Rooms"
Как и многие другие, кстати. На ГД ты получил бы еще более жесткую критику, на Гамине твой проект начали бы обсуждать с точки зрения оригинальности.
» Block Temple Advanced / Недоновость: переработка интерфейса