ID: 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].

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

1. ПОСТАНОВКА ЗАДАЧИ

Разработать программный продукт, реализующий адаптивную модель управления компьютерным персонажем. Модель должна представлять из себя реализованный алгоритм определения поведения персонажа на основе дискретной нечёткой логики второго типа. Программный продукт должен быть написан в виде клиент-серверного приложения. При реализации алгоритма необходимо выполнить следующие пункты:

Построить XML-файлы, управляющие нечётким логическим выводом.
Создать блок, определяющий состояния персонажа по входным факторам.
Создать блок, выполняющий построение базы правил по результатам, полученным при определении состояний.
Создать блок, определяющий действие персонажа по данным из базе правил.
Создать графическое представление, позволяющее пользователю изменять значения входных факторов и наблюдать результаты нечёткого логического вывода.
Использовать библиотеку нечёткого логического вывода DIT2FLS для выполнения операций над нечёткими множествами второго типа.
Распределить функциональность приложения между клиентской и серверной частями.
Определить входные и выходные данные для клиентской и серверной частей.
Организовать отправку и получение сообщений клиентом и сервером.
Обеспечить разбор сообщений в нужные структуры данных и корректное использование их функциональными частями клиента и сервера.

2. ОБЗОР ПОДХОДОВ

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

Существует множество подходов для разработки систем поддержки принятия решений, к примеру, корреляционный и регрессионный анализ, сценарные методы, теория игр и т. д. Данные подходы либо имеют ограничения на применение в связи с высокой вычислительной сложностью, а, соответственно, значительным временем принятия решений и высокой себестоимостью таких систем, либо являются слишком простыми и бесперспективными. В существующих моделях параметры игры рассматриваются либо как чёткие, либо с использованием нечёткой логики только первого типа. Эти модели являются либо не адаптивными, либо частично адаптивными и не учитывают в полной мере неопределённость, которой обладают КП по причине вымышленности их свойств и поведения. Это обуславливает предопределённость сценария игры, в результате чего игрок в определённый момент осмысливает алгоритм принятия решений компьютерными персонажами и теряет интерес к игре.

Для преодоления трудностей в разработке моделей управления поведением КП новым актуальным подходом является разработка развивающегося интеллекта. Любая развивающаяся интеллектуальная система является адаптивной системой, способной к обучению. Целью данного подхода является моделирование функционирования человеческого мозга (обучение, память, абстрактное мышление и т.д.) для создания саморазвивающихся, самообучаемых и адаптивных систем [12].

В данной работе создаётся модель управления поведением персонажа, основанная на нечёткой логике второго типа. Для обеспечения адаптивности модель реализует организацию памяти и обучаемость КП с помощью динамически изменяемой базы нечётких правил.

3. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ ЧАСТИ ПРИЛОЖЕНИЯ

3.1 Математическая модель компьютерного персонажа

3.1.1 Объекты нечёткой логики

Для описания объектов, фактов и явлений в нечёткой логике используются такие понятия, как нечёткое множество, нечёткая переменная, лингвистическая переменная.

Пусть нечёткое множество второго типа определено на универсальном множестве 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].

3.1.2 Управление поведением компьютерного персонажа

Поведение компьютерного персонажа представляет собой последовательность действий, которые определяются в каждый момент времени, когда это необходимо (когда изменяются факторы, которые влияют на персонаж). Действие, которое персонаж производит в данный момент времени, определяется его состояниями в этот момент.

Действия, факторы и состояния описываются лингвистическими переменными. В контексте данного задания для лингвистической переменной может существовать входное значение и активированные этим значением термы. Действия являются термами результирующей лингвистической переменной. Тогда можно записать:

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].

3.1.3 База правил

База правил является моделью «памяти» компьютерного персонажа и позволяет ему «обучаться». Если в начальный момент времени действие КП руководствуется только входными факторами (база правил пуста), то начиная со второго – уже и «памятью».

На вход модуля нечёткого логического вывода подаются значения входных факторов. В процессе обработки этих данных формируются нечёткие правила. Эти нечёткие правила добавляются в базу правил за предыдущий момент времени. которые сгенерировались в текущий момент времени. либо копируется в неё полностью в начальный момент.

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 устанавливает обратную зависимость между максимальным размером базы правил и скоростью её обновления. Для малых баз правил декремент будет выше и новые правила будут записываться в больших объёмах, для больших – наоборот.

3.1.4 Этапы

Может возникнуть ситуация, в которой, по мнению эксперта, моделирующего поведение компьютерного персонажа, определить некоторые состояния персонажа до определения других невозможно по той причине, что, последние зависят от первых. Тогда возникает необходимость поэтапного расчёта состояний. Сначала рассчитываются состояния, которые зависят только от факторов. На каждом следующем этапе рассчитываются те состояния, которые зависят только от факторов и от уже вычисленных состояний. В данной работе представлен пример с двухэтапным определением активированных термов состояний (см. Контрольные примеры).

