?

Log in

No account? Create an account

Разработка AI в стратегических компьютерных играх III - Не кинокритик. Не палеонтолог.

авг. 30, 2007

08:59 pm - Разработка AI в стратегических компьютерных играх III

Previous Entry Поделиться Next Entry

Наконец добрался выложить третью часть.
Ссылки на предыдущие: первая, вторая.

В обсуждениях предыдущих частей мне задали несколько вопросов, попробую ответить.
1. (Это не прямая цитата, я попробую обобщить несколько схожих вопросов) Идеи так или иначе не новые, и встречались в хорошо изученных областях computer science (например: rule-based systems; автоматное программирование). Почему бы не вести рассказ в таких терминах? Или более того, использовать достижения этих областей напрямую?
Более банальная причина состоит в том, что на момент написания текста (2004 год) я еще мало что знал об аналогах, а масштабно переписывать нет времени. Менее явная, но более важная - в том, что переформулировка такого узкоприкладного текста в терминах более широкой области знаний мне кажется неверной. Дело в том, что такая переформулировка приведет к иной расстановке акцентов. Появляется желание мысленно отбросить все то, что на этот язык не переводится. Например, можно сформулировать рассказ в терминах конечных автоматов. Первая часть на таком языке говорит о комбинаторном взрыве числа состояний. Вторая - как этот взрыв преодолевается переходом к стековым автоматам. Но при каждой подобной интерпретации что-то теряется (например, в этом случае мы проигнорируем важность явного управления со стороны сценария, или семантику "минимального поведения"). К тому же появляются какие-то ложные и отвлекающие ассоциации. Например, в автоматном программировании важна (во всяком случае, часто обсуждается) автоматическая проверка полноты и достижимости всех состояний. В игровом AI это не имеет особенного смысла.

2. А как насчет DSL для AI? Мне кажется, это очень хороший подход. Как раз, в нем можно будет описывать планы, правила поведения, и прочее.
Я об этом когда-то размышлял. К сожалению, вряд ли это применимо на практике. Для одной игры (или даже для серии), думаю, оно того не стоит: существующие универсальные языки (тот же Python) достаточно хороши, улучшения будут незначительными - а там, где Python использовать нельзя из-за ограничений "железа", и обязателен С(++), с высокой вероятностью нельзя будет использовать и свой язык. Имело бы смысл делать его как middleware, если бы AI middleware не было так сложно позиционировать и продавать. Может быть, когда у меня каким-то чудом появится много времени, я сделаю подобное middleware "на общественных началах".

3. Вы делали "вязкость AI"? Т.е. чтобы AI был бы ленивым, и не рыпался менять тактики из-за каких-то мелких изменений обстановки.
Иерархическая goal-based система как раз и обеспечивает "вязкость" поведения: структура дерева планов меняется довольно редко и, что называется, "по делу": когда план выполнен или наборот, когда его выполнение уже не представляется возможным. На проблему "дрожания" чем-то похожа проблема "зависания AI", упомянутая в первой части. Но проблема зависания проще: по сути, нужно обеспечить "вязкость" на нулевом времени (я уже писал, как именно можно это гарантировать). Чаще возникает как раз обратная проблема "упрямства", когда план продолжает выполняться в явно неадекватной обстановке - вот зачем понадобились "ассоциированные логические цепочки".

4. Вы задумывались, а видит ли игрок все эти рейды, атаки, передислокации, и пр? ИМХО, когда я играю в стратегии, для меня это не видно. Все, на что обычно я обращаю внимание, это копит ли враг на базе юниты, и атакует ли он меня. Все остальное для меня не имеет особого значения.
Задумывался. Что-то об этом сказано в тексте ниже. К этому еще добавлю, что "рейды" и "передислокации" упомянуты только в качестве удобных примеров. На самом деле эта система дает большой выигрыш и в реализации куда более важного и банального поведения, например, "swarm to position", "патрулировать", "собирать ресурсы" или "атаковать базу противника". Преимущество не столько в том, что AI становится "умнее", сколько в том, что он перестает совершать совсем бредовые действия a la "маршировать, упершись в стенку лбом". Исправление багов становится проще и быстрее.

