?

Log in

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

авг. 9, 2007

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

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

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

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

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

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

Введение

Привет, меня зовут Андрей Плахов, и я работаю в компании «Nival Interactive» ведущим программистом проекта «Silent Storm: Часовые», адд-она к проекту «Операция Silent Storm» (уже давно работаю не там и не над тем). Мой доклад называется «Организация разработки AI в стратегических компьютерных играх».

Есть некоторые разночтения в понимании аббревиатуры «AI» (искусственный интеллект), когда речь идет об играх. Так, на прошлой КРИ читался доклад, подготовленный Алексеем Осипенко из компании «Бука», в котором слово AI понималось скорее в том значении, в котором в компании «Нивал» понимаются словосочетания «игровая механика» или «игровая логика». Очень часто к AI относят также механизмы поиска пути и следования по найденному пути - pathfinding и pathtracking (и правильно относят, нечего их разделять).

В моем докладе я этого делать не буду. Произнося слово AI, я буду иметь в виду исключительно только механизм, при помощи которого формируются команды, отдаваемые компьютерным игроком - то есть то, на что заменяется input, если переходить от игрока-человека к компьютерному сопернику. И доклад посвящен исключительно только разработке этого механизма.

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

Довольно большая часть доклада будет посвящена опыту, полученному в ходе проектов Silent Storm и Silent Storm: Sentinels, поэтому я буду рад, если Вы играли в эти игры, или знаете, что они собой представляют. Если Вы не знаете, на что они похожи, возможно, Вам поможет перечисление аналогичных проектов: известная серия Jagged Alliance, не менее известная серия X-Com (UFO), игра Fallout Tactics, а также русская игра «Код доступа: Рай». Надо отметить, что игры серии Silent Storm отличаются от вышеперечисленных большим количеством возможностей игровой механики со сложно просчитываемыми результатами. Например, все здания и объекты в игре могут быть разрушены. Полет пуль, гранат, снарядов и то, видит ли один персонаж другого, просчитывается в 3d с учетом всех препятствий. Все это, естественно, приводит в том числе и к усложнению AI.

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

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

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

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