3.2 Структура XML-файлов

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

3.2.1 Файлы с лингвистическими переменными

Файл с названием вида stageJ.xml описывает систему входных и выходных лингвистических переменных для этапа J. Последний этап – этап вывода действия из состояний, описывается таким же образом и имеет одну выходную ЛП и столько входных ЛП, сколько выходных состояний.

Для этапов J-1 и J характерно, что описание входных переменных для этапа J совпадает с описание выходных переменных этапа J-1.

Общий вид файла:

</systemInfo>

</MF>

. . .

</LI>

. . . . .

</MF>

. . .

</LO>

. . . . .

Теги:

<systemInfo> - информация о системе

<NumLIs> - количество входных ЛП

<NumLOs> - количество выходных ЛП

<LI> - входная ЛП

<LO> - выходная ЛП

<x> - универсальное дискретизированное множество, на котором определены термы ЛП, состоящее из NX точек

<MF> - нечёткое множество (терм)

<lmf> - значения нижней функции принадлежности, NX значений

<umf> - значения верхней функции принадлежности, NX значений

Файл с названием stage_last.xml также описывает систему входных и выходных ЛП, в которой входными ЛП являются ЛП конечных состояний (не влияющих ни на какие другие состояния), а выходной – единственная результирующая ЛП, описывающая действия компьютерного персонажа.

3.2.2 Файлы с коэффициентами

Файл с названием вида coeffs.xml описывает коэффициенты и функциональные зависимости выходных лингвистических переменных (состояний) от входных (факторов) для выполнения логического вывода.

Общий вид файла:

</factor>

. . .

. . .

</factor>

</stage>

Теги:

<stage id=”n”> - контейнер, в котором описываются коэффициенты и зависимости состояний от факторов на этапе n.
< factor id=”k” name=”Namek”> - контейнер, в котором описываются коэффициенты и зависимости состояний от конкретного фактора k.
<coeffs> - описывает набор коэффициентов функциональных зависимостей состояний от фактора k.
<function> - описывает набор функциональных зависимостей состояний от фактора k.
сm – коэффициент функциональной зависимости состояния m от фактора k.
fm – функциональная зависимость состояния m от фактора k. 1 – прямая f(x) = x; 2 – обратная f(x) = 1 – x.

Последний контейнер stage (с наибольшим id) описывает влияние состояний на действие.

3.2.3 Файлы правил

Файл с названием RuleBase.xml описывает правила, содержащиеся в базе правил. Общий вид файла:

</systemInfo>

<if_values> av1; av2; … ; avN </if_values>

<then_values> cv1; cv2; … ; cvM </then_values>

</R>

. . . . .

Теги:

<systemInfo> - информация о системе ЛП

<NumLIs> - количество факторов

<NumLOs> - количество конечных состояний

<NumRs> - количество правил в базе

<R> - правило

<if> - антецеденты, N целых чисел, соответствующих активированным термам факторов

<if_values> - конкретные значения, активировавшие термы факторов

<then> - консеквенты, M целых чисел, соответствующих активированным термам конечных состояний

<then_values> - конкретные значения, активировавшие термы конечных состояний

<s> - уверенность в правиле, S ϵ [0; 1]

3.3 Операции нечёткого вывода

В таблице №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

3.4 Архитектура функциональной части приложения.