Рекомендации для гейм-дизайнеров

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

Диктуйте, «что» сделать, а не «как»
Программистам надо рассказать, какой результат хочется получить, но не более того. Это правило всегда казалось мне настолько очевидным, что очередное его нарушение каждый раз приводит меня в ступор. Более того, даже если конечное поведение может немного меняться в зависимости от способа реализации, все равно не нужно описывать его «от и до», достаточно объяснить требования к нему.

Что касается разработки AI, это правило можно сформулировать так: ставя задачу программисту, объясняйте только, какое поведение вы хотите получить, а не каким способом. Например, задача «AI должен уметь окружать и заходить во фланг» сформулирована верно, а задача «Сделать AI-генерала», «Применить нечеткую логику» или «Перебирать глубже, чем на один ход» - неверно. Почему-то именно гейм-дизайнеры, ранее работавшие программистами, чаще всего допускают подобные ошибки.

К этому же пункту относятся и оценки времени программистских задач, которые дизайнеры пытаются сделать за нас (например, слова «ну что вам стоит, это же просто»). Очень может быть, что это не просто. Если бы дизайнеры знали, как именно устроен код, и что именно нужно сделать, они бы поняли, почему. До тех пор, пока они не знают, следует спрашивать оценки задач у программистов до того, как состояние их дизайна изменится на «все уже решено, выполняйте».

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

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

1. Часто встречаются миниигры типа «игра на бирже». Игрок управляет некоторым «пакетом» ресурсов, которые может распределять в разной пропорции для выполнения задач разного вида. Примером может служить распределение ресурсов планеты в Master Of Orion. Не нужно реализовывать в полном объеме работу AI с такой миниигрой - это лишняя работа, игроку она все равно видна не будет. Для AI ее лучше заменить небольшим гандикапом во всех ресурсах и считать, что он всегда выбирает некоторую «усредненную стратегию».

2. Часто встречаются миниигры типа «работа с инвентарем». Типичные примеры - MMORPG, серия Diablo. На нашем опыте можно сказать, что «честная» работа AI с инвентарем игроку не видна, вместе с тем приносит множество проблем.

Вот типичная проблема, подобные которой в Silent Storm возникали постоянно: AI пытается сменить стрелковое оружие на гранату, но не может это сделать, так как старое оружие не помещается «в рюкзак». О такой возможности заранее никто не подумал, поэтому он не пытается выкидывать лишние вещи на землю или проделывать аналогичные действия. В итоге AI остается со старым оружием и ничего не делает, передав свой ход следующему солдату. С точки зрения игрока, не знающего о его затруднениях, данный солдат почему-то ничего не сделал, хотя мог и выстрелить, и бросить гранату.

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

Похожие проблемы доставляла система поломки, заклинивания и починки оружия. Точно так же, идеальным решением было бы «оружие у AI никогда не ломается, никогда не изнашивается, но чаще делает осечки» (осечка с точки зрения игровой механики Silent Storm принципиально отличается от заклинивания или поломки тем, что оружие после нее не требуется чинить специальным образом).

3. Перегруппировка невидимых игроку юнитов. Многие тактические маневры требуют специальной перегруппировки войск: например, «толстые воины спереди, хилые маги позади». Перегруппировка - очень сложный в реализации, муторный и вычислительно опасный маневр, требующий многократных вызовов pathfinding и pathtracking на узком участке. Такой «маневр» может легко привести к падению производительности или провалиться по тысяче разных причин. Можно сделать подобную перегруппировку мгновенной (в виде «массовой телепортации»), если игрок не видит ни одного из перегруппируемых, и производить не раньше, чем через сколько-то секунд после того, как игрок потерял из виду последний unit группы. Это существенно проще и безопаснее, чем описывать соответствующую логику «честно».

