Comments 188
UFO just landed and posted this here
В некотором большом продукте видел еще более эпичную ситуацию. Приложение парсит аргументы командной строки с нечетким поиском и тихо подменяет, например, --long-complex-option-id на --long-complex-option-name
Ха. Компилятор LabVIEW пересобирает классы после добавления в них новых переменных, опираясь на порядок определения этих переменных, их имена и фазу Луны. В результате имена переменных путаются только в путь, причем невероятно феерическим образом — например, имя строковой константы может достаться указателю.
Но это еще нестрашно, ибо сразу обнаруживается проверкой синтаксиса.
Страшно становится, когда он начинает путать, скажем, MainMotor.Voltage и AuxiliaryMotor.Voltage.
Но это еще нестрашно, ибо сразу обнаруживается проверкой синтаксиса.
Страшно становится, когда он начинает путать, скажем, MainMotor.Voltage и AuxiliaryMotor.Voltage.
А в одном большом SCADA продукте в скриптах можно делить на ноль. Ничего не происходит, и результат — кажется, тоже ноль (не помню, к сожалению). Когда-то был очень удивлён, обнаружив невидимую ошибку.
Согласно стандарту IEEE 754 числа с плавающей точкой можно делить на ноль. Получается специальное значение в зависимости от знака числа.
А JS округляет большие целые до 56 бит…
НЕТ. JS ничего сам не делает. Для начала не 56 а 52 бита, это размер мантисы числа двойной точности стандарта IEEE754. И число максимальное (2^53)-1. И никакого отношения к JS это поведение не имеет. Точно также будет в С++, С# Делфи и всё что вы придумаете, потому что так работает процессор. Другой вопрос что в других языках вы можете выбрать разные типы для представления чисел, а в js это всегда double precision floating point. Хватит верить в магию особого поведения JS и разносить эту чушь по интернету. Читайте: ru.wikipedia.org/wiki/Число_двойной_точности habr.com/post/112953 и старайтесь спрашивать себя, точно ли я понимаю что пишу. Простите, накипело от людей которые оправдывают свою некомпетентность чудодейственными свойствами JavaScript которые выглядят чудодейственными только из за невежества.
В скаде допустить подобную ошибку легче легкого. На моём опыте был баг, когда система после развертывания работала корректно в течение 5 суток 23 часов 49 минут и скольких-то там секунд по причине того, что в функциональном блоке сравнивались метки времени в разном формате, и одна из них переполнялась по истечении указанного времени. Инженер приезжал на объект, перезагружал систему, проводил все тесты — всё работает. Уезжал — через пять дней всё ломалось. Вызывали снова. Мы поняли, что баг, только когда ситуация повторилась на другом объекте.
Удивляюсь этому удивлению. В большинстве сторонних библиотек, в том числе и известных, в большинстве случаев я встречаю вывод всех исключений, в том числе и Runtime, в printStackTrace (). Наверное большинство пользователей приложений пользуются только подключенной к компу мобилой с запущенным на нем отладчиком. Реже встречаются свои обработчики, куда пускают вывод других обработчиков. Такое поведение можно объяснить только либо не совсем высокой квалификацией разрабов, либо то, что это все пишется в спешке и в русском стиле «и так сойдет». И то, и другое, разумеется, плохо.
Обычное. Скрипты зачастую пишут люди не сильно квалифицированные как программисты, поэтому чтобы игра не падала на каждой опечатке скриптовые движки лояльно относятся к некорректному коду. Но это не отменяет того что движок при этом должен сыпать warning'ами, и все они должны исправляться на этапе тестирования.
UFO just landed and posted this here
Есть скриптовые движки, в которых доступ к несуществующей переменной неотличим от доступа к переменной, содержащей null или его эквивалент. В Lua, например, так. Плюс запись в несуществующую переменную автоматически ее создает.
В таких условиях ворнинг будет на каждую вторую строчку скрипта. Ну или надо тогда изначально договариваться, что в коде скриптов использование нулевых переменных не допускается.
В таких условиях ворнинг будет на каждую вторую строчку скрипта. Ну или надо тогда изначально договариваться, что в коде скриптов использование нулевых переменных не допускается.
Далеко ходить не надо, javascript такое позволяет. При обращении к несуществующим свойствам объекта возвращает undefined. И записывать в них можно что угодно.
Недавно реверсил один движок, так у него в сетевой компоненте null можно передать пятью разными способами в зависимости от типа и назначения поля — -1, -999, "null", "xxx" и "***". Но при этом отсутствующее числовое поле приравнивается не к null, а к 0, и соответственно понять, что где-то протерял массив, получилось только по тому, что в конце игры вместо перехода в меню было 20 анимаций повышения уровня, а потом вылезло шесть экранов с выигрышем ничего :-)
Потом выяснится, что эти warning'и достали и просто включили их игнорирование.
Ну не знаю, fail hard как по мне лучшее поведение в таких ситуациях. Всё, что не ожидает код увидеть должно вызывать немедленную панику и падение с отправлением ошибок.
Если бы при очередном запуске игры она бы просто вылетела с ошибкой:
То разработчик бы пожал плечами, нажал бы бекспейс, и даже не вспомнил бы на обеде про такую проблему. Не говоря уже про то, чтобы это повлияло на релиз.
Если бы при очередном запуске игры она бы просто вылетела с ошибкой:
thread 'main' panicked at 'Unknown parameter 'ClassRemapping=PecanGame.PecanSeqAct_AttachXenoToTether -> PecanGame.PecanSeqAct_AttachPawnToTeather'', libcore/option.rs:914:5То разработчик бы пожал плечами, нажал бы бекспейс, и даже не вспомнил бы на обеде про такую проблему. Не говоря уже про то, чтобы это повлияло на релиз.
Предлагаете браузеру если тэг не закрытый просто белый экран и писать ошибку? Потому что ситуации похожие.
То, что вы написали, только показывает, что вы не знаете разницу между паникой и ошибкой. Браузер выпущенный в продакшн может встречать незакрытые теги. Игра вышедшая в продакшн не должна иметь недостающих ресурсов.
UFO just landed and posted this here
Что плохого, если игра не будет падать, а у медведя будет нормальная голова?
Отвечает Капитан Очевидность: плохого тут в том, что в этом случае игра рискует вовсе не выйти.
Есть сроки, есть договоры, есть анонсы, есть штрафы за задержки.
Есть сроки, есть договоры, есть анонсы, есть штрафы за задержки.
А на сроки это никак не влияет. Конкретно в этом случае разработчик вряд ли потратил бы больше минуты на то, чтобы нажать на бекспейс один раз.
Конкретно до этого случая дело могло и вовсе не дойти, если бы игра на каждую опечатку падала. Дизайнеры и скриптописатели бы просто не успели написать хоть что-то шевелящееся и не падающее в обозримые сроки.
А так-то да, в каждом конкретном случае исправление опечатки — секундное дело. :)
А так-то да, в каждом конкретном случае исправление опечатки — секундное дело. :)
А так-то да, в каждом конкретном случае исправление опечатки — секундное дело. :)
Верно. А исправление 100 опечаток — 100 минут, то есть лишних полутора часов одного человека было бы достаточно, чтобы ни одна опечатка в прод не попало. Цифру 100 я взял от балды, просто не думаю, что игра более чем с 100 багами только в скриптах вообще работала бы.
Минутка с вашем КО: видимо, код для марсохода писали не так
Возможно, если бы браузеры именно так и делали, интернет был бы гораздо лучше…
Может быть и не игнорировал, а ругался. Если разработчики/тестеры игры в релизе не заметили, что с ней что-то не так, то подозреваю, что и в сообщения об ошибках в консоли не особо заглядывали.
Нормальное для большинства xml и текстовых конфигов.
UFO just landed and posted this here
Вы не можете гарантировать того, что ни один мелкий баг не пролезет. Нужно помнить, что пользователю не интересно читать сообщения об исключениях — они интересны только вам. Делать из пользователя тестировщика, заставляя его отправлять багрепорты из-за падений программы, тоже не стоит. Вы правы в том, что идеального варианта нет. Даже если на этапе тестирования применять второй подход, а в релизе применять первый подход, то мы получим новую проблему — разное поведение у тестировщиков и у пользователя.
UFO just landed and posted this here
Возможно там что-то произошло на уровне менеджмента. Например, разработчики делали игру по заказу другой студии, сдали продукт, и после релиза уже ни за что не отвечали. А в студии не разобрались, что это баг, а не просто корявая игра. Или разработчикам недоплатили и они отказались переделывать. Или разработчик ИИ уволился, а остальные не стали в этом разбираться, так как не их зона ответственности. Или ещё что-то на этом уровне.
По поводу диффов — думаю там изначально в конфиге с опечаткой написали. Если не знать в какой момент всё пошло не так — отыскать такое очень сложно.
По поводу диффов — думаю там изначально в конфиге с опечаткой написали. Если не знать в какой момент всё пошло не так — отыскать такое очень сложно.
Эта игра — очередной инди-вечный-ерли-аксцесс-дайте-нам-миллион-и-мы-сделаем-супер-игру-мечты. Я ее даже купил когда-то, повелся на ролик что это типа тактический командный шутер в сайфай сеттинге, а оказалось что разрабы как обычно переоценили свои силы, и на тот момент в игре не было ни-че-го, две мультиплеерные арены, туториал и никакого обещанного сингла.
Ничего удивительного что там никто ничего не фиксил. Скорее всего разработчики потеряли интерес к игре, после нескольких лет разработки поняв, что не получается сделать то что было запланировано, а кредит доверия покупателей уже исчерпан (т.е. даже если и получится все сделать — денег это уже не принесет).
Ничего удивительного что там никто ничего не фиксил. Скорее всего разработчики потеряли интерес к игре, после нескольких лет разработки поняв, что не получается сделать то что было запланировано, а кредит доверия покупателей уже исчерпан (т.е. даже если и получится все сделать — денег это уже не принесет).
И вообще, зачем такой основополагающий параметр, не предназначенный для изменения, выносить в конфиг.
Вот к чему метод "хуяк, хуяк и в продакшен" приводит. Похоже, разработчики не только не обеспечили корректную обработку ошибок (хотя бы логгирование), но и сами ни разу не запускали игру (могли бы заметить, что ИИ отключён).
Сейчас есть ранний доступ. Народ платит за то, чтоб получить доступ к игре на уровне бэты и «получать» удовольствие от игры раньше других. А еще у них есть возможность строчить баг-репорты, и таким образом влиять на ход разработки. Чем не мечта… вангую, что в дальнейшем можно будет присоединится к основному составу разработчиков, заплатив им за это, чтоб была у тебя возможность кодить во благо.
А как игрок, точнее бета-тестер, поймет что вот тут, не просто тупой ИИ, а ошибка в строке?
А это не задача тестировщика. Он должен репортить о том, что ИИ туп. Это глобально. И если много таких репортов от разных тестировщиков, то команда разработчиков может и задумается — так ли это или нет. Если работает не так как задумано — должны искать причины. Если же не нашли и нет времени на поиски — самое простое — забить, сложнее — переписать. А когда переписываешь, можешь натолкнуться на баг. Но это очень сложный и дорогой путь, к которому QA не имеют отношения, вопросы должны быть к QC.
Вопрос в качестве QA. У нас например тестер не заметил двух блокеров, которые уехали в прод и пришлось в пожарном режиме фиксить неделю после релиза (мне одному), зато все опечатки и поехавшие стили в IE9 были пофикшены. П — приоритеты.
1 тестировщик не заметил. Я могу предположить, что 1 человек — это слишком мало для тестирования чего либо.
Там функционал — SPA со списком айтемов, у каждого из которых есть кнопка «подробнее», в котором еще немного данных. Как по мне, это вполне реально протестировать одному человеку.
Предвосхищая вопрос, где же была бага: в краулере, который собирал данные для отображения. Он тоже был несложный, и вполне тестируемый.
Предвосхищая вопрос, где же была бага: в краулере, который собирал данные для отображения. Он тоже был несложный, и вполне тестируемый.
>Похоже, разработчики не только не обеспечили корректную обработку ошибок (хотя бы логгирование), но и сами ни разу не запускали игру (могли бы заметить, что ИИ отключён).
При чем тут разработчики? Уж кто-кто, а они вообще не причем, код написали, протестировали — код работал как надо.
А вот кто-то из гейм дизайнеров, левел дизайеров, тестеров и менджмента забили болт на свою работу. Причем скорее всего все сразу.
При чем тут разработчики? Уж кто-кто, а они вообще не причем, код написали, протестировали — код работал как надо.
А вот кто-то из гейм дизайнеров, левел дизайеров, тестеров и менджмента забили болт на свою работу. Причем скорее всего все сразу.
Что значит "при чём"? Некорректный код просто игнорируется, как будто всё в порядке! Это что, косяк дизайнеров?
Я не в курсе, что за "традиции" у них там в тестировании и менеджменте, но, возможно, они все виноваты. Или кто-то из них точно. Но быдлокод всё равно присутствует.
>Что значит «при чём»? Некорректный код просто игнорируется, как будто всё в порядке! Это что, косяк дизайнеров?
Это фантазии, никто не знает, что происходит с некорректными настройками, они вполне могут и писаться в какой-то лог. И все равно это вторично.
А по сути
Именно отдел качества должен был указать на проблему.
Именно лвл дизайнеры должны были орать что левл не работает так как задумывалось.
Именно менжмент должен был среагировать на негативные отзывы.
Но ни как не программисты.
И скажи по секрету — ты же не программист? Иначе бы ты знал главную программерскую тайну:
Всегда виноват заказчик, написавший кривое ТЗ.
Всегда виноват дизайнер, выдавший убогий UI.
И наконец всегда виноват тестер, который пропустил баг в релиз.
Ну а программист то причем?
Это фантазии, никто не знает, что происходит с некорректными настройками, они вполне могут и писаться в какой-то лог. И все равно это вторично.
А по сути
Именно отдел качества должен был указать на проблему.
Именно лвл дизайнеры должны были орать что левл не работает так как задумывалось.
Именно менжмент должен был среагировать на негативные отзывы.
Но ни как не программисты.
И скажи по секрету — ты же не программист? Иначе бы ты знал главную программерскую тайну:
Всегда виноват заказчик, написавший кривое ТЗ.
Всегда виноват дизайнер, выдавший убогий UI.
И наконец всегда виноват тестер, который пропустил баг в релиз.
Ну а программист то причем?
Гейм-дизайнеры и левел-дизайнеры — это тоже разработчики как бы.
После исправления опечатки заметна разница: генерируется в целом меньше религии (faith), но строится больше зданий и лучше развивается наука.
Кажется у мировых правительств в реальном мире тоже опечатка в конфиге.
UFO just landed and posted this here
Эйнштейн после смерти попал на небо, но никак не успокоится: всё его что-то гнетёт, о чём-то мучительно думает.
Бог увидел это и спрашивает:
— Альберт, я вижу что-то не даёт тебе покоя — спроси меня: я разрешу все твои сомнения, отвечу на любой вопрос.
— Понимаешь, я всю жизнь пытался найти Самую Главную Формулу Мира. А ты — бог. Ты создал этот мир. Ты же знаешь её?
— Конечно знаю, Альберт!
— Напиши мне её, пожалуйста!
Бог садится писать большую формулу, Эйнштейн смотрит у него из-за плеча и вдруг говорит:
— Постой-постой! Вот тут же — явная ошибка.
Бог со вздохом, качая головой:
— И это, Альберт, я тоже знаю…
Бог увидел это и спрашивает:
— Альберт, я вижу что-то не даёт тебе покоя — спроси меня: я разрешу все твои сомнения, отвечу на любой вопрос.
— Понимаешь, я всю жизнь пытался найти Самую Главную Формулу Мира. А ты — бог. Ты создал этот мир. Ты же знаешь её?
— Конечно знаю, Альберт!
— Напиши мне её, пожалуйста!
Бог садится писать большую формулу, Эйнштейн смотрит у него из-за плеча и вдруг говорит:
— Постой-постой! Вот тут же — явная ошибка.
Бог со вздохом, качая головой:
— И это, Альберт, я тоже знаю…
Блин. Ломанулся в стим за «трехдолларовой игрой, которую сейчас себе сам поправлю» — 1149 рублей.
на gamefarm.ru и прочих сайтах можно глянуть все текущие цены у реселлеров. И очень часто они бывают ниже стимовских, особенно когда дело касается неликвидных игр.
Конкретно сейчас оно на гамазавре за 91р есть… черт, возьму парочку. С женой потом поиграем :)
Конкретно сейчас оно на гамазавре за 91р есть… черт, возьму парочку. С женой потом поиграем :)
Да ну нафиг:
Серьезно, старая игра, которая много хуже чем та, что была в 2000м году. По своему сюжеты и фишкам даже с патчем она не стоит своих денег.
UFO just landed and posted this here
странно, что они это не пофиксили еще в 2013ом — разве что только предположить, что команда разработчиков была сокращена всем составом сразу после релиза…
У них там вакансия появилась интересная:
Programming Copy Editor
Gearbox Software is looking for a capable and driven full-time engineer to review all code for typos.
К вопросу о строгой статической типизации…
… который тут совершенно ни при чём, хватило бы и динамической типизации. Попробуйте написать подобную хрень в питоне, запустить интерпретатор.
Ошибаетесь. Основная проблема динамической типизации тут в том, что проверка происходит только при выполнении конкретной строки. Условно говоря, если у вас опечатка в блоке
Обмануть джиес ничего не стоит. Питон, к его чести, делает некоторые статические проверки, поэтому с ним посложнее, но все же довольно легко.
else, а в данный момент условие истинно — вы можете даже не узнать о ее наличии.Обмануть джиес ничего не стоит. Питон, к его чести, делает некоторые статические проверки, поэтому с ним посложнее, но все же довольно легко.
Не манипулируйте. Вы «условно говорите про блок else», а здесь другой случай, код выполняется безусловно. И к чему тут ваши ссылки на какие-то сниппеты с ветвлением, вы лучше статью перечитайте. Ещё раз, там происходит присваивание объекта, несуществующего в текущем скоупе. И джиес, и питон такое не разрешают, и программа должна падать.
Тут видимо имеется в виду, что если в Java подобный код просто не скомпилируется, то в JS программа будет работать несмотря на ошибку до тех пор, пока не дойдёт до явного выполнения ошибочного кода.
Только:
1. Причём здесь динамическая/статическая типизация?
2. Это явно не наш случай, так как конфиг очевидно подгружался каждый раз, это не какое-то редкое ветвление else.
Только:
1. Причём здесь динамическая/статическая типизация?
2. Это явно не наш случай, так как конфиг очевидно подгружался каждый раз, это не какое-то редкое ветвление else.
Важное в статье — не конкретный пример простейшего формата конфига, а то, насколько опасно игнорировать опечатки в программе, а важное в моем комментарии — что динамическая типизация позволяет их обнаруживать только в совсем элементарных случаях. Впрочем, даже в этом примере джиес сработает не так, как вы предположили.
Динамическая типизация ходит рука об руку с undefined by default, автоисправлением ошибок (нет поля? Ну на тебе null) и т.п. В итоге появляются подобные прекрасные решения, как это обходить, в итоге код подвержен ошибкам и выглядит так себе.
Вот так можно разлюбить плодить конфиги и полюбить инициализацию в коде.
Проблема в организации конфигов. Я как-то раз реализовал конфиги через Луа. Каждый конфиг был скриптом, например: server.addr = "127.1", где server — связанная переменная, а addr — ее поле. Тот же самый luabind генерит корректные геттеры, которые генерируют человекочитаемую ошибку.
Да конфиг-то на самом деле нормальный — при его загрузке ничто не мешало кинуть warning про несуществующее значение. Но этого не сделали :(
как будто в коде не написать ту же самую опечатку
К вопросу о строгой статической типизации…Одна из причин, почему Delphi использую и на другое не смотрю.
умные все… статическая типизация, ворнинги… обычно не конфиг ставит значения переменных в разных сервисах, а сервисы дергают по ключам значения из конфига, и они понятия не имеют, что там значения лежат по ключам с опечатками… можно разве что сыпать ворнинги через пару минут после старта приложения, что значение из конфига не было использовано
Ну так объекту конфига надо сначала загрузить конфиг в память, прежде чем отдавать опции. На этом этапе можно и проверить соответствие конфига схеме. Схема вам нужна в любом случае, хотя бы для документирования возможных опций.
Как бы это ни было грустно, но за десять лет в разработке я не видел ни одного проекта, который бы валидировал конфиг
Расскажите, пожалуйста, на чем в основном пишите. Интересно где так делают unmarshalling, что он не сыпет ошибками при несоответствии структуры данным.
бекенд, фронтенд… js, java, spring, grails… начал вспоминать софт, который юзаю: только nginx не стартует, если в конфиге какая-то фигня написана
Не обязательно не стартовать, моя программа стартует при любом конфиге, но если считалась переменная вне диапазона разрешенных значений используется значение по умолчанию. (Мне некуда ошибками сыпать, хотя по хорошему было бы хорошо)
если считалась переменная вне диапазона разрешенных значений используется значение по умолчанию
Казалось бы, сказочные игроделы из исходного поста ровно это и делали — молча использовали значение по умолчанию. У них, правда, переменная была типа "действие", поэтому значение по умолчанию оказалось "ничего не делать", но Вы уверены, что для более простых типов переменных этот подход более удачен?
Хмм, «по умолчанию» это «заводские настройки».
Но как раз в Aliens переменная была за пределами допустимых значений. Это не важно что они текстовые, такого варианта как Teather не предусмотрено, значит не допустимое значение. От случая Civilization 6 конечно не застраховывает. Но у них и не было проверки этих «допустимых значений», просто если не поняла то не смогла.
А другого подхода я не вижу, если нельзя выдать пользователю предупреждение. Окирпичить устройство? Диапазон допустимых значений пришлось ввести после второго случая с битой памятью. (Оказалось что после обновления, которое может происходить только на заводе изготовителе, поменялась адресация памяти и данные читались с других адресов по старым конфигам. Вот тут как раз устройство и окирпичивалось. В то время как свеже изготовленное устройство имеет все конфиги по умолчанию.) Разве что, как вариант, при одном неправильном значении считывать все значения по умолчанию.
Но как раз в Aliens переменная была за пределами допустимых значений. Это не важно что они текстовые, такого варианта как Teather не предусмотрено, значит не допустимое значение. От случая Civilization 6 конечно не застраховывает. Но у них и не было проверки этих «допустимых значений», просто если не поняла то не смогла.
А другого подхода я не вижу, если нельзя выдать пользователю предупреждение. Окирпичить устройство? Диапазон допустимых значений пришлось ввести после второго случая с битой памятью. (Оказалось что после обновления, которое может происходить только на заводе изготовителе, поменялась адресация памяти и данные читались с других адресов по старым конфигам. Вот тут как раз устройство и окирпичивалось. В то время как свеже изготовленное устройство имеет все конфиги по умолчанию.) Разве что, как вариант, при одном неправильном значении считывать все значения по умолчанию.
А при чем тут unmarshallinng? Структура типичного неструктурированного конфига — словарь со строковыми ключами и значениями
Я так не делаю на своей работе.
Зачем описывать конфигурации строковыми k=v, если можно описать их json/yaml/xml и положить на структуру?
Меньше стрельбы в ноги, типизация, понимание что и как в конфиге опционально/что обязательно.
Что на JAVA, что на Go так делал всегда.
Зачем описывать конфигурации строковыми k=v, если можно описать их json/yaml/xml и положить на структуру?
Меньше стрельбы в ноги, типизация, понимание что и как в конфиге опционально/что обязательно.
Что на JAVA, что на Go так делал всегда.
Это из классики про электронную почту не дальше 500 миль.
Спойлер, на случай, если кто не читал, в чём там была причина:
Ну, короче говоря. Пятый (по крайней мере, в варианте Sun’а) – нормально отрабатывал sendmail.cf от восьмого. Рулсеты-то не изменились. Но вот опции настройки, такие неприлично длинные – он считал чуть ли не комментариями. Клал на них. А откомпилирован он был без настроек по умолчанию.
И, как честный человек, не найдя чего-то в sendmail.cf, он устанавливал это в 0.
И, как честный человек, не найдя чего-то в sendmail.cf, он устанавливал это в 0.
nginx -t?Тут нужен ворнинг что значение не найдено или не является валидным. Так как кто то его читает. Но глядя на походку чужого что то я сомневаюсь что исправление этой опечатки как либо бы изменило ситуацию.
Почему все пишут про ворнинги? Никто их не читает. Вот если у разработчика/тестировщика упала программа, то он наверное почешется и исправит проблему. Чем игнорирование-то поможет? Все баги такого уровня должны исправляться при разработке, до пользователя паники не дойдут. А то сначала пишем ворнинги, потом их не читаем, потом если пользователи вдруг начали строчить гневные письма, начинаем разбирать поток из тысяч этих самых варнингов, и просто тонем…
Неужели нет ресурсов исправить хотя бы все критические ошибки в коде? Или лучше выкатить фигак-фигак в продакшн, чтобы собрать за ранний доступ деньжат, а потом свалить на Багамы?..
Неужели нет ресурсов исправить хотя бы все критические ошибки в коде? Или лучше выкатить фигак-фигак в продакшн, чтобы собрать за ранний доступ деньжат, а потом свалить на Багамы?..
Причина в следующем. Дело в том, что изначальная функция AttachXenoToTether вообще ничего не делает, а вот функция AttachPawnToTether делает
У вас по тексту опечатка в одном из названий функции.
А проблема игры, похоже, не в опечатке, но в недостаточном тестировании. Неужели перед выпуском, нормально проверив, нельзя было не заметить, что-то пошло не так?
Сюда же возможно прибавить недостаточное логирование ошибок, либо недостаточную внимательность разработчиков к предупреждениям (если движок их давал на опечатку), что косвенно говорит о не самой высокой культуре разработки.
Я больше худею с этого: дизайнер описал ИИ, программист все реализовал. Потом программист проверил, что все более менее работает. Потом дизайнер проверил, что все его идеи воплощены корректно. Потом тестировщик проверил, что идеи дизайнера отражены корректно, согласно ТЗ. А потом через 4 года выясняется что ИИ в принципиальных моментах работал не так как надо.
Мдя, шел 2018 год, разработчики до сих пор не научились проверять на ошибки парсинг текстовых файлов.
4 (четыре) года!
Разгромные обзоры, провальные продажи, судебные иски… И компания за 4 года не смогла найти ошибку?!
Разгромные обзоры, провальные продажи, судебные иски… И компания за 4 года не смогла найти ошибку?!
Подозреваю, что команду разработчиков сразу показательно расстреляли и больше искать было некому.
Думаете, она её искала?
А что если она там появилась не случайно, а в качестве расплаты за работу? Слышал такие истории, про коварных программистов и сисадминов. =)
Всё равно это какое-то невероятное стечение обстоятельств. Даже если это было написано специально, то оно значительно влияет на игру, не заметить это невозможно. А не заметить и не поправить за 4 года — это вообще непонятно как. Одно дело злодей-программист напишет
define true false
Зато сейчас все ломанутся её скачивать покупать! И они ещё в выигрыше останутся. Вот что значит грамотная стратегия!
демонстрирует принципиальное отличие настоящего ИИ от хм, его «реализаций» в настоящий момент. Настоящий ИИ догадался бы что там опечатка
Всё-таки не понимаю. Одно дело баг из-за опечатки, который появляется редко и непойми когда. А другое дело — баг, который влияет на всю игровую механику и портит впечатление от игры. Даже если эта команда не выбрасывала никаких ворнингов — разработчики же должны были заметить что что-то не так, что специально разработанная ими функция в один момент перестала работать. Я понимаю что такое очень сложно найти, но зачем выпускать явно сырую вещь в продакшен, словить кучу негативных отзывов, и так и не поправить баг за 4 года. Это как вообще возможно?
Причин может быть несколько.
1. Обычное дело, когда у студии много проектов, разработчики и тестировщики переводятся с одного на другой. Плюс куча задач выполняется внешними разработчиками по контракту.
Один разработчик реализовал, протестировали, все ок.
Потом он и тестировщик перешли на другой проект/уволились/у них закончился контракт.
Другой разработчик вынес в конфиг (внеся ошибку).
Новый тестировщик мог быть вообще не в курсе этой функциональности (обычное дело, даже если пару лет работал параллельно с первым тестировщиком).
2. Когда игру выпустили, программисты уже давно работали над другими проектами. Заказчик за поддержку не платил либо платил мало, и игра была в стадии поддержки.
3. (вариант п.2) Цикл разработки и релиза мог был полностью разделен, и игра некоторое время вообще просто «валялась» на полке, пока готовили маркетинговые материалы и договаривались с площадками о размещении. А у разработчиков уже давно были новые проекты.
1. Обычное дело, когда у студии много проектов, разработчики и тестировщики переводятся с одного на другой. Плюс куча задач выполняется внешними разработчиками по контракту.
Один разработчик реализовал, протестировали, все ок.
Потом он и тестировщик перешли на другой проект/уволились/у них закончился контракт.
Другой разработчик вынес в конфиг (внеся ошибку).
Новый тестировщик мог быть вообще не в курсе этой функциональности (обычное дело, даже если пару лет работал параллельно с первым тестировщиком).
2. Когда игру выпустили, программисты уже давно работали над другими проектами. Заказчик за поддержку не платил либо платил мало, и игра была в стадии поддержки.
3. (вариант п.2) Цикл разработки и релиза мог был полностью разделен, и игра некоторое время вообще просто «валялась» на полке, пока готовили маркетинговые материалы и договаривались с площадками о размещении. А у разработчиков уже давно были новые проекты.
Возможно, у разработчиков был свой конфиг, с которым всё работало. Ошибка могла возникать на этапе релиза и не обнаруживаться автоматическими тестами.
Может это тот тип разрабов которые вообще не играют в игры сами.
Не понимаю. Должен же быть контроль версий. Тестеры должны были обнаружить эту ерунду. За такое время можно было миллион раз проверить построчно весь код, который менялся. Или я что-то не понимаю? Просто бред какой-то.
Возможно сразу после релиза команду разработчиков перекинули на другую игрушку, а на техподдержку оставили пару человек и всё. И эта пара человек может быть вообще не в курсе была что это баг, может это просто такая вот фиговая игровая механика. Но ведь оригинальные разработчики должны были играть в игру после релиза? Должны были увидеть что что-то не так и сообщить руководству?
Игра в Steam как стоила 29,99 евро так и стоит, откуда уважаемый alizar взял цену в несколько долларов?
На скидках цена опускалась ниже 100 рублей в российском сегменте. И стим не единственное место где продаются иры для стима :)
Тогда можно утверждать, что игра доступна бесплатно, если вы понимаете о чем я.
Ну это уже крайность. Игра 2013 года стоит ровно столько, за сколько ее готовы купить, и в данном случае это было 'несколько долларов'.
Даже если на стиме сейчас нет скидки, крайне велика вероятность найти ее у реселлеров с огромной скидкой. Эта вон сейчас за 91р продается.
Даже если на стиме сейчас нет скидки, крайне велика вероятность найти ее у реселлеров с огромной скидкой. Эта вон сейчас за 91р продается.
Вы делаете взгляд на цену очень субъективным. На том же стиме цена по странам считается автоматически: если вы поставили 5$ в США, для пользователей из России автоматом выставится 133 рубля. Т.е. один и тот же продукт на одной и той же площадке сразу имеет разную цену.
Не понимаю, какое это имеет отношение к делу. Цена с учетом 90% скидки (такая была пару недель назад) будет 2.99$ и это более чем подходит под «несколько долларов». Точно так же как и у огромного количества западных реселлеров ее можно было взять даже дешевле. За 29.99 ее сейчас никто не купит.
Да и региональные цены стима — это лишь разумное предложение со стороны стима. Каждая контора может глубоко наплевать на это и выставить такой ценник, который пожелает. В последнее время такие игры появляются все чаще.
Да и региональные цены стима — это лишь разумное предложение со стороны стима. Каждая контора может глубоко наплевать на это и выставить такой ценник, который пожелает. В последнее время такие игры появляются все чаще.
<Row Item="YEILD_PRODUCTION" ListType="DefaultYieldBias" Value="25"/>Вариант в Цивилизации кстати вообще сложно отследить. Ладно, в Aliens присваивается значение из несуществующей переменной, можно было выбросить исключение, а здесь опечатка в самом названии параметра в глобальном конфиге. И если изначально не задать список возможных параметров (в котором тоже может быть опечатка), то сложно понять, используется ли это значение дальше в коде или нет.
UFO just landed and posted this here
Ну это уже совсем плохой тон.
Скорее там что-то вроде nullObject — refactoring.guru/ru/introduce-null-object
В противном случае достаточно муторно происходит добавление новых элементов конфига.
В противном случае достаточно муторно происходит добавление новых элементов конфига.
UFO just landed and posted this here
По-моему это маркетинговая акция. Допилили промеж дела ИИ в полумертвом проекте и пытаются продажи сделать.
Вопрос к n0mo: возможно ли отловить подобную ошибку в конфигах с помощью PVS-Studio?
UFO just landed and posted this here
Я упоминания об этом тоже не встречал, но, чисто теоретически, какая разница, где искать опечатки методом статистического анализа — в исходном коде или в ini-файле?
Я довольно часто видел грамматические ошибки в именах переменных, заложенные туда изначально потому-что программист думал(!), что знает, как это слово правильно пишется. Апофеозом было обнаруженное слово sporadick. Так-что проверять за разработчиком грамматику коде или конфиге — последнее дело для статического анализатора кода.
PyCharm такое отслеживает — он даёт предупреждения на названия переменных, написанные с опечаткой.
Разницу ощущаете между sporadic и sporadick?
Да. То, которое кончается на «уменьшительное от Ричард», — устаревшая форма другого.
Суть в том, что автор этой переменной не настолько силён в английском, чтобы использовать устаревшее написание этого довольно распространённого в нашей трудовой деятельности слова. Причём настолько не силён, что даже не знал о наиболее часто подразумеваемом значении этого самого «уменьшительного от Ричард». А вот пользователи, то как-раз знали и ситуация на самом деле не очень приятная.
Кстати, другой случай — несколько раз у разных людей никак между собой не связанных встречал в коде ПО (и в текстовых блоках UI) связанного с морским транспортом именование кораблей, как sheep.
Кстати, другой случай — несколько раз у разных людей никак между собой не связанных встречал в коде ПО (и в текстовых блоках UI) связанного с морским транспортом именование кораблей, как sheep.
Можно просто искать уникальные названия, которые встречаются в скриптах один раз или два раза — и вручную их потом проверить.
Если XML правится ручками (это же не сериализатор такую ошибку допустил), то лучше делать проверки и выдавать ошибки или предупреждения. Действительно, больше похоже на PR-ход.
Упор на графику, а вот под носом что в коде инишника даже на отладке не проверили логи…
Наверное, немаленькие убытки они понесли из-за какой-то опечатки.
UFO just landed and posted this here
вообще это журналистская работа — фактчекинг. по идее автор перевода должен был купить игру и проверить. и если бы оказалось что уже пофиксили — то и писать было бы не о чем :)
То есть, когда пишется статья о том, что роверы на Марсе нашли воду, то автору такой статьи нужно лично туда слетать и только после этого что-то да писать?
мощно передергиваете :)
Про Марс — почитать в авторитетных источниках (научных журналах например, где каждая статья пишется ученым и рецензируется тоже учеными), отчетах НАСА и тд и проверить соответствие фактов тому что в статье написано.
Научных журналов о играх не знаю, да и проверить факты очень просто на дому, поэтому написал так.
Про Марс — почитать в авторитетных источниках (научных журналах например, где каждая статья пишется ученым и рецензируется тоже учеными), отчетах НАСА и тд и проверить соответствие фактов тому что в статье написано.
Научных журналов о играх не знаю, да и проверить факты очень просто на дому, поэтому написал так.
UFO just landed and posted this here
потому что движок просто игнорировал незнакомый термин
Забавно. Но как это прошло тестирование? Почему сразу не выявили после жалоб пользователей? Мне кажется, там какой-то внутренний бардак является причиной, а не опечатка.
Но как это прошло тестирование?
Да сам вот про это думаю, по хорошему вообще в дебажных билдах должна быть предусмотрена возможность при спотыкании интерпретатора об что-то выкидывать некий «эксепшен» с описанием ошибки, но есть жутко филосАфы которые гутарят об том что программа не должна падать никак и никогда, вполне возможно что игнор ошибки в интерпретатор был встроен под хотелку такого умника.
После исправления опечатки заметна разница: генерируется в целом меньше религии (faith), но строится больше зданий и лучше развивается наука.
Вот черт, у человечества опечатку в коде бы кто исправил :)
И только спустя четыре года стало понятно, в чём корень проблем.
Ну, справедливости ради, ИИ — это вроде не единственная претензия которая была у игроков к игре (например, качество графики релиза по сравлению с трейлерами).
Ну ладно.
Создателям игры стало пофиг на неё аккурат в момент выхода — печально, но бывает.
Тестерам пофиг, что мобы начали тупить (хотя в пререлизах этого не делали) — печально,гнать таких тестеров, но тоже бывает.
Игрокам пофиг, что в игре мобы тупят, потому что сейчас каждая вторая игра такая, после работы неохота напрягать мозг, безысходность, много почему — тоже, в конце концов, бывает :)
Но я не об этом.
Я о разрабах движка.
На кой дьявол вообще изначально было выносить это в конфиг?
Серьёзно, у вас есть возможность вырубить AI. Покажите хоть одну причину, по которой это стоит делать в юзерском конфиге? (а не через чит-код, консоль разработчика,…, если это нужно для тестов ?)
Создателям игры стало пофиг на неё аккурат в момент выхода — печально, но бывает.
Тестерам пофиг, что мобы начали тупить (хотя в пререлизах этого не делали) — печально,
Игрокам пофиг, что в игре мобы тупят,
Но я не об этом.
Я о разрабах движка.
На кой дьявол вообще изначально было выносить это в конфиг?
Серьёзно, у вас есть возможность вырубить AI. Покажите хоть одну причину, по которой это стоит делать в юзерском конфиге? (а не через чит-код, консоль разработчика,…, если это нужно для тестов ?)
Я не знаю, как это в геймдеве устроено, но, скорее всего, так же как и везде. Когда требования постоянно меняются, менеждер говорит: «А давай попробуем сделать так?», то некоторые вещи выносятся во внешние конфиги, типа настраивайте сами, как вам больше нравится. Ну, вот и настроили.
Окей, допустим.
Вчитаемся в код.
Промолчу про синтаксис конфига.
Но сам подход!
Тут ремапится некий класс в другой класс. Один из них по факту не используется, второй что-то делает, оба актуальны для огромного множества объектов в игре. Хрен с ним, что из-за опечатки ремап не происходил — это всё лежит по пути
My Documents\My Games\Aliens Colonial Marines\PecanGame\Config\PecanEngine.ini
Т.е. движок писался в предположении, что под юзером Васей мы класс поведения мобов можем ремапить в одно место, а под юзером Машей — в другое — ЗАЧЕМ?
Наркоманы :)
Положили бы это в GameRoot, меньше вероятность, что кто-то невнимательный перед релизом накосячил.
У кого есть игра, много там такого в userspace? :)
Вчитаемся в код.
ClassRemapping=PecanGame.PecanSeqAct_AttachXenoToTether -> PecanGame.PecanSeqAct_AttachPawnToTether
Промолчу про синтаксис конфига.
Но сам подход!
Тут ремапится некий класс в другой класс. Один из них по факту не используется, второй что-то делает, оба актуальны для огромного множества объектов в игре. Хрен с ним, что из-за опечатки ремап не происходил — это всё лежит по пути
My Documents\My Games\Aliens Colonial Marines\PecanGame\Config\PecanEngine.ini
Т.е. движок писался в предположении, что под юзером Васей мы класс поведения мобов можем ремапить в одно место, а под юзером Машей — в другое — ЗАЧЕМ?
Наркоманы :)
Положили бы это в GameRoot, меньше вероятность, что кто-то невнимательный перед релизом накосячил.
У кого есть игра, много там такого в userspace? :)
это всё лежит по пути
My Documents\My Games\Aliens Colonial Marines\PecanGame\Config\PecanEngine.ini
Видимо, это затем, чтобы можно было патчить игру, не требуя прав админа (и не устанавливая в систему службу для апдейта, а то их в системе какая-то прорва уже, каждое ПО пытается пропихнуть апдейтер), или, скажем, моды на игру ставить. Reasoning ИМХО такой: на этапе проектирования строится архитектура, прикидывается, какие части и как часто придется патчить, соответствующие часто патчащимся частям файлы кладутся в user-space ака %USERPROFILE%, остальное в os-space ака %PROGRAMFILES% или %PROGRAMDATA%. Скриптовая логика ИМХО может меняться чаще, чем основной код движка, тем более если в нем требуется поправить какие-то константы, скажем, нерфнуть оружие или абилку, как следствие, была отнесена к "часто патчащимся" файлам.
Тестирование? Не, не слышали.
Никто из команды разработчиков не пытался играть до релиза в стиме?
Бред, любой разработчик бы заметил аномальное поведение.
К слову сказать, по некоторым признакам это unreal engine. Там действительно можно наломать :)
upd: действительно, он.
upd: действительно, он.
Sign up to leave a comment.
В конфиге Aliens: Colonial Marines нашли опечатку, из-за которой четыре года глючил игровой ИИ