xmoonlight, на самом деле я имел в виду более сложные ситуации. Например, игрок идет срывать яблоко. NPC тоже хочет яблоко, но видит, что не успевает раньше игрока. Тогда он меняет направление и идет к другой яблоне, которая дальше, и яблоки на ней мельче, но шанс их заполучить в разы больше. Как-то так.
Суть в том, что конкретно для этой ситуации можно было бы написать простой скрипт. Но всевозможных ситуаций может быть бесконечно много. ИИ должен быть таким, что на вход даются какой-то заранее неизвестный набор условий и возможных действий, а на выходе - конкретное разумное решение.
И не должно быть ситуаций, когда игрок идет то к яблоне, то от нее, а ИИ при этом также мечется туда-сюда. Выглядит это глупо, ни разу не разумно и не человечно. Игрок может легко прощупать закриптованность поведения серией экспериментов, и дальше ему уже не интересно. Это либо абьюз ИИ игроком, что скучно, либо ИИ совершает большую глупость, что вызывает только раздражение от игры в целом. То есть ИИ должен быть настолько гибким, чтобы менять своё поведения в тех же рамках, в каких бы это сделал человек.
xmoonlight, естественно, он есть. Предположим, действий 1000 шт., часть из которых известны ИИ сразу, а другие действия могут стать доступны для ИИ позже.
xmoonlight,
2d, 3d, сеттинг, метео-условия - не имеют значения. Оформление и анимации ИИ не касаются, он имеет дело с подготовленными данными и командами, которые имеют смысл. И если там вдруг будет что-то из разряда "улыбнуться", то для ИИ это просто команда, даже номер команды (id), а 2d-спрайт ли это или 3d-анимация - ИИ не касается. От ИИ требуется лишь, чтобы эта улыбка была адекватной (в подходящие моменты).
Возраст - тонкий момент. В конкретной игре он может как меняться в пределах игры, так и не меняться. Но скорее, он постоянный, чем динамичный. Значение возраста любое (заранее не известно).
С животными проблем нет, для описания их поведения подходят несложные скрипты. И в целом животные обязаны быть предсказуемы, так что схематичность их поведения (набор повадок) - вполне себе норма.
xmoonlight, пример чего? Игры? Выживалка с участием npc, которые могут быть как союзниками, так и врагами, в зависимости от ситуации. Пример модели ИИ - дерево решений.
xmoonlight, ну это очень абстрактный вопрос, и я не ожидаю, что его поймёт каждый. Ключевые слова - модель ИИ. То есть не просто ИИ, а модель, методология построения или что-то в этом роде.
В зависимости от цели модель ИИ может быть разной. Здесь акцент делается на человечность. Собственно, я сказал всё то же самое, только другими словами. Не знаю, стало ли понятнее.
Зачем так делать? В чем гениальность такого решения геймдизайнера? Какие ощущения это должно вызвать у игрока?
Помнится, в сторону Frostpunk была абсурдная (но реальная) волна негодования по поводу того, что он вышел зимой. Типа нафига играть зимой в игру про зиму? Зимой хочется лета!
xmoonlight, повторюсь, я не могу увеличить информацию, не обладая ей. Навскидку могу предложить такой вариант для нового вопроса: "Как автоматически транслировать любой код Python на JS без ущерба для скорости работы?". Но без полноты картины я не знаю, как будет лучше.
BoShurik, автор исправил один недочет, добавив другой.
xmoonlight, я не просил переименовывать. Лишь привел пример нарушения с целью показать, что в правилах много полезных моментов о том, как формулировать вопросы, чтобы получать на них релевантные ответы. Ведь речь шла о том, как лучше сформулировать вопрос. И лучшую формулировку может подобрать только автор (или телепат, читающий между строк, было бы что читать).
xmoonlight, какая разница? Это нужно для полноты понимания проблемы и нахождения возможных решений. Возможно, и не понадобится. Но в сложных вопросах любая дополнительная информация может оказаться полезной. Без нее сужается круг возможных решений. То есть вы как бы задаете более жесткие условия, в рамках которых могут быть только менее эффективные решения, а эффективное никто предложить не может, потому что не обладает полнотой картины. Но дело ваше.
К примеру, в заголовке вопроса у вас неправильный порядок слов в вопросительном предложении. Это нарушение одного из пунктов правил. Нет вопросительного слова. По сути вы взяли какое-то выражение (словосочетание) и добавили к нему знак вопроса, но это не делает предложение вопросом.
xmoonlight, а я не могу увеличить информацию, не обладая ей. Разве что из комментов скомпилировать, но всё равно здесь много догадок будет. Что за код, нафига его транслировать и т.д.
Общий принцип (даже для тех, кто не умеет формулировать) - описать суть как можно точнее в 1-2 абзаца, а стену текста и прочих данных засунуть под спойлер. Остальные моменты хорошо описаны в правилах: например, вопрос должен быть однозначным и содержать постановку проблемы и т.д.
xmoonlight, автоматически и код быстрым? Одновременно никак. Даже просто транслировать без учета эффективности довольно сложно. Но в любом случае, это совсем другой вопрос, чем "почему не используют единый ассоциативный массив для всех переменных".
xmoonlight, ну так это редкая задача. Большинству она не нужна, потому что есть человеческое описание алгоритма генерации хеша. Да и вообще большинство нормальных алгоритмов хешей уже написаны на разных языках, или даже встроены в язык в виде модуля.
В вашем примере код должен быть не столь понятным, сколько жутко оптимизированным. Соответственно, если не пользоваться доками, то сначала его нужно разоптимизировать, потом переписать на js, а затем снова оптимизировать, но уже на js. И лишний ассоциативный массив, имхо, вреден в такой функции, которая является узким местом вычислений.
xmoonlight, про визуализацию скажу, что текст удобнее. А сложные и плотно оптимизированные алгоритмы принято документировать. Скорее всего, у вас более узкая задача, где это и правда нужно (например, анализ какого-то чужого кода), но вы о ней не рассказываете.
MireskaHasArrived, странно, но это ваш первый вопрос на Тостере. Не ясно, когда вы успели "выслушать" много ответов. В любом случае, если вы нашли много "желчи" и восприняли её на свой счёт, то это, в первую очередь, ваша проблема, без обид. Ведь вы, похоже, и в моем ответе нашли намек на "желчь", не так ли?
А от понимания целеполагания вы зря отмахиваетесь. Если бы вы просто получали удовольствие от процесса создания новых миров, то и вопроса бы не возникло. Однако вы задаётесь вопросом эффективности, а она возможна лишь в рамках конкретной измеримой цели.
Просто представьте на секунду конечную точку (какая бы она ни была), чтобы лучше понять цель. Предположим, вы всё осилили и начали делать свой игровой движок, чтобы он был каркасом для других миров. Вы делали это три года. Но оказалось, что ваш движок никому не нужен, потому что на рынке есть другие решения. Вас это устроит? Вас устроит бесполезность результата ваших трудов? Возможно, в каком-нибудь UE5 или Unity 2021 уже будет встроено большинство ваших новых (пока что) идей, просто потому что за каждым движком стоит команда толковых разработчиков, а вы - одиночка. Понимая цель без "наверное", "звучит глупо" и прочих сомнений, можно уже будет точнее сказать, как именно к ней лучше прийти.
Пока что лучшим ответом будет цитата, которую я привел в моем другом ответе.
