Log of Alprog

2021-02-19 01:22:56 А давайте поболтаем?
#лайт
Знаете чего не хватает, когда все месяцами работают удалённо? Технической болтовни из-за мониторов. Нормальное гиковское чувство рассказать о том, какой крутой пейпер прочитал вчера ночью, и как здорово раст уделывает кресты на синтетических тестах. Не уныло бросить ссылку в чат, а голосом раскидать императивщику за тайп-дедукшен здорового человека.

Вы уже догадываетесь к чему я клоню? Если вы из тех, кого хайп вокруг трендов раздражает, как блики солнечного света на дисплее, вам впору зашторивать окна. Речь пойдёт о clubhouse.

Мне прислали инвайт пару дней назад и я немного помониторил, если там жизнь в плане игростроя. Оказалось, что есть! Днём, разумеется, никого нет, но по вечерам там появляется «геймдев курилка», в которой всегда на удивление много людей. Причём не левого народу: если вы в индустрии не первый год или тусили пару раз на конференциях, то без труда отыщите кучу знакомых лиц на аватарках. Но, к сожалению, тон разговоров в курилке, как это часто бывает, захватили основатели студий, инвесторы и менеджеры. Эдакий дискурс старого DTF (ещё до смены владельцев). Вклиниваться в эти высокие разговоры о free to play не очень интересно; да и это совсем не то, чего просит душа простого технаря. А запрос на свою комнату, мне кажется, есть.

Я предлагаю собраться втроём или вчетвером, каждому заранее прочесть/изучить по одной интересной статье или пейперу, и рассказать каким-нибудь воскресным вечером друг другу, почему этот подход классный (или отстой). Это может быть новый proposal в С++, какая-нибудь фича из kotlin, статья про новый метод рейтрейсинга или же и вовсе эзотерический язык программирования. Что угодно. Расширим кругозор друг друга, а может чего интересного узнаем от аудитории.

Чем это отличается от подкаста?
Я давно хотел попробовать провести что-то вроде подкаста, но не был уверен насчёт формата. В своё время, когда заводил блог, я выбрал телеграмм, потому что рассудил, что это наиболее вменяемая платформа для технических блогов в наше время. Никому мои посты не интересны настолько, чтобы заходить на какой-то мой личный сайт или мониторить на Medium. А когда это всё происходит внутри платформы Telegram, куда люди и так заходят время от времени, аудитория не пропадает, и мои посты кто-то видит и обсуждает, даже если я пишу раз в месяц. Так же и с clubhouse. Там уже есть какой-то движ и люди туда заходят каждый день, так что почему бы и не поболтать?

Кроме того, традиционный подкаст предполагает более строгое отношение к контенту, хотя бы потому, что сохраняется в вечность. Он нацелен на то, что его будут слушать и после. Здесь же после прямого эфира ничего не остаётся. Это менее обязывающая форма подкаста, зато более динамичная и с живым общением со случайными слушателями. А после обсуждения и пост на тему проще писать.

Чем тогда это отличается от созвона в дискорде?
Тем, что в дискорде не бывает случайной аудитории. Никто не узнает, что на каком-то никому неизвестном сервере собрались три калеки и что-то обсуждают. Никто не подключится, не задаст вопросов и не вклинится в разговор. Здесь же мы можем создать комнату в clubhouse заранее и расписание увидит много людей. Кто-то поставит в календарь, а кто-то подключится в прямом эфире и «поднимет руку», чтобы ему тоже дали слово. Это может быть гораздо более интересный движняк, чем разговор на пустом сервере.

Так и чё?
Один я ничего не сделаю. Нужно ещё хотя бы пара человек, кому интересно читать/изучать что-то новое для себя, и кому интересно это обсудить в таком формате. Пишите в комментариях, кому идея кажется хорошей. Ну и о том, как вас достали разговоры о clubhouse из всех утюгов, тоже туда пишите. Не держите в себе :) Открыть/Комментировать

2021-02-19 01:22:56 Открыть/Комментировать

2021-01-08 07:18:30 Нетерпеливый подписчик возразит мне, что отличный вокабуляр это вовсе не проблема и я зря драматизирую; но язык определяет сознание, и в случае геймдева неизбежно приводит к натягиванию совы на известно что. Приведу пример поубедительнее. Если вы загуглите уровень зарплат в геймдеве, вы скорее всего найдёте опросы, где разработчики разбиты на Frontend, Backend и Fullstack. Привычное разделение в IT, но которое совершенно бессмысленно в геймдеве. Тут сразу несколько проблем.

Прежде всего, поставьте себя на место разработчика игрового движка синглплеерной игры. С одной стороны сервера нет, так что он работает, получается, над клиентом. Записываем во Frontend. С другой стороны, он не пишет саму игру, а для скриптеров его API выступает вполне себе Backend’ом. Наконец, можно заключить, что есть элементы того и другого, и выбрать вариант Fullstack. С равной вероятностью можно занести себя куда угодно. Подобные неоднозначности возникают и со многими другими геймдев-специализациями, если задуматься. В итоге такой опрос не показывает ничего, кроме погоды в унитазе составителя.