4. Повреждения, получаемые союзниками от area-effect attacks, могут быть ниже для AI, чем для человека. Этот пункт, собственно, не нуждается в дополнительных объяснениях - нельзя карать AI за ошибки, которые совершает даже человек, от рождения обладающий мощнейшим «геометрическим вычислителем», при выполнении узкоспециализированных «геометрических» задач существенно превосходящим по своим возможностям современные микропроцессоры.

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

Рекомендации для программистов

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

Не увлекайтесь высокими технологиями
Не увлекайтесь высокими технологиями, и тем более не используйте проект как полигон для своих научных разработок. Правильно применить любую новую технологию - нелегкое и очень рискованное дело. Это имеет смысл только в том случае, когда она в итоге становится главной отличительной чертой проекта (например, 3D-картинка в первых шутерах от id software) и при этом результаты ее работы хорошо заметны конечному пользователю. Я имею в виду действительно хорошо заметны: их должно быть можно заметить в короткий момент принятия решения «куплю ли я коробку с игрой» - по паре скриншотов, описанию игры на коробке, максимум - по демонстрационному ролику. Если вы не собираетесь делать AI-технологию такой отличительной чертой (а лично я не представляю себе, как это хотя бы принципиально возможно), то не используйте в нем «наукоемких», неочевидных для понимания и воплощения технологий.

Забудьте про самообучение
Хорошие, предсказуемые, отработанные технологии самообучения появятся в лучшем случае только к концу десятилетия (2007: afaik, пока не появились). Какие-то есть уже сейчас, но они пригодны только для весьма специфических задач, которые в игровом AI не встречаются. Чтобы применить генетические алгоритмы, нейронные сети, или теорию марковских цепей, прежде всего, нужны определенным образом подготовленные вход и выход. И преобразовать хотя бы часть игровой информации в такой вид, а тем более правильно построить процесс обучения и интерпретировать выход, безумно сложно.

Более того, самообучение на самом-то деле не стоит не только таких усилий, оно не стоит никаких. Самообучение попросту не нужно почти никому из будущих игроков. Из него сложно сделать даже wow-фактор, не говоря уже о major feature.

Сделайте систему визуального мониторинга AI
Система визуального мониторинга состояния AI должна быть готова практически с самого начала проекта. Вы должны в любой момент времени, не выходя из игры, уметь посмотреть, какой логикой он сейчас пользуется, что у него «на уме», какова, по его мнению ситуация, какие «планы» включены для выделенного набора войск. Это существенно сократит время и силы, нужные для поиска ошибок. Без этого процесс bugfixing’a для AI отличается крайней трудоемкостью и муторностью. Причем чем больше информации вам будет видно, тем лучше - верхней грани практически не существует.

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

Слово «видно» также очень важно. То, что вы можете прочитать или, тем более понять, исходя из доступных данных, дает вам гораздо меньше информации, чем то, что вы можете увидеть. Так уж устроен человеческий мозг. Поэтому вместо сообщения «А движется в точку (X,Y)» гораздо правильнее выводить прямую, соединяющую А и точку (Х,У), причем варьировать ее цвет в зависимости от того, зачем он туда едет.

Основные производственные циклы. Действия гейм-дизайнеров, программистов и тестировщиков

2007: Ниже следует очень примерное описание. Любой реальный проект будет идти по-своему по тем или иным причинам (в основном из-за влияния квалификации и привычек сотрудников, а также использования разного legacy code). Не нужно этого бояться.

Создание основы
Этот набор действий вам придется сделать один раз за время разработки игры.

1. Создание общей архитектуры AI. Задача для technical lead, поскольку качество ее решения довольно критично. При ее выполнении важно сразу заложить основы системы визуального поиска ошибок, скрыть источники управления, реализовать парадигму «плана», сделать систему установки/запрещения планов.