Функциональная часть приложения представлена отдельным модулем DLL (проект Visual Studio .NET Framework C# Class Library), который можно удобно подключать и использовать в других проектах. Название LogicalOutput.dll, namespace - LogicalOutput.

На рис.1 изображена диаграмма взаимодействия всех классов модуля LogicalOutput.dll.

Рис. 1. Диаграмма взаимодействия классов функциональной части

3.4.1 Классы представления данных

Классы предназначены для удобного представления данных важнейших объектов логического нечёткого вывода вместе с функциями их обработки. Эти классы обёрнуты в namespace LogicalOutput.DataClasses.

Класс LInfo. Представляет расширенную информацию о лингвистической переменной, обладает несколькими перегруженными конструкторами. Поля:
DataSystemLib.DataSystem.L L – представление самой ЛП из модуля DataSystemLib.dll, разработанного в прошлой курсовой работе.
Double[] left, right – массивы правых и левых границ термов ЛП.
List<int> activated – список номеров активированных термов.
List<double> MUs – список функций принадлежности (уверенностей), соответствующих активированным термам.
Double value – входное значение для этой ЛП
Класс StageInfo. Представляет суммарную расширенную информацию об этапе нечёткого вывода, обладает несколькими перегруженными конструкторами, функциями-сеттерами и функциями геттерами. Поля:
List<LInfo> IN – список объектов LInfo, описывающих входные факторы
List<List<LInfo>> OUTs – список списков LInfo. Внутренний список представляет один из вариантов наборов состояний, который возникает при логическом выводе в результате рекурсивного перебора.
StageInfo prevStage – предыдущий этап StageInfo.
List<LInfo> prevOUT – один из результатов рекурсивного перебора предыдущего этапа, набор состояний, для которого запустился этот этап.
List<StageInfo> nextStages – следующие этапы, которые породил этот этап в результате рекурсивного перебора.
DataSystem.Sys Sys – представление системы ЛП, которая описывает этот этап, из модуля DataSystemLib.dll, разработанного в прошлой курсовой работе.
int id – идентификатор глубины рекурсии (номер ветви этапов начиная с первоначального этапа)
Класс Rule. Представляет суммарную расширенную информацию о правиле, обладает несколькими перегруженными конструкторами и функциями обработки правил. Поля:
List<int> IF – список антецедентов (номера термов факторов)
List<int> THEN – список консеквентов (номера термов состояний)
List<double> IFvalues, THENvalues – значения, которые активировали термы факторов и состояний
double sertainty – уверенность в правиле, от 0 до 1

Функции:

void CopyFrom(Rule rule) – копирует из rule все значения в данное правило
bool _Equals(Rule rule) - сравнение данного правила с rule по спискам IF и THEN

3.4.2 Функциональные классы

Классы обеспечивают всю функциональность по произведению нечёткого логического вывода. Содержатся в namespace LogicalOutput.

Класс Operations. Содержит функции по произведению операций над нечёткими множествами 2го типа (см. пункт 3.3). Функции:
double[,] determineSummaryFigure – определяет суммарную фигуру при сложении активированных разными факторами термов одного состояния (операция OR), используя также операции понижения типа и дефаззификации из библиотеки DIT2FLS.
void determineTermsAndMUs(List<double> INs, List<LInfo> Ls) – определяет для списка Ls по вектору входных значений INs поля LInfo.activated LInfo.MUs, т.е. активированные термы и им соответствующие функции принадлежности
double[,] Transpose(double[,] o) – транспонирует двумерный массив. Используется для предоставления суммарных фигур в правильном виде методу TypeReducer.GetTypeReduceFS из библиотеки нечёткого логического вывода DIT2FLS.
void purifyLs(List<LInfo> Ls)- для все LInfo в Ls очищает списки activated и MUs.
Класс LogicalOutput. Производит нечёткий логический вывод для установленного ему этапа и записывает результаты в соответствующий этапу переданный экземпляр StageInfo. Функции:
SetNewStage – подготовка(установка) данных для нового этапа
MakeLogicalOutput – запуск нового этапа
buildRulesFile – начало построения файла с правилами для этого этапа (промежуточная база правил) и запуск рекурсивного перебора активированных термов факторов, в процессе которого файл и дозаполняется.
evalLIlines – рекурсивный перебор активированных термов факторов для построения антецедентов. Для каждого набора антецедентов запускается рекурсивный перебор активированных термов состояний (evalLOlines).
evalLOlines – рекурсивный перебор активированных термов состояний для построения консеквентов. Когда определён и консеквент, и антецедент – в файл записывается правило.
determineTermsBorders – реализует функцию определения границ термов ЛП

Класс CoverLogicalOutput. Определяет конечные факторы и состояния из факторов и состояний всех этапов. Управляет запуском этапов. Является посредником между алгоритмом и вызывающим. Хранит суммарную модель базы правил, сформировавшуюся после всех последних запусков механизма нечёткого вывода. Функции:
Prepare – инициализация некоторых данных, определение конечных факторов и состояний (finalLIs, finalLOs). Возвращает список строк, соответствующих конечным факторам
Start – запуск механизма нечёткого логического вывода. Вызывает нерекурсивную перегрузку функции run.
run, нерекурсивная перегрузка. Непосредственно производит по очереди вызовы следующих функций из своего класса, после чего вызывает функции DetermineConditions и DetermineAction класса RulesHandler:
run, рекурсивная перегрузка - получение результатов всех разветвлений этапов, что хранится в StageInfo stage, которая содержит ссылки на такие же объекты StageInfo, которые она породила.
renderLInfoLines – рекурсивная функция, которая из каждой ветви выходных LInfo (StageInfo.OUTs) выбирает наборы тех, которые соответствуют конечным состояниям, и параллельно из этой же ветви из входных LInfo (StageInfo.IN) выбирает наборы тех, которые соответствуют конечным факторам. Для каждой пары таких наборов запускает рекурсивную функцию evalLIbranches.
1. evalLIbranches – перебирает все наборы активированных термов конечных факторов. Для каждого набора запускает рекурсивную функцию evalLObranches.
  1. evalLObranches - перебирает все наборы активированных термов конечных состояний. Внизу этой третьей по вложенности рекурсии формируются те наборы активированных термов конечных факторов и состояний, которые и являются правилами, т.е. антецедентами и консеквентами. Каждое из этих правил сверяется с имеющейся базой правил List<Rule> RuleBase и добавляется, если необходимо (операции по добавлению правил в базу см. в пункте 3.1.3).
WriteRulesXml – записывает правила из RuleBase в файл XML
determineIN – определяет для каждого нового этапа входные значения, выбирая их из входных факторов и уже вычисленных промежуточных состояний, от которых зависят состояния этого этапа.
Класс RulesHandler. Служит обработчиком базы правил для выдачи окончательного результата. Функции:
DetermineConditions – по базе правил определяет те состояния, в которые однозначно перейдёт персонаж.
DetermineAction – запускает единичный этап нечёткого логического вывода, представленный классом LogicalOutput, для определения активированного терма результирующей ЛП, описывающей действие персонажа.
determineLastINs – по активированным термам конечных состояний определяются входные состояния для выполнения последнего этапа логического вывода. Это выполняется с помощью библиотеки DIT2FLS путём выделения каждого терма, проведения операций понижения типа и дефаззификации.

4. ПРОЕКТИРОВАНИЕ КЛИЕНТ-СЕРВЕРНОГО ПРИЛОЖЕНИЯ

4.1 Общие сведения об архитектуре клиент-серверного приложения

В рамках многоуровневого представления вычислительных систем можно выделить три группы функций, ориентированных на решение различных подзадач:

функции ввода и отображения данных (обеспечивают взаимодействие с пользователем);
прикладные функции, характерные для данной предметной области;
функции управления ресурсами (файловой системой, базой данных и т.д.)

Рис.2. Компоненты сетевого приложения

Выполнение этих функций в основном обеспечивается программными средствами, которые можно представить в виде взаимосвязанных компонентов где:

компонент представления отвечает за пользовательский интерфейс;
прикладной компонент реализует алгоритм решения конкретной задачи;
компонент управления ресурсом обеспечивает доступ к необходимым ресурсам.

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

Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты, потребители этих функций [1].

Клиент называется узел сети (компьютер, программа или пользователь), запрашивающий и использующий информацию и/или ресурсы у сервера в рамках архитектуры клиент-сервер. Существует два типа клиентов:

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

Толстый клиент - рабочая станция или персональный компьютер, работающие под управлением собственной дисковой операционной системы и использующие определённый набор программного обеспечения. К серверам такие клиенты обращаются преимущественно за дополнительными услугами, например за информацией. Также под «толстым» клиентом подразумевается и клиентское сетевое приложение, запущенное под управлением локальной ОС. Такое приложение совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).

