Елена — QA лид в GameDev

Закончила курс Стратоплан "Руководитель отдела", и получила сертификат.🥳

Это первый курс в осознанном возрасте, пройденный полностью с посещением всех занятий. У Стратоплан высокий процент доходимости до финала. С опытом преподавания на курсах знаю: удержать людей до конца сложно. Было интересно понять, как им это удаётся.
И смогла прочувствовать на себе. Мне было важно и хотелось ходить на лекции, слушать преподавателей, думать над задачами вместе.

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

Ещё понравилось, что с самого начала показали: зачем нужна роль руководителя отдела, как она встраивается в компанию и чем отличается от уровня C-level. После курса сложилась картинка, а не список тем.

Что уже пробую применять:
По операционному менеджменту, работу со структурой отдела. Разбирали много подходов, и это актуально: QA-команда сейчас перестраивается под AI-разработку. В группе как раз обсуждали свои процессы, требующие оптимизации, и команда предложила идеи для улучшений. 
По управлению ресурсами, как балансировать между запросами сверху и мощностью команды. Было задание, где очевидный вариант оказался невыгодным. И ещё запомнился акцент на том, что люди не ресурсы. Очевидность, но в управленческом контексте об этом часто забывают.

Этот курс помог подвести какой-то итог лидской работы и понять, как хочу расти дальше. Было приятно осознавать, что многие вещи делаешь правильно. Что-то поняла как можно масштабировать на более большие команды. Что-то было в новинку как оргструктура или бюджетирование отдела.

Как итог, хоть было и тяжело, не пожалела, что решилась. Когда будет необходимость, пойду к ним на курс для С-левела.🦄

На на курсе Основы в Стратоплане проходили конфликты. Точнее конструктивную конфронтацию.

И в первый день было задание "где я, а где конфликты".
Раньше воспринимала конфликты как что-то эмоциональное и почти всегда негативное. Избегала, старалась не доводить до столкновения. Либо просто дулась на какие-то замечания.

Но на самом деле конфликт часто помогает увидеть, что иначе не замечаешь. Другую сторону ситуации. Общие проблемы в процессах и взаимодействии.

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

Но когда в итоге поговорили с ними и сказали, что так из-за них страдает 10 человек. Оказалось, что они и сами видят проблему и уже пробовали ее решить. Но пока не получалось иначе.

В итоге совместными силами, мы сдвинули один релиз. Чтобы у нас на подготовку следующих обновлений было на неделю больше. И художники неожиданно оказались не "мудаками", а вполне хорошими ребятами.

И так бывает часто. Проблема не конкретный человек, а чаще это процесс, инструмент, непрозрачная договорённость. Просто этого не видим, потому что крутимся вокруг своей боли и своей правоты.

Особенно это знакомо тестировщикам. Прилетает "не протестировали" и эмоция уже включилась. В таком состоянии идти в разговор — значит идти разругаться, а не решить проблему. Но об этом легко говорить, когда ты вне ситуации. В моменте сложнее.

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

Второй - безоценочность. Язык описания вместо ярлыков. Это не включает защитную реакцию у собеседника — и разговор остаётся разговором, а не спором.

Голова кипела после десяти часов интенсива. Но это, наверное, одно из моих любимых занятий,потому что было много практики. И было важно поговорить с другими руководителями, о том, что никто не любит конфликты. И многим сложно даются конфликты, как и мне.

Как мы дошли до CDN, а потом случайно затёрли прод

Одна из наших игр доросла до CDN. Долго сопротивлялись, но контент уже не вмещался. И нужен был CDN для статики.

Content Delivery Networ это инфраструктура для раздачи контента. Входящие в состав CDN серверы географически располагаются таким образом, чтобы сделать время ответа для пользователей минимальным. Есть origin сервер, на котором хранятся исходные файлы или данные, есть точка присутствия, кэширующий сервер в составе CDN, расположенный в определённой географической локации.

Перед выкаткой протестировали прерывание соединения, недоступность origin, поведение при cache miss. Всё прошло нормально. Выкатили в прод.

В релизе все прошло без проблем. Делали техническую закупку, по аналитике и обращениям - все гуд.

В какой-то момент ответственной тестировщице что-то понадобилось проверить на проде. И билд не запускался. По логам не мог скачать какой-то ассет. Что было странно, так как прошло уже три недели с момента релиза, и 1,5 недели назад проблем не было.

