Тенденция к выпуску полусырых игр и тонны критических заплаток к ним

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

 

Кому как, лично меня близзарды со своим патчеклепанием и "вечным оттачиванием баланса" только бесят.

 

Кармак - уникум. Подавляющее большинство хуже. Гениев мало, больше как-то обычные люди встречаются.

Самым - нет. Сложным - да.

Несмотря на это, объемы (количество строк кода) одних только движков выросли в несколько раз, а, стало быть, и общая сложность.

Все может быть... Просто я со стороны программирования вижу определенные тенденции. Тот же С++ сейчас выжимается из многих областей и заменяется другими инструментами, положительные результаты есть - повышение надежности одновременно с увеличением скорости разработки. А в играх его пока заменить сложно - из-за требования "выжать из железа все, что можно".

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

 

Так ясное дело, движки стали малость покруче. Но писать их, несмотря на это, проще - рутинные операции не надо вручную клепать и извращаться на низком уровне.

 

(О Кармаке)

Это с каких это пор какой-нибудь UE3 - на основе движка Кармака? В последнее время вообще на движках от Кармака вышло всего 4 игры (D3,Q4,Prey,ETQW). (Не считая движков RPG для телефонов).

 

Плагиат и копирование. Зачем изобретать колесо?

 

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

И да, на Кармаке свет клином не сошелся. На примере Doom 3 и выше уже заметно, что подрастерял он молодецкий задор.

 

Причём здесь Картостроение, фичи и рендеринг? Основа написанная на C++ думаю может и отличаться, но методы то одинаковые, не могут же они кардинально отличаться?!

 

КАНАВОПЫТ

При таком ходе мыслей Кармак тоже, мягко говоря, плагиатор.

 

Dimouse, все же в больших проектах желателен (а иногда и необходим) формальный контроль, а не просто методики рекомендательного типа. В частности, желательно контролировать как можно больше всего на этапе компиляции (строгие проверки типов, контракты интерфейсов как в Eiffel, есть методы и еще серьезнее, вроде dependent types).

Честно говоря, 4 гигабайта исходников - это у меня в голове не умещается. Это сколько же там строк? В WinXP - 40 миллионов, в Mac OS X - 100 миллионов. У вас миллиарды чтоли?

 

kreol, в первой части Lands of Lore тоже был критический баг да и вторая часть не без греха..

 

Что-то тут много упоминаются думы и Кармаки.
http://www.youtube.com/view_play_list?p=2C05FCD2000FBE3D
Думвики пока лежит, а то бы я и на неё дал бы ссылку. Глюки есть везде, просто где-то их так и не нашли(за ненадобностью скорее всего). Другое дело, что игра-таки на момент выхода должна быть 100% проходима всеми доступными классами, расами, чтобы все пушки стреляли, и все машинки ездили. чтобы все карты открывались и проходились. А что ошибки, неточности и местами визуальные глюки, то тут уж пусть патчами лечат, я не против.

 

очередная демагогия

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

Для того что бы написать хоть какую-то программу необходимо пройти как минимум три этапа: №1) проектировка — на этом этапе решается вопрос «А чего мы собственно говоря хотим сделать?», т.е. ставятся цели, сдесь же выбирается среда разработки и определяются средства. №2) алгоритмизация или программирование — на этом этапе составляются, ещё на бумаге, алгоритмы выполнения задачи, разбиение программы на модули и прочая метаработа отвечающая на вопрос «Как нам всю эту фигню сделать». И наконец №3) кодирование — на этом этапе кости алгоритмов обрастают мясом программного кода. На этом этапе всё и реализуется. Но это в идеале. Реально же необходим и существует ещё и №4) отладка — поиск и исправление ошибок. В идеале первые три этапа должна проходить одна и та же команда, все члены которой участвуют на каждом этапе — ведь даже глупость сказанная полным профаном может дать рождение новой идеи или показать как точно делать не надо. К тому же это исключает появление фантастических (не алгоритмизируемых) проектов и мало кодируемых алгоритмов, например — нечёткая логика в искусственном интеллекте. Если разработка на каком-либо из этапов заходит в тупик, то необходимо вернуться на предыдущий этап, часто это влечёт переосмысление всей работы и как следствие «на заборе мочало — начинай всё сначала». Если на всех трёх этапах команда одна и та же, то большинство подобных тупиковых ситуаций можно избежать.

