В коммерческой разработке, да и просто игровой, особенно в клиентской, крайне редко нужно писать бенчмарки. Это просто не имеет особого смысла, поэтому если вы не разрабатываете игровой движок или типа того, то вам не нужно в целом то и знать, как пишутся бенчмарки)

Но хоть в этом докладе поднимается тема бенчмарков, я считаю что он полезен всем чисто для общего образования в плане понимания работы процессора, памяти и т.п. https://youtu.be/XGtieBVI1lk Как и в целом многие другие доклады Андрея Акиньшина по дотнету. Я бы правда сказал, это такое знание не которым надо прям пользоваться, но о котором в общих чертах надо помнить. Так как реальная применимость этого — редкая, но знать о том, что такое есть — очень важно, так как это расширяет понимание работы с дотнетом, кодом и т.п.

Профессионал и ремесленник

Разработка достаточно любопытная область. Для того, чтобы зарабатывать в ней деньги знать нужно сравнительно немного. Все супер сложные концепции, тонкое устройство систем, понимание что и как работает — не самые важные знания с коммерческой точки зрения. Можно просто писать код не особо глубоко разбираясь технических аспектах и нюансах, да и спокойно остановиться на уровне мидла. Хотя я видел и сеньоров не разбирающихся скажем в устройстве памяти или скажем в шейдерах. Для кого BSP и BRDF — это просто набор букв, хотя работая с графикой стоит хотя бы поверхностно знать базовые концепции на которых она строится)

К чему это я? Можно оставаться ремесленником, всегда как бы и кусок хлеба будет, и к чаю чего-нибудь. Но что отличает в основном профессионала от ремесленника? Для меня это набор пунктов:

1. Понимание того, что бесполезных знаний не существует — да, это может быть ненужно прямо здесь и сейчас, но чем больше ты знаешь, тем больше у тебя инструментов
2. Большая ориентация на фундаметальные знания — знать много частностей рабочий вариант и это классно, но как в любой области обычно эти частности объединяет общий фундамент. И знания фундамента получается всегда более универсальным
3. Знание большого числа технологий. И вот тут важно зачем. Когда ты понимаешь сетевые технологии, понимаешь веб технологии и т.п. — ты по-настоящему можешь писать кроссплатформенно и что угодно. И тебе проще, так как ты понимаешь всегда другую сторону. Неважно чем ты занимаешься бекендом, фронтендом или чем-то ещё

Сейчас просто одно из печальных наблюдений, что понятие сокетов беркли или веб сокетов — это чуть ли не магия для многих. Хотя работать с ней довольно просто :)

#рекомендация #литература

Кстати, по части в целом работы с сетью могу порекомендовать книгу "Многопользовательские игры. Разработка сетевых приложений | Глейзер Джошуа, Мадхав Санджай". Она отлично объясняет устройство модели OSI, разные архитектуры сети и тому подобное. И просто в деталях рассказывает низкий уровень устройства сети и каким образом строятся различные мултиплеерные игры :) Очень советую всем прочесть :) Отличная книга)

Смотри как могу

Большая проблема начинающих, да и не только, делать что-то в игре или приложении не потому что надо, а потому что «смотри как могу». Я помню в школе я участвовал в соревновании по, прости господи, вебдизайну. Я тогда учился HTML+CSS по методичке которую мне скинул кто-то из основного состава рейда (тогда ещё я играл в WoW). И помню на htmlbook что ли я нашёл два html тега: fieldset и legend, которые я нигде до этого не видел. И помню что добавил я их в сайт только чтобы выпендриться, что я их знаю. Особого художественного смысла в этом не было)

И встречается это к сожалению часто. В геймплее, в ux решениях, в анимациях. Я сам себя часто бью по рукам за такие мысли. Типа сделать крутую и замороченную штуку за 3 недели вместо простого решения за 2 дня, которое при этом не оценит пользователь. Безусловно иногда нужно морочиться и делать что-то сложное, но только тогда, когда есть ответ на вопрос — зачем. Любой функционал, любая финтифлюшка служат какой-то цели. Анимация тех же иконок (сейчас все с ума сошли по микроанимациям) не имеет смысла, если она не несёт в себе никакой информации. Есть много способов сделать что-то "живее" в том же дизайне, даже просто "перекрасив кнопку в другой цвет". И она уже не будет "мёртвой", а пользователю при этом будет безразлично, что это не сложно преобразовавшийся доллар в крестик)