2. Формулировка правил, характеризующих «минимальное поведение». Задача должна выполняться гейм-дизайнером. Ни в коем случае нельзя перекладывать ее на программистов, т.к. в тот момент, когда она должна выполняться, гейм-дизайнеры обладают гораздо большей информацией об игре, нежели программисты.

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

3. Реализация «минимального поведения». Задача, естественно, для программистов. При ее выполнении важно реализовать простой «переключатель»: «использовать только минимальное поведение (т.е. запретить все «планы»)». Это очень пригодится для последующего тестирования.

4. Тестирование и уточнение «минимального поведения». Задача общая для гейм-дизайнеров и тестировщиков игры. На этом этапе в первоначальный набор может добавиться одно-два новых простых правила. Если хочется добавить больше, чем 1-2 правила, или новые правила оказываются сложными, то эти правила надо выделить в отдельный план.

5. Внесение изменений программистами.

Осуществление игровой возможности (feature implementing)
Предположим, что гейм-дизайнеры придумали новую игровую возможность (или игровую механику). Назовем эту новую возможность Х. Например, это может быть новое заклинание, новая «спецвозможность» или новая миниигра. Обучение AI работе с этой возможностью, можно разделить на 3 этапа.

1 этап. Научить AI защищаться от Х, применяемого игроком. То есть, постоянное применение Х игроком не должно вести к его практически гарантированному выигрышу. Это общая задача как дизайнеров, так и программистов. Если разделить все задачи AI, связанные с новой игровой механикой, по удельной важности (иначе говоря. по влиянию на мнение игрока об игре), то на этот этап придется 60% важности.

2 этап. Научить AI хотя бы иногда и хотя бы случайным образом использовать возможность Х. На этот этап придется около 30% важности.

3 этап. Научить AI не просто использовать Х, но делать это «к месту». Это самая интересная и самая сложная из AI-задач, связанных с новой механикой, но увы, на нее приходится не более 10% важности. Вам следует вообще приступать к этому этапу только в том случае, если вы серьезно намерены сделать AI одной из основных features вашего проекта, а Х является важной частью игровой механики.

Набор действий по обучению AI новой игровой возможности вам придется выполнить порядка 30 раз за игру. 2007: Конечно, сильно зависит от масштаба - но порядок действительно такой, проверено.

Создание нового тактического приема, стратегии
Этот набор действий вам придется выполнить порядка 20 раз за игру. 2007: Неверно. Если все продумано как следует, 20 больших превращается в 100 маленьких, которые можно гибко комбинировать, и которые, фактически, являют собой некий domain specific language.

1. Дизайнер, программист, тестер придумывает (маневр/план/логику), и вкратце формулирует ассоциированную логическую цепочку. Важно понимать, что новый тактический прием нужно вводить только в том случае, если он будет явно заметен игроку. Важно сразу продумать, почему игрок увидит и поймет, что AI использовал этот прием, и сделать все для того, чтобы он сказал: «Вау». Важно также положить описание плана и ассоциированную логическую цепочку в некоторое место, где на них все заинтересованные лица (программист, QA, дизайнер) могут посмотреть и внести изменения. Например, в систему учета задач или на закрытую для посторонних область сайта проекта. Правило: чем подробнее описание, тем лучше.

2. Программист реализует логику маневра и делает возможным его запрещение и явную установку для выбранных юнитов или всего AI из редактора или скрипта.

3. Программист реализует «логическую цепочку», по возможности дополняя ее и соответственно изменяя ее описание.

Выявление и исправление ошибки
Этот набор действий вам придется выполнить порядка сотни раз за игру. Важно правильно распределить время между двумя методами тестирования: тестированием игры «в целом» (ощущения от игры, наличия явных ошибок или «глупостей») и тестированием определенной логики (т.е. проверкой соответствия спецификациям). Нельзя игнорировать ни тот, ни другой метод. По моему мнению, время между ними должно быть распределено примерно как 30% : 70%.

1. Тестер встречает явно глупое поведение AI, и смотрит, какую логику тот в данный момент использует.