Но если мы делаем не отдельную программу, а систему или игру, состоящую из множества модулей/частей? Одна и та же команда будет действовать очень медленно, т.к. решает задачи последовательно. И вот так и получается, что создаётся отдел проектировщиков, часто далёких от программирования, который помимо самого проектирования ещё и разбивает задачу на части и отдаёт дальше по цепочке нескольким отделам программистов. Причём частенько логика разбиения на подзадачи в лучшем случае не понятна. При «тупике» у одного из программеров реально может возникнуть ситуация когда вся работа спускается в утиль и начинается всё с начала во всех отделах и звеньях цепочки. Правда такие ситуации крайне редки — чаще всего алгоритмизации поддаётся даже самый кривой проект. Вот вам и первое горлышко бутылки — проект. Раньше его составляли грамотные технари, а теперь менеджеры, маркетологи и прочий коммерческий планктон. На втором этапе уже параллельно работают несколько отделов программистов. Обычно эти специалисты хоть как-то разбираются в кодировании и особых огрехов здесь весьма мало, кроме тех что пришли с предыдущего этапа — принципы алгоритмизирования практически не изменились со временем, а если изменились, то в лучшую сторону. Назвать этот этап местом рождения ошибок можно только если на нём работали полные дилетанты, а это редкость и система/игра тогда часто просто не выходит. Программисты отдают свои алгоритмы на реализацию в один и тот же или несколько отделов кодировщиков. Вот здесь-то и произошли самые глобальные изменения со временем, но об этом позже. Получается настоящий конвейер — работа идёт гораздо быстрее.

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

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

Вот теперь рассмотрим как изменился процесс кодирования. Условно всё время разделим на три этапа (висту трогать не будем — а то пахнуть будет): интерпретатор команд вместо ОС — эпоха DOS; ядро Win 9x/ME и ядро WinNT. Первый этап отличался простатой работы, но не кодирования, никакой стандартизации — каждый писал во что горазд. Языки высокого уровня появлялись как грибы после дождя и всем этим правили языки низкого уровня типа ассемблера или Си (о Би тактично забудем). Того что мы сейчас называем драйверами тогда просто не было — все обращения к железу осуществлялись посредством прерываний через языки низкого уровня. Большинства карт расширения — особенно видео карт тогда просто не существовало, да-да всеми нами так любимый VGA адаптер как и VGA мониторы появились далеко не сразу. Да ещё и прогресс палки в колёса вставлял... архитектура и как следствие набор команд процессора от версии к версии различалась кардинально — в результате код откомпелированный на языке низкого уровня для одного процессора (пусть 286) мог оказаться не работоспособным на машинах с другим процессором (386 и 486 например). И это еще без учёта различных видов звуковых карт, отсутствия или наличия мыши, памяти (разрядность адресации менялась), различных видов видео режимов и многого другого. Это сейчас оборудование более или менее обобщено и стандартизировано, да и старьё исчезает быстрее, а раньше встречались компьютеры всех возрастов и вероисповеданий. Перед разработчиками стояла задача заставить игру работать на различном железе, фактически написав драйвера на все случаи жизни и для всех устройств. Часто драйвера приходилось писать с нуля и оптимизировать их под конкретную игру — о жёстких ограничениях по памяти ещё никто не забыл? В эту эпоху кодировать было очень сложно — почти всё приходилось делать самостоятельно, но и занимались этим люди куда как лучше разбирающиеся в своём деле и им редко кто мешал. К тому же тогда многие были энтузиастами и как все фанаты своего дела не стеснялись делиться своими достижениями. Таким образом стандартные задачи получали практически идеальные решения отлаженные множеством людей.