Теперь о том, чего не будет в докладе
Я не буду рассказывать о нейронных сетях, генетических алгоритмах, цепях Маркова и прочих принятых парадигмах самообучения. Это связано с тем, что, по нашим данным, в компьютерных играх данные техники не оправдывают себя - результаты, полученные с помощью них, малопредсказуемы, и не обладают какими-либо важными преимуществами. Примерно по тем же причинам речь не пойдет ни о языках Lisp, ПРОЛОГ (в 2007 году я совсем не так уверен насчет Lisp'а), ни о нечеткой логике.

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

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

Эволюция парадигм AI в проекте Silent Storm

Эволюция архитектуры и основных идей AI в Silent Storm изложу достаточно кратко и во многом упрощенно, иначе это займет слишком много времени

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

Просчет пар «позиция-действие». После этого мы перешли к просчету вариантов действий только на текущем ходу, при этом действия выбирались на основе весовых коэффициентов, определяемых сначала «нечеткой логикой», затем распознавателем паттернов действий игрока, а также при помощи прочих «продвинутых» методик. При выборе нужного действия определенный вес придавался каждой паре «позиция – действие», и из них выбиралась пара, отвечающая наибольшему коэффициенту, например, «бежать в точку (3:12) и кидать оттуда гранату в точку (3,22)». Основной проблемой при использовании такой архитектуры стала сложность реализации требований дизайнеров. Настройкой весовых коэффициентов сложно, а иногда и невозможно реализовать правила «общего характера». Например, для реализации правила «всегда, когда видишь группу близко стоящих персонажей, кидай в них гранату» пришлось бы менять коэффициенты «на лету» в зависимости от того, стоит ли часть видимых врагов группой. А ведь есть и такие логики, как «отступить» или «выйти из-за укрытия - выстрелить - зайти обратно», требующие определенных действий в течение нескольких последовательных ходов. При использовании просчета пар «позиция-действие» реализовать становилось почти невозможно (во всяком случае, громоздко и запутанно).

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

Иерархия «Реакции → логики → действия». Иерархия «логики→действия» решала многие проблемы, но оставалась проблема правильной смены логик. Все «тактические приемы» (искать врага по звуку, патрулировать, залечь, спрятаться за препятствие, использовать стационарный пулемет и т.п.) естественно реализовать при помощи отдельных логик. Но как в этом случае реализовать то, что персонаж «боится», «паникует», «охраняет»? Если сделать это некоторой логикой, то он либо не сможет использовать никакие «тактические приемы», либо нужно где-то хранить, что после окончания логики, соответствующей данному «тактическому приему», необходимо вновь сменить логику на предыдущую. Естественным образом мы пришли к тому, что механизмы смены логик стали самостоятельными сущностями, которые были названы «реакциями». Итак, схема стала выглядеть так: реакция определяет текущую логику, которая определяет текущие действия. При этом для вынесения общей части всех реакций персонаж обладает «AI-состоянием», которое реализует память о происходивших с ним событиях и хранит информацию, которая может быть необходима всем или нескольким реакциям.

На этом этапе, в общем и целом, развитие AI в Silent Storm прекратилось. Мы получили несколько важных уроков.

Проблемы

Главные проблемы, возникшие при разработке и тестировании AI в Silent Storm и Silent Storm: Sentinels. Я расскажу о них потому, что они вовсе не специфичны для наших проектов. В той или иной степени они встречаются при разработке любой игры стратегического жанра. И следующие части доклада будут посвящены тому, как от них избавиться выбором правильной архитектуры AI и налаживанием правильной технологической цепочки между программистами, дизайнерами и тестерами.

Затрудненный tracing и bugfixing причин, приведших к явно неверному поведению AI. В ходе тестирования игры обнаруживается ситуация, в которой AI повел себя глупо. Но как узнать, где ошибка? В момент ее непосредственного проявления настоящая причина, как правило, давно осталась позади. Даже если сохранился save с подобной ситуацией, или она может быть воспроизведена, понять, в чем причина, бывает сложно и часто требует часов внимательного tracing'a исходного кода игры.

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

Отсутствие предсказуемости, затрудненная реализация сценария. При наличии разветвленной системы «реакция→логика→действие», в которой есть несколько типов реакций, пара десятков логик и множество типов действий, сложно предсказать, как поведут себя бойцы AI в том или ином случае. Это сильно ухудшает предсказуемость gameplay'a на различных зонах игры, усложняет скрипты, а также может повлиять на сценарий неожиданным (и чаще всего абсурдным) образом. Пара примеров:
  • Отважный товарищ главного героя, по сюжету сражающийся с ним рука об руку, наплевательски относится к своим обязанностям и сидит в подвале, думая, что его убьют, если он выйдет наружу (хотя, согласно сюжету, главный герой его в любом случае «спасет»).
  • На определенной зоне определенным войскам крайне сложно отдать приказ «не отходить от стационарных пулеметов» (что требуется по задумке), так как то одна, то другая логика все же заставляют их это сделать. Если механически запретить им выполнять любые команды, кроме «стрелять из пулемета», но не запретить их отдавать, такие персонажи вобще перестанут что-либо делать (потому что, как правило, действия, которые им «хочется» выполнить, будут запрещены).
Подобные проблемы непредсказуемости возникали и возникают постоянно.

«Зависания» AI. Эта проблема специфична для походовых игр (то есть, в RTS она не может возникнуть) и заключается в том, что AI в некоторых ситуациях никогда не отдавал команды «конец хода» (вечно удерживал ход). Типичный способ возникновения «зависания» таков: AI отдает команду, которую unit не может выполнить или на выполнение которой он тратит 0 action points (action points - это игровой механизм в turn-based играх, регулирующий максимальное количество действий, выполняемых персонажем за его ход). Игра запрашивает следующую команду для данног unit'a. Она оказывается той же, т.к. AI-состояние unit'a не изменилось. Так и продолжается в вечном цикле.

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

Проблемы, присущие многим другим реализациям AI в играх
Silent Storm явно не является единственной игрой, при реализации AI в которой были допущены ошибки. Достаточно вспомнить классические примеры неверного поведения AI в других играх, даже AAA-класса. Возьмем, например, StarCraft - возможно, лучшую игру жанра realtime strategy.

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

Пример применения логики в неподходящей ситуации. Хороший пример того, что данная ошибка неспецифична для Silent Storm - погоня «крестьян», управляемых AI, за разведывательным юнитом вплоть до их бесславной кончины (в StarCraft это позволяло уничтожить 4 компьютерных соперников на маленькой карте, не потеряв ни одного своего бойца). Другой пример - строительство строения shipyard на картах, лишенных воды (эта нелогичность встречается во многих играх).

Tags: ,

Comments:

From:314159265
Date:Август 9, 2007 06:22 pm
(Link)
Очень интересно. В том числе тем, кто от геймдева далеко (как я). Близко к ситуации, когда работа ведется в режиме waterfall, а требования и feedback получается в режиме agile[1].

[1] Как это на русском нормально принято называть... черт его знает.
(Ответить) (Thread)
[User Picture]
From:plakhov
Date:Август 10, 2007 07:05 am
(Link)
К сожалению, об этом будет не очень много, большая часть текста все-таки про абсолютно unreliable окружение.
(Ответить) (Parent) (Thread)
From:(Anonymous)
Date:Август 9, 2007 06:24 pm
(Link)
Примерно по тем же причинам речь не пойдет ни о языках Lisp, ПРОЛОГ (в 2007 году я совсем не так уверен насчет Lisp'а), ни о нечеткой логике
А что сейчас изменилось с Lisp'ом? И с какими именно из его диалектов? И почему здесь вообще Лисп упоминается? Объясни пожалуйста, каким образом Лисп облегчает данный кусок работы в сравнении с Прологом, к примеру. Code is data paradigm (если да, то как)? Структуры данных (если да, то почему не Haskell какой-нибудь)?
(Ответить) (Thread)
[User Picture]
From:plakhov
Date:Август 10, 2007 06:41 am
(Link)
Изначально Lisp упоминался потому, что всю жизнь являлся главным ЯП в "большом AI".

Сейчас мне кажется, что в организации AI кода объектно-ориентированные способы хромают. Действительно, как вы и предположили, не хватает возможности работать с одной и той же сущностью и как с логикой, и как с данными. То, что в С++ нет coroutines, писать AI страшно мешает - последовательная по своей сути логика превращается в класс, устроенный как state mashine. Ну и вообще state machines на ОО-языках писать умучаешься. Closures тоже были бы хороши, а то на каждый чих приходится классы заводить. Паттерн "команда" приходится использовать, а в нормальных языках он просто не нужен - исполняемые данные могут где нужно интерпретироваться как команда к их исполнению.

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

Известен и как минимум один success story, вот тут, например: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
(Ответить) (Parent) (Thread)
From:peeplevarreh
Date:Август 10, 2007 08:06 am
(Link)
C++ - не OO-язык. Он мультипарадигменный.

Success story какая-то странная. По всему получается, что ребята были бы рады интерпретатору C++, но не нашли.

Увидишь Грэма - не трогай его, он мой:)
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Август 10, 2007 08:23 am
(Link)
Забей на терминологию. Мультипарадигменный или нет, а cредство для virtual binding одно - классы, виртуальные методы и их наследование. Ну не считать же таковым указатели на функции.

Самый крутой интерпретатор С++ все равно будет не так хорош для горячей замены кода из-за статической типизации. Кроме того, я боюсь предположить, сколько ЭТО будет жрать памяти. Вот почему им Lua для тех же целей не хватило - не знаю. Нам хватило :)
(Ответить) (Parent) (Thread)
From:peeplevarreh
Date:Август 10, 2007 11:39 am
(Link)
Сначала не было Lua, видать:) Потом было уже поздно:)
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Август 10, 2007 11:45 am
(Link)
Да ладно тебе, Lua старше, чем Java :)
(Ответить) (Parent) (Thread)
[User Picture]
From:ufonaut
Date:Август 10, 2007 12:32 pm
(Link)
У нас "вся игра" (AI выше pathfinder'а и куклы с анимацией, логические объекты, оружие и пр.) на Lua - есть проблемы с производительностью и памятью.
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Август 10, 2007 01:01 pm
(Link)
У, круто! Мы, конечно, не отваживались на такое. У нас на Lua какое-то время писались слои, которые еще все время меняются, и потому рано писать на С(++). Сейчас дизайн устаканился, и Lua вообще не используется, но к концу, наверное, какие-то скрипты на ней опять появятся. А напишешь подробнее у себя, как вообще все у вас прошло с Lua? А я пропиарю :)
(Ответить) (Parent) (Thread)
[User Picture]
From:ufonaut
Date:Август 10, 2007 01:12 pm
(Link)
Думаю, напишу мини-постмортем по этой части.
(Ответить) (Parent) (Thread)
From:(Anonymous)
Date:Ноябрь 15, 2007 06:55 pm
(Link)
ping :)
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Апрель 8, 2008 08:39 am
(Link)
ping =)
(Ответить) (Parent) (Thread)
From:peeplevarreh
Date:Август 10, 2007 01:02 pm
(Link)
Пойнт их "lisp'а" в том, что у них есть и интерпретатор, и компилятор. Интерпретатор еще и переносимый.
(Ответить) (Parent) (Thread)
From:peeplevarreh
Date:Август 10, 2007 01:00 pm
(Link)
Ну, ребята Lisp использовали с 1992, тоже до Явы.
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Август 10, 2007 01:02 pm
(Link)
А, да, правда.
Мне почему-то казалось, что это недавно было, а это и впрямь девяностые...
(Ответить) (Parent) (Thread)
From:peeplevarreh
Date:Август 10, 2007 01:18 pm