2. Тестер читает описание «логической цепочки», и делает предварительный вывод: где ошибка – в цепочке или в ее реализации?

3. Свои выводы он отсылает программисту.

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

Заключение

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

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

Tags: ,

Comments:

From:(Anonymous)
Date:Август 30, 2007 05:34 pm
(Link)
Плахов! Всегда думал что компьютер жульничает - а теперь убедился в этом - нет в мире совершенства :)
(Ответить) (Thread)
[User Picture]
From:_winnie
Date:Август 31, 2007 01:04 am
(Link)
Я как геймер замечу, что рекомендации по оптимизации хороши для "campaign"-игры, но в meelee/deathmatch вызовет справедливые обвинения в читерстве.
(Ответить) (Thread)
[User Picture]
From:plakhov
Date:Август 31, 2007 06:38 am
(Link)
Да, я тоже хотел об этом написать подробнее, но абзац и так оказался безумно раздут по сравнению со своей значимостью.
(Ответить) (Parent) (Thread)
From:(Anonymous)
Date:Август 31, 2007 08:05 am
(Link)
На самом деле, все описания "частного" в отрыве от "целого" по определению грешат узостью применимости. Это нормально, так и должно быть. В докладе возможно стоило более четко указать область применения статьи (подобная тема была и на gamedezigner, с той же шириной охвата). На самом деле в большинстве игр АИ вообще не нужен, никакой, ни жульнический, ни отдающийся, ни честный, ни умный. Боты для мультиплейеа должны хотя бы уметь быть "честными", изображая лишь вероятность человеческой ошибки, и тд - дополнять можно долго.
Статья хорошая

Todace, пароль на работе
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Август 31, 2007 08:28 am
(Link)
Ну, вроде бы в названии написано "стратегических". Я плохо представляю себе мейнстримовую RTS или TBS совсем без AI.
(Ответить) (Parent) (Thread)
From:todace
Date:Август 31, 2007 12:01 pm
(Link)
* Чисто мультиплейерная (не знаю, есть ли мейнстримовы такие, но это вопрос времени).
* сеттлеры какиенибудь

Примеры еще могут найтись, но мейнстримовые, впрочем, вряд ли.
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Август 31, 2007 12:10 pm
(Link)
Я уже плохо помню "Сеттлеров", и играл только пару миссий, но подозреваю, что AI там есть, и еще какой. Просто он тобой не воспринимается. Вот эта вся believable "реальная жизнь" маленькой деревни - ее не очень просто сделать. Хотя, опять же, не помню, как это было сделано там. Все советы доклада к такому AI тоже относятся. Вообще, вот эта имитация жизни, по моим текущим представлениям, главная и самая полезная задача игрового AI (куда важнее, чем игра против игрока).
(Ответить) (Parent) (Thread)
[User Picture]
From:faceted_jacinth
Date:Сентябрь 1, 2007 07:52 pm
(Link)
Зацепился за фразу
Более того, самообучение на самом-то деле не стоит не только таких усилий, оно не стоит никаких. Самообучение попросту не нужно почти никому из будущих игроков. Из него сложно сделать даже wow-фактор, не говоря уже о major feature.
... и вот почему: когда-то давно я проходил ку3 первый раз в жизни. При этом я довольно хорошо играл в ку1 и ку2 десматч. И очень мне тяжело было почему-то завалить Уриэля, который на карте с жолтым туманчегом. Комп тормозил ли, мышка была говнологитеховская лазерная ли, ракеты непривычно быстро/медленно летали и доставляли маленький радиус разрыва ли -- уже и не помню. В какой-то момент, со счётом порядка 7-1 в его пользу, я отчаялся и зарокетджампился на стеночку центральной комнаты. И замочил уриэля восемь раз подряд. А потом он меня ещё три. "Окей" -- подумал я, -- "сейчас я взопрыгну туда с самого начала и доставлю вин!"

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