Архитектуры построения сети:

Двухзвенная модель — архитектура построения сети, предусматривающая один сервер и несколько клиентов, является наиболее простой и распространенной. Недостаток — ограниченное число клиентских рабочих мест.

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

N-звенная модель — архитектура построения сети, предусматривающая наличие нескольких серверов приложений, число которых определяется необходимым уровнем нагрузки сети. При многозвенной модели построения системы количество возможных клиентских мест значительно больше, чем при использовании двухзвенной модели [2, 3].

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

4.2 Концептуальная модель

В данном приложении реализуется модель управления поведением компьютерного персонажа по взаимодействию с персонажем игрока-человека, основанная на нечёткой логике. Поведение компьютерного персонажа может характеризоваться одним из трёх действий относительно персонажа игрока-человека: агрессия, нейтральность, бегство.

Реализация модели представляет из себя модуль, использующий алгоритм нечёткого логического вывода для вычисления необходимых данных. Результатом i –того цикла работы модуля являются правила, которыми пополняется база правил, а также действие, которое он будет выполнять на шаге i, формирующееся на основе пополненной на этом шаге базы правил. Модуль состоит из классов, последовательная работа которых позволяет получить набор правил таких правил на каждом шаге. Логический вывод производится в каждый момент времени, когда персонажу поступает новый набор входных значений. Каждый раз, когда меняется хотя бы одно входное значение, нужно запускать алгоритм логического вывода, то есть устанавливать новые входные данные для модуля и запускать новый цикл работы.

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

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

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

Для обработки информации требуется серверное приложение, способное получать и распознавать запросы, посылаемые клиентами, запускать модуль нечёткого вывода и отправлять информацию о действии, которое должен выполнять компьютерный персонаж. Каждый раз, когда входные данные изменяются пользователем на визуальном представлении клиента, серверной части отправляются новые данные. Для каждого клиента на сервере должна создаваться своя база правил, поскольку у каждого из клиентов визуальное представление будет уникальным.

Потоки информации, передающиеся между клиентом и сервером:

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

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