Серебряной пули нет:)

(Link)
1. GOAL sucks! While it's true that GOAL gave us many advantages, GOAL caused us a lot of grief. A single programmer (who could easily be one of the top ten Lisp programmers in the world) wrote GOAL. While he called his Lisp techniques and programming practices "revolutionary," others referred to them as "code encryption," since only he could understand them. Because of this, all of the support, bug fixes, feature enhancements, and optimizations had to come from one person, creating quite a bottleneck. Also, it took over a year to develop the compiler, during which time the other programmers had to make do with missing features, odd quirks, and numerous bugs.

Eventually GOAL became much more robust, but even now C++ has some advantages over GOAL, such as destructors, better constructors, and the ease of declaring inline methods.
A major difficulty was that we worked in such isolation from the rest of the world. We gave up third-party development tools such as profilers and debuggers, and we gave up existing libraries, including code previously developed internally. Compared to the thousands of programmers with many years of C++ experience, there are relatively few programmers with Lisp experience, and no programmers (outside of Naughty Dog) with GOAL experience, making hiring more difficult.

GOAL's ability both to execute code at the listener and to replace existing code in the game at run time introduced the problem of memory usage, and more specifically, garbage collection. As new code was compiled, older code (and other memory used by the compiler) was orphaned, eventually causing the PC to run low on free memory. A slow garbage collection process would automatically occur when available memory became sufficiently low, and the compiler would be unresponsive until the process had completed, sometimes taking as long as 15 minutes.
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Август 10, 2007 01:20 pm