Это был офигительный элемент геймплея. Даже если его на самом деле и не было -- я в результате нашёл Тезис разработчика АИ ку3шных ботов, внимательно прочитал, дико интересно и тебе, наверное, тоже было бы, но там ни слова про повышенное внимание к определённым локациям не было, хотя совершенно очевидно, что поверх той структуры его как нефиг заимплементить (и, может, оно таки есть, просто про него не написано). Так вот, тем не менее, даже иллюзия обучаемости оппонента доставляет с абсолютно нереальной силой, честно. Потому что обучаемость -- это и есть основное свойство человека, любой игрок в принципе понимает, что играет с тупой железкой, даже если она умеет хитроумно обходить его с флангов, а вот когда эта железка вдруг жостко обламывает его свежепридуманную стратегию, тогда она уже не железка совсем, тогда она Оппонент, победой над которым можно гордиться, и играть с которым можно вечно (replayability++, хотя она с точки зрения маркетинга скорее вредна, чем полезна, нет?).
(Ответить) (Thread)
[User Picture]
From:faceted_jacinth
Date:Сентябрь 1, 2007 07:56 pm
(Link)
Да, интересные цифры:
The 1st and 2nd layers of bot AI code is about 33.7 kilo lines of code (KLOC). The 3rd and 4th layer of bot AI code is about 16.1 KLOC. All the bot AI code together accounts for about 25% of all the code in Quake III Arena that is used at run time.

Причём 3ий и 4ый слои написаны на специальном языке и интерпретируемы, а есть ещё и behind-the-scene код, при помощи которого генетическими алгоритмами оттачивалась fuzzy logic.
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Сентябрь 4, 2007 01:10 pm
(Link)
Ну я эту фразу не просто так написал, так что наверное правильно, что ты за нее зацепился =)

Диссер этот я читал, и давно, и считаю его (как inspiration и тем более как источник практик) крайне вредным. Тут вот какое дело. Q3 в некотором смысле уникален. Кармак откуда-то умудрился найти этого J.M.P. (на самом деле известно откуда - разработчика лучшего стороннего бота к какой-то из прошлых частей, не помню точнее, я в Quake не играл), а тому как раз надо было писать диссертацию. И человек, даже afaik не работая официально в id software, писал "высоконаучный код" 12 часов в сутки в течение всего проекта, и у них все получилось. На самом деле 25% AI кода в AAA-шутере, причем шутере мультиплеерном, это невозможное, невообразимое количество, "так не бывает". Это чудовищный overkill. Все это в тексте не акцентируется (что понятно, это диссертация как-никак).

Это - уникумы. Don't try this at home, не получится, проект так и не выйдет, компания разорится. Я серьезно.

Хотя, естественно, шедевр без нарушения каких-то правил, и без сверхусилий не получится. Realtime 3d до Кармака вообще считали невозможным. =)

Ну и - тебе не приходило в голову, что ты получаешь фан совсем от других вещей, нежели 95% населения? Любимая призказка нивальских дизайнеров - "AI должен красиво отдаваться". Ситуация, когда игрок никак не может пройти определенную стадию, потому что сложность растет со временем, прямо запрещена стандартами многих разработчиков (тот же Нивал) и многих издателей (CDV например).
(Ответить) (Parent) (Thread)
[User Picture]
From:bwolf33
Date:Сентябрь 9, 2014 03:50 pm
(Link)
Прочитал все три части. Довольно много для себя почерпнул, в особенности про планирование поведения ИИ. Я только начал в суть игростроя вникать, но делать однокнопочные игрушки нет желания. Тем более игровой опыт и логика позволяют сделать что то более сложное, чем передвижение кубиков или примитивную TD. А такие статьи, где кратно и по делу излагают нужные вещи очень сложно найти. Очень Вам благодарен за труд :). Если есть еще интересные статьи, то с удовольствием почитаю.

Edited at 2014-09-09 15:57 (UTC)
(Ответить) (Thread)