Начали разбираться, и, конечно же, обновился контент на проде. Обновился по очень тупой причине. Версию контента не поменяли после релиза, а кому-то понадобилось собрать билд с прод настройками. И параметры контента оставили по умолчанию, а по умолчанию все обновляется.

Получилось, что продовским билдам отдавался не тот контент. Откатить файлы не получилось, пришлось пересобрать контент. Но починить получилось быстро. Но пайплайн сборок и работу с версиями пришлось менять.

Добавился аппрув сборок с prod-параметрами. По дефолту теперь не обновляем контент во время сборки, и после релиза в деве меняем версию сборки и контента сразу.

На Стратоплане разбирали кейс: нужно выбрать зама. Лид, который два года в компании, или лид, который пришёл недавно, но уже расположил к себе команду. 

Я была за старого. Преподаватель за нового. И главный аргумент: если за два месяца не смогли себя проявить, то и не проявят. Я не согласилась. 

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

Вторая - моя. Меня не брали на новые проекты, потому что я была из "старой" команды. Считалось, что перенесу с собой старые проблемы. Я тогда устала от проектов, от того, сколько усилий надо было, чтобы поменять что-то на проекте, который уже 8 лет как в проде. 
Но вопрос о переводе создал у меня ощущение всё, что я делала до этого, как будто не считается. Новые люди делали то же самое или меньше, но в других компаниях и это шло им в плюс. Я злилась на это. Долго.  И опять ситуация что, нет у меня достижений за последнее время и "глаза не горят". Значит кто-то другой будет лучше.

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

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

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

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

Думала, что модуль будет довольно поверхностным, про простое ведение счетов. Но темы оказались намного глубже. Разбирали кейсы не только про деньги, но и про жизнь команды в целом. Кейсы оказались очень жизненными. Понимаешь, насколько это рабочие ситуации. И либо уже сталкивался с похожим, либо видел подобное в компаниях🦄 Такая практика помогла соединить интуитивные решения с логикой бизнеса.

В итоге расчеты показали: экономия на мелочах часто обходится компании слишком дорого. И теперь можно приходить не только с готовыми решениями, но и сколько это будет стоить. Хочу теперь посчитать затраты на использование ИИ для тестирования. Как раз продумываю процесс для команды.

🧭 В марте стартует новый сезон Podlodka QA Crew — «Зрелость QA»

Сегодня от QA-инженеров ждут гораздо большего, чем просто аккуратное тестирование. Бизнесу важно, чтобы каждая функция двигала его вперед. При этом многие специалисты продолжают работать в режиме бесконечной операционки. Из этого состояния бывает сложно думать о том, чтобы перейти на следующий уровень.

С 16 по 20 марта пройдет Podlodka QA Crew — онлайн-конференция, посвященная зрелости QA.

💡Контент затронет все уровни работы над качеством. Участники Podlodka QA Crew:

• узнают, как приземлять годовые стратегии на ежедневные задачи,
• обсудят понятие «зрелость QA» и получат понимание, зачем об этом думать инженерам,
• изучат, как на работу QA-инженеров влияют практики вайб-кодинга и AI-инструменты,
• научатся говорить о болях QA на языке бизнеса.

Формат будет классическим для Podlodka QA Crew: живые Zoom-сессии, закрытое профессиональное сообщество в Telegram и много общения со спикерами.

Скидка по промокоду: gameQA_15

На следующей неделе стартует Podlodka QA Crew. В этот раз я иду только как слушатель и очень жду рулетку кейсов «Переводим боли QA на язык бизнеса». Зрелость процессов и выбор уровня зрелости сейчас,пожалуй, самая большая головная боль в индустрии. В целом в этом сезоне затрагивают много важных тем и выстраивание стратегии, и то, как лавировать между AI и автотестами, и даже кризис сообщества. Очень жду старта.

Как один  игрок заставил перевезти серверы

Люблю искать баги через аналитику. Это дополнение к стандартным тестам, которое помогает ловить редкие аномалии.

В одном из таких погружений в данные всплыл странный юзер. Явных ошибок в логах нет, но часть игровых событий пропала.  Логи идут с 12:00 до 12:10, а следующая начинается только с 12:20. При этом игрок не выходил из сети.

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

Собственно, когда в конечной точке событий не досчиталась, пошла смотреть логи сервера. С первого взгляда всё было ок, ошибок ноль. Но сами события в Графане видела, а значит, они где-то «между». Дальше нужно было идти к бэкенду, у них логи были поподробнее.