Re: Holywar-holywar, yahoo!!

(Link)
Я это читал.
(Ответить) (Parent) (Thread)
From:peeplevarreh
Date:Август 10, 2007 01:43 pm

Re: Holywar-holywar, yahoo!!

(Link)
Да нет, не холиво. Просто анти-ПЕАР :)
Что сделали yahoo, купив ViaWeb? Правильно, выкинули все, что на Lisp . C Naughty dogs - то же самое сделали SCE.
Сваять на коленке что-то, что можно впарить - это одно. Продукт сделать - совсем другое. По старым оценкам - раз в 9 сложнее:)
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Август 10, 2007 01:50 pm

Re: Holywar-holywar, yahoo!!

(Link)
Это и есть holy war. Твоя позиция звучит даже в выборе слов ("сваять на коленке, чтобы впарить" vs "продукт").

Думаю, выбор между mainstream'ом и high epic'ом делался скорее между "гарантированно за 9x" vs "рискованно за 1х". А качество итогового продукта тут ни при чем.
(Ответить) (Parent) (Thread)
From:peeplevarreh
Date:Август 10, 2007 02:02 pm

Re: Holywar-holywar, yahoo!!

(Link)
Да не, это жизнь, а не holy war, к сожалению:(

Но от темы мы и правда как-то отклонились.
(Ответить) (Parent) (Thread)
[User Picture]
From:plakhov
Date:Август 10, 2007 06:45 am
(Link)
С Прологом все проще - я просто не знаю, где его можно тут использовать :)