От сервера клиенту – действие, а также значения состояний которые привели к такому действию. Клиент, получая значения состояний, изменяет визуальное представление для демонстрации пользователю.

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

4.3 Логическая модель

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

Для взаимодействия частей системы используется 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.

4.4 Физическая модель

Класс Socket имеет возможности запуска для асинхронных получения, отправки данных, подключения:

IAsyncResult Socket.BeginAccept(AsyncCallback, Object) – начинает асинхронную операцию, чтобы принять попытку входящего подключения.

AsyncCallback – функция-делегат вида void func(IAsyncResult),

Object – объект сокета для дальнейшей обработки.

IAsyncResult Socket.BeginReceive(Byte[], Int32, Int32, SocketFlags, AsyncCallback, Object) - начинает выполнение асинхронного приёма данных с подключённого объекта Socket.
IAsyncResult Socket.BeginSend(Byte[], Int32, Int32, SocketFlags, AsyncCallback, Object) – выполняет асинхронную передачу данных на подключённый объект Socket.
IAsyncResult Socket.BeginConnect (IPAddress, Int32, AsyncCallback, Object) – начинает выполнение асинхронного запроса для подключения к удалённому узлу, задаваемого IP-адресом IPAddress и портом Int32. В данном приложении используется для проверки связи с сервером.

Класс System.Threading.ManualResetEvent – уведомляет один или более ожидающих потоков о том, что произошло событие. Методы:

Set() – задаёт сигнальное состояние события, позволяя всем ожидающим потокам продолжить.
Reset() – задаёт несигнальное состояние событие, вызывая блокирование всех других потоков.
WaitOne() – блокирует текущий поток до получения сигнала о продолжении.

Клиент-серверное приложение состоит из двух solutions (решений) Visual Studio 2012: Character_Client и Character_Server.

Решение Character_Server отвечает за работу сервера и состоит из четырёх проектов:

Character_Server - основной проект, тип – консольное приложение. Содержит классы по работе с клиентами и вызову функциональности (прослушивание IP-адресов, получение запроса, разбор запроса, формирование ответа, отправка ответа). IP-адрес сервера определяется обратной петлёй, использовавшейся для тестирования – 127.0.0.1, порт, на котором работает сервер – 3456.
Проект модуля нечёткого вывода LogicalOutput, тип – dll.
Проект модуля представления системы лингвистических переменых DataSystemLib, тип – dll.
Проект модуля для чтения XML-файлов ReadXmlLib, тип – dll.

Модуль LogicalOutput.dll

Рис.3. Взаимодействие классов проекта Character_Server

Классы проекта Character_Server :

SocketListener – класс, обеспечивающий прослушивание пространства IP-адресов, получение запросов и отправку ответов. Содержит объект синхронизации ManualResetEvent done для предотвращения одновременного обращения к небезопасным участкам кода. Функции:
StartListening – начинает процесс прослушки. Это реализуется в цикле whilе, на каждой итерации которого происходит попытка серверного сокета принять попытку входящего подключения (Socket.BeginAccept). Перед попыткой все другие потоки блокируются установкой done.Reset(), а после – данный поток устанавливается в режим ожидания сигнала done.WaitOne().
Если попытка успешная, вызывается callback-метод AcceptRequest, запускающий процесс чтения запроса (Socket.BeginReceive c переданной callback-функцией ReadRequest). Эта функция устанавливает сигнальное состояние события done.Set() и прослушка в цикле продолжается.
ReadRequest – завершает процесс получения запроса методом Socket.EndReceiv, который возвращает массив байтов запроса. Массив байтов преобразуется в строку и посылается в экземпляр класса ServerOperations для обработки. Возвращённый им ответ преобразуется в массив байтов и начинается посылка ответа методом Socket.BeginSend, которому передана callback-функция SendResponse.
SendResponse – завершает посылку ответа методом Socket.EndSend, прекращает сессию клиента на сервере методом Socket.Shutdown(SocketShutdown.Both) и закрывает сокет методом Socket.Close. Выдаёт на консоль и в файл лога сервера server_log.txt сообщение о размере отправленного ответа и о завершении операции.
WorkObject – вспомогательный класс, служащий контейнером для передачи в потоки в одном объекте сокета, объекта StringBuilder для преобразования из массива байт в строку и буфера с запросом.
ServerOperations – класс, вызывающий методы модуля LogicalOutput. Содержит набор объектов CoverLogicalOutput для каждого подключившегося клиента. Функция:
PerformOperation(String request) – содержит блок switch с двумя ветвями case :
при поступлении запроса "GET_REQUIRED_IN" создаётся новый экземпляр класса CoverLogicalOutput и возвращается список конечных входных факторов.
при поступлении запроса "GET_ACTION" вызывается метод Start() нужного экземпляра класса CoverLogicalOutput и возвращается список с действием и состояниями персонажа.