Но даже если представить, что мы договорились, кого в какую группу относить, это всё равно бессмысленные надкатегории, которые ничего не значат. В вэбе и мобильных приложениях Front и Back это естественным образом выделившиеся специализации, но в геймдеве такого разделения не произошло. Generalist-программисты у нас разделяются на геймплейщиков, графических, движкописателей/туловиков, иногда отдельно интерфейсщиков. Из геймплейщиков можно отдельно выделять скриптеров; из графических тех.артистов; движковых можно дальше дробить на физику, звук, АИ, сеть и т.п., но это не принципиально. Я не претендую на полноту классификации, но главное, что за категориями «графический программист» или «программист UI» стоят реальные вакансии и карьеры людей, которые двигались по этому пути, а Frontend-программист в геймдеве — это просто искусственная категория. И игровой код, и ИИ, и физика могут выполняться как на клиенте, так и на сервере, но различать их по этому признаку плохая идея.

Это ведь нетрудно задуматься, что некоторые привычные процессы или подходы просто неприменимы в геймдеве; что существует специфика работы. Но львиную долю набежавших энтепрайзников не посещает такая мысль даже на уровне терминологии. Теперь представьте, насколько часто в ваших внутренних процессах происходят спотыкания о всевозможные нюансы, если ваш HR тратит время разработчика на рассказы про вашу продуктовость; PM не видит перед собой геймплейного и графического программиста, а оперирует в голове выдуманными категориями; а программист интерфейсов требует ТЗ за два месяца и по шаблону мобильных приложений. И это только внешние очевидные проявления, а дьявол в мелочах и повседневном опыте.

Если слышите, что кто-то бездумно тащит в наше ремесло чужую терминологию, гоните его, насмехайтесь, зовите земляным червяком. Открыть/Комментировать

2021-01-08 07:18:30 По кровавым словам узнаете их
#лайт
Если бы IT было командой черепашек-ниндзя, то игровая индустрия была бы в ней Микеланджело. Ну а среди грызунов-спасателей геймдеву, конечно же, досталась бы роль Дейла. Мы всегда были эдаким младшим и немного придурковатым персонажем IT-мира. Самый весёлый, но наивный раздолбай в гавайской рубашке, обожающий пиццу, комиксы и попадать в дебильные ситуации — это всё мы. И безусловно, нам есть чему поучиться у более старших и серьёзных коллег: от дисциплины и оценки сроков до культуры софтскиллов и ведения документации. У нас всё ещё полно детских болячек отрасли, как прыщей у подростка. Но всё же это не значит, что какой-нибудь занудный Донателло сможет так же ловко управляться с нунчаками, как это делаем мы. Когда дело доходит до владения палками на цепи, стоит спросить совета у Микеланджело.

К сожалению, на фоне всех хороших трендов взросления индустрии, сближение с энтерпрайзом занесло в нашу песочницу и пару куличиков добротного дерьма. Речь идёт о стадах программистов и менеджеров, которые последние пару лет толпами мигрируют к нам из соседних областей, но при этом совершенно игнорируют специфику геймдева. По моему опыту людям из кровавого крайне трудно вкатиться в разработку игр: здесь другой темп написания кода; другие методы тестирования; другая, в конце концов, динамика изменения ТЗ от геймдизайнера. Но есть люди, которые понимают, что теперь работают с произведением искусства, и пытаются адаптироваться; а есть мудилы, которые этого не хотят. Последние — это, как ни парадоксально, люди поопытнее, сформировавшие уже не только собственные привычки, но и солидное ЧСВ. Это тот чувак у вас в команде, который типа прохавал всё IT, много говорит о софтскиллах и о том, как делать правильно, но в общей телеге его колесо всегда волочится по другой колее. Это он треплет нервы всем артистам бюрократией, и именно на его тасках всегда в итоге происходит фичекат.

Частные эманации этого ползучего зла могут быть самые разные, поэтому мне не удастся рассказать, как это выглядит изнутри в каждой конкретной студии, но я могу описать их внешние проявления: по терминологии узнаете их! Уже столько вокруг пролезло бездушного, что их язык стал проникать в нашу среду.

Начну с моего личного чемпиона по мерзости: «мы продуктовая игровая компания!». Если у вас ещё почему-то не задёргался глаз, то поясню. Дело в том, что у них там в большом IT компании сплошь оутсорсовые, консалтинговые и бог знает какие ещё (уж извините, не разбираюсь). Бывает, что люди там годами таски какие-то делают, а пощупать плоды труда нельзя. Поэтому слово «продуктовая» для гребцов в тугих галстуках — это реально порой единственный глоток неденежной мотивации. Но когда HR радостно сообщает мне о «продуктовой игровой компании», для меня это тавтология. Для любого разработчика игр понятие «игровая компания» по умолчанию подразумевает работу над продуктом. Мы пришли в профессию, чтобы делать игры, и в большинстве своём только в таких компаниях и работали. «Продуктовость» это не бонус для нас, а вещь сама собой разумеющаяся. Это вот если вдруг компания не делает собственные игры, а аутсорсит непонятно что — вот тогда уже надо уточнять. Поэтому если вам кто-то из разрабов презентует свою компанию, как «продуктовую», то бегите. Вы там вряд ли встретите крутых артистов, которые делают вещи, или идейных программеров. Если они там были, то разбежались. Судя по лексикону, скорее всего это просто студия-симулякр из энтерпрайзников, где думают не об игре и игроках, а об удовлетворении шизы какого-нибудь заказчика (совсем как в вэбе, да). Открыть/Комментировать