А что же в разработке? Оооо "потому что я могу" это то что создаёт миллиард проблем всегда. Часто это касается модных фишек языка, или функций которые человек узнал вчера. Хешсеты с переопределением гетхешкода, переопределение дефолтных операторов класса и много другое. Иногда, краайне редко, это имеет смысл. Но когда я вижу, что на списке в котором в максимуме в прыжке 100 элементов кто-то делает хешсет и пишет хеш функцию, это вот прям грустно. Заморочки с генериками, с функторами вместо просто определения класса и метода. Советую всем запомнить. Код в первую очередь должен быть простым! А что является простыми сущностями, которые легко читать? Поля, классы, методы, списки и словари. Если нет обоснования тому, зачем вы тут переусложняете, не надо переусложнять. Так как доказательства требует не то "почему ты здесь использовал List с LINQ ведь это медленно?" (зато супер читаемо) А как раз скорее "зачем ты тут построил супер гибкую абстракцию в три этажа?". И об этом всегда надо помнить. И один из навыков программиста разделять "лишнюю оптимизацию или переусложнение" и "банальные ошибки" (По второму вроде необоснованного GetComponent в Update)

Буду ждать, когда выпустят исходники :) https://youtu.be/-S6J8zm_w1E

То что юнити пробует свои силы в играх, это классно. Хотя лучше бы в коммерческих, чем в бесплатных. Чтобы метрики бюджетов и сроков бились с реальностью :) Но это прям интересно, даже конечно в ролике видно косяки с биасом теней, но я буду ждать :) Поковырять проект сделаный опытными людьми или крупной командой всегда интересно и полезно :)

Программирование не точная наука

Поработав на большом количестве проектов с большим количеством разных лид разработчиков, технических директоров и т.п. всё чаще понимаешь, чем программирование отличается от точных наук. У многих новичков я встречал вопрос: "а правильно ли я пишу код?" И в программировании пожалуй что если и существует, то это грубые ошибки. В остальном тут идёт огромный простор фантазии, иначе бы не было бы такого числа холиваров. В каждой конкретной компании кодовая база в среднем зависит от вкусовых предпочтений конкретного лида. И в этом нет ничего плохого :)

Просто я замечал (и даже за собой) что один и тот же тезис "делаем штуку Х". Я могу как логично поддержать сказав "почему это круто". Также логично и опровергнуть приведя аргументы почему "это хрень". Допустим самый противоречивый паттерн проектирования — синглтон. Можно привести кучу аргументов за, кучу аргументов против. Долго обсуждать чем DI лучше и так далее, но факт в том что. Я работал во множестве компаний, участвовал во множестве проектов, часть компаний консультировал, и я помню как минимум 3 супер успешных крупных проекта, с миллионной аудиторией игроков, где в ядре вообще всё стоит на синглтонах. Это создавало бы некоторые проблемы, но там был выстроен неплохой процесс ревью, который это нивелировал)

Может когда-нибудь программирование достигнет той степени формализации, что можно будет однозначно сказать "это хорошо, а это плохо", но сейчас это не так. Так как вопрос в том, какими метриками мы всё считаем. Можно долго и ловко жонглировать аргументами про "стоимость поддержки", "стабильность системы" и т.п. Но правда в том, что на самом деле даже в этом случае код идёт на второй план. А на первом месте стоят процессы. А уже исходя из процессов подбирается методология написания кода :) А новичкам не стоит ничего бояться, так как либо в компании ваши коллеги вас поправят, либо написав херню вы уже через пол года поймёте почему это херня. Или же гораздо раньше столкнётесь с проблемами. Лучше всего понимают люди зачем нужна архитектура ПО, когда один разок перепишут пол проекта ради какой-то казалось бы простой фичи :)

Какую интересную штуку нашёл на просторах интернетов. Опенсорсную тулзу для Unity, которая позволяет преобразовывать фотографии в текстуры для материалов Unity. Конечно она уже 4 года, как не поддерживается судя по всему. Но всё равно надо будет поковырять :)

https://www.youtube.com/watch?v=I1yO0UlLnC4

Интересный доклад с GDC про сеть в Mortal Combat и Injustice 2 https://www.youtube.com/watch?v=7jb0FOcImdg

Большая часть игр просто стиль в победителях :) https://youtu.be/Vbrn76pEOHE

Референсы и насмотренность

У разных профессий различные проф деформации. Например во времена работы геймдизайнером я разбирал любую игру на механики автоматом. Но в графике я считаю одну привычку очень полезной — собирать рефы. В интернетах они есть не для всего. У меня когда-то был целый каталог видео допустим дождя в луже, чтобы смотреть на поведение капель воды)

