боевая система — не совсем удачна я бы сказал. по ногам никто не бьет, а в предыдущей статье автор текущей как раз касался этой темы (спойлер — по ногам били много, особенно подготовленные неподготовленных). да и преимущества рипостов над атаками + постоянное прерывание комбо рипостами, идеальными блоками и уворотами врага практически выпиливают их из игры (модами немного правится, но все равно довольно проблемная система)
Добросовестный джун будет шерстить интернет в поисках таких вот мелких вопросов на «особенности», когда синьер понимает что эта дичь пригодится раз в год на минуту и сразу же после благополучно забудется. Порядочных разрабов отсеете больше чем бестолковых джунов-заучек.
Я обычно даю какую-нибудь задачку на то, с чем кандидат будет сталкиваться довольно часто, типа такой (я работаю с 3д-графикой поэтому тригонометрия крайне важна):
Задачка
Есть дверь, которая расположена в точке P1 и базисом [DoorRight, DoorUp, DoorForward] (DoorUp == GlobalUp). У двери есть 2 анимации открывания clockwise/counter-clockwise. К двери подходит персонаж с координатой в точке P2 и базисом [PlayerRight, PlayerUp, PlayerForward]. Определить какую из анимаций двери нужно запустить.
Она имеет как минимум 4 хороших варианта решения и если кандидат минут за 10 находит любое — голова варит, можно брать: нюансам синтаксиса научится, а вот пространственное мышление прокачивать нужно гораздо дольше.
Это не билд демо, а лог какого-то алгоритма. Если Вы предоставите это заказчику, он просто не поймет что это.
Да у вас у самого проект не 3Д
Это 3д-графика и 3-д мир, но да все события происходят в плоскости. Но я согласен и на 2-д игру взглянуть.
Спор о преимуществах ООП подхода и мой тезис был о том, что такой подход раскрывается лучше в более сложных задачах. Мне правда интересно посмотреть на толковую игровую логику использующую «не ООП» — был бы рад увидеть такой даже уже готовый игровой код. В случае, если Вы действительно хотите убедить кого-то в своей правоте (а не просто потешить свое самолюбие), это был бы конструктивный аргумент.
что писать такой код как у Вас — это неконструктивно
у читателей возникнут сомнения в Вашей адекватности
можно написать ООП код, но у вас, увы, это пока что не получается. Как и у всех, кого я знаю
это не ООП
Спасибо конечно за урок русского (не родной язык), но это все по прежнему нисколько не конструктивно и довольно высокомерно.
Согласно ООП ничто извне не должно менять поведение объекта. А что Вы делаете?
На самом деле там нет изменения объекта через константу, там оптимизация рейкаста при помощи константы. Из этого я делаю 2 вывода:
1) да, для текущей задачи это и правда было излишеством — сори, писал с оптимизацией по привычке.
2) хороший код должен быть очевиден даже для джуна и т.к. Вы его не поняли, то код и правда не так хорош.
Но это не ООП, это не компилится, и у этого до сих пор нет скринов — а вечер уже близко
Хм, а ведь и правда сказал. Ок, вот демка (как оказалось заняло это на Юнити около 40 мин):
а вот и код (интересующая часть практически не отличается от предоставленной изначально): https ://drive.google.com/open?id=1lw5Q7JRDzu3ET5OLs0ATA1Rw5s3iW5De
Ваш код больше похож на хаки джуна, это своеобразная мимикрия под продакшн-код в геймдеве. Я такого добра много видел на проектах второкурсников.
А с возрастом и опытом понимаешь
Ну так у Вас и не пахнет правильными абстракциями
Но у Вас всё хуже — у Вас дикая смесь
То, что принято использовать в низкобюджетном геймдеве
нелогичное нагромождение случайных шаблонов
Это не конструктивно.
не должно быть статических методов и глобальных констант. Всё должно быть реализовано на объектах.
Мои Globals да, попахивают, лучше эту константу хранить в спец. классе (да хоть в том же Физикс), но по сути это останется глобальной константой.
Без статических методов можно обойтись, но зачем? Это будет не оптимально — нужно выделять и освобождать память там, где это не нужно. Это просто методы, которые можно использовать без создания экземпляра класса. Почему статические методы противоречат концепции ООП?
Определитесь, пожалуйста, моя демка нерабочая или всё-таки решает задачу?)
Она не рабочая как демка. С таким же успехом можно было написать просто log(50-5) — т.е. это хардкод для одного случая. Мы по-разному смотрим на задачу: я вижу проблему взаимодействия Monster-Player, Вы, на сколько я понял, проблему отнимания хп. Первая решается при помощи ООП (особенно если подразумевается такое взаимодействие между различными объектами, а не только уловными Monster и Player), для второй, безусловно, ООП оверкил.
А Вы когда сможете?
Используя какой-то Unreal или Unity — к вечеру, но моя демка будет являться продуктом в который можно поиграть и, т.к. я потратил лишние 20 мин на проектирование структуры и еще 40 на имплементацию доп. слоев абстракций, можно будет в дальнейшем расширять, не переписывая все с 0.
Глобальные константы. в данном случае хранит битовую маску слоев с IAffectable объектами.
Где идёт разделение игровой логики, физической модели, геометрической модели и рендеринга?
Это игровая логика, использующая физику. За рендеринг обычно отвечает конвейер визуализации — это другая степь.
Коллайдер — это геометрия, а не физика
В гейм-деве часто коллайдеры используются как часть физической модели (примитивы — для упрощения расчетов).
Физика опять же бывает разная: кинематика, динамика, инверсная кинематика.
Физика использовалась только для определения столкновений динамических объектов — Актора и пули(которая для упрощения примера двигалась моментально, да и ее класс мы опустили).
Инверсная кинематика (IK) обычно используется в гейм-деве для анимаций конечностей (ходьба по ступенькам, толкание дверей и т.п.), а не для расчетов физики.
даже если нагородить «правильных» абстракций — это тоже не помогает
В этом и суть ООП — правильные абстракции уменьшают количество повторяющегося кода, логических ошибок и упрощают расширение приложения. В простых приложениях это конечно «стрельба из пушки по пернатым», но даже средняя по сложности игра — это уже далеко не простое приложение — без ООП тут можно попасть в Бедлам.
Мой Time To Market — 10 минут. Ваш — если всё-таки возьмётесь довести свой код до работоспособного состояния — пара дней. Эффект для пользователя один и тот же.
Теперь считаем: 1 час разработчика стоит $100. За готовую демку платят $1000.
Подскажите плиз где за такие демки как ваша платят по 1к? Она не рабочая. Она решает одну тривиальную задачу в вакууме. Как, впрочем, и мой набросок (хотя в нем хотя бы подразумевается какой-то намек на способ интересующего взаимодействия).
При реальной бизнес-задаче нужно будет предоставить демку такой игры. Всего по минимуму, но оно должно быть рабочим. Я просто предположил, что речь идет о 3х-мерном шутере — в этом суть этих всех HitInfo, Globals, Physics: показать на основании чего будет происходить взаимодействие между сущностями (на основании физики в данном случае). И этот код будет работать правильно практически без изменений для многих расширений: стреляем из дробовика или огнемета, стреляем по банкам/стенам/окнам/врагам/союзникам или вообще хиляем их или бафаем.
В требованиях к:
— знанию определенных языков и технологий;
— количеству оперируемых переменных;
— умению оперировать взаимосвязями переменных разной степени сложности;
— умению оперировать взаимозависимыми переменными;
— степени обучаемости;
— способности к абстрагированию;
— аналитическому, комбинаторному, пространственному и креативному мышлению;
— комплексному подходу к решению задач;
— воображению;
— концентрации;
— … список можно продолжать еще долго…
Черт! Да тут как минимум нужно уметь читать и писать. Как это вообще можно сравнивать?
Я бы понял сравни вы с инженером-конструктором изделий из композиционных материалов в сфере авиастроения — это другая инженерная профессия, требующая других специализированных знаний, но по степени сложности уже ближе, но даже у нее меньше требований (т.к. сам процесс в большей степени стандартизирован).
Конечно это эффективнее некуда, сидеть 3 часа и пытаться самостоятельно разобраться, как работает соседний сервис. А не просто спросить у коллеги и получить ответ за 15 минут.
И пока вы отвлекали коллегу, он ошибся, что через неделю вылилось в «криты и блокеры в середине спринта». Так что:
Да, черт возьми! Разбираемся хоть 6 часов пока это дает толк, зато не будем потом отвлекать человека каждые 15 минут «на 15 минут».
Или додумать за ПО спорные моменты в задаче, а потом выкинуть 90% работы и переделать заново после первого демо.
Да, черт возьми! В следующий раз будут четче формулировать задачу. Хотя обычно в таких ситуациях человек сам до конца не знает чего хочет и хороший разработчик придумает отличное решение как вариант для первой итерации.
Или не услышать или не понять критику на обсуждении тех решения. А потом переделывать, костылить и велосипедить. И получать криты и блокеры в середине спринта.
IT-специалисты полностью переключатся на бизнес-процессы, а техническими задачами будут заниматься машины.
Статья из серии «Sad, but true». В том смысле, что многие софт-скилловые управленцы действительно приравнивают высококлассных спецов по сложным системам к операторам лифтов из начала 20-го века (утрировано конечно) и с этим нужно считаться. Программист — скорее последняя профессия которую заменят машины. Это может стать даже последним событием для человечества.
По опыту скажу, что в команда «слабых, но коммуникабельных» разработчиков за пол года на проекте добавит с пол дюжины кривых фичей и создаст снежный ком из багов, а команда «сильных, но жестких (и даже агрессивных)» спецов превратит проект в произведение искусства.
Я обычно даю какую-нибудь задачку на то, с чем кандидат будет сталкиваться довольно часто, типа такой (я работаю с 3д-графикой поэтому тригонометрия крайне важна):
Она имеет как минимум 4 хороших варианта решения и если кандидат минут за 10 находит любое — голова варит, можно брать: нюансам синтаксиса научится, а вот пространственное мышление прокачивать нужно гораздо дольше.
Это 3д-графика и 3-д мир, но да все события происходят в плоскости. Но я согласен и на 2-д игру взглянуть.
Спор о преимуществах ООП подхода и мой тезис был о том, что такой подход раскрывается лучше в более сложных задачах. Мне правда интересно посмотреть на толковую игровую логику использующую «не ООП» — был бы рад увидеть такой даже уже готовый игровой код. В случае, если Вы действительно хотите убедить кого-то в своей правоте (а не просто потешить свое самолюбие), это был бы конструктивный аргумент.
Погуглите как запускать сцену если что. Версия Юнити 2018.1.8.1f1+
На самом деле там нет изменения объекта через константу, там оптимизация рейкаста при помощи константы. Из этого я делаю 2 вывода:
1) да, для текущей задачи это и правда было излишеством — сори, писал с оптимизацией по привычке.
2) хороший код должен быть очевиден даже для джуна и т.к. Вы его не поняли, то код и правда не так хорош.
Хм, а ведь и правда сказал. Ок, вот демка (как оказалось заняло это на Юнити около 40 мин):
а вот и код (интересующая часть практически не отличается от предоставленной изначально): https ://drive.google.com/open?id=1lw5Q7JRDzu3ET5OLs0ATA1Rw5s3iW5De
Мои Globals да, попахивают, лучше эту константу хранить в спец. классе (да хоть в том же Физикс), но по сути это останется глобальной константой.
Без статических методов можно обойтись, но зачем? Это будет не оптимально — нужно выделять и освобождать память там, где это не нужно. Это просто методы, которые можно использовать без создания экземпляра класса. Почему статические методы противоречат концепции ООП?
Она не рабочая как демка. С таким же успехом можно было написать просто log(50-5) — т.е. это хардкод для одного случая. Мы по-разному смотрим на задачу: я вижу проблему взаимодействия Monster-Player, Вы, на сколько я понял, проблему отнимания хп. Первая решается при помощи ООП (особенно если подразумевается такое взаимодействие между различными объектами, а не только уловными Monster и Player), для второй, безусловно, ООП оверкил.
Используя какой-то Unreal или Unity — к вечеру, но моя демка будет являться продуктом в который можно поиграть и, т.к. я потратил лишние 20 мин на проектирование структуры и еще 40 на имплементацию доп. слоев абстракций, можно будет в дальнейшем расширять, не переписывая все с 0.
Глобальные константы. в данном случае хранит битовую маску слоев с IAffectable объектами.
Это игровая логика, использующая физику. За рендеринг обычно отвечает конвейер визуализации — это другая степь.
В гейм-деве часто коллайдеры используются как часть физической модели (примитивы — для упрощения расчетов).
Физика использовалась только для определения столкновений динамических объектов — Актора и пули(которая для упрощения примера двигалась моментально, да и ее класс мы опустили).
Инверсная кинематика (IK) обычно используется в гейм-деве для анимаций конечностей (ходьба по ступенькам, толкание дверей и т.п.), а не для расчетов физики.
В этом и суть ООП — правильные абстракции уменьшают количество повторяющегося кода, логических ошибок и упрощают расширение приложения. В простых приложениях это конечно «стрельба из пушки по пернатым», но даже средняя по сложности игра — это уже далеко не простое приложение — без ООП тут можно попасть в Бедлам.
Подскажите плиз где за такие демки как ваша платят по 1к? Она не рабочая. Она решает одну тривиальную задачу в вакууме. Как, впрочем, и мой набросок (хотя в нем хотя бы подразумевается какой-то намек на способ интересующего взаимодействия).
Прелести ООП в примитивных задачах понять нельзя.
Опуская менее важное:
— знанию определенных языков и технологий;
— количеству оперируемых переменных;
— умению оперировать взаимосвязями переменных разной степени сложности;
— умению оперировать взаимозависимыми переменными;
— степени обучаемости;
— способности к абстрагированию;
— аналитическому, комбинаторному, пространственному и креативному мышлению;
— комплексному подходу к решению задач;
— воображению;
— концентрации;
— … список можно продолжать еще долго…
Черт! Да тут как минимум нужно уметь читать и писать. Как это вообще можно сравнивать?
Я бы понял сравни вы с инженером-конструктором изделий из композиционных материалов в сфере авиастроения — это другая инженерная профессия, требующая других специализированных знаний, но по степени сложности уже ближе, но даже у нее меньше требований (т.к. сам процесс в большей степени стандартизирован).
Да, черт возьми! Разбираемся хоть 6 часов пока это дает толк, зато не будем потом отвлекать человека каждые 15 минут «на 15 минут».
Да, черт возьми! В следующий раз будут четче формулировать задачу. Хотя обычно в таких ситуациях человек сам до конца не знает чего хочет и хороший разработчик придумает отличное решение как вариант для первой итерации.
А для этого существуют тим-лиды и пул-реквесты.
Статья из серии «Sad, but true». В том смысле, что многие софт-скилловые управленцы действительно приравнивают высококлассных спецов по сложным системам к операторам лифтов из начала 20-го века (утрировано конечно) и с этим нужно считаться. Программист — скорее последняя профессия которую заменят машины. Это может стать даже последним событием для человечества.
По опыту скажу, что в команда «слабых, но коммуникабельных» разработчиков за пол года на проекте добавит с пол дюжины кривых фичей и создаст снежный ком из багов, а команда «сильных, но жестких (и даже агрессивных)» спецов превратит проект в произведение искусства.
Смотрим на табличку с софт-скиллами и только «лидерство» выбивается