Решение Character_Client отвечает за работу клиента и состоит из одного проекта Character_Client, тип – Windows Forms. Содержит классы по работе с сервером (формирование запроса, отправка запроса, получение ответа, разбор строки ответа). Представляет на форме поле с компьютерным персонажем и персонажем игрока-человека и элементы управления TrackBar для управления посылаемыми серверу входными значениями. На форме также имеется StatusBar для отображения в текстовом виде действия и состояний компьютерного персонажа. В верхнем левом углу формы находится кнопка Restart, которая задаёт новые случайные положения изображениям персонажей компьютерного и человека-игрока.

Рис.4 Взаимодействие классов проекта клиента Character_Client

Классы проекта Character_Client :

Client – класс, обеспечивающий подключение к серверу, отправку запросов, получение ответов. Содержит переменные, хранящие IP-адрес и порт сервера. Использует для синхронизации потоков такие объекты (чтобы не допустить одновременного нахождения двух клиентов в опасных участках кода, а также чтобы контролировать моменты начала получения и отправки сообщений) : ManualResetEvent connectDone, ManualResetEvent sendDone, receiveDone.
WorkObject – вспомогательный класс, служащий контейнером для передачи в потоки в одном объекте сокета, объекта StringBuilder для преобразования из массива байт в строку и буфера с запросом.
ClientOperations – вызывает метод Start класса Client, получает ответ от сервера, разбирает его и возвращает разобранные данные. Функции : GetRequiredINnames, GetAction.
FormGUI – класс клиентской формы. В нём запущен таймер, проверяющий наличие нового необработанного набора значений факторов, полученного при изменении трек-баров пользователем. Посылать серверу новые значения моментально после изменения трек-баров нельзя, поскольку обработка данных сервером происходит за определённый промежуток времени. Пока новое действие не вернётся с сервера, нельзя запускать новый логический вывод, поскольку он может произойти быстрее предыдущего (что в значительной мере зависит от размера базы правил, на что влияют в свою очередь количества факторов и состояний, а также этапов) и действие, производимое персонажем, не будет соответствовать последнему вводу значений.

Сообщения и потоки данных между клиентом и сервером:

“GET_REQUIRED_IN;” + tail.

Запрос на получение количества факторов у модели компьютерного персонажа, описанного в xml-файлах, имена которых заканчиваются на tail. Таким образом, tail определяет «семейство» файлов отдельной модели персонажа. Так разные клиенты могут загружать и отображать разные модели. Этот запрос производится при загрузке формы на клиенте, и по полученным данным на форме формируется нужное количество трек-баров, посредством которых пользователь управляет входными значениями факторов. Количество посылаемых байт равно: 16 + tail.length.

Ответ сервера:

На сервере по этому запросу создаётся новый объект класса CoverLogicalOutput из модуля LogicalOutput.dll. Конструктор этого класса возвращает массив строк с именами факторов указанной модели

В ответ сервер посылает строку с подстроками, разделёнными символом ‘;’, количество которых равно количеству факторов, каждая из которых представляет имя фактора. Количество байт меняется в зависимости от длин названий и кол-ва факторов. В консоли сервера, а также в файле server_log.txt пишется количество отправленных клиенту байт.

“GET_ACTION” + IN.

Запрос на получение действия, которое выполнять персонажу. После идентификатора запроса в строку запроса помещаются через строку N чисел типа double от 0 до 1 с точностью до двух знаков после запятой, которые соответствуют входным факторам. Одно дробное число, таким образом, занимает 5 байт вместе с разделителем – ‘;’. Тогда количество отправляемых байт равно: 10 + 5 * N.

Ответ сервера:

На сервере по этому запросу запускается функция объекта класса CoverLogicalOutput Start(). Эта функция возвращает строку, разделённую символом ‘;’ на подстроки. Первая подстрока – действие для персонажа, а каждые следующие две подстроки представляют пару {имя лингвистической переменной состояния; состояние}. Эти пары отображаются в статусной строке клиентской формы, чтобы продемонстрировать изменение состояний, повлиявших на действие. Количество байт: lenA + M * average(lenNameLI + lenNameS). где lenA – длина подстроки действия, average(lenNameLI + lenNameS) – среднее значение суммы длин имён ЛП состояния и состояния

* Числа, использованные при расчёте размеров сообщений, подсчитаны при условии того, что все символы сообщений имеют размер 1 байт. Однако для разных кодировок размер символа может быть разным. К примеру, в кодировке UTF-8 имеются символы размером от 1 до 4 байт.

Действия могут быть такими :

“aggression” – сближение с персонажем игрока-человека
“neutrality” – оставаться на месте
“running” – удаление от персонажа игрока-человека.