Сначала, конечно, классика: «У нас всё хорошо, ищи проблему на клиенте». Но когда всё-таки вместе зарылись в дебри, то нашли лог Failed to send. Баг оказался простым, как обычно. Сервер отправлял событие в Кафку, та отвечала, что приняла... и тут же отваливалась по таймауту, не успев сохранить данные. В итоге сервер считал, что всё ок, а Кафка эти зависшие события просто теряла. И так как в Кафке их не было, до аналитики они не доходили.

Конкретно в тот день пострадало всего три пользователя. За месяц таких потерь набегало штук 10, не критично, никто и не замечал. Игрок набил столько данных,  чтобы баг наконец вылез наружу.

По итогу пришлось переезжать на Кафку в USA, для этой игры регион оказался стабильнее. Ну и алерты на подтверждение приема тоже немного переделали.

Прошел месяц обучения в «Стратоплане».

Уже завершился первый модуль и пройдена половина второго. Плюс позади 2 из 4 занятий из блока «Основы». Если честно, это тяжело. Думала, что будет проще, но реальность внесла коррективы.😁

«Основы» давят графиком, раз в месяц выходные полностью уходят на учебу. Суббота и воскресенье с 10:00 до 15:00 по МСК, а для меня это с 8 утра. Вроде и перерывы есть, и даже обед, но всё равно нагрузка ощутимая. Темп очень активный, постоянно разбираем кейсы и ищем решения внутри команды.

Командной работы я, кстати, боялась больше всего, а по итогу мне нравится. Так тема заходит гораздо лучше. Слушаешь другие мнения, где-то споришь. Жаль, времени на дискуссии вечно не хватает)

Из минусов, на занятиях после работы пару раз скатывались в обсуждение текущих рабочих проблем, и выполнение заданий превращалось в «нытинг». Было не всегда комфортно. Всё-таки хотелось тратить время на кейс, а не на жалобы.

Самым сложным было задание по оргструктуре. Мозг поплыл, до сих пор не уверена, что до конца поняла эту тему.

Сейчас поменялось отношение к роли руководителя отдела. Раньше смотрела на это как на работу тимлида, где больше людей и объем задач. Но на лекции в ходе обсуждения пришла к тому, что тимлид еще может прийти к команде за советом или вместе искать ответ. А вот от руководителя отдела ждут прежде всего готовых решений. Это совершенно другой уровень ответственности.

Еще удачно сейчас говорим о бизнес-процессах, настройку и оптимизацию. На работе как раз появилась такая необходимость. Буду сразу на практике тренироваться.🦄

На следующей неделе стартует Podlodka по AI. И у меня есть проходка, которую я хочу разыграть!

Я сама сейчас плотно сижу на GPT и Gemini, в основном использую их для структуры больших доков, выжимок из статей или книг. Ну или просто когда нужно "об кого-то подумать". Ну и картинки, мемы сами себя не сделают.

А вот с Cursor у нас не задалось. Он мне помогает, только если я совсем не понимаю, в какую сторону смотреть. С моими задачами справляется посредственно. Как-то дала ему доступ к пет-проекту, а потом месяц всё чинила.

Остальные инструменты тоже поглядываю, хочу вот Клода потестить. Но вообще не считаю, что AI это серебряная пуля. Практика показывает, что реально внедрить их в процессы смогли пока единицы.

Условия розыгрыша простые:
Пишите в комментарии, как (и для чего) вы используете AI в работе или жизни.

В это воскресенье я выберу самый интересный/жизненный коммент и отправлю проходку победителю.

🚀 Как ускорить разработку с AI-инструментами

Когда мы говорим об AI, хочется обсуждать реальную практику коллег и смотреть на то, как инструменты работают в продакшене.

И скоро у нас будет такая возможность — с 16 по 20 февраля у Podlodka AI Crew пройдёт сезон «AI-агенты в разработке».

👨‍💻Опытом поделятся инженеры и исследователи из Яндекса, Т-Банка, Plata, RealtyCalendar, inDrive, AI Mindset, overwatch.ai и других компаний. Участников ждет 10 сессий и закрытое комьюнити в Telegram. Все кейсы — с прицелом на то, чтобы забирать решения сразу в продакшн.

Смотрите полную программу на сайте и забирайте свой билет на Podlodka AI Crew, чтобы изучить актуальные AI-инструменты в компании практиков.

А по промокоду ai_crew_2_aSirZ4 получите скидку🎁

Vampire: the masquerade - bloodlines 2

Попыталась поиграть во вторую часть маскарада. Забавно, что из первой части вторая также отличается кол-во багом.

