66602
Создание модуля для управления поведением компьютерного персонажа
Отчет о прохождении практики
Информатика, кибернетика и программирование
Цель работы: создание программного модуля, реализующего алгоритм нечёткого логического вывода, применение модуля для определения поведения компьютерного персонажа, клиент-серверное разделение функциональности. Создан модуль нечёткого логического вывода LogicalOutput...
Русский
2014-08-25
569.79 KB
3 чел.
МІНІСТЕРСТВО ОСВІТИ, НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ
Донецький Національний Університет
Кафедра компютерних технологій
КУРСОВИЙ ПРОЕКТ
(РОБОТА)
з компютерних мереж
на тему: Створення адаптивної системи керування
компютерним персонажем
Студента 4 курсу групи А1
напряму підготовки 6.0501
спеціальності Системи штучного інтелекту
Виконав: Тараш В.В.
Керівник: доц. каф. КТ, к.т.н.
Петренко Т. Г
Національна шкала ________________
Кількість балів: __________Оцінка: ECTS _____
Члени комісії ________________ ___________________________
(підпис) (прізвище та ініціали)
________________ ___________________________
(підпис) (прізвище та ініціали)
________________ ___________________________
(підпис) (прізвище та ініціали
Донецьк - 2012
РЕФЕРАТ
Отчёт о курсовой работе: с.53, рис. 12, табл. 7, приложений 3, источн. 11.
Предмет исследования: адаптивные модели и нечёткий логический вывод.
Объект исследования: алгоритм нечёткого логического вывода.
Метод исследования: программирование на объектно-ориентированном языке C# платформы .NET с применением клиент-серверного разделения.
Цель работы: создание программного модуля, реализующего алгоритм нечёткого логического вывода, применение модуля для определения поведения компьютерного персонажа, клиент-серверное разделение функциональности.
Создан модуль нечёткого логического вывода LogicalOutput, позволяющий выдавать решения по управлению поведением компьютерного персонажа в условиях нечёткой информации, которая описывает модель поведения персонажа. Модель поведения персонажа создана на основе реальных представлений человека о факторах, которые могут влиять на персонажа, и состояний, в которые он переходит в зависимости от факторов, что обуславливает нечёткость построенной модели. Модуль нечёткого вывода и модель поведения персонажа, описанная в XML-файлах, вместе образуют адаптивную модель управления поведением компьютерного персонажа. Адаптивность в этом случае обеспечивается базой правил, накапливающейся и изменяющейся в процессе вывода.
Визуальное представление поведения персонажа на клиентской форме, реализованное в работе, даёт наглядное представление результатов работы модуля. Клиентская форма также позволяет управлять входными факторами, влияющими на поведение. Серверная часть содержит модуль нечёткого вывода и принимает, обрабатывает, и отвечает на запросы с клиента по получению действия персонажа при конкретном наборе значений факторов.
Клиент-серверное приложение реализовано асинхронно. При отключении и повторном включении сервера клиенты имеют возможность с помощью вспомогательной формы подключиться к серверу вновь.
КЛЮЧЕВЫЕ СЛОВА: адаптивная модель, нечёткий логический вывод, база правил, XML-файл, клиент-серверное приложение.
СЛОВАРЬ ТЕРМИНОВ
10) Нечёткий логический вывод вывод, основой для проведения которого является база правил, содержащая правила нечёткого логического вывода, и функции принадлежности для соответствующих лингвистических термов. Включает четыре этапа: введение нечеткости (фаззификация), нечеткий вывод, композиция и приведение к четкости, или дефаззификация.
11) Клиент-серверная архитектура - метод разделения функциональности единой системы для повышения продуктивности, при котором одна сторона является провайдером ресурсов, а другая - потребителем.
12) Компьютерный персонаж (КП) самостоятельный объект компьютерной игры, управляющийся компьютером и взаимодействующий с человеком-игроком.
СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
1. ПОСТАНОВКА ЗАДАЧИ 4
2. ОБЗОР ПОДХОДОВ 5
3. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ ЧАСТИ ПРИЛОЖЕНИЯ 6
3.1 Математическая модель компьютерного персонажа 6
3.1.1 Объекты нечёткой логики 6
3.1.2 Управление поведением компьютерного персонажа 7
3.1.3 База правил 8
3.1.4 Этапы 10
3.2 Структура XML-файлов 10
3.2.1 Файлы с лингвистическими переменными 10
3.2.2 Файлы с коэффициентами 12
3.2.3 Файлы правил 13
3.3 Операции нечёткого вывода 14
3.4 Архитектура функциональной части приложения. 16
3.4.1 Классы представления данных 17
3.4.2 Функциональные классы 18
4. ПРОЕКТИРОВАНИЕ КЛИЕНТ-СЕРВЕРНОГО ПРИЛОЖЕНИЯ 22
4.1 Общие сведения об архитектуре клиент-серверного приложения 22
4.2 Концептуальная модель 24
4.3 Логическая модель 26
4.4 Физическая модель 28
5. КОНТРОЛЬНЫЕ ПРИМЕРЫ 36
5.1 Пример работы модуля LogicalOutput 36
5.2 Пример работы клиент-серверного приложения 38
6. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ 39
7. СИСТЕМНЫЕ И АППАРАТНЫЕ СРЕДСТВА 40
ВЫВОДЫ 41
СПИСОК ССЫЛОК 42
ПРИЛОЖЕНИЕ A. Таблицы описания модели поведения компьютерного персонажа 43
ПРИЛОЖЕНИЕ Б. Примеры XML-файлов 44
ПРИЛОЖЕНИЕ В. Экранные формы 49
ПРИЛОЖЕНИЕ Г. Результаты нечёткого логического вывода 53
Правильное, обдуманное принятие решений является важнейшей способностью человека, одним из важнейших этапов для любой целенаправленной человеческой деятельности. Этот этап проходится многократно во всех отраслях деятельности человека перед и во время разработки продуктов деятельности. В настоящее время объёмы производства сложных продуктов, таких, как создание устройств, автомобилей, различного технического оборудования обширны, но кроме этого и скорость их увеличения растёт. Поэтому существует потребность программного управления процессами на производствах.
Принятие решений в проблемно-ориентированных информационных системах и системах управления осуществляется в условиях неопределенности, обусловленной неточностью или неполнотой исходных данных, стохастической природой внешних воздействий, отсутствием адекватной математической модели, нечеткостью сформулированной цели, человеческим фактором и пр. Неопределенность системы может привести к увеличению рисков принятия неэффективных решений, в результате чего могут наблюдаться негативные экономические, технические и социальные последствия. Неопределенности в системах принятия решений компенсируются различными методами искусственного интеллекта. Для эффективного принятия решений при неопределенности условий функционирования системы применяют методы на основе правил нечеткой логики. Такие методы основываются на нечетких множествах и используют лингвистические величины и выражения для описания стратегий принятия решений. Одним из таких методов является метод нечеткого логического вывода [11].
Создание адаптивных моделей управления процессами широко используется и в области компьютерных игр для моделирования поведения персонажей, управляемых компьютером. Существующие подходы к управлению компьютерными персонажами обладают различными недостатками. Возможности устранения этих недостатков может предоставить нечёткая логика второго типа. В данной работе реализован алгоритм нечёткого логического вывода и применён для определения поведения компьютерного персонажа.
Разработать программный продукт, реализующий адаптивную модель управления компьютерным персонажем. Модель должна представлять из себя реализованный алгоритм определения поведения персонажа на основе дискретной нечёткой логики второго типа. Программный продукт должен быть написан в виде клиент-серверного приложения. При реализации алгоритма необходимо выполнить следующие пункты:
В настоящее время компьютерные игры имеют высокую популярность и спрос на них только растёт. Основным фактором, влияющим на популярность конкретной игры является её интересность с точки зрения человека-игрока. Поэтому для поддержания таких тенденций необходимо удовлетворять потребности игрового сообщества, которые также повышаются. Интересность игры напрямую зависит от поведения объектов игры, управляемых не игроком, а системами принятия решений.
Существует множество подходов для разработки систем поддержки принятия решений, к примеру, корреляционный и регрессионный анализ, сценарные методы, теория игр и т. д. Данные подходы либо имеют ограничения на применение в связи с высокой вычислительной сложностью, а, соответственно, значительным временем принятия решений и высокой себестоимостью таких систем, либо являются слишком простыми и бесперспективными. В существующих моделях параметры игры рассматриваются либо как чёткие, либо с использованием нечёткой логики только первого типа. Эти модели являются либо не адаптивными, либо частично адаптивными и не учитывают в полной мере неопределённость, которой обладают КП по причине вымышленности их свойств и поведения. Это обуславливает предопределённость сценария игры, в результате чего игрок в определённый момент осмысливает алгоритм принятия решений компьютерными персонажами и теряет интерес к игре.
Для преодоления трудностей в разработке моделей управления поведением КП новым актуальным подходом является разработка развивающегося интеллекта. Любая развивающаяся интеллектуальная система является адаптивной системой, способной к обучению. Целью данного подхода является моделирование функционирования человеческого мозга (обучение, память, абстрактное мышление и т.д.) для создания саморазвивающихся, самообучаемых и адаптивных систем [12].
В данной работе создаётся модель управления поведением персонажа, основанная на нечёткой логике второго типа. Для обеспечения адаптивности модель реализует организацию памяти и обучаемость КП с помощью динамически изменяемой базы нечётких правил.
Для описания объектов, фактов и явлений в нечёткой логике используются такие понятия, как нечёткое множество, нечёткая переменная, лингвистическая переменная.
Пусть нечёткое множество второго типа определено на универсальном множестве X. Тогда это нечёткое множество описывается парами значение-уверенность:
<x, ϻ(x)>, где
x ϵ X значения из области определения,
ϻ(x) ϵ [ϻlmf(x)… ϻumf(x)] функция принадлежности второго типа, возвращающая уверенность. Здесь:
ϻlmf(x) ϵ [0; 1] нижняя функция принадлежности первого типа
ϻumf (x) ϵ [0; 1] верхняя функция принадлежности первого типа
Нечеткая переменная характеризуется тройкой <α, X, A>, где
α имя переменной,
X универсальное множество (область определения α),
A нечеткое множество, определённое на X
Лингвистической переменной называется набор <β,T,X,G,M>, где
β имя лингвистической переменной,
Т множество нечётких переменных (терм-множество), областью определения которых является множество X. Множество T называется базовым терм-множеством лингвистической переменной,
G синтаксическая процедура, позволяющая оперировать элементами терм-множества T, в частности, генерировать новые термы (значения). В данной работе G используется при определении действия персонажа.
М семантическая процедура, позволяющая преобразовать новое значение лингвистической переменной, образованной процедурой G, в нечеткую переменную, то есть сформировать соответствующее нечеткое множество. В данной работе использование M не требуется [4].
Поведение компьютерного персонажа представляет собой последовательность действий, которые определяются в каждый момент времени, когда это необходимо (когда изменяются факторы, которые влияют на персонаж). Действие, которое персонаж производит в данный момент времени, определяется его состояниями в этот момент.
Действия, факторы и состояния описываются лингвистическими переменными. В контексте данного задания для лингвистической переменной может существовать входное значение и активированные этим значением термы. Действия являются термами результирующей лингвистической переменной. Тогда можно записать:
A(t) = Func1(<S(t)>, LR),
где A(t) действие (активированный терм результирующей ЛП),
Func1 операция нечёткого логического вывода для вычисления действия по активированным термам состояний,
<S(t)> - набор из M активированных термов состояний в момент времени t,
LR результирующая лингвистическая переменная.
Активированные термы состояний зависят от факторов, которые оказывают влияние на персонаж, а также от нечёткой базы правил:
<S(t)> = Func2(<F(t)>, <LO>, RB (t)),
Где Func2 операция нечёткого логического вывода для вычисления активированных термов состояния по активированным термам факторов,
<F(t)> - набор, состоящий из N активированных термов факторов в момент времени t,
<LO> - набор из M выходных лингвистических переменных, которые описывают состояния персонажа,
RB (t) база правил в момент времени t.
Активированные термы факторов определяются по входным значениям:
<F(t)> = Func3(IN(t), <LI>),
Где Func3 операция нечёткого логического вывода для вычисления активированных термов факторов по входным значениям,
IN(t) вектор из N входных значений в момент времени t.
<LI> - набор из M входных лингвистических переменных, описывающих имеющиеся N факторов.
<LI>, <LO> и LR описываются в XML-файлах.
Все лингвистические переменные определены на универсальном множестве X = [0; 1].
База правил является моделью «памяти» компьютерного персонажа и позволяет ему «обучаться». Если в начальный момент времени действие КП руководствуется только входными факторами (база правил пуста), то начиная со второго уже и «памятью».
На вход модуля нечёткого логического вывода подаются значения входных факторов. В процессе обработки этих данных формируются нечёткие правила. Эти нечёткие правила добавляются в базу правил за предыдущий момент времени. которые сгенерировались в текущий момент времени. либо копируется в неё полностью в начальный момент.
RB(t) = RB(t-1) \/ r(t),
где r(t) нечёткие правила, сгенерированные в момент.
По правилам в суммарной базе и активированным термам факторов определяются активированные термы каждого из состояний <S(t)>.
Далее по аналогичному алгоритму, с помощью нечёткого логического вывода, но без использования базы правил, определяется действие A(t) по термам <S(t)>. Поскольку на этом этапе состояния играют роль входных ЛП, а результирующая выходной ЛП, для определения A(t) можно использовать тот же алгоритм нечёткого вывода, что и при определении <S(t)>. Это означает, что Func1(<S(t)>, LR) = Func2(<S(t)>, LR, null) база правил не нужна при определении A(t).
Каждое правило имеет вид:
IF <условие> THEN <следствие>
S <уверенность>
Если при добавлении нового правила Rі в базу правил в ней уже имеется некое правило Rj, для которого выполняется:
<условие>i== <условие>j AND <следствие>i == <следствие>j ,
то новое правило Rі не добавляется, но обновляется увереность имеющегося правила Rj по закону:
<уверенность>j = MAX (<уверенность>i , <уверенность>j)
База правил имеет ограничение на количество правил:
MAX(RB.Size) = K.
Это необходимо для того, чтобы в определённый момент времени база правил не стала полной, т.е. заполненной всеми возможными правилами. Это обеспечивает эффект
Если база правил имеет K правил и добавляется новое уникальное правило Rnew, то в базе ищутся правила (их может быть несколько) Rmin с наименьшей уверенностью:
<Rmin> = {R | MIN(<уверенность>)}
Если уверенность правила Rnew выше уверенности <Rmin>, то удаляется любое из <Rmin> и добавляется Rnew, иначе база правил остаётся неизменной.
Каждый момент t, когда на вход модуля подаются новые входные значения, уверенности всех правил в базе RB(t-1) уменьшаются по такому закону:
FOREACH Ri IN RB <уверенность>i = <уверенность>i 1/K
Это создаёт эффект забывания информации и обеспечивает обновляемость базы правил. Декремент 1/K устанавливает обратную зависимость между максимальным размером базы правил и скоростью её обновления. Для малых баз правил декремент будет выше и новые правила будут записываться в больших объёмах, для больших наоборот.
Может возникнуть ситуация, в которой, по мнению эксперта, моделирующего поведение компьютерного персонажа, определить некоторые состояния персонажа до определения других невозможно по той причине, что, последние зависят от первых. Тогда возникает необходимость поэтапного расчёта состояний. Сначала рассчитываются состояния, которые зависят только от факторов. На каждом следующем этапе рассчитываются те состояния, которые зависят только от факторов и от уже вычисленных состояний. В данной работе представлен пример с двухэтапным определением активированных термов состояний (см. Контрольные примеры).
Структура входных и выходных лингвистических переменных, коэффициентные и функциональные зависимости между ними, а также правила в базе правил описываются в XML-файлах.
Файл с названием вида stageJ.xml описывает систему входных и выходных лингвистических переменных для этапа J. Последний этап этап вывода действия из состояний, описывается таким же образом и имеет одну выходную ЛП и столько входных ЛП, сколько выходных состояний.
Для этапов J-1 и J характерно, что описание входных переменных для этапа J совпадает с описание выходных переменных этапа J-1.
Общий вид файла:
<systemInfo>
<NumLIs> N </NumLIs>
<NumLOs>N</NumLOs>
</systemInfo>
<LI id=”0” name=”NameLI0”>
<x> x1; x2; … ; xNX </x>
<MF id=”0” name=”nameLI0Term0”>
<lmf> l1; l2; … ; lNX </lmf>
<umf> u1; u2; … ; uNX </umf>
</MF>
. . .
</LI>
. . . . .
<LO id=”0” name=”NameLI0”>
<x> x1; x2; … ; xNX </x>
<MF id=”0” name=”nameLO0Term0”>
<lmf> l1; l2; … ; lNX </lmf>
<umf> u1; u2; … ; uNX </umf>
</MF>
. . .
</LO>
. . . . .
Теги:
<systemInfo> - информация о системе
<NumLIs> - количество входных ЛП
<NumLOs> - количество выходных ЛП
<LI> - входная ЛП
<LO> - выходная ЛП
<x> - универсальное дискретизированное множество, на котором определены термы ЛП, состоящее из NX точек
<MF> - нечёткое множество (терм)
<lmf> - значения нижней функции принадлежности, NX значений
<umf> - значения верхней функции принадлежности, NX значений
Файл с названием stage_last.xml также описывает систему входных и выходных ЛП, в которой входными ЛП являются ЛП конечных состояний (не влияющих ни на какие другие состояния), а выходной единственная результирующая ЛП, описывающая действия компьютерного персонажа.
Файл с названием вида coeffs.xml описывает коэффициенты и функциональные зависимости выходных лингвистических переменных (состояний) от входных (факторов) для выполнения логического вывода.
Общий вид файла:
<stage id="n">
<factor id="0" name="Name0">
<coeffs>c1; c2; …; cm</coeffs>
<function>f1; f2; … ;fm</function>
</factor>
. . .
<factor id="k" name="Namek">
. . .
</factor>
</stage>
Теги:
Последний контейнер stage (с наибольшим id) описывает влияние состояний на действие.
Файл с названием RuleBase.xml описывает правила, содержащиеся в базе правил. Общий вид файла:
<systemInfo>
<NumLIs> N </NumLIs>
<NumLOs> M </NumLOs>
<NumRs> K </NumRs>
</systemInfo>
<R id=”0”>
<if> a1; a2; … ;aN </if>
<if_values> av1; av2; … ; avN </if_values>
<then> c1; c2; … ;cM </then>
<then_values> cv1; cv2; … ; cvM </then_values>
<s> S </s>
</R>
. . . . .
Теги:
<systemInfo> - информация о системе ЛП
<NumLIs> - количество факторов
<NumLOs> - количество конечных состояний
<NumRs> - количество правил в базе
<R> - правило
<if> - антецеденты, N целых чисел, соответствующих активированным термам факторов
<if_values> - конкретные значения, активировавшие термы факторов
<then> - консеквенты, M целых чисел, соответствующих активированным термам конечных состояний
<then_values> - конкретные значения, активировавшие термы конечных состояний
<s> - уверенность в правиле, S ϵ [0; 1]
В таблице №1 представлены операции, которые выполняются над нечёткими множествами в данной работе, а также классы и функции, которые их реализуют.
Таблица №1. Операции над нечёткими множествами второго типа.
Операция |
Реализация |
|
Определение границ термов (области ненулевой уверенности) |
Модуль: LogicalOutput.dll Класс: LogicalOutput Функция: determineTermsBorders |
|
Определение активированных термов |
Модуль: LogicalOutput.dll Класс: Operations Функция: determineTermsAndMUs |
|
Определение функций принадлежности у активированных термов по значению x ϵ X |
Модуль: LogicalOutput.dll Класс: Operations Функция: determineTermsAndMUs |
|
Обрезка термов сверху (сжатие) |
Модуль: LogicalOutput.dll Класс: Operations Функция: determineSummaryFigure |
|
Объединение (OR, сумма) |
Модуль: LogicalOutput.dll Класс: Operations Функция: determineSummaryFigure |
|
Перебор активированных термов факторов и состояний |
Модуль: LogicalOutput.dll Класс: LogicalOutput Функции: evalLIlines и evalLOlines |
Модуль: LogicalOutput.dll Класс: CoverLogicalOutput Функции: evalLIbranches и evalLObranches |
Выделение одного терма из лингвистической переменной (функция G и математического представления ЛП) |
Модуль: LogicalOutput.dll Класс: RulesHandler Функция: determineLastINs |
Модуль: LogicalOutput.dll Класс: Operations Функция: determineSummaryFigure |
Понижение типа |
Библиотека DIT2FLS Модуль: EKM.dll Класс: TypeReducer Функция: GetTypeReduceFS |
|
Определение центра тяжести (дефаззификация) |
Библиотека DIT2FLS Модуль: Defuzzifier.dll Класс: Defuzzification Функция: GetValue() |
В таблице №2 представлены операции над базой правил, которые осуществляются для моделирования «памяти» персонажа, а также классы и функции, которые их реализуют.
Таблица №2. Операции над базой правил
Операция |
Реализация |
Добавление правила |
Модуль: LogicalOutput.dll Класс: CoverLogicalOutput Функция: evalLObranches |
Удаление правила |
Модуль: LogicalOutput.dll Класс: CoverLogicalOutput Функция: Start |
Поиск подобного правила |
Модуль: LogicalOutput.dll Класс: CoverLogicalOutput Функция: evalLObranches |
Уменьшение уверенности всех правил |
Модуль: LogicalOutput.dll Класс: CoverLogicalOutput Функция: Start |
Слияние баз правил |
Модуль: LogicalOutput.dll Класс: CoverLogicalOutput Функция: evalLObranches |
Функциональная часть приложения представлена отдельным модулем DLL (проект Visual Studio .NET Framework C# Class Library), который можно удобно подключать и использовать в других проектах. Название LogicalOutput.dll, namespace - LogicalOutput.
На рис.1 изображена диаграмма взаимодействия всех классов модуля LogicalOutput.dll.
Рис. 1. Диаграмма взаимодействия классов функциональной части
Классы предназначены для удобного представления данных важнейших объектов логического нечёткого вывода вместе с функциями их обработки. Эти классы обёрнуты в namespace LogicalOutput.DataClasses.
Функции:
Классы обеспечивают всю функциональность по произведению нечёткого логического вывода. Содержатся в namespace LogicalOutput.
В рамках многоуровневого представления вычислительных систем можно выделить три группы функций, ориентированных на решение различных подзадач:
Рис.2. Компоненты сетевого приложения
Выполнение этих функций в основном обеспечивается программными средствами, которые можно представить в виде взаимосвязанных компонентов где:
Компьютер, не подключенный к сети, представляет все эти компоненты как на различных уровнях (ОС, служебное ПО и утилиты, прикладное ПО), так и на уровне приложений. Таким же образом и сеть представляет все эти компоненты, но, в общем случае, распределенными между узлами. Задача сводится к обеспечению сетевого взаимодействия между этими компонентами.
Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты, потребители этих функций [1].
Клиент называется узел сети (компьютер, программа или пользователь), запрашивающий и использующий информацию и/или ресурсы у сервера в рамках архитектуры клиент-сервер. Существует два типа клиентов:
Тонкий клиент терминал сети , не использующий жесткие диски, вычислительная мощность и объем памяти которого определяются только задачами представления пользователю информации. Все программы и приложения, хранящиеся на сервере, становятся доступными для пользователя при включении его устройства и выполнении процедуры соединения с сервером. Тонким клиентом называют также ПК (в том числе и мобильный) с минимизированной мощностью процессора, оперативной и внешней памяти, позволяющий пользователю осуществлять ввод и отображение данных за счет выполнения вычислений и хранения данных на более мощном ПК или сервере, с которыми он может осуществлять связь, при помощи каналов средней пропускной способности. К тонкому клиенту могут подключаться внешние устройства ввода/вывода данных.
Толстый клиент - рабочая станция или персональный компьютер, работающие под управлением собственной дисковой операционной системы и использующие определённый набор программного обеспечения. К серверам такие клиенты обращаются преимущественно за дополнительными услугами, например за информацией. Также под «толстым» клиентом подразумевается и клиентское сетевое приложение, запущенное под управлением локальной ОС. Такое приложение совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).
Архитектуры построения сети:
Двухзвенная модель архитектура построения сети, предусматривающая один сервер и несколько клиентов, является наиболее простой и распространенной. Недостаток ограниченное число клиентских рабочих мест.
Трехзвенная модель архитектура построения системы клиент-сервер, в которой предусмотрено промежуточное звено (дополнительный компьютер), расположенное между сервером и клиентом двухзвенной модели. Промежуточное звено работает как монитор обработки транзакций или брокер объектных запросов. Трехзвенные модели обеспечивают работу существенно большего числа клиентов, чем двухзвенные модели.
N-звенная модель архитектура построения сети, предусматривающая наличие нескольких серверов приложений, число которых определяется необходимым уровнем нагрузки сети. При многозвенной модели построения системы количество возможных клиентских мест значительно больше, чем при использовании двухзвенной модели [2, 3].
Взаимодействие клиента и сервера может быть синхронным и асинхронным. При синхронном ресурсы сервера оказываются недоступными каждый раз, когда один из клиентов обратился к нему с запросом. Пока Сервер не выполнит отправку ответа этому клиенту, остальные клиенты ожидают своей очереди на использование ресурсов. При асинхронном клиенты могут обращаться к серверу в любой момент времени и их запросы сразу же начнут выполняться на сервере, независимо от количества подключений (ограничиваться количество подключений будет другими параметрами, к примеру пропускной способностью сети).
В данном приложении реализуется модель управления поведением компьютерного персонажа по взаимодействию с персонажем игрока-человека, основанная на нечёткой логике. Поведение компьютерного персонажа может характеризоваться одним из трёх действий относительно персонажа игрока-человека: агрессия, нейтральность, бегство.
Реализация модели представляет из себя модуль, использующий алгоритм нечёткого логического вывода для вычисления необходимых данных. Результатом i того цикла работы модуля являются правила, которыми пополняется база правил, а также действие, которое он будет выполнять на шаге i, формирующееся на основе пополненной на этом шаге базы правил. Модуль состоит из классов, последовательная работа которых позволяет получить набор правил таких правил на каждом шаге. Логический вывод производится в каждый момент времени, когда персонажу поступает новый набор входных значений. Каждый раз, когда меняется хотя бы одно входное значение, нужно запускать алгоритм логического вывода, то есть устанавливать новые входные данные для модуля и запускать новый цикл работы.
Клиент-серверная система характеризуется наличием двух взаимодействующих самостоятельных процессов - клиента и сервера, которые, в общем случае, могут выполняться на разных компьютерах, обмениваясь данными по сети. Клиенты подключаются к серверу и используют его ресурсы.
В данном случае для обеспечения многопользовательского использования ресурса модуля нечёткого вывода необходимо выделить модуль в виде серверного приложения, к которому сможет подключаться несколько клиентов.
Таким образом, для демонстрации работы модели необходимо создать некоторое визуальное представление, которое будет отображать текущее состояние персонажа, а также элементы управления входными данными, которые будут влиять на текущее состояние персонажа. Это представление должно быть размещено на клиентском приложении.
Для обработки информации требуется серверное приложение, способное получать и распознавать запросы, посылаемые клиентами, запускать модуль нечёткого вывода и отправлять информацию о действии, которое должен выполнять компьютерный персонаж. Каждый раз, когда входные данные изменяются пользователем на визуальном представлении клиента, серверной части отправляются новые данные. Для каждого клиента на сервере должна создаваться своя база правил, поскольку у каждого из клиентов визуальное представление будет уникальным.
Потоки информации, передающиеся между клиентом и сервером:
В начале работы клиент отправляет серверу запрос с идентификатором файлов, описывающих конкретную систему лингвистических переменных, коэффициентных и функциональных зависимостей между этими ЛП. Сервер отвечает информацией о количестве факторов.
В процессе работы от клиента серверу отправляется набор входных значений факторов, сгенерированных пользователем при изменении пользовательских элементов. Сервер выполняет логический вывод: вычисляет правила и, пополняет базу правил, вычисляет значения состояний компьютерного персонажа и его действие.
От сервера клиенту действие, а также значения состояний которые привели к такому действию. Клиент, получая значения состояний, изменяет визуальное представление для демонстрации пользователю.
Обмен данными происходит каждый раз, когда пользователем меняются элементы управления входными значениями.
Архитектура реализованной модели клиент-серверного приложения является двухзвенной (двухранговой), поскольку имеется один сервер и несколько клиентов. Выбор такой архитектуры обусловлен отсутствием необходимости в дополнительных серверов, что определяется невысокой планируемой нагрузкой на сеть.
Для взаимодействия частей системы используется TCP/IP (Transmission Control Protocol/Internet Protocol). TCP/IP - это набор протоколов, которые позволяют физическим сетям или компьютерам объединяться вместе для образования общей сети. TCP/IP соединяет индивидуальные сети или компьютеры для образования виртуальной вычислительной сети, в которой отдельные главные компьютеры идентифицируются не физическими адресами сетей, а IP-адресами.
В TCP/IP используется многоуровневая архитектура, которая четко описывает, за что отвечает каждый протокол. TCP - это протокол транспортного уровня модели OSI, который позволяет прикладным программам, запущенным на компьютерах сети, обмениваться потоками даннях. IP - самый фундаментальный протокол из комплекта TCP/IP - передает IP-дейтаграммы по интрасети и выполняет функцию, называемую маршрутизацией. Маршрутизация, осуществляемая протоколом IP - процесс поиска в таблице маршрутизации, определение интерфейса, куда будет послан пакет [6, 7].
Данные, перемещающиеся между двумя прикладными программами, работающими на разных компьютерах сети, транспортируются вверх и вниз по стекам TCP/IP на этих компьютерах. Информация, добавленная модулями TCP/IP на стороне отправителя, разбирается соответствующими TCP/IP-модулями на принимающем конце и используется для воссоздания исходных данных [5, 6].
Для передачи информации между сервером и клиентом необходимо знать не только IP-адрес компьютера, но и как-то идентифицировать приложение, которому направляется информация. Сокет - средство двунаправленной связи, которое может использоваться для взаимодействия с другим процессом на одной и той же машине или с процессом, запущенным на других машинах [8]. Другими словами, сокет - программный интерфейс, служащий для обеспечения обмена данными между процессами, исполняющимися как на одном компьютере, так и на различных, связанных между собой сетью. Сокет абстрактный объект, представляющий собой конечную точку соединения. Сокет характеризуется парой { IP-адрес, порт }, где порт это точка логического соединения, идентифицирующая приложение, работающее на компьютере.
Для создаваемого клиент-серверного приложения связь между клиентом и сервером должна быть асинхронной, поскольку время обработки данных сервером становится заметным (несколько секунд) при больших размерах исходных XML-файлов, описывающих модель компьютерного персонажа, и соответственно при сильно разрастающейся базе правил (до десятков килобайт в формате XML).
Поэтому выбор языка программирования основывается на его возможностях по работе с сетевыми сокетами и многопоточностью. Таким языком является С#, выполняемый в среде .NET Framework. Он обеспечивает необходимые классы и методы: System.Net.Sockets.Socket, System.Threading, а также способы синхронизации семафоры, мьютексы и т.п. В данном приложении для синхронизации потоков клиента и сервера используется класс System.Threading.ManualResetEvent.
Класс Socket имеет возможности запуска для асинхронных получения, отправки данных, подключения:
AsyncCallback функция-делегат вида void func(IAsyncResult),
Object объект сокета для дальнейшей обработки.
Класс System.Threading.ManualResetEvent уведомляет один или более ожидающих потоков о том, что произошло событие. Методы:
Клиент-серверное приложение состоит из двух solutions (решений) Visual Studio 2012: Character_Client и Character_Server.
Решение Character_Server отвечает за работу сервера и состоит из четырёх проектов:
Модуль LogicalOutput.dll
Рис.3. Взаимодействие классов проекта Character_Server
Классы проекта Character_Server :
Решение Character_Client отвечает за работу клиента и состоит из одного проекта Character_Client, тип Windows Forms. Содержит классы по работе с сервером (формирование запроса, отправка запроса, получение ответа, разбор строки ответа). Представляет на форме поле с компьютерным персонажем и персонажем игрока-человека и элементы управления TrackBar для управления посылаемыми серверу входными значениями. На форме также имеется StatusBar для отображения в текстовом виде действия и состояний компьютерного персонажа. В верхнем левом углу формы находится кнопка Restart, которая задаёт новые случайные положения изображениям персонажей компьютерного и человека-игрока.
Рис.4 Взаимодействие классов проекта клиента Character_Client
Классы проекта Character_Client :
Сообщения и потоки данных между клиентом и сервером:
Запрос на получение количества факторов у модели компьютерного персонажа, описанного в xml-файлах, имена которых заканчиваются на tail. Таким образом, tail определяет «семейство» файлов отдельной модели персонажа. Так разные клиенты могут загружать и отображать разные модели. Этот запрос производится при загрузке формы на клиенте, и по полученным данным на форме формируется нужное количество трек-баров, посредством которых пользователь управляет входными значениями факторов. Количество посылаемых байт равно: 16 + tail.length.
Ответ сервера:
На сервере по этому запросу создаётся новый объект класса CoverLogicalOutput из модуля LogicalOutput.dll. Конструктор этого класса возвращает массив строк с именами факторов указанной модели
В ответ сервер посылает строку с подстроками, разделёнными символом ;, количество которых равно количеству факторов, каждая из которых представляет имя фактора. Количество байт меняется в зависимости от длин названий и кол-ва факторов. В консоли сервера, а также в файле server_log.txt пишется количество отправленных клиенту байт.
Запрос на получение действия, которое выполнять персонажу. После идентификатора запроса в строку запроса помещаются через строку N чисел типа double от 0 до 1 с точностью до двух знаков после запятой, которые соответствуют входным факторам. Одно дробное число, таким образом, занимает 5 байт вместе с разделителем ;. Тогда количество отправляемых байт равно: 10 + 5 * N.
Ответ сервера:
На сервере по этому запросу запускается функция объекта класса CoverLogicalOutput Start(). Эта функция возвращает строку, разделённую символом ; на подстроки. Первая подстрока действие для персонажа, а каждые следующие две подстроки представляют пару {имя лингвистической переменной состояния; состояние}. Эти пары отображаются в статусной строке клиентской формы, чтобы продемонстрировать изменение состояний, повлиявших на действие. Количество байт: lenA + M * average(lenNameLI + lenNameS). где lenA длина подстроки действия, average(lenNameLI + lenNameS) среднее значение суммы длин имён ЛП состояния и состояния
* Числа, использованные при расчёте размеров сообщений, подсчитаны при условии того, что все символы сообщений имеют размер 1 байт. Однако для разных кодировок размер символа может быть разным. К примеру, в кодировке UTF-8 имеются символы размером от 1 до 4 байт.
Действия могут быть такими :
В процессе совместной работы клиента и сервера соединение между ними устанавливается только на момент передачи запроса клиентом и получения им ответа. Всё остальное время клиент работает полностью автономно, а сервер производит прослушивание по всем IP-адресам и ожидает подключения. Поэтому при отключении какого-либо из приложений не требуется никаких действий и ничего не происходит в другом приложении. При попытке установки клиентом связи с выключенным сервером или при другой ошибке подключения выдаётся сообщение об этой ошибке с помощью MessageBox. При отключении и повторном включении сервера клиенты имеют возможность с помощью вспомогательной формы FormConnection (рис. В6, приложение В) подключиться к серверу вновь. Для этого необходимо нажать кнопку Connect (с синей стрелкой) в верхней левой части формы.
Для демонстрации работы и тестирования модуля была разработана модель компьютерного персонажа, состоящая из двух этапов. Модель описана в таблицах (приложение А) и представлена в XML-файлах (приложение Б). Первый этап (приложение А, таблица. А1) состоит из
7 факторов: сытость, уровень жидкости в организме, усталость, здоровье, расстояние до объекта (персонажа игрока), степень опасности объекта (персонажа игрока), эмоциональная устойчивость
и 4 состояний: потребность в пище, потребность в воде, потребность во сне, уровень страха.
Второй этап (приложение А, таблица. А2) состоит из
5 факторов: уровень страха, потребность в ближайшем объекте (полезность), степень опасности ближайшего объекта, потребность во сне, сытость
и 3 состояний: желание приближения к ближайшему объекту, желание удаления от ближайшего объекта, активность.
Необходимость в создании двух этапов состоит в том, что «желание приближения к ближайшему объекту», «желание удаления от ближайшего объекта» и «активность» зависят не только от факторов, но и от состояний «потребность во сне» и «уровень страха».
Таким образом, если не вникать во внутренние зависимости этой двухэтапной системы, то для наглядности условно можно сказать, что имеется 8 конечных факторов, которые необходимо получить извне модуля нечёткого вывода и 5 конечных состояний (приложение А, таблица. А3), в которых находится персонаж. Поэтому на действие персонажа как факторы будут оказывать влияние эти 5 состояний (приложение А, таблица А4): потребность в пище, потребность в воде, желание приближения к ближайшему объекту, желание удаления от ближайшего объекта, активность.
На таблицах в приложении А зелёным цветом изображены конечные факторы, синим факторы-состояния, красным конечные состояния. В пересечении рядов и столбцов находятся коэффициенты влияния фактора их конкретного ряда на состояние конкретного столбца. Пометка «обр.» обозначает, что зависимость обратная, т.е.
f(x) = 1 x,
отсутствие пометки означает прямую зависимость, т.е.
f(x) = x,
где f(x) функция получения входного значения для состояния по входному значению фактора.
Файлы, которые описывают модель поведения персонажа (приложение Б):
Когда запускается клиент, форма клиента имеет вид, как на рис.В1 приложения В. Если изменить входное значение фактора Feedness (сытость), то результат можно наблюдать на рис. В3 приложения В:
- в статусной строке выводится выводится, в какие состояния перешёл персонаж и какое действие выполняет:
Рис. 5. Статусная строка формы клиента
- на игровом поле сократилось расстояние между игроком и компьютерным персонажем через некоторое время выполнения действия «агрессия» персонажем.
В процессе работы форма клиента выглядит, как на рис. В5 приложения 5.
Результаты работы модуля в текстовом виде продемонстрированы в приложении Г в виде таблицы. Каждая строка таблицы описывает определённый набор активированных термов факторов, набор активированных термов состояний, которые активизировались при это набор активированных термов факторов и действие, которое предпринимает персонаж. Поскольку модель персонажа, описанная в этом примере, содержит 12 ЛП, для простоты и наглядности представления данных таблица построена для другой модели с 5 ЛП (см. рис. В7 приложения В). В связи с различными правилами, которыми наполняется база, такая таблица является лишь одним из вариантов, поскольку каждый раз база правил была бы разной
При запуске сервера в консоли выводится сообщение “Ready. Listening…”. При запуске клиента консоль сервера имеет вид, как на рис. В2. Из сообщения в консоли видим, что клиент с IP 127.0.0.1 (на том же компьютере, что и сервер) подключился по порту 60073 , от правил запрос на получение информации о факторах и получил 139 байт ответа от сервера. После этого клиент подключился по порту 60074 и запросил действие по входным параметрам (0,5; 0,5; 0,5; 0,5; 0,5; 0,5; 0,5) - начальным параметрам, устанавливаемым при инициализации формы клиента, а потом получил ответ из 116 байт. В результате форма клиента имеет вид, как на рис. В1 приложения В.
При изменении пользователем положения ползунка трек-бара, управляющего значением фактора Feedness, видим на рис. В4 приложения В состояние консоли: получены запросы от клиента с IP 127.0.0.1 на определение действия по факторам. Последний запрос (0,83; 0,5; 0,5; 0,5; 0,5; 0,5; 0,5), после обработки которого клиенту отправлено 118 байт. Результат видим на рис. В3 приложения В в статусной строке и на игровом поле.
При нажатии на кнопку Connect в верхнем левом углу форму клиента (кнопка с синей стрелкой) открывается форма подключения (рис. В6 приложения В). В форму вводятся IP 127.0.0.1 и порт 3456 сервера и «хвост» “_ex” для имён XML-файлов другой модели персонажа. В результате этого действия на форму заново загрузятся трек-бары для новой модели. На рис. В7 видим результат загрузки новой модели названия и количество трек-баров изменилось.
Запустить сервер character_server.exe. На экране появится консольное приложение с сообщением “Ready. Listening…”. Это говорит о том, что сервер установил прослушку IP-адресов и можно запускать клиент. Это выполняется с помощью файла character_client.exe. При загрузке формы произойдёт автоматическое подключение к серверу по сокету 127.0.0.1 : 3456 и с хвостом для названий XML-файлов, равным “” пустой строке. На экране появится форма с изображением персонажа человека-игрока и компьютерного персонажа. Изначальные входные значения для трек-баров, управляющих входными параметрами, установлены в 0,5. Это приводит к некоторому изначальному действию, которое персонаж производит при загрузке формы.
Для изменения поведения персонажа пользователю нужно изменить значения входных параметров с помощью трек-баров на форме, подписанных соответствующими названиями. Поведение персонажа, а соответственно и его логичность, будет целиком зависеть от его модели, описанной в XML-файлах на сервере.
Для задания случайных позиций изображений персонажей игрока и компьютерного нужно нажать на кнопку Replace в верхнем левом углу формы.
Возможно изменение положения изображения персонажа игрока с помощью нажатия левой клавишей мыши и перетаскиванием. Компьютерный персонаж реагирует на новое положение игрока и производит свои текущие действия относительно новых положений даже в процессе перемещения мышью.
Лог взаимодействия клиента и сервера администратор сервера может увидеть в процессе работы клиента и сервера в консоли, либо в файле server_log.txt, располагающемся в директории с файлом character_server.exe.
Для разработки были использованы средства:
Минимальные требования для эксплуатации:
В результате выполнения курсовой работы было разработано приложение, которое состоит из двух частей клиентской и серверной и позволяет управлять со стороны клиента действиями компьютерного персонажа. Созданы XML-файлы, описывающие модель персонажа, реализован модуль нечёткого логического вывода LogicalOutput.dll, использующий базу правил для создания эффекта накопления опыта у персонажа. Определены функциональности клиента и сервера, организованы отправка и получение сообщений между ними, разбор и корректное использование этих сообщений.
По материалам данной работы написана научная статья.
Дальнейшее улучшение приложения может быть связано с:
[1] http://www.4stud.info/networking/lecture5.html Клиент-серверные приложения. Дата взятия информации: 19.12.12.
[2] http://technologies.su/client-server Основные особенности архитектуры «клиент-сервер». Дата взятия информации: 19.12.12.
[3] http://www.megabook.ru/Article.asp?AID=606989 Клиент-сервер. Энциклопедия Кирилла и Мефодия. Дата взятия информации: 19.12.12.
[4] http://www.victoria.lviv.ua/html/oio/html/theme11_1_rus.htm#11_8. Тема 11. «Нечёткая логика. Дата взятия информации: 19.12.12.
[5] http://ru.wikipedia.org/wiki/TCP/IP. Стек протоколов TCP/IP. Дата взятия информации: 19.12.12.
[6] http://www.codenet.ru/webmast/tcpip.php. Основы TCP/IP. Дата взятия информации: 19.12.12.
[7] http://citforum.ru/internet/tifamily/iproutng.shtml. Статическая IP-маршрутизация. Дата взятия информации: 19.12.12.
[8] http://masters.donntu.edu.ua/2005/fvti/lukyanov/library/ipc/socket.html. Сокеты. Дата взятия информации: 19.12.12.
[9] http://msdn.microsoft.com/ru-ru/library/600stss7.aspx Класс Socket. Дата взятия информации: 20.12.12.
[10] http://matlab.exponenta.ru/fuzzylogic/book1/1_7_5_1.php С.Д.Штовба "Введение в теорию нечетких множеств и нечеткую логику". Дата взятия информации: 20.12.12.
[11] http://www.nbuv.gov.ua/e-journals/VNTU/2011_3/2011-3_ru.files/ru/11rnkflc_ru.pdf Р. Н. Кветный, статья «Адаптивная система поддержки принятия решений на основе нечёткого логического вивода». Дата взятия информации: 20.12.12.
[12] Тимчук О.С. Перспективное направление развития вычислительного интеллекта в индустрии видеоигр / О.С. Тимчук // Проблеми інформаційних технологій. 2012. №11. с. 128 135
Таблица А1. Этап 1
Состояние Фактор |
Потребность в пище |
Потребность в воде |
Потребность во сне |
Уровень страха |
сытость |
1.0 обр |
0.1 обр |
||
уровень жидкости |
0.2 обр |
1.0 обр |
||
усталость |
0.5 |
0.5 |
1.0 |
0.3 |
здоровье |
0.3 обр |
0.3обр |
0.5 обр |
0.5 обр |
расстояние до бл. объекта |
0.6 обр |
|||
степень опасности бл. объекта |
1.0 |
|||
эмоциональная устойчивость |
0.3 обр |
0.7 обр |
Таблица А2. Этап 2
Состояние Фактор |
Желание приближения к ближайшему объекту |
Желание удаления от ближайшего объекта |
Активность |
Уровень страха |
0.9 |
0.2 |
|
Потребность в бл. объекте |
1.0 |
0.5 обр |
|
Степень опасности бл. объекта |
0.4 обр |
||
Потребность во сне |
0.3 |
0.9 обр |
|
Сытость |
0.7 |
Таблица А3. Условное представление системы
Состояние Фактор |
Потребность в пище |
Потребность в воде |
Желание приближения к ближайшему объекту |
Желание удаления от ближайшего объекта |
Активность |
сытость |
1.0 обр |
0.1 обр |
? |
? |
? |
уровень жидкости |
0.2 обр |
1.0 обр |
? |
? |
? |
усталость |
0.5 |
0.5 |
? |
? |
? |
здоровье |
0.3 обр |
0.3обр |
? |
? |
? |
расстояние до бл. объекта |
? |
? |
? |
||
степень опасности бл. объекта |
? |
? |
? |
||
эмоциональная устойчивость |
? |
? |
? |
||
Потребность в бл. объекте |
? |
? |
? |
Таблица А4. Последний этап
Состояние Фактор |
Действие |
Потребность в пище |
0.7 обр |
Потребность в воде |
0.8 обр |
Желание приближения к ближайшему объекту |
1.0 |
Желание удаления от ближайшего объекта |
1.0 обр |
Активность |
0.6 |
1) Файл stage1.xml:
<STAGE id="1">
<systemInfo>
<NumLIs>7</NumLIs>
<NumLOs>4</NumLOs>
</systemInfo>
<LI id="0" name="Feedness">
<x>0;0.05;0.1;0.15;0.2;0.25;0.3;0.35;0.4;0.45;0.5;0.55;0.6;0.65;0.7;0.75;0.8;0.85;0.9;0.95;1;</x>
<MF id="0" name="starving">
<lmf>0.5;0.35;0.1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>1;1;0.8;0.5;0.3;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="1" name="hungry">
<lmf>0;0;0;0;0;0.5;0.7;0.3;0.12;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0.333333333333333;0.666666666666667;1;0.75;0.5;0.25;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="2" name="tolerable">
<lmf>0;0;0;0;0;0;0;0;0;0;0.5;0.6;0.33;0.12;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0;0;0;0;0;0.4;0.7;1;0.8;0.5;0.25;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="3" name="fed">
<lmf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.2;0.3;0.6;0.8;0.9;1;1;1;</lmf>
<umf>0;0;0;0;0;0;0;0;0;0;0;0;0.123;0.4;0.6;0.666666666666667;1;1;1;1;1;</umf>
</MF>
</LI>
<LI id="1" name="Water">
<x>0;0.05; 0.1;0.15;0.2;0.25;0.3;0.35;0.4;0.45;0.5;0.55;0.6;0.65;0.7;0.75;0.8;0.85;0.9;0.95;1;</x>
<MF id="0" name="drought" color="Blue">
<lmf>1;1;1;1;1;0.75;0.5;0.25;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>1;1;1;1;1;0.8;0.6;0.4;0.2;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="1" name="tolerable" color="Yellow">
<lmf>0;0;0;0;0;0;2.77555756156289E-16;0.25;0.5;0.75;1;0.666666666666666;0.333333333333333;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0;0;0.166666666666667;0.333333333333333;0.5;0.666666666666667;0.833333333333333;1;0.75;0.499999999999999;0.25;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="2" name="enough" color="Orange">
<lmf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.2;0.4;0.6;0.8;1;1;1;</lmf>
<umf>0;0;0;0;0;0;0;0;0;0;0;0;3.70074341541719E-16;0.166666666666667;0.333333333333334;0.5;0.666666666666667;0.833333333333334;1;1;1;</umf>
</MF>
</LI>
. . . . . . . . . .
2) Файл stage2.xml:
<STAGE id="2">
<systemInfo>
<NumLIs>5</NumLIs>
<NumLOs>3</NumLOs>
</systemInfo>
<LI id="0" name="Fear">
<x>0;0.05; 0.1;0.15;0.2;0.25;0.3;0.35;0.4;0.45;0.5;0.55;0.6;0.65;0.7;0.75;0.8;0.85;0.9;0.95;1;</x>
<MF id="0" name="fearless">
<lmf>1;1;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>1;1;1;0.666666666666667;0.333333333333333;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="1" name="confident">
<lmf>0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0.333333333333333;0.666666666666667;1;0.666666666666666;0.333333333333333;0;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="2" name="holds on">
<lmf>0;0;0;0;0;0;0;0;0;0.5;1;0.499999999999999;0;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0;0;0;2.77555756156289E-16;0.25;0.5;0.75;1;0.75;0.499999999999999;0.25;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="3" name="scared">
<lmf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;2.22044604925031E-15;1;0.666666666666666;0.333333333333333;0;0;0;</lmf>
<umf>0;0;0;0;0;0;0;0;0;0;0;0;7.40148683083438E-16;0.333333333333334;0.666666666666667;1;0.75;0.499999999999999;0.25;0;0;</umf>
</MF>
<MF id="4" name="terrified">
<lmf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.500000000000001;1;1;1;</lmf>
<umf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.333333333333334;0.666666666666667;1;1;1;</umf>
</MF>
</LI>
<LI id="1" name="Need for the nearest object">
<x>0;0.05;0.1;0.15;0.2;0.25;0.3;0.35;0.4;0.45;0.5;0.55;0.6;0.65;0.7;0.75;0.8;0.85;0.9;0.95;1;</x>
<MF id="0" name="unnesessary">
<lmf>0.5;0.35;0.1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>1;1;0.8;0.5;0.3;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="1" name="low">
<lmf>0;0;0;0;0;0.5;0.7;0.3;0.12;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0.333333333333333;0.666666666666667;1;0.75;0.5;0.25;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="2" name="medium">
<lmf>0;0;0;0;0;0;0;0;0;0;0.5;0.6;0.33;0.12;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0;0;0;0;0;0.4;0.7;1;0.8;0.5;0.25;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="3" name="high">
<lmf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.2;0.3;0.6;0.8;0.9;1;1;1;</lmf>
<umf>0;0;0;0;0;0;0;0;0;0;0;0;0.123;0.4;0.6;0.666666666666667;1;1;1;1;1;</umf>
</MF>
</LI>
. . . . . . . . . .
3) Файл coeffs.xml:
<COEFFICIENTS>
<stage id="1">
<factor id="0" name="Feedness">
<coeffs>1,0; 0,1; 0,0; 0,0;</coeffs>
<function>0;0;1;1;</function>
</factor>
<factor id="1" name="Water">
<coeffs>0,2; 1,0; 0,0; 0,0;</coeffs>
<function>0;0;1;1;</function>
</factor>
<factor id="2" name="Tiredness">
<coeffs>0,5; 0,5; 1,0; 0,3;</coeffs>
<function>1;1;1;1;</function>
</factor>
<factor id="3" name="Health">
<coeffs>0,3; 0,3; 0,5; 0,5;</coeffs>
<function>0;0;0;0;</function>
</factor>
<factor id="4" name="Distance to the nearest object">
<coeffs>0,0; 0,0; 0,0; 0,6;</coeffs>
<function>1;1;1;0;</function>
</factor>
<factor id="5" name="Danger of the nearest object">
<coeffs>0,0; 0,0; 0,0; 1,0;</coeffs>
<function>1;1;1;1;</function>
</factor>
<factor id="6" name="Emotional stability">
<coeffs>0,0;0,0;0,3;0,7;</coeffs>
<function>1;1;0;0;</function>
</factor>
</stage>
<stage id="2">
<factor id="0" name="Fear">
<coeffs>0,0;0,9;0,2;</coeffs>
<function>1;1;1;</function>
</factor>
<factor id="1" name="Need for the nearest object">
<coeffs>1,0;0,5;0,0;</coeffs>
<function>1;0;1;</function>
</factor>
<factor id="2" name="Danger of the nearest object">
<coeffs>0,4;0,0;0,0;</coeffs>
<function>0;1;1;</function>
</factor>
<factor id="3" name="Need for sleep">
<coeffs>0,0;0,3;1,0;</coeffs>
<function>1;1;0;</function>
</factor>
<factor id="4" name="Feedness">
<coeffs>0,0;0,0;0,7;</coeffs>
<function>1;1;1;</function>
</factor>
</stage>
</COEFFICIENTS>
4) Файл stage_last.xml:
<RESUTING>
<systemInfo>
<NumLIs>5</NumLIs>
<NumLOs>1</NumLOs>
</systemInfo>
<LI id="0" name="Need for food">
<x>0;0.05; 0.1;0.15;0.2;0.25;0.3;0.35;0.4;0.45;0.5;0.55;0.6;0.65;0.7;0.75;0.8;0.85;0.9;0.95;1;</x>
<MF id="0" name="unnecessary">
<lmf>1;1;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>1;1;1;0.666666666666667;0.333333333333333;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="1" name="slightly">
<lmf>0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0.333333333333333;0.666666666666667;1;0.666666666666666;0.333333333333333;0;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="2" name="medium">
<lmf>0;0;0;0;0;0;0;0;0;0.5;1;0.499999999999999;0;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0;0;0;2.77555756156289E-16;0.25;0.5;0.75;1;0.75;0.499999999999999;0.25;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="3" name="needs">
<lmf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;2.22044604925031E-15;1;0.666666666666666;0.333333333333333;0;0;0;</lmf>
<umf>0;0;0;0;0;0;0;0;0;0;0;0;7.40148683083438E-16;0.333333333333334;0.666666666666667;1;0.75;0.499999999999999;0.25;0;0;</umf>
</MF>
<MF id="4" name="urgent">
<lmf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.500000000000001;1;1;1;</lmf>
<umf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.333333333333334;0.666666666666667;1;1;1;</umf>
</MF>
</LI>
<LI id="1" name="Need for water">
<x>0;0.05; 0.1;0.15;0.2;0.25;0.3;0.35;0.4;0.45;0.5;0.55;0.6;0.65;0.7;0.75;0.8;0.85;0.9;0.95;1;</x>
<MF id="0" name="unnecessary">
<lmf>1;1;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>1;1;1;0.666666666666667;0.333333333333333;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="1" name="slightly">
<lmf>0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0.333333333333333;0.666666666666667;1;0.666666666666666;0.333333333333333;0;0;0;0;0;0;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="2" name="medium">
<lmf>0;0;0;0;0;0;0;0;0;0.5;1;0.499999999999999;0;0;0;0;0;0;0;0;0;</lmf>
<umf>0;0;0;0;0;0;2.77555756156289E-16;0.25;0.5;0.75;1;0.75;0.499999999999999;0.25;0;0;0;0;0;0;0;</umf>
</MF>
<MF id="3" name="needs">
<lmf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;2.22044604925031E-15;1;0.666666666666666;0.333333333333333;0;0;0;</lmf>
<umf>0;0;0;0;0;0;0;0;0;0;0;0;7.40148683083438E-16;0.333333333333334;0.666666666666667;1;0.75;0.499999999999999;0.25;0;0;</umf>
</MF>
<MF id="4" name="urgent">
<lmf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.500000000000001;1;1;1;</lmf>
<umf>0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.333333333333334;0.666666666666667;1;1;1;</umf>
</MF>
</LI>
. . . . . . . . . .
5) Файл coeffs_last.xml:
<COEFFICIENTS>
<stage>
<factor id="0" name="Need for food">
<coeffs>0,7;</coeffs>
<function>0;</function>
</factor>
<factor id="1" name="Need for water">
<coeffs>0,8</coeffs>
<function>0;</function>
</factor>
<factor id="2" name="Wish to get closer">
<coeffs>1,0;</coeffs>
<function>1;</function>
</factor>
<factor id="3" name="Wish to move away">
<coeffs>1,0</coeffs>
<function>0;</function>
</factor>
<factor id="4" name="Activity">
<coeffs>0,6</coeffs>
<function>1;</function>
</factor>
</stage>
</COEFFICIENTS>
Рис. В1. Основная форма клиента в начальный момент времени
Рис. В2. Консоль сервера в начальный момент времени после
Рис. В3. Основная форма клиента после действия пользователя
Рис. В4. Консоль сервера после действия пользователя
Рис. В5. Основная форма клиента
Рис. В6. Форма подключения к серверу
Рис. В7. Форма клиента для другой модели поведения персонажа (хвост “_ex”)
Таблица 7. Результаты нечёткого логического вывода
Значения факторов |
Состояния |
Действие |
0 | 0 | 0 | excited | high || running
0 | 0 | 0,01 | excited | high || running
0 | 0 | 0,02 | excited | high || running
0 | 0 | 0,03 | excited | high || running
0 | 0 | 0,04 | excited | high || running
0 | 0 | 0,05 | excited | high || running
0 | 0 | 0,06 | excited | high || running
0 | 0 | 0,07 | excited | high || running
0 | 0 | 0,08 | excited | high || running
0 | 0 | 0,09 | excited | high || running
0 | 0 | 0,1 | excited | high || running
0 | 0 | 0,11 | stressed | high || neutrality
0 | 0 | 0,12 | stressed | high || neutrality
0 | 0 | 0,13 | stressed | high || neutrality
0 | 0 | 0,14 | stressed | high || neutrality
0 | 0 | 0,15 | stressed | high || neutrality
0 | 0 | 0,16 | stressed | high || neutrality
0 | 0 | 0,17 | stressed | high || neutrality
0 | 0 | 0,18 | stressed | high || neutrality
0 | 0 | 0,19 | stressed | high || neutrality
0 | 0 | 0,2 | stressed | high || neutrality
0 | 0 | 0,21 | stressed | high || neutrality
0 | 0 | 0,22 | stressed | high || neutrality
. . . . . . .
0 | 0,76 | 0,13 | scared | medium || aggression
0 | 0,76 | 0,14 | scared | medium || aggression
0 | 0,76 | 0,15 | scared | medium || aggression
0 | 0,76 | 0,16 | scared | medium || aggression
0 | 0,76 | 0,17 | scared | medium || aggression
0 | 0,76 | 0,18 | scared | medium || aggression
0 | 0,76 | 0,19 | scared | medium || aggression
0 | 0,76 | 0,2 | scared | medium || aggression
0 | 0,76 | 0,21 | scared | medium || aggression
0 | 0,76 | 0,22 | scared | medium || aggression
0 | 0,76 | 0,23 | scared | medium || aggression
0 | 0,76 | 0,24 | scared | medium || aggression
0 | 0,76 | 0,25 | scared | medium || aggression
0 | 0,76 | 0,26 | scared | medium || aggression
0 | 0,76 | 0,27 | scared | medium || aggression
. . . . . . .
А также другие работы, которые могут Вас заинтересовать | |||
75213. | Национальный язык. Формы его существования и образования | 34 KB | |
Национальный язык. Формы его существования и образования Национальный язык это важнейшая форма. Каждый национальный язык состоит из основной его части литературного языка и развитых диалектов. Диалекты: Территориальные на определенной территории могли стать национальными языками как провансальский язык на юге Франции. | |||
75214. | КУЛЬТУРА И НАУКА США ПОСЛЕ ВТОРОЙ МИРОВОЙ ВОЙНЫ. СОВРЕМЕННАЯ НАУКА И КУЛЬТУРА США | 19.68 KB | |
КУЛЬТУРА И НАУКА США ПОСЛЕ ВТОРОЙ МИРОВОЙ ВОЙНЫ. СОВРЕМЕННАЯ НАУКА И КУЛЬТУРА США После Второй мировой войны центр мирового искусства переместился из Парижа в НьюЙорк. Кино главный вид искусства и всей культуры США. Классическая музыка в США находится на высоком уровне. | |||
75215. | Образование английского национального языка | 37.5 KB | |
Fisk fisker рыба древне-английский Sun sunner сын К концу X века господство было преодолено образовались Уэссекские королевства. К концу средне-английского периода начало XV века грамматический строй сильно изменился. С конца XV века образование раннего ново-английского языка XVI конец XVII первые десятилетия XVIII. К концу XV века появляются первые типографии. | |||
75217. | Понятие литературного языка | 36 KB | |
Понятие литературного языка Литературный язык играет очень важную роль. Это нормированный язык. Свойства: Нормированность Поливалентность многофункциональность Общеобязательность Стилистическая дифференцированность Функциональная дифференцированность Носит наддиалектный характер носители диалектов понимают этот язык. Например койне может использоваться носителями разных диалектов Имеет свою письменность Норма может быть различной в разные периоды существования языка. | |||
75219. | Язык как предмет языкознания. Язык и речь | 21.65 KB | |
Определений языка очень много. Самое известное дал Ферденанд де Соссюр(швейцарский лингвист): Язык — это система произвольных знаков. | |||
75221. | Социолингвистика. Макросоциолингвистика и Микросоциолингвитсика | 20 KB | |
Социолингвистика область в которой рассматривается проблематика и вопросы соотношения языка и общества. Керри Вопросами связанными с проблемами соотношения языка и общества занимались и до 20-ого века но термин Социолингвистика появился... | |||