Переобувания Блаба
#код
Что-то нашло настроение поразмышлять о том, как часто я менял мнение на программерском поприще. Такое на самом деле случается нечасто, потому что мы все живём в пузырях из собственного опыта. Первый инструмент или подход, который хорошо себя зарекомендовал, формирует в нас эффект утёнка. Затем мы этим самым утёнком какое-то время восторженно забиваем все гвозди в округе. И вот спустя десятки птичьих, натянутых на разнообразные модели Земли, когда по-хорошему стоило бы задуматься об этичности происходящего, у нас уже достаточно травматичного опыта, чтобы спутать стокгольмский синдром с любовью.
Когда твоя позиция сформулирована и озвучена коллегам возле кулера, когда по теме написаны посты и твиты, бывает уже очень трудно выйти на следующий виток спирали понимания и начать декларировать противоположное своим же вчерашним взглядам. Самая главная моя ошибка прошлого — это конечно то, как упорно я в юности не признавал, что Visual Basic плохой язык (если вам резануло ухо слово «плохой», то переформулирую: неподходящий для моих задач). Осознание этого было длительным и болезненным. Я топал ножкой и капризничал, лишь бы не учить С++. Но сегодня я фанат крестов. Я добрался сюда через пару витков .Net, но что-то мне подсказывает, что на этом моя личная спираль обрывается. Конечно, сейчас я привязан к С++ во многом стокгольмским синдромом, но как мне кажется, у меня есть и рациональные аргументы, почему оглядываясь назад через 10 лет я не сочту это ошибкой.
Другие примеры изменения моего мнения не столь драматичны, но тоже случались. Например, я помню, как 10 лет назад вкручивал локализацию в игру для Wii. И я тогда на полном серьёзе втирал, что для геймдева строки лучше хранить в 8-битных кодировках с переключением кодовых страниц (Windows-1251, 1252 — вот это вот всё). Мне тогда представлялось важным иметь доступ к нужному символу по смещению в строке, а необходимость помнить кодировку совсем не смущала и не казалась геморройной. Я проникся силой юникода уже буквально через год, но стыдно до сих пор.
А вот если говорить о вечном, то помнится в известном холиваре порядка байт я раньше был на стороне тупоконечников. Превалировало во мне что-то такое дикое, что-то из мира человеческого письма. А теперь я как будто больше проникся машинной красотой остроконечности. Следуя этой же логике я, по идее, должен был стать и фанатом column-мажоров из OpenGL, ведь это так математично. Но здесь я почему-то пропутешествовал на один виток дальше и всё-таки остановился на том, что они (вместе со всей математикой) наркоманы и курильщики, а нормальные люди матрицы перемножают слева направо.
Это далеко не самый интересный для чтения мой пост получился: всем, в общем-то, плевать, какие конкретно метаморфозы проходило чужое мнение. Но как мне кажется, это довольно занятная тема, чтобы порассуждать и проанализировать свои взгляды. А вы помните, как кардинально меняли своё мнение по холиварным темам?
#код
Что-то нашло настроение поразмышлять о том, как часто я менял мнение на программерском поприще. Такое на самом деле случается нечасто, потому что мы все живём в пузырях из собственного опыта. Первый инструмент или подход, который хорошо себя зарекомендовал, формирует в нас эффект утёнка. Затем мы этим самым утёнком какое-то время восторженно забиваем все гвозди в округе. И вот спустя десятки птичьих, натянутых на разнообразные модели Земли, когда по-хорошему стоило бы задуматься об этичности происходящего, у нас уже достаточно травматичного опыта, чтобы спутать стокгольмский синдром с любовью.
Когда твоя позиция сформулирована и озвучена коллегам возле кулера, когда по теме написаны посты и твиты, бывает уже очень трудно выйти на следующий виток спирали понимания и начать декларировать противоположное своим же вчерашним взглядам. Самая главная моя ошибка прошлого — это конечно то, как упорно я в юности не признавал, что Visual Basic плохой язык (если вам резануло ухо слово «плохой», то переформулирую: неподходящий для моих задач). Осознание этого было длительным и болезненным. Я топал ножкой и капризничал, лишь бы не учить С++. Но сегодня я фанат крестов. Я добрался сюда через пару витков .Net, но что-то мне подсказывает, что на этом моя личная спираль обрывается. Конечно, сейчас я привязан к С++ во многом стокгольмским синдромом, но как мне кажется, у меня есть и рациональные аргументы, почему оглядываясь назад через 10 лет я не сочту это ошибкой.
Другие примеры изменения моего мнения не столь драматичны, но тоже случались. Например, я помню, как 10 лет назад вкручивал локализацию в игру для Wii. И я тогда на полном серьёзе втирал, что для геймдева строки лучше хранить в 8-битных кодировках с переключением кодовых страниц (Windows-1251, 1252 — вот это вот всё). Мне тогда представлялось важным иметь доступ к нужному символу по смещению в строке, а необходимость помнить кодировку совсем не смущала и не казалась геморройной. Я проникся силой юникода уже буквально через год, но стыдно до сих пор.
А вот если говорить о вечном, то помнится в известном холиваре порядка байт я раньше был на стороне тупоконечников. Превалировало во мне что-то такое дикое, что-то из мира человеческого письма. А теперь я как будто больше проникся машинной красотой остроконечности. Следуя этой же логике я, по идее, должен был стать и фанатом column-мажоров из OpenGL, ведь это так математично. Но здесь я почему-то пропутешествовал на один виток дальше и всё-таки остановился на том, что они (вместе со всей математикой) наркоманы и курильщики, а нормальные люди матрицы перемножают слева направо.
Это далеко не самый интересный для чтения мой пост получился: всем, в общем-то, плевать, какие конкретно метаморфозы проходило чужое мнение. Но как мне кажется, это довольно занятная тема, чтобы порассуждать и проанализировать свои взгляды. А вы помните, как кардинально меняли своё мнение по холиварным темам?
Что я думаю про C++20
#кодище
На днях С++20 был окончательно утверждён. Осталось чисто формальная публикация ISO, которая может затянуться на пару месяцев. Но даже если это произойдёт в 2021, то стандарт всё равно будет называться С++20, потому работу над ним закончили в этом году. В связи с чем я решил пробежаться по основным нововведениям и написать, что же я про них думаю. Интересно это будет трём с половиной человекам, поэтому выскажусь максимально коротко и не шибко художественно.
Концепты — это SFINAE с человеческим лицом. Ну, вернее так говорить не совсем корректно, потому что это скорее добавка, чем замена, но лицо у них явно более человекообразное. Я уже маленько распробовал, и мне очень нравится. Язык становится удобнее и это прекрасно.
Модули распробовать не удалось. В теории крутая штука, хотя и довольно противоречивая. Надо сильно менять привычки и перестраивать мозг, что не очень-то получается в условиях, когда компиляторы до сих пор не до конца в них умеют. MSVC, например, не всегда понимает, что модули изменились, и что их надо перекомпилировать. Когда ты и сам ещё не до конца понимаешь правила игры, такое безобразное поведение компилятора совсем не помогает вниканию. Вернусь к ним в следующем году.
Корутины в С++ — это настоящий computer science оргазм. Я в принципе обожаю корутины. Это одна из моих любимых концепций программирования вообще, но тут она столкнулась с крестовой политикой «не платишь за то, что не используешь», и вместе они родили совсем уж потрясного ребёночка. Даже не zero, а negative-overhead получился. Я пока в реальных проектах не использовал (пока довольствовался boost-овыми корутинами), но я смотрел пару докладов Гора Нишанова, который их разработал. И там очень круто. Посмотрите, кто не видел. Опять же круто, что всё это чудо в стандарте, а не в бусте.
Ну и понятно, что в языке появилось много маленьких приятностей. Из того, чего прям остро не хватало — это consteval. Следить за такими штуками сейчас совсем не удобно. Ну и строковые литералы в качестве параметра шаблона тоже кайфово.
Не могу сказать, что С++20 прям совсем другим языком ощущается, как было с С++11. Нововведения очень крутые и важные, но они касаются в основном каких-то специальных разделов, а не бытовухи. Единственное изменение, которое сильно меняет ежедневную практику — это модули. Но их распробовать пока не удалось.
#кодище
На днях С++20 был окончательно утверждён. Осталось чисто формальная публикация ISO, которая может затянуться на пару месяцев. Но даже если это произойдёт в 2021, то стандарт всё равно будет называться С++20, потому работу над ним закончили в этом году. В связи с чем я решил пробежаться по основным нововведениям и написать, что же я про них думаю. Интересно это будет трём с половиной человекам, поэтому выскажусь максимально коротко и не шибко художественно.
Концепты — это SFINAE с человеческим лицом. Ну, вернее так говорить не совсем корректно, потому что это скорее добавка, чем замена, но лицо у них явно более человекообразное. Я уже маленько распробовал, и мне очень нравится. Язык становится удобнее и это прекрасно.
Модули распробовать не удалось. В теории крутая штука, хотя и довольно противоречивая. Надо сильно менять привычки и перестраивать мозг, что не очень-то получается в условиях, когда компиляторы до сих пор не до конца в них умеют. MSVC, например, не всегда понимает, что модули изменились, и что их надо перекомпилировать. Когда ты и сам ещё не до конца понимаешь правила игры, такое безобразное поведение компилятора совсем не помогает вниканию. Вернусь к ним в следующем году.
Корутины в С++ — это настоящий computer science оргазм. Я в принципе обожаю корутины. Это одна из моих любимых концепций программирования вообще, но тут она столкнулась с крестовой политикой «не платишь за то, что не используешь», и вместе они родили совсем уж потрясного ребёночка. Даже не zero, а negative-overhead получился. Я пока в реальных проектах не использовал (пока довольствовался boost-овыми корутинами), но я смотрел пару докладов Гора Нишанова, который их разработал. И там очень круто. Посмотрите, кто не видел. Опять же круто, что всё это чудо в стандарте, а не в бусте.
Ну и понятно, что в языке появилось много маленьких приятностей. Из того, чего прям остро не хватало — это consteval. Следить за такими штуками сейчас совсем не удобно. Ну и строковые литералы в качестве параметра шаблона тоже кайфово.
Не могу сказать, что С++20 прям совсем другим языком ощущается, как было с С++11. Нововведения очень крутые и важные, но они касаются в основном каких-то специальных разделов, а не бытовухи. Единственное изменение, которое сильно меняет ежедневную практику — это модули. Но их распробовать пока не удалось.
А подпишитесь на Марка
#light
Марк — это наш главный сценарист. Официальная душа, харизма и чувство юмора Encased RPG. Почти год у Марка есть свой небольшой телеграмм канал, где он пишет всякое разное. Про саму игру, к сожалению, ничего не пишет, но когда у вас ещё будет возможность залезть в застенки черепной коробки сценариста не ферм каких-нибудь, а одной из самых амбициозных игр постсоветского пространства?
А там, как вы понимаете, полный букет всяких разных мировоззренческих, эсхатологических, постмодернистских и прочих рефлексий о нашей жизни. Пишет Марк по три поста в неделю и иногда проскакивают довольно интересные тезисы на поразмышлять. Я вот читаю.
В общем, уважьте старика, подпишитесь на Марка.
#light
Марк — это наш главный сценарист. Официальная душа, харизма и чувство юмора Encased RPG. Почти год у Марка есть свой небольшой телеграмм канал, где он пишет всякое разное. Про саму игру, к сожалению, ничего не пишет, но когда у вас ещё будет возможность залезть в застенки черепной коробки сценариста не ферм каких-нибудь, а одной из самых амбициозных игр постсоветского пространства?
А там, как вы понимаете, полный букет всяких разных мировоззренческих, эсхатологических, постмодернистских и прочих рефлексий о нашей жизни. Пишет Марк по три поста в неделю и иногда проскакивают довольно интересные тезисы на поразмышлять. Я вот читаю.
В общем, уважьте старика, подпишитесь на Марка.
Логарифм и резинки
#код
Как-то в одном из чатов обронили фразу: «а когда вам последний раз был нужен логарифм?». Забавно, но мне он потребовался буквально на следующий день. Это ещё один маленький пост о том, какого рода математика нужна геймплейному программисту в повседневной жизни.
Часто нам нужно сглаживать какие-то процессы, у которых нет чёткого конца или он меняется во времени. Ну, например, у нас один объект — пусть это будет ручной дракончик — движется на воображаемой резинке за другим объектом, который тоже постоянно в движении: скажем, это будет персонаж игрока. Если игрок оказался далеко от дракончика (например, телепортировался), то дракончик сперва летит к нему очень быстро, но при приближении постепенно замедляется, чтобы это смотрелось хорошо.
Новички обычно просто домножают скорость дракончика на расстояние до игрока. Это простое решение, но ужасно плохое, поскольку время, за которое дракончик долетит до игрока, будет напрямую зависеть от FPS. При низком фпс он будет добираться до цели быстро, а при большом топтаться на месте неожиданно долго. А если FPS скачет, то и вовсе придётся лицезреть нечто рывкообразное.
Юнитологи классом повыше обычно используют небезызвестную функцию SmoothDamp. Внутри там скрывается мудрённое решение из книги Game Programming Gems 4. Вот только нам приходится где-то хранить текущую скорость для каждого процесса сглаживания, да и в целом довольно страшно выглядит. Нельзя ли как-то попроще сделать и без лишних переменных в местах вызова?
На самом деле если мы задумаемся, как будет выглядеть FPS-независимый способ приближения со сглаживанием, то быстро поймём, что нам надо проходить одинаковую долю расстояния за одинаковое время. Например, за первую секунду проходим половину пути, за вторую секунду половину от половины, то есть остаётся четверть, затем 1/8, 1/16 и так далее. И никогда мы по настоящему не достигаем цели, но нам это и не надо. При таком движении неважно в какой точке этого процесса мы оказались (на первой секунде, второй и т.п.), мы всегда знаем, как рассчитать движение дальше. От пути всегда остаётся лишь
Можно думать об этом числе, как о степени агрессивности нашего In в нашем FPS-независимом сглаживании (аналог InCubic, InQuad и т.д.). Формула продолжит работать.
Но для полного счастья нам не хватает настройки времени, за которое дракончик будет визуально догонять персонажа из любой точки. Конечно, полностью он догнать не может, но нам хватит преодоления, скажем, 98% пути:
По-моему, симпатично получилось. А вы что думаете?
#код
Как-то в одном из чатов обронили фразу: «а когда вам последний раз был нужен логарифм?». Забавно, но мне он потребовался буквально на следующий день. Это ещё один маленький пост о том, какого рода математика нужна геймплейному программисту в повседневной жизни.
Часто нам нужно сглаживать какие-то процессы, у которых нет чёткого конца или он меняется во времени. Ну, например, у нас один объект — пусть это будет ручной дракончик — движется на воображаемой резинке за другим объектом, который тоже постоянно в движении: скажем, это будет персонаж игрока. Если игрок оказался далеко от дракончика (например, телепортировался), то дракончик сперва летит к нему очень быстро, но при приближении постепенно замедляется, чтобы это смотрелось хорошо.
Новички обычно просто домножают скорость дракончика на расстояние до игрока. Это простое решение, но ужасно плохое, поскольку время, за которое дракончик долетит до игрока, будет напрямую зависеть от FPS. При низком фпс он будет добираться до цели быстро, а при большом топтаться на месте неожиданно долго. А если FPS скачет, то и вовсе придётся лицезреть нечто рывкообразное.
Юнитологи классом повыше обычно используют небезызвестную функцию SmoothDamp. Внутри там скрывается мудрённое решение из книги Game Programming Gems 4. Вот только нам приходится где-то хранить текущую скорость для каждого процесса сглаживания, да и в целом довольно страшно выглядит. Нельзя ли как-то попроще сделать и без лишних переменных в местах вызова?
На самом деле если мы задумаемся, как будет выглядеть FPS-независимый способ приближения со сглаживанием, то быстро поймём, что нам надо проходить одинаковую долю расстояния за одинаковое время. Например, за первую секунду проходим половину пути, за вторую секунду половину от половины, то есть остаётся четверть, затем 1/8, 1/16 и так далее. И никогда мы по настоящему не достигаем цели, но нам это и не надо. При таком движении неважно в какой точке этого процесса мы оказались (на первой секунде, второй и т.п.), мы всегда знаем, как рассчитать движение дальше. От пути всегда остаётся лишь
1 / 2^tА значит пройденное расстояние от времени вычисляется по формуле:
1 - 1 / 2^tДвойка здесь всего лишь указатель на то, что в качестве одинаковых промежутков мы выбрали половину расстояния. Мы можем подставить туда 3, чтобы получить треть, или любое другое число больше 1.
Но для полного счастья нам не хватает настройки времени, за которое дракончик будет визуально догонять персонажа из любой точки. Конечно, полностью он догнать не может, но нам хватит преодоления, скажем, 98% пути:
1 - 1 / base^t = 0,98Ну вот и всё. Теперь мы можем инициализировать этими параметрами нашу бесконечную резинку-пружинку, после чего ей можно будет скармливать deltaTime, а в ответ получать LerpK. Таким образом получилось простое FPS-независимое сглаживание для всего, что можно лерпать. Финальный класс можно видеть на скриншоте.
base^t = 1 / (1 - 0,98)
t = log(1 / (1 - 0,98), base)
По-моему, симпатично получилось. А вы что думаете?
Поправочка!
#код
Ох, что-то я написал этот пост и тут же понял, что лишнего наворотил. Движение, при котором мы за равные промежутки проходим половину, затем половину от остатка и так далее — это фактически тоже самое движение, когда мы за равные промежутки проходим треть, затем треть от остатка и так далее. Это просто свойство перевёрнутой экспоненты самой по себе. И неважно какое основание. А чтобы управлять агрессивностью In-прыжка, достаточно слегка менять threshold-порог. Чем выше выставить процент порога, тем агрессивнее будет прыжок в начале.
Правду говорят, что если хочешь в чём-то разобраться сам, то расскажи это другому. Вот и здесь так получилось.
#код
Ох, что-то я написал этот пост и тут же понял, что лишнего наворотил. Движение, при котором мы за равные промежутки проходим половину, затем половину от остатка и так далее — это фактически тоже самое движение, когда мы за равные промежутки проходим треть, затем треть от остатка и так далее. Это просто свойство перевёрнутой экспоненты самой по себе. И неважно какое основание. А чтобы управлять агрессивностью In-прыжка, достаточно слегка менять threshold-порог. Чем выше выставить процент порога, тем агрессивнее будет прыжок в начале.
Правду говорят, что если хочешь в чём-то разобраться сам, то расскажи это другому. Вот и здесь так получилось.
public struct EndlessSpring
{
private float TimeScale;
// time is amount of time that needeed to pass
// threshold-share of the distance (never pass 100%)
public EndlessSpring(float time, float threashold = 0.98f)
{
var expectedValue = 1 / (1 - threashold);
this.TimeScale = Mathf.Log(expectedValue, 2) / time;
}
public float GetLerpK(float deltaTime)
{
return 1 - 1 / Mathf.Pow(2, deltaTime * TimeScale);
}
}
По кровавым словам узнаете их
#лайт
Если бы IT было командой черепашек-ниндзя, то игровая индустрия была бы в ней Микеланджело. Ну а среди грызунов-спасателей геймдеву, конечно же, досталась бы роль Дейла. Мы всегда были эдаким младшим и немного придурковатым персонажем IT-мира. Самый весёлый, но наивный раздолбай в гавайской рубашке, обожающий пиццу, комиксы и попадать в дебильные ситуации — это всё мы. И безусловно, нам есть чему поучиться у более старших и серьёзных коллег: от дисциплины и оценки сроков до культуры софтскиллов и ведения документации. У нас всё ещё полно детских болячек отрасли, как прыщей у подростка. Но всё же это не значит, что какой-нибудь занудный Донателло сможет так же ловко управляться с нунчаками, как это делаем мы. Когда дело доходит до владения палками на цепи, стоит спросить совета у Микеланджело.
К сожалению, на фоне всех хороших трендов взросления индустрии, сближение с энтерпрайзом занесло в нашу песочницу и пару куличиков добротного дерьма. Речь идёт о стадах программистов и менеджеров, которые последние пару лет толпами мигрируют к нам из соседних областей, но при этом совершенно игнорируют специфику геймдева. По моему опыту людям из кровавого крайне трудно вкатиться в разработку игр: здесь другой темп написания кода; другие методы тестирования; другая, в конце концов, динамика изменения ТЗ от геймдизайнера. Но есть люди, которые понимают, что теперь работают с произведением искусства, и пытаются адаптироваться; а есть мудилы, которые этого не хотят. Последние — это, как ни парадоксально, люди поопытнее, сформировавшие уже не только собственные привычки, но и солидное ЧСВ. Это тот чувак у вас в команде, который типа прохавал всё IT, много говорит о софтскиллах и о том, как делать правильно, но в общей телеге его колесо всегда волочится по другой колее. Это он треплет нервы всем артистам бюрократией, и именно на его тасках всегда в итоге происходит фичекат.
Частные эманации этого ползучего зла могут быть самые разные, поэтому мне не удастся рассказать, как это выглядит изнутри в каждой конкретной студии, но я могу описать их внешние проявления: по терминологии узнаете их! Уже столько вокруг пролезло бездушного, что их язык стал проникать в нашу среду.
Начну с моего личного чемпиона по мерзости: «мы продуктовая игровая компания!». Если у вас ещё почему-то не задёргался глаз, то поясню. Дело в том, что у них там в большом IT компании сплошь оутсорсовые, консалтинговые и бог знает какие ещё (уж извините, не разбираюсь). Бывает, что люди там годами таски какие-то делают, а пощупать плоды труда нельзя. Поэтому слово «продуктовая» для гребцов в тугих галстуках — это реально порой единственный глоток неденежной мотивации. Но когда HR радостно сообщает мне о «продуктовой игровой компании», для меня это тавтология. Для любого разработчика игр понятие «игровая компания» по умолчанию подразумевает работу над продуктом. Мы пришли в профессию, чтобы делать игры, и в большинстве своём только в таких компаниях и работали. «Продуктовость» это не бонус для нас, а вещь сама собой разумеющаяся. Это вот если вдруг компания не делает собственные игры, а аутсорсит непонятно что — вот тогда уже надо уточнять. Поэтому если вам кто-то из разрабов презентует свою компанию, как «продуктовую», то бегите. Вы там вряд ли встретите крутых артистов, которые делают вещи, или идейных программеров. Если они там были, то разбежались. Судя по лексикону, скорее всего это просто студия-симулякр из энтерпрайзников, где думают не об игре и игроках, а об удовлетворении шизы какого-нибудь заказчика (совсем как в вэбе, да).
#лайт
Если бы IT было командой черепашек-ниндзя, то игровая индустрия была бы в ней Микеланджело. Ну а среди грызунов-спасателей геймдеву, конечно же, досталась бы роль Дейла. Мы всегда были эдаким младшим и немного придурковатым персонажем IT-мира. Самый весёлый, но наивный раздолбай в гавайской рубашке, обожающий пиццу, комиксы и попадать в дебильные ситуации — это всё мы. И безусловно, нам есть чему поучиться у более старших и серьёзных коллег: от дисциплины и оценки сроков до культуры софтскиллов и ведения документации. У нас всё ещё полно детских болячек отрасли, как прыщей у подростка. Но всё же это не значит, что какой-нибудь занудный Донателло сможет так же ловко управляться с нунчаками, как это делаем мы. Когда дело доходит до владения палками на цепи, стоит спросить совета у Микеланджело.
К сожалению, на фоне всех хороших трендов взросления индустрии, сближение с энтерпрайзом занесло в нашу песочницу и пару куличиков добротного дерьма. Речь идёт о стадах программистов и менеджеров, которые последние пару лет толпами мигрируют к нам из соседних областей, но при этом совершенно игнорируют специфику геймдева. По моему опыту людям из кровавого крайне трудно вкатиться в разработку игр: здесь другой темп написания кода; другие методы тестирования; другая, в конце концов, динамика изменения ТЗ от геймдизайнера. Но есть люди, которые понимают, что теперь работают с произведением искусства, и пытаются адаптироваться; а есть мудилы, которые этого не хотят. Последние — это, как ни парадоксально, люди поопытнее, сформировавшие уже не только собственные привычки, но и солидное ЧСВ. Это тот чувак у вас в команде, который типа прохавал всё IT, много говорит о софтскиллах и о том, как делать правильно, но в общей телеге его колесо всегда волочится по другой колее. Это он треплет нервы всем артистам бюрократией, и именно на его тасках всегда в итоге происходит фичекат.
Частные эманации этого ползучего зла могут быть самые разные, поэтому мне не удастся рассказать, как это выглядит изнутри в каждой конкретной студии, но я могу описать их внешние проявления: по терминологии узнаете их! Уже столько вокруг пролезло бездушного, что их язык стал проникать в нашу среду.
Начну с моего личного чемпиона по мерзости: «мы продуктовая игровая компания!». Если у вас ещё почему-то не задёргался глаз, то поясню. Дело в том, что у них там в большом IT компании сплошь оутсорсовые, консалтинговые и бог знает какие ещё (уж извините, не разбираюсь). Бывает, что люди там годами таски какие-то делают, а пощупать плоды труда нельзя. Поэтому слово «продуктовая» для гребцов в тугих галстуках — это реально порой единственный глоток неденежной мотивации. Но когда HR радостно сообщает мне о «продуктовой игровой компании», для меня это тавтология. Для любого разработчика игр понятие «игровая компания» по умолчанию подразумевает работу над продуктом. Мы пришли в профессию, чтобы делать игры, и в большинстве своём только в таких компаниях и работали. «Продуктовость» это не бонус для нас, а вещь сама собой разумеющаяся. Это вот если вдруг компания не делает собственные игры, а аутсорсит непонятно что — вот тогда уже надо уточнять. Поэтому если вам кто-то из разрабов презентует свою компанию, как «продуктовую», то бегите. Вы там вряд ли встретите крутых артистов, которые делают вещи, или идейных программеров. Если они там были, то разбежались. Судя по лексикону, скорее всего это просто студия-симулякр из энтерпрайзников, где думают не об игре и игроках, а об удовлетворении шизы какого-нибудь заказчика (совсем как в вэбе, да).
Нетерпеливый подписчик возразит мне, что отличный вокабуляр это вовсе не проблема и я зря драматизирую; но язык определяет сознание, и в случае геймдева неизбежно приводит к натягиванию совы на известно что. Приведу пример поубедительнее. Если вы загуглите уровень зарплат в геймдеве, вы скорее всего найдёте опросы, где разработчики разбиты на Frontend, Backend и Fullstack. Привычное разделение в IT, но которое совершенно бессмысленно в геймдеве. Тут сразу несколько проблем.
Прежде всего, поставьте себя на место разработчика игрового движка синглплеерной игры. С одной стороны сервера нет, так что он работает, получается, над клиентом. Записываем во Frontend. С другой стороны, он не пишет саму игру, а для скриптеров его API выступает вполне себе Backend’ом. Наконец, можно заключить, что есть элементы того и другого, и выбрать вариант Fullstack. С равной вероятностью можно занести себя куда угодно. Подобные неоднозначности возникают и со многими другими геймдев-специализациями, если задуматься. В итоге такой опрос не показывает ничего, кроме погоды в унитазе составителя.
Но даже если представить, что мы договорились, кого в какую группу относить, это всё равно бессмысленные надкатегории, которые ничего не значат. В вэбе и мобильных приложениях Front и Back это естественным образом выделившиеся специализации, но в геймдеве такого разделения не произошло. Generalist-программисты у нас разделяются на геймплейщиков, графических, движкописателей/туловиков, иногда отдельно интерфейсщиков. Из геймплейщиков можно отдельно выделять скриптеров; из графических тех.артистов; движковых можно дальше дробить на физику, звук, АИ, сеть и т.п., но это не принципиально. Я не претендую на полноту классификации, но главное, что за категориями «графический программист» или «программист UI» стоят реальные вакансии и карьеры людей, которые двигались по этому пути, а Frontend-программист в геймдеве — это просто искусственная категория. И игровой код, и ИИ, и физика могут выполняться как на клиенте, так и на сервере, но различать их по этому признаку плохая идея.
Это ведь нетрудно задуматься, что некоторые привычные процессы или подходы просто неприменимы в геймдеве; что существует специфика работы. Но львиную долю набежавших энтепрайзников не посещает такая мысль даже на уровне терминологии. Теперь представьте, насколько часто в ваших внутренних процессах происходят спотыкания о всевозможные нюансы, если ваш HR тратит время разработчика на рассказы про вашу продуктовость; PM не видит перед собой геймплейного и графического программиста, а оперирует в голове выдуманными категориями; а программист интерфейсов требует ТЗ за два месяца и по шаблону мобильных приложений. И это только внешние очевидные проявления, а дьявол в мелочах и повседневном опыте.
Если слышите, что кто-то бездумно тащит в наше ремесло чужую терминологию, гоните его, насмехайтесь, зовите земляным червяком.
Прежде всего, поставьте себя на место разработчика игрового движка синглплеерной игры. С одной стороны сервера нет, так что он работает, получается, над клиентом. Записываем во Frontend. С другой стороны, он не пишет саму игру, а для скриптеров его API выступает вполне себе Backend’ом. Наконец, можно заключить, что есть элементы того и другого, и выбрать вариант Fullstack. С равной вероятностью можно занести себя куда угодно. Подобные неоднозначности возникают и со многими другими геймдев-специализациями, если задуматься. В итоге такой опрос не показывает ничего, кроме погоды в унитазе составителя.
Но даже если представить, что мы договорились, кого в какую группу относить, это всё равно бессмысленные надкатегории, которые ничего не значат. В вэбе и мобильных приложениях Front и Back это естественным образом выделившиеся специализации, но в геймдеве такого разделения не произошло. Generalist-программисты у нас разделяются на геймплейщиков, графических, движкописателей/туловиков, иногда отдельно интерфейсщиков. Из геймплейщиков можно отдельно выделять скриптеров; из графических тех.артистов; движковых можно дальше дробить на физику, звук, АИ, сеть и т.п., но это не принципиально. Я не претендую на полноту классификации, но главное, что за категориями «графический программист» или «программист UI» стоят реальные вакансии и карьеры людей, которые двигались по этому пути, а Frontend-программист в геймдеве — это просто искусственная категория. И игровой код, и ИИ, и физика могут выполняться как на клиенте, так и на сервере, но различать их по этому признаку плохая идея.
Это ведь нетрудно задуматься, что некоторые привычные процессы или подходы просто неприменимы в геймдеве; что существует специфика работы. Но львиную долю набежавших энтепрайзников не посещает такая мысль даже на уровне терминологии. Теперь представьте, насколько часто в ваших внутренних процессах происходят спотыкания о всевозможные нюансы, если ваш HR тратит время разработчика на рассказы про вашу продуктовость; PM не видит перед собой геймплейного и графического программиста, а оперирует в голове выдуманными категориями; а программист интерфейсов требует ТЗ за два месяца и по шаблону мобильных приложений. И это только внешние очевидные проявления, а дьявол в мелочах и повседневном опыте.
Если слышите, что кто-то бездумно тащит в наше ремесло чужую терминологию, гоните его, насмехайтесь, зовите земляным червяком.
А давайте поболтаем?
#лайт
Знаете чего не хватает, когда все месяцами работают удалённо? Технической болтовни из-за мониторов. Нормальное гиковское чувство рассказать о том, какой крутой пейпер прочитал вчера ночью, и как здорово раст уделывает кресты на синтетических тестах. Не уныло бросить ссылку в чат, а голосом раскидать императивщику за тайп-дедукшен здорового человека.
Вы уже догадываетесь к чему я клоню? Если вы из тех, кого хайп вокруг трендов раздражает, как блики солнечного света на дисплее, вам впору зашторивать окна. Речь пойдёт о clubhouse.
Мне прислали инвайт пару дней назад и я немного помониторил, если там жизнь в плане игростроя. Оказалось, что есть! Днём, разумеется, никого нет, но по вечерам там появляется «геймдев курилка», в которой всегда на удивление много людей. Причём не левого народу: если вы в индустрии не первый год или тусили пару раз на конференциях, то без труда отыщите кучу знакомых лиц на аватарках. Но, к сожалению, тон разговоров в курилке, как это часто бывает, захватили основатели студий, инвесторы и менеджеры. Эдакий дискурс старого DTF (ещё до смены владельцев). Вклиниваться в эти высокие разговоры о free to play не очень интересно; да и это совсем не то, чего просит душа простого технаря. А запрос на свою комнату, мне кажется, есть.
Я предлагаю собраться втроём или вчетвером, каждому заранее прочесть/изучить по одной интересной статье или пейперу, и рассказать каким-нибудь воскресным вечером друг другу, почему этот подход классный (или отстой). Это может быть новый proposal в С++, какая-нибудь фича из kotlin, статья про новый метод рейтрейсинга или же и вовсе эзотерический язык программирования. Что угодно. Расширим кругозор друг друга, а может чего интересного узнаем от аудитории.
Чем это отличается от подкаста?
Я давно хотел попробовать провести что-то вроде подкаста, но не был уверен насчёт формата. В своё время, когда заводил блог, я выбрал телеграмм, потому что рассудил, что это наиболее вменяемая платформа для технических блогов в наше время. Никому мои посты не интересны настолько, чтобы заходить на какой-то мой личный сайт или мониторить на Medium. А когда это всё происходит внутри платформы Telegram, куда люди и так заходят время от времени, аудитория не пропадает, и мои посты кто-то видит и обсуждает, даже если я пишу раз в месяц. Так же и с clubhouse. Там уже есть какой-то движ и люди туда заходят каждый день, так что почему бы и не поболтать?
Кроме того, традиционный подкаст предполагает более строгое отношение к контенту, хотя бы потому, что сохраняется в вечность. Он нацелен на то, что его будут слушать и после. Здесь же после прямого эфира ничего не остаётся. Это менее обязывающая форма подкаста, зато более динамичная и с живым общением со случайными слушателями. А после обсуждения и пост на тему проще писать.
Чем тогда это отличается от созвона в дискорде?
Тем, что в дискорде не бывает случайной аудитории. Никто не узнает, что на каком-то никому неизвестном сервере собрались три калеки и что-то обсуждают. Никто не подключится, не задаст вопросов и не вклинится в разговор. Здесь же мы можем создать комнату в clubhouse заранее и расписание увидит много людей. Кто-то поставит в календарь, а кто-то подключится в прямом эфире и «поднимет руку», чтобы ему тоже дали слово. Это может быть гораздо более интересный движняк, чем разговор на пустом сервере.
Так и чё?
Один я ничего не сделаю. Нужно ещё хотя бы пара человек, кому интересно читать/изучать что-то новое для себя, и кому интересно это обсудить в таком формате. Пишите в комментариях, кому идея кажется хорошей. Ну и о том, как вас достали разговоры о clubhouse из всех утюгов, тоже туда пишите. Не держите в себе :)
#лайт
Знаете чего не хватает, когда все месяцами работают удалённо? Технической болтовни из-за мониторов. Нормальное гиковское чувство рассказать о том, какой крутой пейпер прочитал вчера ночью, и как здорово раст уделывает кресты на синтетических тестах. Не уныло бросить ссылку в чат, а голосом раскидать императивщику за тайп-дедукшен здорового человека.
Вы уже догадываетесь к чему я клоню? Если вы из тех, кого хайп вокруг трендов раздражает, как блики солнечного света на дисплее, вам впору зашторивать окна. Речь пойдёт о clubhouse.
Мне прислали инвайт пару дней назад и я немного помониторил, если там жизнь в плане игростроя. Оказалось, что есть! Днём, разумеется, никого нет, но по вечерам там появляется «геймдев курилка», в которой всегда на удивление много людей. Причём не левого народу: если вы в индустрии не первый год или тусили пару раз на конференциях, то без труда отыщите кучу знакомых лиц на аватарках. Но, к сожалению, тон разговоров в курилке, как это часто бывает, захватили основатели студий, инвесторы и менеджеры. Эдакий дискурс старого DTF (ещё до смены владельцев). Вклиниваться в эти высокие разговоры о free to play не очень интересно; да и это совсем не то, чего просит душа простого технаря. А запрос на свою комнату, мне кажется, есть.
Я предлагаю собраться втроём или вчетвером, каждому заранее прочесть/изучить по одной интересной статье или пейперу, и рассказать каким-нибудь воскресным вечером друг другу, почему этот подход классный (или отстой). Это может быть новый proposal в С++, какая-нибудь фича из kotlin, статья про новый метод рейтрейсинга или же и вовсе эзотерический язык программирования. Что угодно. Расширим кругозор друг друга, а может чего интересного узнаем от аудитории.
Чем это отличается от подкаста?
Я давно хотел попробовать провести что-то вроде подкаста, но не был уверен насчёт формата. В своё время, когда заводил блог, я выбрал телеграмм, потому что рассудил, что это наиболее вменяемая платформа для технических блогов в наше время. Никому мои посты не интересны настолько, чтобы заходить на какой-то мой личный сайт или мониторить на Medium. А когда это всё происходит внутри платформы Telegram, куда люди и так заходят время от времени, аудитория не пропадает, и мои посты кто-то видит и обсуждает, даже если я пишу раз в месяц. Так же и с clubhouse. Там уже есть какой-то движ и люди туда заходят каждый день, так что почему бы и не поболтать?
Кроме того, традиционный подкаст предполагает более строгое отношение к контенту, хотя бы потому, что сохраняется в вечность. Он нацелен на то, что его будут слушать и после. Здесь же после прямого эфира ничего не остаётся. Это менее обязывающая форма подкаста, зато более динамичная и с живым общением со случайными слушателями. А после обсуждения и пост на тему проще писать.
Чем тогда это отличается от созвона в дискорде?
Тем, что в дискорде не бывает случайной аудитории. Никто не узнает, что на каком-то никому неизвестном сервере собрались три калеки и что-то обсуждают. Никто не подключится, не задаст вопросов и не вклинится в разговор. Здесь же мы можем создать комнату в clubhouse заранее и расписание увидит много людей. Кто-то поставит в календарь, а кто-то подключится в прямом эфире и «поднимет руку», чтобы ему тоже дали слово. Это может быть гораздо более интересный движняк, чем разговор на пустом сервере.
Так и чё?
Один я ничего не сделаю. Нужно ещё хотя бы пара человек, кому интересно читать/изучать что-то новое для себя, и кому интересно это обсудить в таком формате. Пишите в комментариях, кому идея кажется хорошей. Ну и о том, как вас достали разговоры о clubhouse из всех утюгов, тоже туда пишите. Не держите в себе :)
Патетичная речь о том, что я покидаю Encased
Encased — это очень важный для меня проект. В конце 2017 года, во время моего мексиканского саббатикала после работы в одной инди-команде, я вписался в новый геймдев-стартап. Фактически, мои старые университетские друзья позвали меня писать «русский Fallout». Это выглядело именно так, как звучит. Даже хуже: это сегодня словосочетание «русский Fallout» уже немного реабилитировано, а на тот момент это было чистым ругательством. Словом, очередные «корованы».
Но меня тогда прельщала возможность работать удалённо (да-да, были времена, когда это воспринималось привилегией, а не наказанием), попробовать себя лидом большого хардкорного проекта, а также у меня ещё жутко свербел гештальт по написанию ролевой игры. Олдфаги форума gamedev.ru наверняка помнят мой эпичный тред «маленькое и скромное РПГ», которое я ещё со школьной скамьи два года пилил на Visual Basic. Так вот ещё с тех пор мне хотелось снова залететь в эту же историю, но уже профессионально.
Удивительное дело, но наша команда не развалилась через два месяца. Мы просто фигачили лучшее, что могли, и мало-помалу у меня сперва исчезал скептицизм по отношению к нашему детищу, а затем я и вовсе по-настоящему прикипел к нему душой. Я фигачил над Encased 3 года и 4 месяца от первой строчки кода, от архитектуры, собственной сериализации и компонентной системы; к кикстартеру, на котором у меня случился нервный срыв; через собеседования новых сотрудников, прожатие F5 на странице отзывов и через девгаммы к раннему доступу; с переносом сроков, сменой издателя, портированием и ещё со множеством эпичных историй, которые без пива не рассказывают; в ту точку, где мы находимся сейчас — в пред-релизный пятый патч.
Сейчас я уверен в проекте, как никогда. Мы действительно делали «игру-мечты». Я не просто закрывал таски, но оказал большое влияние на то, как в итоге реализованы многие механики, боёвка, интерфейс, да и в целом управление в игре. Потому что мне было не пофиг. И наверное сейчас я впервые верю, что у нас действительно получается игра, которая посоревнуется с лучшими мировыми.
И в этом месте я покидаю Encased.
С самого начала проекта я жил в двух реальностях. В одной реальности я делал самый офигенный и важный проект в своей карьере, а в другой — жил не совсем своей жизнью. Меня захантили на проект немного хитростью: при обсуждении стартапа в качестве возможного движка рассматривался Unreal, а когда я уже морально настроился работать, оказалось, что бизнес готов вести дела только на Unity. Пришлось переступить через себя и вернуться к нелюбимому Unity. Но вообще мой настоящий гендер, как многие знают, — это крестовик с движкописательным уклоном. Плюс быть лидом, конечно, круто; но когда нет более крутых коллег, начинаешь замыкаться в собственных соплях, что не очень круто. Мне пока ещё рано замыкаться — хочется покачаться ещё хотя бы пару лет. Не говоря уж о планах эмиграции.
Encased — это очень важный для меня проект. В конце 2017 года, во время моего мексиканского саббатикала после работы в одной инди-команде, я вписался в новый геймдев-стартап. Фактически, мои старые университетские друзья позвали меня писать «русский Fallout». Это выглядело именно так, как звучит. Даже хуже: это сегодня словосочетание «русский Fallout» уже немного реабилитировано, а на тот момент это было чистым ругательством. Словом, очередные «корованы».
Но меня тогда прельщала возможность работать удалённо (да-да, были времена, когда это воспринималось привилегией, а не наказанием), попробовать себя лидом большого хардкорного проекта, а также у меня ещё жутко свербел гештальт по написанию ролевой игры. Олдфаги форума gamedev.ru наверняка помнят мой эпичный тред «маленькое и скромное РПГ», которое я ещё со школьной скамьи два года пилил на Visual Basic. Так вот ещё с тех пор мне хотелось снова залететь в эту же историю, но уже профессионально.
Удивительное дело, но наша команда не развалилась через два месяца. Мы просто фигачили лучшее, что могли, и мало-помалу у меня сперва исчезал скептицизм по отношению к нашему детищу, а затем я и вовсе по-настоящему прикипел к нему душой. Я фигачил над Encased 3 года и 4 месяца от первой строчки кода, от архитектуры, собственной сериализации и компонентной системы; к кикстартеру, на котором у меня случился нервный срыв; через собеседования новых сотрудников, прожатие F5 на странице отзывов и через девгаммы к раннему доступу; с переносом сроков, сменой издателя, портированием и ещё со множеством эпичных историй, которые без пива не рассказывают; в ту точку, где мы находимся сейчас — в пред-релизный пятый патч.
Сейчас я уверен в проекте, как никогда. Мы действительно делали «игру-мечты». Я не просто закрывал таски, но оказал большое влияние на то, как в итоге реализованы многие механики, боёвка, интерфейс, да и в целом управление в игре. Потому что мне было не пофиг. И наверное сейчас я впервые верю, что у нас действительно получается игра, которая посоревнуется с лучшими мировыми.
И в этом месте я покидаю Encased.
С самого начала проекта я жил в двух реальностях. В одной реальности я делал самый офигенный и важный проект в своей карьере, а в другой — жил не совсем своей жизнью. Меня захантили на проект немного хитростью: при обсуждении стартапа в качестве возможного движка рассматривался Unreal, а когда я уже морально настроился работать, оказалось, что бизнес готов вести дела только на Unity. Пришлось переступить через себя и вернуться к нелюбимому Unity. Но вообще мой настоящий гендер, как многие знают, — это крестовик с движкописательным уклоном. Плюс быть лидом, конечно, круто; но когда нет более крутых коллег, начинаешь замыкаться в собственных соплях, что не очень круто. Мне пока ещё рано замыкаться — хочется покачаться ещё хотя бы пару лет. Не говоря уж о планах эмиграции.
Короче говоря, ещё в самом начале проекта я пообещал себе, что не буду просиживать штаны на поддержке и полировке, если полный релиз будет постоянно откладываться (о том, что с крупными долгостроями так бывает, я понимал изначально). Сделаю всё основное — и уйду. И вот я наконец-то сдержал обещание (хотя и так затянул сильно дольше, чем рассчитывал).
Я оставляю проект со спокойной душой, потому что он в хорошем состоянии. И не смотрите, что сейчас недавние отзывы на стиме красные. Это только последние штук 30 и только из-за нашего долгого молчания. Но вопреки крикам хейтеров, которые утверждают, что мы ничего не делали чуть ли не с прошлого августа; игра всё это время активно разрабатывалась. Игра действительно уже проходится от начала до конца и технически полностью готова. Я закончил архитектуру и все важнейшие подсистемы, а также «вырастил» нового лида, который шарит в моём коде уже чуть ли не как я сам, и который с лёгкостью дотащит проект. Собственно, уже даже в этом патче все самые сочные изменения были внесены под его руководством; а я последние два месяца лишь поглядывал за процессом из полу-саббатикала. Ну а теперь я полностью ушёл.
Посмотрите свежий дневник разработки в шапке поста, чтобы узнать в каком состоянии игра на самом деле. Поиграйте в патч 5, который выходит сегодня на Steam, чтобы убедиться, что это не монтаж. Но только сильно не увлекайтесь — полноценное прохождение стоит отложить до релиза. Это в самом деле хорошая игра получается.
Я оставляю проект со спокойной душой, потому что он в хорошем состоянии. И не смотрите, что сейчас недавние отзывы на стиме красные. Это только последние штук 30 и только из-за нашего долгого молчания. Но вопреки крикам хейтеров, которые утверждают, что мы ничего не делали чуть ли не с прошлого августа; игра всё это время активно разрабатывалась. Игра действительно уже проходится от начала до конца и технически полностью готова. Я закончил архитектуру и все важнейшие подсистемы, а также «вырастил» нового лида, который шарит в моём коде уже чуть ли не как я сам, и который с лёгкостью дотащит проект. Собственно, уже даже в этом патче все самые сочные изменения были внесены под его руководством; а я последние два месяца лишь поглядывал за процессом из полу-саббатикала. Ну а теперь я полностью ушёл.
Посмотрите свежий дневник разработки в шапке поста, чтобы узнать в каком состоянии игра на самом деле. Поиграйте в патч 5, который выходит сегодня на Steam, чтобы убедиться, что это не монтаж. Но только сильно не увлекайтесь — полноценное прохождение стоит отложить до релиза. Это в самом деле хорошая игра получается.
Я вас всех немножко обманул
В прошлом сообщении я писал, что покидаю Encased, но это оказалась не совсем правда. Уходить-то я уходил, но ненадолго (всего на 2 месяца). Видимо, такие проекты просто так не отпускают. Планы, сроки и даты сложились таким образом, что у меня образовалось идеальное окно, чтобы вернуться и довести проект до релиза. В конце июня я вернулся и работал над Encased практически вплоть до настоящего момента.
Ужасно рад, что так сложились звёзды, что мне всё-таки удалось работать над проектом от первой строчки кода и до версии 1.0. Которую я сегодня и хочу вам представить от имени всей команды.
Пару часов назад Encased 1.0 вышел в релиз в Steam, Gog и Epic Games Store. Бегите скорее покупать, если ещё этого не сделали:
https://store.steampowered.com/app/921800/
Что же касается моих планов, сроков и дат, о которые я упоминал выше; то со вчерашнего дня я работаю в Paradox Development Studio. Чем я там занимаюсь, я, естественно, не расскажу. Но это ровно та компания, в которую я хотел устроиться. Может быть отдельным постом как-нибудь расскажу, почему я хотел именно в Швецию, и почему именно в Paradox. Но это будет в другой раз. А сегодня мы празднуем выход Encased! Ваше здоровье, господа! Skål!
В прошлом сообщении я писал, что покидаю Encased, но это оказалась не совсем правда. Уходить-то я уходил, но ненадолго (всего на 2 месяца). Видимо, такие проекты просто так не отпускают. Планы, сроки и даты сложились таким образом, что у меня образовалось идеальное окно, чтобы вернуться и довести проект до релиза. В конце июня я вернулся и работал над Encased практически вплоть до настоящего момента.
Ужасно рад, что так сложились звёзды, что мне всё-таки удалось работать над проектом от первой строчки кода и до версии 1.0. Которую я сегодня и хочу вам представить от имени всей команды.
Пару часов назад Encased 1.0 вышел в релиз в Steam, Gog и Epic Games Store. Бегите скорее покупать, если ещё этого не сделали:
https://store.steampowered.com/app/921800/
Что же касается моих планов, сроков и дат, о которые я упоминал выше; то со вчерашнего дня я работаю в Paradox Development Studio. Чем я там занимаюсь, я, естественно, не расскажу. Но это ровно та компания, в которую я хотел устроиться. Может быть отдельным постом как-нибудь расскажу, почему я хотел именно в Швецию, и почему именно в Paradox. Но это будет в другой раз. А сегодня мы празднуем выход Encased! Ваше здоровье, господа! Skål!