Предыстория этой игры. Вторую часть ждали около 20 лет. Мир игры развивается больше через настолку в стиле D&D. Технически это третья часть игры. Нулевая часть вышла летом 2000 года и называлась Vampire: The Masquerade - Redemption.

Со второй частью, которая вышла в 2004 и стала культовой позже, были проблемы из-за разработки на движке от Valve. Проблемы маркетинговые, так как нельзя было анонсировать и рекламировать игру до выхода Half-Life 2. Но беда приключилась не только с этим. Игра подразумевала большую вариативность и разнообразный мир. И вышла откровенно недоделанной, думаю у разработчиков не хватило опыта и было слишком много энтузиазма. В итоге, у студии Troika не хватило ресурсов ее доделать. Через 4 месяца студия закрылась. Эту часть фанаты до сих пор доделывают, последний патч вышел в мае 2025.

Дальше были истории с перекупкой компании с правами. И где-то в 2015 начали всплывать слухи о второй части, когда права перешли Paradox Interactive. И в 2019 даже стали появился трейлер о второй части bloodlines. Но по итогу первая студия, которая занималась разработкой, переключилась на другой проект. В 2023 Paradox нашли вторую студию, The Chinese Room. В итоге игра вышла в октябре 2025. По второй пока патчей не нашла от фанатов, но ее еще поддерживают сами разработчики. До 3 квартала текущего года точно.

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

Ну и самое обидное, что недоделки продают по 40$+оплата за DLS. И 10$ за косметику. И я бы рада даже купить DLS, понравилась атмосфера. Из-за нее и хотела купить игру. Но я не могу пройти весь сюжет, потому что не могу брать и завершать сайд квесты. А это ломает баланс и прокачку перса. Надеюсь следующем патчем пофиксят)

Не люблю абстрактные вопросы на собеседованиях.

Возможно, потому, что сложно на них отвечать) Больше всего вопросы о стратегиях и настраивании процессов. Без точки отсчёта и ситуации в вакууме такие вопросы чисто теоретические.

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

Риск в таких ситуациях начать менять не то и не там. Чтобы не переносить практики вслепую, для изменений нужно сначала понять текущую ситуацию. Для этого использую модели для оценки зрелости процессов тестирования. Предпочитаю TPi Next, потому что там как раз лучше учитывается контекст. И видно, какие приоритетные зоны проседают, а не «меняем вообще всё».

Часто о процессах говорят, вот стартап в самом начале там хаосная или начальная зрелость. А вот энтерпрайз, в идеале ещё и финтех, там будет высокий уровень зрелости. На практике сложнее. Как минимум существует большой сегмент компаний между стартапом и энтерпрайзом. Два стартапа на одной стадии могут требовать принципиально разного тестирования. И два энтерпрайз продукта тоже. В итоге упираемся не только в размер компании, но и в продукт, бизнес-цели, архитектуру, команду разработки.

Я смотрю на вопрос зрелости как на оценку, насколько процессы помогают продукту на текущем этапе. Универсальных процессов и универсального качества не бывает. Важно, чтобы они были достаточными для конкретного контекста.

Модели помогают понять текущий уровень и как перейти на следующий. И это, наверное, наиболее понятная часть настройки и оптимизации процессов. Дальше идет много разговоров, договорённостей, передоговорённостей, иногда и конфликтов. Но об этом уже в другой раз.

В понедельник вышла игра Highguard, которая сразу всплыла в обсуждениях. Это рейд-шутер, бьются команды 3 на 3. Игра состоит из трех фаз.

Однако внимание к ней сместилось с геймплея на качество и сопутствующий скандал.

В чем же претензии? Основные, конечно, по оптимизации. Игра тормозит на RTX 5080, при этом минимальное требование GTX 1060. Оптимизировать игру можно самому, если пошаманить в настройках, но звучит это так себе.

Также были проблемы на самом старте игры, когда игроков не пускало в сессию.

Из геймдизайнерских косяков отмечают тутор и бессмертных защитников базы. Тутор долгий и непонятный.

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

На выходе у игры 29% положительных отзывов. Игру называют вторым конкордом. При этом странное поведение маркетинга. Так как появляется много положительных рецензий в разных изданиях.

Скандал же из-за одного человека - Джефф Кили. Он проанонсировал игру на Game Awords в конце прошлого года. Перед релизом был не сильно толерантен по отношению к хейтерам игры.

Скорее всего, это сильно спутало планы разработчикам. Так как планировалось стартовать рекламную кампанию, только после релиза.