2021-01-08 07:18:30 Открыть/Комментировать

2020-12-18 23:17:54 Поправочка!
#код
Ох, что-то я написал этот пост и тут же понял, что лишнего наворотил. Движение, при котором мы за равные промежутки проходим половину, затем половину от остатка и так далее — это фактически тоже самое движение, когда мы за равные промежутки проходим треть, затем треть от остатка и так далее. Это просто свойство перевёрнутой экспоненты самой по себе. И неважно какое основание. А чтобы управлять агрессивностью 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);
}
} Открыть/Комментировать

2020-12-18 21:26:52 Логарифм и резинки
#код
Как-то в одном из чатов обронили фразу: «а когда вам последний раз был нужен логарифм?». Забавно, но мне он потребовался буквально на следующий день. Это ещё один маленький пост о том, какого рода математика нужна геймплейному программисту в повседневной жизни.

Часто нам нужно сглаживать какие-то процессы, у которых нет чёткого конца или он меняется во времени. Ну, например, у нас один объект — пусть это будет ручной дракончик — движется на воображаемой резинке за другим объектом, который тоже постоянно в движении: скажем, это будет персонаж игрока. Если игрок оказался далеко от дракончика (например, телепортировался), то дракончик сперва летит к нему очень быстро, но при приближении постепенно замедляется, чтобы это смотрелось хорошо.

Новички обычно просто домножают скорость дракончика на расстояние до игрока. Это простое решение, но ужасно плохое, поскольку время, за которое дракончик долетит до игрока, будет напрямую зависеть от FPS. При низком фпс он будет добираться до цели быстро, а при большом топтаться на месте неожиданно долго. А если FPS скачет, то и вовсе придётся лицезреть нечто рывкообразное.

Юнитологи классом повыше обычно используют небезызвестную функцию SmoothDamp. Внутри там скрывается мудрённое решение из книги Game Programming Gems 4. Вот только нам приходится где-то хранить текущую скорость для каждого процесса сглаживания, да и в целом довольно страшно выглядит. Нельзя ли как-то попроще сделать и без лишних переменных в местах вызова?

На самом деле если мы задумаемся, как будет выглядеть FPS-независимый способ приближения со сглаживанием, то быстро поймём, что нам надо проходить одинаковую долю расстояния за одинаковое время. Например, за первую секунду проходим половину пути, за вторую секунду половину от половины, то есть остаётся четверть, затем 1/8, 1/16 и так далее. И никогда мы по настоящему не достигаем цели, но нам это и не надо. При таком движении неважно в какой точке этого процесса мы оказались (на первой секунде, второй и т.п.), мы всегда знаем, как рассчитать движение дальше. От пути всегда остаётся лишь

1 / 2^t

А значит пройденное расстояние от времени вычисляется по формуле:

1 - 1 / 2^t

Двойка здесь всего лишь указатель на то, что в качестве одинаковых промежутков мы выбрали половину расстояния. Мы можем подставить туда 3, чтобы получить треть, или любое другое число больше 1. Можно думать об этом числе, как о степени агрессивности нашего In в нашем FPS-независимом сглаживании (аналог InCubic, InQuad и т.д.). Формула продолжит работать.

Но для полного счастья нам не хватает настройки времени, за которое дракончик будет визуально догонять персонажа из любой точки. Конечно, полностью он догнать не может, но нам хватит преодоления, скажем, 98% пути:

1 - 1 / base^t = 0,98
base^t = 1 / (1 - 0,98)
t = log(1 / (1 - 0,98), base)

Ну вот и всё. Теперь мы можем инициализировать этими параметрами нашу бесконечную резинку-пружинку, после чего ей можно будет скармливать deltaTime, а в ответ получать LerpK. Таким образом получилось простое FPS-независимое сглаживание для всего, что можно лерпать. Финальный класс можно видеть на скриншоте.

По-моему, симпатично получилось. А вы что думаете? Открыть/Комментировать

2020-12-18 21:26:52 Открыть/Комментировать

2020-11-02 00:09:18 А подпишитесь на Марка
#light
Марк — это наш главный сценарист. Официальная душа, харизма и чувство юмора Encased RPG. Почти год у Марка есть свой небольшой телеграмм канал, где он пишет всякое разное. Про саму игру, к сожалению, ничего не пишет, но когда у вас ещё будет возможность залезть в застенки черепной коробки сценариста не ферм каких-нибудь, а одной из самых амбициозных игр постсоветского пространства?

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

В общем, уважьте старика, подпишитесь на Марка. Открыть/Комментировать

2020-11-02 00:09:18 Открыть/Комментировать