Почему не Haskell - потому что чисто функциональный язык тут не подходит. Явным образом хранимое и mutable состояние естественным образом присутствует в самой задаче (для AI есть "внешний мир"). А я не знаю Haskell как Simon Peyton Jones, чтобы говорить, что "Haskell is world's best imperative language", и боюсь, его мало кто так знает.
(Ответить) (Parent) (Thread)
From:(Anonymous)
Date:Август 10, 2007 10:09 am
(Link)
Не думаю, что стóит так преувеличивать, всё-таки там вся императивность находиться в рамках стандарта Haskell98, который сам по себе сравнительно гладок и постигаем простыми смертными. Основные навороты уже идут именно как GHC extensions (всё те же Саймоны в деле, да) в области системы типов, не особо понимаю, как это делает Хаскель более императивным.

В целом ведь императивщина, насколько известно на мой холопский ум, лежит в IO и State монадах, которые можно прокидывать с клозурами, комбинировать и проч., что действительно делает даже голую императивщину местами короче, чем в честно-императивных язычках. Если правильно готовить, естественно. Но это мне доступно, а уж всем остальным и подавно.
(Ответить) (Parent) (Thread)
[User Picture]
From:steel_monster
Date:Август 9, 2007 08:06 pm
(Link)
Был. Слышал.
(Ответить) (Thread)
[User Picture]
From:sim0nsays
Date:Август 9, 2007 08:39 pm
(Link)
Здорово, отлично рассказываешь. Пеши исчо!
(Ответить) (Thread)
[User Picture]
From:ex_wat364
Date:Август 9, 2007 09:02 pm
(Link)
> оказывается, в сети его нигде нет, а жаль
гэймдэвру хорошее место для сохранения, если надо. :)
(Ответить) (Thread)
[User Picture]
From:ufonaut
Date:Август 10, 2007 07:53 am
(Link)
Очень жизненно!
У нас проблемы схожие были, несмотря на различие жанров (у нас шутер).
Ждём продолжения..
(Ответить) (Thread)
[User Picture]
From:sergemi
Date:Сентябрь 26, 2007 09:27 am
(Link)
сейчас я бы уже мог рассказать, как изложенные решения меняются с учетом жестко ограниченной памяти и быстродействия Nintendo DS или наоборот, с учетом нагрузки масштабной ММО - думаю, многих бы это заинтересовало

Кстати по поводу Nintendo DS действительно очень интересно.
(Ответить) (Thread)