28 декабря 2020 года CD Projekt Red выложила в открытый доступ тизер первого дополнения к Cyberpunk 2077. Также студия открыла на сайте игры отдельный раздел с DLC.
Первым это заметил пользователь Reddit под ником DiegoOnishi. Пользователи предположили, что этот DLC будет содержать ранее убранные перед релизом из-за непроработки части игрового мира, предметы и квесты.
Разработчики игры пояснили, что бесплатное дополнение будет отдельной веткой от центрального сюжета истории Найт-Сити. Первый DLС к Cyberpunk 2077 выйдет в начале 2021 года.
Ранее пользователи обнаружили в игре элементы пустующего метрополитена (монорельсы и даже одну станцию), который разработчики планировали реализовать, но так и не доделали в релизе. CD Projekt Red не стала удалять уже созданные части метро в Cyberpunk 2077.
10 декабря CD Projekt Red рассказала, что 8 млн пользователей предзаказали игру Cyberpunk 2077. Тогда стало известно, что запуск Cyberpunk 2077 на ПК стал самым крупным в истории компьютерного игропроизводства. На 20 декабря более 13 млн пользователей приобрели игру.
За три недели после релиза студия CD Projekt Red выпустила три патча к игре. Первый патч 1.04, который вышел 11 декабря, через день после релиза игры, содержал 27 исправлений. Второй патч 1.05 вышел 19 декабря и содержал 61 исправление. Третий патч для Cyberpunk 2077 содержал всего три исправления.
См. также:
- «Генератор извинений как у CD Projekt Red. »
- «Cyberpunk 2077 исчезла из PlayStation Store, магазин вернёт желающим деньги за покупку»
- «CD Projekt Red признала, что «игнорировала сигналы» о проблемах с Cyberpunk 2077 на консолях Xbox One и PlayStation 4»
- «Руководство CD Projekt Red взяло на себя ответственность за баги на старте Cyberpunk 2077. Сотрудники получат все бонусы»
- «Запуск Cyberpunk 2077 стал рекордно крупным в истории компьютерного игропроизводства»
namikiri
То есть они ещё не исправили все баги, а уже дополнение лепят?
ghrb
Такие игры делают большие коллективы. Нельзя же позволить спецам по 3D моделям простаивать только потому что кодеры правят баги в коде. Персонал нужно по-возможности максимально утилизировать.
atomlib
perfect_genius
Для максимального погружения в атмосферу киберпанка, а то не будет аутентично.
Wizard_of_light
«Больных в глазном отделении утром закапывать всех» (с)
AllexIn
Это делают разные люди. Там же не три человека команда.
«Девять женщин не родят ребенка за один месяц»
Akuma
Да, но девять программистов сделают работу быстрее, хоть и не в 9 раз.
AllexIn
Ок. Я скажу по другому:
«Девять женщин не родят ребенка за 8 месяцев.»
Без разницы сколько программистов* мы возьмем — быстрее чиниться ничего не будет.
Есть задачи, которые можно масштабировать. Есть задачи, которые нельзя масштабировать. Как правило починка бага — та вешь, которая масштабируется плохо. Отдельная ошибка — кидать на решение бага человека, который с нужным куском кода не работал.
* — откуда вообще мнение, что там все баги программистские? Кривая логика квестов — это не программистский баг. Это геймдизайн, скриптовка.
Даже проваливающиеся через землю машины может быть ошибкой левелдизайна, а не кода физики.
Akuma
Не спорю, но все же и сама фраза про женщин к разработке не совсем относится. Ну а «программисты» в данном случае просто обобщение, понятно что там множество направлений.
foxin
вы скорее недооцениваете масштабы гейм-девелопмента. люди, которые пишут движок скриптов и люди, которые дорабатывают видео engine — скорее всего разные. более того, они могут слабо пересекаться экспретизой не только в игре, но и экспертизой вообще. и никак не поставишь человека, который кодил в игре загрузку сейвов — фиксить баги с текстурами. а тут и еще и пачка разных платформ, каждая со своей спецификой, и зачастую разные команды занимаются разными платформами (там, где есть различия).
Hardcoin
Зато девять женщин родят девять детей за девять месяцев. Если есть потребность в большом количестве детей, то девять женщин намного производительнее, чем одна.
В данном случае есть потребность починить много багов.
ardraeiss
Если считать все баги(и модели, и текстуры, и системы хранения/загрузки ресурсов игры на диске, и баланса оружия, и краевых моментов в физике машин, и ИИ) универсальными, и программистов универсально же универсальными — то да.
В реальности, увы, так бывает чуть реже чем никогда.
Hardcoin
Не такие уж мы и ограниченные. Может не можем взяться за любой баг, но из смежной темы — вполне.
ardraeiss
Так вот это "из смежной" и есть ключевое.
Am0ralist
к вопросу о том, что не все задачи надо решать брутфорсом
EVolans
Есть мнение выраженное в целой книге (Ф.Брукса) что они могут ее делать не то чтобы быстрей, а дольше.
Akuma
Как и написал — не спорю.
Но если 9 женщин в 100% случаях не смогут родить ребенка быстрее, то уж 9 программистов, скорее всего, сделают работу быстрее. Даже если будут работать не параллельно, а сменами. Конечно, зависит от задачи, программистов и прочих факторов.
Я это к тому, что сравнение с родами некорректно.
AllexIn
Это же не детали точить по очереди.
Впрочем, токари тоже друг за другом врядли возьмутся дотачивать.
GrigoryPerepechko
Если 1 год проект пилило 5 разработчиков, и руководство за месяц-два до релиза докинуло еще 4 — то будет только хуже. Почитайте Брукса.
imanushin
Это аппеляция к авторитету. Он, кстати, не опирается на исследования, а просто приводит опыт своей работы в разработке. И, если я не ошибаюсь, как минимум технологии с тех пор изменились (а вообще — изменились процессы, появилась более глубокая специализация и так далее, так как я напомню, что оригинал издали в 1975 году).
По моему опыту, добавление разработчиков может улучшить релиз (но скорее незначительно, так как изначально планировалось 5*12=60 человекомесяцев, а здесь же стало 5*12+4*2=68 человекомесяцев, то есть не стоит расчитывать на более, чем 10% к общим ресурсам), если новые люди в команде являются опытными специалистами и не являются новичками в самой компании. И как дополнительное необходимое условие — достаточно хорошее покрытие тестами (в том числе интеграционными), разумная автоматизация и тд.
Если же в проекте все проверяется руками, билды налажены кое-как, контракты в коде выражены не строгой типизацей/тестами, а просто хранятся в памяти разработчиков, нет линтеров и каких-то style guide'ов и так далее, то действительно, новички будут входить в проект долго и скорее затормозят развитие проекта.
ardraeiss
То есть, Ваш личный опыт и Ваша аппеляция к собственному авторитету против опыта и авторитета Брукса(и тех, кто по опыту своей практике с Бруксом скорее соглашается).
imanushin
Я говорю, что нельзя приводить в пример книгу, которая даже не является научным исследованием, плюс в которой выводы делаются на основе IT 70х годов.
В качестве слабого подтверждения я привел свой пример (а я участвовал в таком изменении команды около 7 лет назад). Соответственно, для меня существует как минимум один контрпример.
В дополнение я привел агрумент (а не свой опыт), в котором демонстрируется технологическая разница в проектах, которая влияет на время "входа новичка в проект". Из-за развития IT, лет 50 назад (годы написания цитируемой книги) большая часть автоматизации (которую я привел в пример) отсутствовала, а значит новый человек тратил больше времени на "вход в проект", отвлекая бывалых сотрудников. Именно про это, кстати, и говорил Брукс. В современных IT проектах время входа может быть меньше (не всегда), а потому и добавление новых людей в проект может улучшить ситуацию (опять-таки — не всегда).
Как следствие из ненаучности изначальной книги и довольно старых практик, контрпримера и аргумента про технологии я далее сделал вывод, что нельзя слепо следовать как минимум этому доводу из книги (пусть даже и довольно популярной).
Однако, так как у меня тоже нет под рукой исследований, я не смогу построить корректную модель. Я только могу сказать, какая модель "стала менее корректной".
valexey
В ряде (довольно частых)ситуаций 9 программистов сделают работу СИЛЬНО медленней (вплоть до того, что не сделают никогда), чем если бы над задачей работал один программист.
Antervis
ну это при условии что работа посильна одному программисту. Координация же программистов это задача лида и менеджера.
delhi_heir
Если следы недовырезанного метрополитена глючат из-за того, что его криво обрезали, то легче вернуть его в игру, чем обрезая в спешке получить ещё глюки.
grvelvet
Дополнение чаще всего закладывается в процессе производства игры.
Antervis
А вообще конечно же хочется чтобы сюжетные дополнения для CP77 были на уровне таковых в ведьмаке.