В процессе совместной работы клиента и сервера соединение между ними устанавливается только на момент передачи запроса клиентом и получения им ответа. Всё остальное время клиент работает полностью автономно, а сервер производит прослушивание по всем IP-адресам и ожидает подключения. Поэтому при отключении какого-либо из приложений не требуется никаких действий и ничего не происходит в другом приложении. При попытке установки клиентом связи с выключенным сервером или при другой ошибке подключения выдаётся сообщение об этой ошибке с помощью MessageBox. При отключении и повторном включении сервера клиенты имеют возможность с помощью вспомогательной формы FormConnection (рис. В6, приложение В) подключиться к серверу вновь. Для этого необходимо нажать кнопку Connect (с синей стрелкой) в верхней левой части формы.

5. КОНТРОЛЬНЫЕ ПРИМЕРЫ

5.1 Пример работы модуля LogicalOutput

Для демонстрации работы и тестирования модуля была разработана модель компьютерного персонажа, состоящая из двух этапов. Модель описана в таблицах (приложение А) и представлена в XML-файлах (приложение Б). Первый этап (приложение А, таблица. А1) состоит из

7 факторов: сытость, уровень жидкости в организме, усталость, здоровье, расстояние до объекта (персонажа игрока), степень опасности объекта (персонажа игрока), эмоциональная устойчивость

и 4 состояний: потребность в пище, потребность в воде, потребность во сне, уровень страха.

Второй этап (приложение А, таблица. А2) состоит из

5 факторов: уровень страха, потребность в ближайшем объекте (полезность), степень опасности ближайшего объекта, потребность во сне, сытость

и 3 состояний: желание приближения к ближайшему объекту, желание удаления от ближайшего объекта, активность.

Необходимость в создании двух этапов состоит в том, что «желание приближения к ближайшему объекту», «желание удаления от ближайшего объекта» и «активность» зависят не только от факторов, но и от состояний «потребность во сне» и «уровень страха».

Таким образом, если не вникать во внутренние зависимости этой двухэтапной системы, то для наглядности условно можно сказать, что имеется 8 конечных факторов, которые необходимо получить извне модуля нечёткого вывода и 5 конечных состояний (приложение А, таблица. А3), в которых находится персонаж. Поэтому на действие персонажа как факторы будут оказывать влияние эти 5 состояний (приложение А, таблица А4): потребность в пище, потребность в воде, желание приближения к ближайшему объекту, желание удаления от ближайшего объекта, активность.

На таблицах в приложении А зелёным цветом изображены конечные факторы, синим – факторы-состояния, красным – конечные состояния. В пересечении рядов и столбцов находятся коэффициенты влияния фактора их конкретного ряда на состояние конкретного столбца. Пометка «обр.» обозначает, что зависимость обратная, т.е.

f(x) = 1 – x,

отсутствие пометки означает прямую зависимость, т.е.

f(x) = x,

где f(x) – функция получения входного значения для состояния по входному значению фактора.

Файлы, которые описывают модель поведения персонажа (приложение Б):

stage1.xml – описывает ЛП первого этапа
stage2.xml - описывает ЛП второго этапа
coeffs.xml – описывает коэффициенты и функциональные зависимости состояний от факторов на каждом этапе
stage_last.xml – описывает ЛП последнего этапа определения действия
coeffs_last.xml - описывает коэффициенты и функциональные зависимости состояний от факторов на последнем этапе

Когда запускается клиент, форма клиента имеет вид, как на рис.В1 приложения В. Если изменить входное значение фактора Feedness (сытость), то результат можно наблюдать на рис. В3 приложения В:

- в статусной строке выводится выводится, в какие состояния перешёл персонаж и какое действие выполняет:

Рис. 5. Статусная строка формы клиента

- на игровом поле сократилось расстояние между игроком и компьютерным персонажем через некоторое время выполнения действия «агрессия» персонажем.

В процессе работы форма клиента выглядит, как на рис. В5 приложения 5.

Результаты работы модуля в текстовом виде продемонстрированы в приложении Г в виде таблицы. Каждая строка таблицы описывает определённый набор активированных термов факторов, набор активированных термов состояний, которые активизировались при это набор активированных термов факторов и действие, которое предпринимает персонаж. Поскольку модель персонажа, описанная в этом примере, содержит 12 ЛП, для простоты и наглядности представления данных таблица построена для другой модели с 5 ЛП (см. рис. В7 приложения В). В связи с различными правилами, которыми наполняется база, такая таблица является лишь одним из вариантов, поскольку каждый раз база правил была бы разной

5.2 Пример работы клиент-серверного приложения

При запуске сервера в консоли выводится сообщение “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 видим результат загрузки новой модели – названия и количество трек-баров изменилось.

6. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

Запустить сервер 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.

7. СИСТЕМНЫЕ И АППАРАТНЫЕ СРЕДСТВА

Для разработки были использованы средства:

