Полезная и интересная статья про текстуры и виды текстурных карт. В особенности для начинающих https://dtf.ru/gamedev/1113705-plotnost-tekseley-i-nemnogo-teorii-tekstur-ot-entoni-o-donnella?from=rss

Немного мыслей про заклинания и UX

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

И они довольно неплохи, но выглядят скорее как недоделанный WoW. И я заметил одну мелкую недоработку. Я начал играть за метаморфа и почти все спеллы, на низких уровнях по крайней мере, работают странно. При построении любого заклинания с точки зрения игры есть 3 фазы, как оно по хорошему должно работать. Запуск, полёт и попадание. И попадание должно быть:

1) Достаточно ярким
2) Синхронизировано с получением урона
3) Синхронизировано с отлетающим текстам

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

Иногда нужно разминаться

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

Например написание игрового ИИ и ботов. Да, есть много всяких книжек, где объясняются концепции Behavior Tree или FSM, но чтобы попрактиковаться в написании ИИ в том же юнити — нужно сначала написать игру, и целую систему. Не лучший подход для получения практики. Я периодически люблю для разминки играть в эту штуку: https://www.codingame.com/ Это прикольная платформа с интерактивными заданиями. ИИ это один из моих любимых видов контестов. Так же, как есть всякие пазлы, оптимизации и многое другое на самых разных языках программирования. И шарп тоже есть. И для разминки штука вообще замечательная. Не думаешь про архитектуру, про систему, просто решаешь выделенные задачки и практикуешься :) И главное — он весёлый, так как у игр тут есть графика и т.п.

Можно было бы вспомнить https://codeforces.com/ но для меня он больше олимпиадный для разработчиков олимпиадников, что тоже классно, но мягко говоря в коммерции не всегда нужно и важно. Так как большинство программистов и Кнута то не читали в наши дни :) И главная проблема кодфорсес — он скучный, хотя он и не задумывался, чтобы быть весёлым :)

Вот как пример одной из игр — гоночки, с которой я раньше любил играться. Хотя до ума я там его и не довёл, болтаюсь где-то на 19 тысячном месте в рейтинге :) https://www.codingame.com/replay/603073981

Новый супер красивый ролик от Unity. Волосы просто кайф :) И огонь хорош) https://youtu.be/eXYUNrgqWUU

Поговорим про графику

Ну и под такой красивый ролик, как не поговорить про графику :) В целом реалтайм пайплайн — это классный концепт сейчас. Конечно же в сравнении с тем, когда кадры рендерятся по несколько минут. Даже когда кадр рендерится одну минуту, то рендер десяти секунд ролика в 30 фпс превращается в 5 часов. Ну и в целом хорошая графика зависит лишь от проработки материалов, системы освещения и т.п.

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

Да, если по этому ролику ещё пока сампл не выложен, но у Unity есть пакет Digital Human (про который многие не знают) Где есть интересные шейдеры кожи, волос, зубов и т.п. https://github.com/Unity-Technologies/com.unity.demoteam.digital-human

И есть более менее разобранный пример с Heretic

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

Ну и показывает интересные приколы и фишки юнити :) С точки зрения перфоманса https://youtu.be/W45-fsnPhJY

Новый прикольный шоурил от юнити, показывающий разнообразие создаваемых проектов на движке https://youtu.be/c90KRdMz1zw

В целом даже завораживающе, сколько совершенно разных проектов делается в мире, разными командами с разными подходами и уровнями :) Всегда любил наблюдать за разными инди проектами :)

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

Но хоть в этом докладе поднимается тема бенчмарков, я считаю что он полезен всем чисто для общего образования в плане понимания работы процессора, памяти и т.п. 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 в юнити и почему он так рисуется, а на этой неделе я впервые побывал в горах и теперь — понятно :)