Но видео это видео, камера передаёт всё немного искажённо, так что ещё полезно внимательно смотреть по сторонам. На деревья, архитектуру и какие-то природные явления. Меня вот всегда интересовал fog в юнити и почему он так рисуется, а на этой неделе я впервые побывал в горах и теперь — понятно :)

Базовые ошибки фрилансеров

Как технический продюсер, которому сейчас периодически нужны рабочие руки я отсматриваю очень много фрилансеров. И замечаю их банальные ошибки. Помимо этого я был с другой стороны баррикад) Я в течении 2 лет фрилансил разработку со ставкой 2к/час. И если вы хотите держать такую ставку, адекватных заказчиков и в целом, чтобы с вами хотели работать вот набор простых правил)

1. Никогда не «придирайтесь» к заказчику

Объяснять что-то заказчику с точки зрения экспертности — нормально, напрямую несоглашаться — лучше мягко, но тоже можно. Не в стиле «вы нихера не знаете, я тут эксперт», а «я бы рекомендовал сделать так». Занудствовать и поправлять в мелочах — никогда. Как-то раз я писал с телефона и мне указали на орфографическую ошибку в тексте, и тут как бы вопрос «а зачем, как это поможет сотрудничеству?» Это причём довольно частая ошибка :) Если вы хотите успешно что-то кому-то продавать, так делать нельзя :)

2. Заказчик не обязан вам что-то объяснять

Основная работа чтобы всё прошло с заказом спокойно, это предпродакшен или подготовка. Тут нужно примерять роли бизнес аналитика и дотошно выяснять все детали, если заказ на конкретный объём и функционал. Я чаще сейчас в работе обозначаю рамки времени работы, так как я +- понимаю, что сколько делается, как технический директор и профильный заказчик сделавший больше 50 проектов :) А непрофильные заказчики не знают чего хотят, это надо выяснить и зафиксировать) И всё будет спокойно. Мне много кто рассказывает про ад с заказчиками, я с этим сталкивался редко, так как просто не допускал на этапе согласования разночтений. Хотя конечно не скажу, что такого не бывает

3. Не работать с мудаками

Честно говоря, я очень избирателен в заказчиках, и сейчас уже в разы больше отказываюсь, чем соглашаюсь. Как показывает практика любой заказ с неадекватами, как ты бюджет не выкручивай штука нерентабельная. С хорошими заказчиками я иногда делаю просто огромные скидки, когда им «нужна помощь», с средними всё по стандартному процессу. С мудаками, доделать то, о чём договорились и забыть

4. Никогда не пропадайте

Это уже со стороны продюсера. Очень многое можно обсуждать. Если вы работаете с продюсером или хорошим ПМ, это его задача придумать, как мы выкручиваемся. Всякое бывает. Проебались, заболели, переоценили силы. Главное говорить и обсуждать. С кем я работал, и кто проебался но не пропал, я всегда работаю дальше. Если человек пропал и меня подставил, я как продюсер решу проблему, но это вечный блок подрядчика

5. Желание делать работу

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

Хорошо организованная иерархия — это важно

В целом не стоит недооценивать важность дисциплины в организации проекта. С хорошей структурой папок проще работать. С хорошей организацией иерархии сцены проще работать. В целом достаточно выработать один раз удобную вам структуру, чтобы потом всегда делать по лекалу и нигде не путаться. Тут главное не лениться, так же как и с неймингами объектов. Потому что когда всё проименовано по какой-то логике и схеме проектом проще управлять

В плане структуры папок я предпочитаю:
Assets:
Scenes: сцены
Scripts: скрипты
Core: основная логика
UI: скрипты интерфейсов
Plugins: плагины
External: все внешние ассеты
Sources:
Prefabs: префабы
Shaders: шейдеры
Textures: текстуры
Models: 3d
Materials: материалы
UI: интерфейс
Backgrounds: задники
Icons: иконки
Buttons: кнопки

Вариации бывают только в Assets/Sources/UI и также исключением является папка Resources но это чистой воды оптимизация. Там могут лежать Scriptable Objects, которые ссылаются на префабы и т.п. Лежат они там, так как доступ к ним нужен по пути, чтобы правильно асинхронно грузить сцену. В юнити есть такой нюанс. Если в сцене есть ссылка скажем на SO, в SO на какой-то префаб в котором лежит модель. То при загрузке сцены вы загрузите в память модель и всё на что есть ссылки. Даже если оно не инстанцировано, и это логично. Поэтому иногда нужен доступ к ресурсам по путям. Но проще оперировать SO, где лежат группы нужных префабов