Операционная система Windows 7 Home Premium х64
Среда разработки Microsoft Visual Studio 2012
Технология Windows Forms
объектно-ориентированный язык C#

Минимальные требования для эксплуатации:

Компьютер с операционной системой Windows семейства NT (версии 7, 8, Vista, ХР) x64
Сетевой адаптер Wi-Fi или Ethernet
Процессор 1400 MHz
Оперативная память 512 Мб
Мб памяти на жёстком диске
256 Мб видеопамяти
Установленный .NET Framework версии 4.5 и выше
Мышь
Клавиатура
Дисплей с разрешением 640х480 и выше

ВЫВОДЫ

В результате выполнения курсовой работы было разработано приложение, которое состоит из двух частей – клиентской и серверной и позволяет управлять со стороны клиента действиями компьютерного персонажа. Созданы 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

ПРИЛОЖЕНИЕ A. Таблицы описания модели поведения компьютерного персонажа

Таблица А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

ПРИЛОЖЕНИЕ Б. Примеры XML-файлов

1) Файл stage1.xml:

</systemInfo>

</MF>

</MF>

</MF>

</MF>

</LI>

</MF>

</MF>

</MF>

</LI>

. . . . . . . . . .

2) Файл stage2.xml:

</systemInfo>

</MF>

</MF>

</MF>

</MF>

</MF>

</LI>

</MF>

</MF>

</MF>

</MF>

</LI>

. . . . . . . . . .

3) Файл coeffs.xml:

</factor>

</factor>

</factor>

</factor>

</factor>

</factor>

</factor>

</stage>

</factor>

</factor>

</factor>

</factor>

</factor>

</stage>

</COEFFICIENTS>

4) Файл stage_last.xml:

</systemInfo>

</MF>

</MF>

</MF>

</MF>

</MF>

</LI>

</MF>

</MF>

</MF>

</MF>

</MF>

</LI>

. . . . . . . . . .

5) Файл coeffs_last.xml:

<stage>

</factor>

</factor>

</factor>

</factor>

</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

. . . . . . .

А также другие работы, которые могут Вас заинтересовать
79151.	Доклад	Учение пятидесятников о крещении Духом Святым	11.87 KB
	Внешним признаком КДС для большинства пятидесятников является говорение на иных языках. обладают даром говорения на языках. Учение пятидесятников о КДС которое обязательно должно сопровождаться внешним проявлением в виде говорения на иных языках не находит подтверждение в Св. Так в день пятидесятницы крестилось около 3000 человек но они не говорили на языках Деян.
79152.	Доклад	Пятидесятнические теории говорения иными языками	14.2 KB
	Из Деяний следует что апостолы говорил на национальных языках но в послании к 1Кор. Правда сейчас теория говорения на смешанных языках не получила своего распространения. Писания о предназначении дара говорения на иных языках. Широкое распространение дара говорение на иных языках в ранний период церковной истории было вызвано необходимостью проповедью христианства в языческом и многоязычном мире который требовал знамений служивших для религиозного сознания верующего человека подтверждением истинности какой либо доктрины.

ВВЕДЕНИЕ

1. ПОСТАНОВКА ЗАДАЧИ

2. ОБЗОР ПОДХОДОВ

3. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ ЧАСТИ ПРИЛОЖЕНИЯ

3.1 Математическая модель компьютерного персонажа

3.1.1 Объекты нечёткой логики

3.1.2 Управление поведением компьютерного персонажа

3.1.3 База правил

3.1.4 Этапы

3.2 Структура XML-файлов

3.2.1 Файлы с лингвистическими переменными

3.2.2 Файлы с коэффициентами

3.2.3 Файлы правил

3.3 Операции нечёткого вывода

3.4 Архитектура функциональной части приложения.

3.4.1 Классы представления данных

3.4.2 Функциональные классы

4. ПРОЕКТИРОВАНИЕ КЛИЕНТ-СЕРВЕРНОГО ПРИЛОЖЕНИЯ

4.1 Общие сведения об архитектуре клиент-серверного приложения

4.2 Концептуальная модель

4.3 Логическая модель

4.4 Физическая модель

5. КОНТРОЛЬНЫЕ ПРИМЕРЫ

5.1 Пример работы модуля LogicalOutput

5.2 Пример работы клиент-серверного приложения

6. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

7. СИСТЕМНЫЕ И АППАРАТНЫЕ СРЕДСТВА

ВЫВОДЫ

СПИСОК ССЫЛОК

ПРИЛОЖЕНИЕ A. Таблицы описания модели поведения компьютерного персонажа

ПРИЛОЖЕНИЕ Б. Примеры XML-файлов

ПРИЛОЖЕНИЕ В. Экранные формы

ПРИЛОЖЕНИЕ Г. Результаты нечёткого логического вывода

А также другие работы, которые могут Вас заинтересовать