Но идилия такая длилась не долго. Появились люди которые хотели продавать свои наработки и так наступила следующая эпоха. Появление API и сред разработки значительно упростило процесс кодирования — теперь не надо было изучать принцип работы железа, копаться в прерываниях и выполнять множество других действий достойных истинных гуру — операционная систем сама обо всём позаботится. Главная проблема такого подхода была в том, что сами функции были закрыты от кодировщика — как они работают — одному создателю известно (про OpenGL в другой раз). Игры написанные таким образом были несколько медленнее, но пользователь уже мог самостоятельно усовершенствовать свой компьютер; могли содержать «чужие» ошибки — функции API и драйвера тоже люди писали, причём чужие, незнакомые дядечки. Но с другой стороны исчезла привязка к железу и любой апгрейд уже не вызывал каждый раз вопрос «А будет ли моя игрушка работать?». В качестве побочного эффекта такого подхода хочется отметить общую деградацию навыков кодирования и развитие навыков программирования, а так же повсеместное распространение ОС небезызвестной Вам всем компании. Эта же ОС выступала посредником почти во всех вопросах, особенно при обращении к железу, и т.к. она сама стабильностью похвастаться не могла, то и качество игр часто оставляла желать лучшего. В это время ещё встречаются работы матёрых мастеров, что большинство критичных участков кода пишут на языках низкого уровня — ядро ОС ещё позволяет обращение к железу напрямую. Игры таких разработчиков могли похвастаться крайне малым количеством ошибок — чем меньше посредников тем меньше сбоев, при наличии грамотности, естественно.

Но эпоха опять сменилась — новое ядро уже не позволяет общаться с железом напрямую, только через ring0 (тама старфорс и сидит). Появился обязательный посредник от которого уже не отвертишься, а вмете с ним ещё и множество сервисов. Как же теперь избавляться от привязки к железу? Как ещё далее систематизировать и стандартизировать процесс кодинга? После таких вопросов и появились виртуальные машины - каркасы (.Net Framework, JVM например) — это ещё один посредник — коллекция библиотек готовых решений и обособленная от железа среда для их выполнения - ещё один посредник. Такие библиотеки мало чем отличались по форме кодирования от API — быстро, удобно, легко и приятно и всё тот же чёрный ящик, и всё то же последствие — деградация навыков кодирования. Всё сложнее и сложнее заставить кодировщика оптимизировать код по быстродействию — для этого ведь так много надо знать и уметь, а производители железа всё норовят штуцель по мощнее сбацать — а ну его пользователя... раз у него есть деньги и время на игры пущай раскошеливается!

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

На сладкое я приберёг процесс отладки — его больше всего ругают. В каждой конторе есть свои тестеры/отладчики — только вот они тестят отнюдь не готовый продукт, а его модули. Готовым продуктом же занимаются сдельщики — чем дольше идёт тестирование тем оно дороже — кодировщики-то без дела ждут результатов тестирования, а это всё деньги. Да и тестеры часто оставляют желать лучшего — ни толком описать ошибки не могут, ни после чего она появилась, а профессиональные и грамотные тестеры больших денег просят да ещё и не всё тестить соглашаются. Так и получатся, что в погоне за экономией волевым решением издателя на прилавок попадает сыроватый продукт, а кодеры вставляют в игру внутренний баг-репортер в качестве дополнительного модуля — потенциально дополнительного источника ошибок. Польза от этого двойная — экономия времени и использование фанатов мазохистов в качестве бесплатных тестеров. Раньше просто таких гонок и борьбы за долю рынка не было.

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

В качестве вывода хочу сказать — пока процесс разработки является коммерческим процессом, пока деньги играют ключевую роль во всей жизни общества, пока все пользователи не станут требовать к себе справедливого отношения и адекватности цен на получаемый на руки товар качеству товара (а не на тот что в проекте) ничего в этой жизни не изменится. Жадность и лень людские виноваты. Причём как разработчиков/издателей, так и игроков. А вот нытьё о том что ошибок раньше было меньше ни к чему не приведёт.

И на последок. Вспомните такие игры как Daggerfall и Master of Magic — сколько к ним патчей выходило и всё равно они весьма глючные. Прошу прощения за ошибки — писал ночью, и за длину сообщения.

 

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

 

Всё правильно,только кажется,что ничего не изменится даже если "начать требовать".
К сожалению.

 

ShnigaMi_r, а вот это уже зависит от того сколько потенциальных покупателей будут предложенный товар байкотировать. процентов 40 уже заставит задуматься. только издатель/разработчик знать об этом байкоте должен. Ошибки в финальных версиях должны быть максимально невыгодны для издателя