Команда там сильная, и QA в том числе. И не думаю, что они не знали о проблемах. Про те же туторы ещё говорили приглашённые блогеры летом. Но как будто релиз пропушили. И опять вместо того, чтобы фиксить хотя бы технические проблемы, пытаются найти виноватого.

Надеюсь, у них все таки получится допилить игру. Как допилили предыдущий Concord 2: Marathon.

Когда билд на массе

Столкнулись с интересным багом в Unity 6. Во время сборок apk накидывается несколько сотен МБ.

Критичный баг для мобилок. Размер билда влияет на конверсию и увеличивает риск отвалов во время установок.

Среди контента наибольший вес обычно занимает аудио. Медиа часто самые жирные в билде, поэтому требуют особого внимания при оптимизации.Поэтому в командах важны практики "вычистки" контента. Когда вырезается старый контент, или оптимизируется существующий. Например, какое разделение, что идет в билд, а что докачивается.

Но кроме контента билд состоит из вашего кода, библиотек движка, сторонних SDK. платформенных обвязок. И обычно это не создает проблем. Но если бьет, то очень метко.

Немного про сами лимиты. В Google Play базовый модуль 200 мб и еще 200 на модули функции. Но все, что больше 200 мб при скачивании через мобильный интернет покажет предупреждение пользователем. И многие отказываются скачивать такие приложения. Для игр критично, так как мало кто к ним возвращается. Также есть ограничение на размер скачиваемого контента. Обычное ограничение 8 ГБ. Можно расширить до 34, если вступить в программу Level Play.

В AppStore нет жёсткого ограничения по размеру, но то же есть ограничение на скачивания в мобильной сети. То же 200 мб. Также на мобильных платформах есть ограничение на размер после установки 4ГБ.

Для ПК и консолей нет явных ограничений на сам билд.Но это часто расхолаживает команды, так как они забивают на оптимизацию ресурсов.

Но здесь следят за размерами обновлений. И получается тут больше репутационные риски. Также консоли более критичны к потребляемой оперативки.

И напоследок про Nintendo. У них тоже нет явных ограничений. Но влияют размеры накопителя самих консолей 32 и 64 ГБ. Плюс ограничение картриджей до 32 ГБ.

Мем на эту тему с первой работы. Там приходилось часто его использовать.

Сеньерство и количество вздохов

Когда растёшь как специалист, помимо опыта, знаний и навыков, постепенно приобретаешь ещё одну особенность - вздохи.

Они появляются не от усталости. Не потому, что «всё надоело».

Чаще всего они появляются во время обсуждения задач. Или когда в тех самых задачах на 5 минут, на которые можно потратить несколько дней в итоге и пару нервных клеток.

Вот здесь появляется вздох. Негромкий. Недемонстративный. А такой… опытный.

Означает примерно следующее:
🦄 Я уже видел, чем это закончится.
🦄 Это будет дороже, чем кажется.
🦄 Сейчас мы полезем в старые решения, зависимости и контекст.
🦄 Это работает не так.

Сеньерство - это некогда всё знаешь и некогда всё делаешь быстро.

Это когда заранее чувствуешь сложность там, где другие её ещё не видят.
Иногда твой самый точный инструмент - это вовремя сделанный вздох и фраза:«Давайте чуть подробнее посмотрим, какой результат хотим».

Количество таких вздохов со временем растёт. Но вместе с ними растёт и способность спасать проекты, сроки и команду. И уводить в нужное направление.

Так что если ловишь себя на этом - поздравляю. Ты просто стал опытнее.🦄

Обучение в Стратоплан.

Прошла собеседование на обучение в Стратоплан.🥳

Уже давно слежу за их курсами. В первый раз услышала о них еще в самом начале пути. Но тогда компания не одобрила обучение.

Туда нельзя напрямую купить курс. Сначала - тестовое задание, потом собеседование. Формат непривычный, но неожиданно зашёл.

Тестовое оказалось полезным. Помогло нормально сформулировать, зачем мне курс и что именно хочу из него вынести. Мотивационное эссе скажу честно - пользовалась ИИ. Это разрешалось, нужно было отметить галочку: использовал ИИ или нет. То же с кейсом, где нужно придумать речь для генерального директора о том, почему «прошляпили» бюджет. Мне сложно отвечать о действиях в абстрактных ситуациях. Потому что на практике много вводных, я выстраиваю действия, опираясь на них.

