А подпишитесь на Марка
#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!
Кажется я поехал кукухой
Одна из моих попутных целей недавнего переезда и перемен в жизни — это восстановить work-life баланс, чтобы иметь возможность заниматься своими проектами. Если не считать периодические командировки в Питер, то с декабря 2016 года я всё время работал на удалёнке. Мои личные пет-проекты заглохли ровно с того же момента. Прежде всего потому что я на работе занимался достаточно увлекательными вещами. Но вторая, и, пожалуй, главная причина — это наглухо поехавший график. Когда нет чёткого физического разделения между рабочим временем и личным — всё время рабочее. Конечно, это не означает, что ты всё время работаешь: есть время и на отдых и на свои дела. В будние дни ты отвлекаешься и прокрастинируешь гораздо больше, чем в офисе; но потом нагоняешь ночью и на выходных. И это проблема. У тебя нет твоих личных двух часов перед сном, когда можно что-то поделать для себя и не чувствовать при этом, что это в ущерб работе. Потому что всегда есть, что нагонять в рабочем проекте. Всегда есть пару часиков, которые хорошо бы добить в этом спринте.
Вот почему при выборе нового места мне крайне важно было выйти именно в офис. Благо, в Швеции ⅔ населения уже вакцинированы и народ постепенно возвращается в офисы, так что с этим проблемы нет. Я также прикупил основную мебель в квартиру и разгрёб первичную бюрократию, так что у меня и в самом деле появилось время на свои проекты.
Разумеется, первым делом я стряхнул пыль со своего движка Judy. Ну как движка. Там только редактор скриптов с плеером и дебагером, самопальная рефлексия для С++, да зачатки рендера. Но концепт эстетически приятный. Центральную роль в нём играет Lua, которая выступает одновременно и скриптовым языком, и форматом для конфигов, сцен, файлов сохранений и сетевых сообщений. Не самое быстрое решение, но оно быстрым быть и не собиралось: упор у меня был на удобные тулзы, а не скорость. Игры предполагалось писать всё равно относительно маленькие.
Вот только за последние 5 лет немножко изменились мои требования к движку мечты. Во-первых, IDE повсеместно теперь поддерживают Language Server Protocol, и писать скрипты без возможностей хотя бы EmmyLua нынче уже не комильфо, как говорится. Во-вторых, на старте Encased я сильно вложился в проектирование системы сериализации. Это многократно нам окупилось, а также по мере развития сильно повлияло на мои взгляды по теме. Теперь я хочу что-то подобное встроенное в скриптовый язык. Причём из коробки. Ясное дело, я не мог не пересмотреть немного концепцию Judy.
Меня всё ещё кидает из стороны в сторону, потому что я хочу слишком много всего и сразу, да и отказываться от Lua, которая уже подключена и работает, тоже жалко; но последние 2 дня я размышляю над своим языком. Пока только формулирую основные Design Goals, но одновременно прикидываю к носу, как конкретные фичи будут технически исполнены.
Писать свой скриптовый язык это особый уровень безумия. Даже по меркам движкописателей. Я прекрасно понимаю, что это адски объёмная задача и вряд ли вообще что-то путное получится, но похоже, что кукуха моя уже поехала и остановить будет сложно. Все нормальные названия для языка уже заняты, поэтому пусть пока будет рабочее — Ku-ku language. О том, чем я занимаюсь на работе всё равно больше рассказывать нельзя, так что ближайшее время блог будет в основном про Ku-ku.
Одна из моих попутных целей недавнего переезда и перемен в жизни — это восстановить work-life баланс, чтобы иметь возможность заниматься своими проектами. Если не считать периодические командировки в Питер, то с декабря 2016 года я всё время работал на удалёнке. Мои личные пет-проекты заглохли ровно с того же момента. Прежде всего потому что я на работе занимался достаточно увлекательными вещами. Но вторая, и, пожалуй, главная причина — это наглухо поехавший график. Когда нет чёткого физического разделения между рабочим временем и личным — всё время рабочее. Конечно, это не означает, что ты всё время работаешь: есть время и на отдых и на свои дела. В будние дни ты отвлекаешься и прокрастинируешь гораздо больше, чем в офисе; но потом нагоняешь ночью и на выходных. И это проблема. У тебя нет твоих личных двух часов перед сном, когда можно что-то поделать для себя и не чувствовать при этом, что это в ущерб работе. Потому что всегда есть, что нагонять в рабочем проекте. Всегда есть пару часиков, которые хорошо бы добить в этом спринте.
Вот почему при выборе нового места мне крайне важно было выйти именно в офис. Благо, в Швеции ⅔ населения уже вакцинированы и народ постепенно возвращается в офисы, так что с этим проблемы нет. Я также прикупил основную мебель в квартиру и разгрёб первичную бюрократию, так что у меня и в самом деле появилось время на свои проекты.
Разумеется, первым делом я стряхнул пыль со своего движка Judy. Ну как движка. Там только редактор скриптов с плеером и дебагером, самопальная рефлексия для С++, да зачатки рендера. Но концепт эстетически приятный. Центральную роль в нём играет Lua, которая выступает одновременно и скриптовым языком, и форматом для конфигов, сцен, файлов сохранений и сетевых сообщений. Не самое быстрое решение, но оно быстрым быть и не собиралось: упор у меня был на удобные тулзы, а не скорость. Игры предполагалось писать всё равно относительно маленькие.
Вот только за последние 5 лет немножко изменились мои требования к движку мечты. Во-первых, IDE повсеместно теперь поддерживают Language Server Protocol, и писать скрипты без возможностей хотя бы EmmyLua нынче уже не комильфо, как говорится. Во-вторых, на старте Encased я сильно вложился в проектирование системы сериализации. Это многократно нам окупилось, а также по мере развития сильно повлияло на мои взгляды по теме. Теперь я хочу что-то подобное встроенное в скриптовый язык. Причём из коробки. Ясное дело, я не мог не пересмотреть немного концепцию Judy.
Меня всё ещё кидает из стороны в сторону, потому что я хочу слишком много всего и сразу, да и отказываться от Lua, которая уже подключена и работает, тоже жалко; но последние 2 дня я размышляю над своим языком. Пока только формулирую основные Design Goals, но одновременно прикидываю к носу, как конкретные фичи будут технически исполнены.
Писать свой скриптовый язык это особый уровень безумия. Даже по меркам движкописателей. Я прекрасно понимаю, что это адски объёмная задача и вряд ли вообще что-то путное получится, но похоже, что кукуха моя уже поехала и остановить будет сложно. Все нормальные названия для языка уже заняты, поэтому пусть пока будет рабочее — Ku-ku language. О том, чем я занимаюсь на работе всё равно больше рассказывать нельзя, так что ближайшее время блог будет в основном про Ku-ku.
Ku-ku design goals
Вот я и накатал Design Goals для моего скриптового языка мечты Ku-ku.
Писал изначально на английском. Думал сначала перевести на русский для этого канала, но быстро понял, что любой, кому будет хоть капельку это интересно, должен по идее без труда справиться с техническим английским текстом. Так что пусть будет пока так.
Так или иначе, одно лишь пространное описание того, чего же я хочу от языка, даже без конкретных деталей, получилось весьма внушительным. Как я собираюсь это всё разрабатывать по вечерам и не лопнуть — ума не приложу.
Но это будет чуть позже. А пока я очень жду ваших комментариев по тому, что есть. Заряжайте холивар по каждому пункту. Дайте мне жару, как следует!
Вот я и накатал Design Goals для моего скриптового языка мечты Ku-ku.
Писал изначально на английском. Думал сначала перевести на русский для этого канала, но быстро понял, что любой, кому будет хоть капельку это интересно, должен по идее без труда справиться с техническим английским текстом. Так что пусть будет пока так.
Так или иначе, одно лишь пространное описание того, чего же я хочу от языка, даже без конкретных деталей, получилось весьма внушительным. Как я собираюсь это всё разрабатывать по вечерам и не лопнуть — ума не приложу.
Но это будет чуть позже. А пока я очень жду ваших комментариев по тому, что есть. Заряжайте холивар по каждому пункту. Дайте мне жару, как следует!
Google Docs
Ku-ku
KuKu* language design goals (* - working title) Abstract Easy-to-learn dev-supportive language both for gameplay scripting with close data integration and for store game data I. Core 1.1. Minimalistic Kuku should be relatively small. It must be possible…