Что же касается иерархии я привык для чистоты заводить папочки, вроде [MANGERS] или [UI], где внутри уже будут под каталоги, если объектов слишком много. Так проще не путаться, проще редактировать командой (Вынеся папку в префаб), да и быстрее что-то находить

В общем структура — это важно, и очень ускоряет работу

Да, к прошлому посту. Почему лучше не хранить все исходники в ресурсах. Если коротко, сложнее вычищать при росте проекта ненужные ресурсы. В ресурсах должно лежать только то, что прям очень важно грузить по путям, а остальное лучше хранить вне этой папки. Потому что если вдруг какой-то ресурс не используется в сценах, то если он лежит вне папки ресурсов, то он не пойдёт в сборку автоматически. То есть для примера вы удалили из сцены префаб, который лежит не в ресурсах, и всё на что он ссылается. Все эти ассеты включая сам префаб автоматически не пойдут в билд :)

Я понял, что я очень надеюсь, что эпл обяжут пустить альтернативные сторы и вот почему)

Должна упростится дистрибуция

Сейчас при работе с эплом главным неудобством является дистрибуция. Нельзя просто собрать ipa архив и доставить его пользователю. Есть вариант с ad hoc, но там нужен заранее заготовленный список устройств, что не всегда удобно и реально. Есть вариант тестфлайтом, но там вообще нужно конкретных людей добавлять по эпл айди. Есть вариант с энтерпрайсом, но так как там приложение могут устанавливать «только сотрудники», то тоже свои нюансы

В случае введения альтернативных стров эплу придётся либо со всеми сторами договариваться, чтобы не ломать систему. Либо давать возможность качать ipa в обход неё :) Плюс не будет монополии на ревью :)

#концепт

Прикольно было бы, если бы у скажем банковских приложений был «сотовый режим». Там конечно возникает очень много вопросов, в первую очередь в плане безопасности и стоимости этого дела с авторизацией. Но иногда есть сотовая связь, но нет интернета. У некоторых банков есть переводы через смс, но посмотреть инструкцию без интернета я не могу, а в приложении без интернета она не выводится :)

Но представим что была бы кнопка с механизмом авторизации и возможностью перевода денег через gsm) В местах где бывают проблемы с интернетом, типа тех же гор — это было бы весьма удобно) Надо кому-то перевести скажем срочно, нажал несколько кнопок, улетели автоматом несколько смс, операция прошла и всё замечательно :) Технологически по идее в этом нет никаких проблем, кроме возможно политик безопасности платформ в плане «отправить смс автоматом». Не могу погуглить и посмотреть, пока не очень с инетом :)

Несовершенство компьютера

Есть много забавных ошибок, которые возникают из ограничений возможности компьютера в целом. Моих любимых пожалуй две, но суть у них одна :) Важно помнить, как работают простые типы. Поговорим про float. Я не буду говорить про неточности суммирования и строгие условия, это слишком банально и многие IDE сейчас подсвечивают :) Основное что надо помнить, что хранить он может 6-7 знаков. И из этого у новичков возникают забавные ошибки :) Почему в юнити float, а не double — это довольно долгий рассказ, может как-нибудь потом опишу :)

Получать gps координаты в float. Мало того, что gps сам по себе страдает в плане точности. И это конечно не критично, но важно знать, что будет если перегонять точку в float (что делают на удивление часто) Можно ли писать в float? В целом да, особенно при работе с навигацией, так как точность gps достигает 20 метров и зависит от широты и оборудования рядом (https://support.google.com/maps/answer/2839911?hl=ru&co=GENIE.Platform%3DAndroid) В Москве допустим точность около 5-6 метров. И когда вы округляете координаты до 7 знаков у вас получается точность страдает значения от примерно 80 сантиметров до 8 метров (так как долгота бывает трёхзначной) :) Что в целом ок, хотя лучше иметь ввиду, так как вы добавляете ошибку в несколько метров) Но всё же в кейсе навигации это не критично, а вот в расчёте расстояний ещё как важно. Так как обычно для этого хранятся 7 знаков только после запятой :)

Перемещать игрока в бесконечном мире. Ну тут та же забавная проблема. В бесконечных мирах есть много трюков, но если просто перемешать игрока не используя их, то проблема в позиции (1234567, 123467) мне кажется очевидной. У вас просто не будет работать дробная часть, и будет ошибка округления в 1 :) И там можно доводить до абсурда) А допустим 1 в вашем мире — это один метр) Почему же тогда в Unity float, а не double с его 15 знаками? Они что дураки?) Не, там всё довольно логично, но как я и говорил — это длинная история :)

Интересный простенький тутор)

https://youtu.be/OLEWP7VZVzQ