После тестового был созвон минут на 30. Спокойный, без допросов. По сути - проверка мотивации и сверка ожиданий. У Стратоплана много программ под разный уровень, и на этом этапе могут честно сказать, что конкретно этот курс не подойдёт - и предложить другой. Или сказать, что тебе надо отдохнуть, а не на обучение идти.

У меня всё сложилось - через неделю начинаю обучение на программе для руководителей отделов. Жду старта с большим ожиданием и иду с приятным предвкушением.🦄

С Новым годом 🎄✨

Пусть 2026 будет спокойнее, честнее и устойчивее.
Меньше выгорания — больше просто нормальных дней.
Чтобы задачи были интересными, баги находились вовремя,
сроки оставались адекватными, а цели — понятными.
И чтобы работа не съедала всё вокруг,
а за результаты было по-настоящему не стыдно.

Пусть хватает любопытства и поводов порадоваться —
и в профессии, и за её пределами.
Желаю сил выбирать себя, даже когда вокруг шумно.
Интересных проектов и карьерных успехов.

Спасибо, что читаете, реагируете и остаётесь здесь 🦄
Увидимся в новом году!

Суть бага

И в старой и в новой версии происходила коллизия. (Контакт между объектами ). Разница была в другом.

Оригинальный билд компилировался под старый x87 (8087) math pipeline. Это про вычисления процессором чисел на каждом шаге. Там использовались разные внутренние точности: 32, 64, 80 бит - в зависимости от контекста. Поведение менее предсказуемое, но в этом случае это и «пофиксило» баг.

Спустя годы компиляция шла уже с SSE, где точность строго 32 или 64 бита. Поведение стабильнее, но и результаты другие.

Дверь и NPC физические объекты. Значит, у двери есть импульс, у NPC есть масса, у ботинок есть трение с полом.

В старой версии (x87) при столкновении дверь слегка поворачивала NPC. Этого микроскопического поворота хватало, чтобы носок в следующем кадре вышел из траектории двери. Коллизия разрешалась, дверь спокойно открывалась.

В версии с SSE из-за немного других вычислений NPC всё ещё поворачивается, но чуть меньше.

И в следующем кадре его носок всё ещё в пути двери. Дверь сталкивается, получает импульс и закрывается.

Именно поэтому баг «вернулся из прошлого». Код тот же. Ошибка та же.
Изменился только компилятор и дефолтный math pipeline.

Главная проблема была не в SSE и не в x87.Фундаментальный баг - NPC стоял слишком близко к двери.
Просто раньше физика случайно это «самоисправляла».🦄

Вот история от самого разработчика.

Как появился баг с дверью, который существовал всегда, но стал критическим спустя годы.

Забавная история бага в Half Life 2. В 2013 году в Valve исследовали возможности работать с VR. И так получилось, что две игры использовали движок, в котором предполагался VR. Это Half Life 2 и Portal 1.

Portal работал, но не ощущался в VR. А вот HL2 был неплох. И так как в этот же год обновлялся движок Valve и переиздавались старые игры. Было решено добавить поддержку VR.

И казалось бы всё хорошо. Энтузиасты уже много играли и тестировали функции VR. Но никто не проходил игру, переходили к соответствующим сценам.

Когда всё-таки решили пройти и выбрали новую игру, застряли в самом начале прохождения) Вот это начало обычной версии. Нужный тайминг 3.40. На видео бага нет, но в VR был. 

Самое забавное, что игра сломалась не только в VR. Но и переизданная версия не работала. Нужная дверь не открывалась, и продолжить игру было невозможно.

Во время разбирательств даже скомпилировали оригинальную игру 2004 года и оказалось баг там тоже есть) Началась паника и варианты, что баг переместился во времени и заразил игру.

Потребовались сутки, чтобы понять, что происходит. Если разобрать ситуацию технически, происходит вот что.

Когда дверь разблокируется и начинает открываться, внутри комнаты стоит NPC. Он расположен чуть ближе, чем нужно: самый угол его коллайдера пересекается с траекторией двери. Совсем немного, буквально миллиметры. Дверь начинает открываться, слегка задевает носок охранника, получает импульс, отскакивает назад, закрывается и снова автоматически блокируется. Скрипта, который обработал бы этот кейс и повторно открыл дверь, нет -игрок застрял.

Фикс очевидный: отодвинуть NPC на миллиметр назад. Правка была лёгкой на миллиметр подвинуть защитный кожух, но почему раньше это работало?

Проблема в числах с плавающей запятой, компиляторе и физике объектов. В следующем посте расскажу чуть подробнее.🦄