Уровнем ниже располагается работа с интерфейсами, которые пользователь получает от ядра движка это интерфейс самого ядра и интерфейс сцен. По архитектурной концепции сцены это уровень который организует работу с объектами игрового пространства на высоком уровне исключая необходимость в ручную вызывать методы рендеринга или например обработчики управления. На этом уровне теоретически могут использоваться любые языки программирование совместимые с COM, но нами изначально поддерживается лишь три основных языка это - C++, C# и Delphi. С этого же уровня осуществляется управление уровнем выше т.е. скриптовой системой, регистрация в ней классов или привязки скрипта к какому либо объекту окружения игры или просто некой сущности.

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

Ну и самый низкий уровень это разработка плагинов для движка. Сразу оговорюсь, что тут имеются в виду не основные системные плагины вроде рендера, хотя пользователь, конечно же, может попытаться разработать свой, но это все таки лучше оставить разработчикам движка. Имеются в виду плагины подключаемые к подсистемам движка. На рис.3 изображено, что плагины могу подключаться допустим к файловой системе расширяя тем самым ее функционал. К примеру пользователь может реализовать плагин, который будет загружать текстуры формата изначально не предусмотренного в движке. На этом уровне уже можно работать и с аппаратным обеспечением компьютера на прямую, делать допустим прямые запросы к жесткому диску или обращения к OpenGL, но этого делать не рекомендуется т.к. это может привести к некорректной работе и потере кроссплатформерности. К примеру, возможна ситуация когда в плагине используются OpenGL вызовы, но к движку в данный момент подключена Direct3D система рендеринга, в этом случае ядро отключит неработоспособный плагин и его функционал будет недоступен, по этому при попытке использовать его функции из конечного приложения возникнет ошибка, которая приведет к остановк работы системы (как обрабатываются подобные ситуации ядром будет описано в соответствующем разделе). Для избежание подобных ситуаций подсистемы к которым подключаются пользовательские плагины должны предоставлять им набор интерфейсов оперируя которыми пользователь может реализовать требуемый функционал.

Размещено на http://www.allbest.ru/

Рис. 4 Схема уровней абстракции DPE

2.7 Проектирование и разработка ядра движка

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

И последним, но не менее важным требованием является быстродействие ядра. Принципиальным тут скорее даже является скорость с которым ядро будет обеспечивать межмодульное взаимоедействие.

Тем самым мы определили три основных требования к ядру системы

· Стабильность в работе

· Обеспечение наименьшего, но достаточного функционала для обеспечения эффективного управления плагинами и их взаимодействия

· Максимальное быстродействие как самого ядра, так и обеспечиваемого им межмодульного взаимодействия

2.8 Проектирование ядра

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

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

Рис. 5 Архитектура ядра системы DPE

2.9 Приступая к разработке ядра

Первое с чего началась разработка движка, а следовательно и всей системы в целом это выбор языка реализации и IDE(Interactive Developer Environment). Тут в принципе все было понятно и вполне очевидно, в качестве языка был выбран С++, т.к. на данный момент только он позволит написать быстродействующее кроссплатформерное приложение, а в качестве IDE - Microsoft Visual Studio 2008.

Изначально было решено разрабатывать движок под платформу Win32, но не использую никаких технологий и решений которые в дальнейшем могли бы помешать портированию кода на другие платформы.

Работа была организована с использованием SVN(Subversion) серверера для синхронизации и хранения исходных кодов. Это было сделано для того, что бы не возникало проблем если несколько разработчиков будут работать над одним и тем же фрагментом программы. Хотя я разрабатывал ядро по большому счету в одиночку, эта система была необходима для организации работы над всем проектом в целом.

Subversion -- централизованная система. Данные хранятся в едином хранилище. При сохранении новых версий используется дельта-компрессия, т. е. система находит отличия новой версии от предыдущей и записывает только их, избегая ненужного дублирования данных[11]. Хранилище может располагаться на локальном диске или на сетевом сервере. К локальному хранилищу клиент Subversion обращается непосредственно. Для доступа к удалённому серверу может использоваться собственный сетевой протокол или стандартный протокол WebDAV, поддерживаемый с помощью специального модуля для веб-сервера Apache.

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

В качестве сервера мы поставили компьютер на базе P3, установили на него FreeBSD в дистрибутиве которого сразу есть поддержка протоколов SVN. Открыли доступ в Интернет и настроили Web интерфейс, все это пришлось делать через консоль т.к. такую слабую машину не хотелось и без того загружать графическим интерфейсом.

В качестве клиентской программы была выбрана, пожалуй, наиболее распространенная Tortoise SVN которая удобно встраивается в контекстное меню Windows, вместе с ней на компьютер устанавливается программ KoDiff которая позволяет отслеживать изменения в файле если его изменяло несколько человек и приводить файл к единому виду с учетом всех внесенных изменений.

2.10 Разработка систем ядра

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

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

Следующей важной задачей основного класса ядра является организация бесконечного цикла в приложении. Тут стоит оговориться, что мы имеем дело с приложением которое работает в реальном времени и постоянно непрерывно выводит(рендерит) графику на экран, с максимальной скоростью которую позволяет оборудование на котором оно запущено. И в тоже время есть вещи, которые следует вызывать с определенным четко регламентированным интервалом, например обрабатывающие игровую логику. При этом нельзя использовать стандартные таймеры т.к. у них в стеке сообщений Windows самый низкий приоритет и задержки могут достигать 100 мс., что недопустима для игры, когда частота вызова процедуры обработки процесса обычно 20-30 мс. Теперь я думаю важно обозначить что вся концепция игрового приложения работающего в реальном времени строится на разделение процедуры отрисовки графики (рендеринга) и процедуры обработки игровой логики, которая вызывается с определенной периодичность (процедура процесса). Причем основной бесконечный цикл программы нужно было организовать таким образом что бы прямо из него вызывалась как процедура рендеринга, так и процедура процесса. Причем если к примеру процедура рендеринга занимает допустим 50 мс. машинного времени на выполнение, а периодичность процедуры процесса составляет 10 мс., то процедура процесса будет вызываться в пять раз реже чем следовало и игровой процесс будет происходить медленнее, появится торможение. Я придумал решение, которое частично решает эту проблему.

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

DWORD Time = GetTimer();

DWORD Time_Delta = Time - _Time_Old;

bool flag = false;

for (int i = 0; i<(int)(Time_Delta/_ProcInterval); i++)

{

if ( !_pause ) Process();

flag = true;

}

if ( flag ) _Time_Old = Time - Time_Delta % _ProcInterval;

Render();

Для того что бы отслеживать время была реализована процедура GetTimer которая является высокоточным счетчиком на основе тиков процессора.

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

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

Делегат -- типобезопасный указатель на функцию.

Необходимость возникло в связи с тем что в процедурах процесса и рендеринга может быть много вызовов неких пользовательских процедур, которые регистрируются по средствам указателей на метод класса или процедуру. По этому для удобства и избегания ошибок в памяти были введены делегаты. Реализовывать их пришлось своими силами т.к. в С++ в отличие от более высоко уровневых языков вроде C# или Delphi изначально они не предусмотрены. В дальнейшем делегаты пригодились и в других системах ядра.

Основной класс ядра реализовывает два интерфейса один - для пользователя, другой - для плагинов.

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

Пример вызова методов записи в журнал из кода программы.

log->Info("© //DeeProSoft// 2007-2008 (__www.deeprosoft.com__)");

В этом случае в текстовой реализации запишется строчка выше, а в html реализации сгенерируется следующий html код:

<td><font size='3' color='#000000' face='Verdana'> © <i>DeeProSoft</i> 2007-2008 (<u>www.deeprosoft.com</u>) </font></td></tr>

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

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

С технической точки зрения реализация подобной системы достаточно простая задача.

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

Так же система менеджмента занимается отключением не используемых плагинов и переподключением зависших. Подключение плагинов происходит только при инициализации системы.

Как уже писалось выше изначально движок пишется под систему Win32, по этому следующим логичным шагом стала реализация подсистемы взаимодествия с WinAPI. Основной задачей такой системы является создание Win32 окна и предоставление его в качестве пространства рендеринга системе рендера. Так же в этой системе должна быть сокрыта вся рутина связанная с обработкой WinAPI сообщение посылаемых операционной системой окну. Необходимо было реализовать две подобные системы, первая - создавала свое окно и управляла им, а вторая - позволяла перехватывать окно или компонент чужого приложения и производить рендеринг в него. Обе реализации имели единый интерфейс, что позволи в дальнейшем вместо WinAPI использовать, например, XWindow. Если с необходимостью первой реализации все понятно, то вторая была необходима для тех случаев, когда есть необходимость производить рендеринг в небольшую часть окна контроль над которым расположен не в самом движке, а за его приделами в пользовательском приложении. Подобная необходимость возникает не для игр а для прикладных приложений с визуализацией графики в реальном времени. Для перехвата окна чужого приложения использовались так называемые «ловушки»(Window Hooking). После реализации четырех основных пунктов выше ядро уже являлось вполне работоспособным. К этому моменту у нас уже был частично реализован плагин системы рендеринга и мы начали проводить первые тестирования системы в целом. И практически сразу возникла необходимость управлять системой в реальном времени т.е. без перекомпиляции и изменения исходных кодов, а непосредственно в процессе ее работы менять какие либо параметры или запускать на выполнение заранее написанные куски кода. Для реализации поставленной задачи было необходимо сделать отладочную консоль, наподобие той, которые используются в операционных системах. Консоль должна была релизовывать достаточно простой но необходимый функционал:

· Отображение отладочной информации в окне в реальном времени

· Выполнять команды

· Быть просто и удобной в эксплуатации

· Позволять просто регистрировать новые команды и переменные

· Работать независимо от сиситемы и стабильно, для того что бы можно было производить отладку зависшей системы

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

Консоль работала в своем отдельном потоке, что позволило сделать ее независимой и добиться того, что даже если основной класс ядра завис из консоли можно было выполнят некоторый набор отладочных команд. Хотя иногда при зависании ядра возникала ситуация когда войдя в критическую секцию консоли основной класс ядра не успевая из нее выйти зависал, а поток консоли уже не мог в нее войти и находился в ожидании. Подобная ситуация называется DeadLock. Частична эта проблема была решена тем что основной класс ядра входил в критическую секцию консоли не при каждой итерации своего цикла, а лишь в исключительных случаях, но полностью решить проблему судя по всему не представляется возможным, впрочем, если зависала какая либо из подсистем ядра, а не само ядро отладку из консоли можно было осуществлять без каких либо проблем. По этому очень важно сделать ядро максимально стабильным и защищенным от зависаний и ошибок. Команды в консоле может регистрировать любая подсистема движка. По этому было важно избежать путаницы среди команд и сделать так что бы и другие разработчики могли понимать назначения и использовать команды реализованные их коллегами. Для этого в принудительном порядке при регистрации любой новой команды обязательным условием было описание ее функционала по определенному шаблону. Которое можно было посмотреть в консоли выполнив командe «help» передав ей в качестве параметра имя другой команды. Ниже я приведу приме регистрации процедуры в консоли и переменной:

Console::RegComProc("quit","Quits engine and releases all resources.",&conquit);

Console::RegComValue("fps_in_caption","Displays current fps value in window caption.",&fps_to_caption,0,1);

Конечно, функционал консоли не ограничивается этими возможностями, но они являются основными.

Рис. 6 Консоль в процессе отладки

Таким образом был разработан достаточно удобный инструмент отладки системы в реальном времени.

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

Требуемая для движка система событий должна обладать следующими основными свойствами:

· ООП архитектуру

· Возможность передавать любое количество параметров любого типа

· Совместимость с другими языками, а именно Delphi и C#

· Для получения и обработки сообщений подсистемы ничего не должны знать друг о друге

· Высокое быстродействие т.к. поток сообщений может быть очень большим

Для удовлетворения всех описанных выше требовании было принято решения о реализации системы сообщений на основе интерфейсов.

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

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

Ниже я привожу пример генерации ядром некого события:

IWinEvent *wEvent = new WinEvent(EV_WIN_MESSAGE, message, wParam, lParam);

wEvent->Send();

wEvent->Release();

Это событие создается когда окно движка получает какую либо Win32 сообщение операционной системы. Интерфейс IWinEvent понаследован от стандартного интерфейса IEvent. Далее любая подсистема подписавшаяся на сообщение EV_WIN_MESSAGE получит его и сможет обработать в своем обработчике, выглядеть это будет примерно так:

void CWinAPI_Input::MessageProc( IEvent* Event )

{

UINT message = NULL;

WPARAM wParam = 0;

LPARAM lParam = 0;

IWinEvent *wEvent = dynamic_cast<IWinEvent *>(Event);

wEvent->GetParam(&message, &wParam, &lParam);

}

Таким образом в своем обработчике подсистема извлекает параметры из пришедшего сообщение и может осуществлять с ними дальнейшую работу.

Основная файловая система должна обеспечивать предоставление другим подсистемам файлы в универсальном формате, для этого были определены специальные интерфейсы. IFTexture, например, содержит в себе универсальный формат в который можно записать практически любой тип текстуры. Для других подсистем были реализованы схожие интерфейсы. К основной файловой системы подключаются плагины реализующие загрузку файлов различного формата и осуществляющих работу с паками и физически с фалами на диске. По этому вся задача основной файловой системы сводится к тому что бы передавать соответствующие интерфейсы между плагинами самой файловой системы и подсистемами движка. К примеру, что бы загрузить текстуру из пака сначала будет определен плагин, который работает с этим типом файлов, если он найден, то запрос будет переадресован ему. Этот плагин обработав запрос возвращает универсальный интерфейс IFile в основную файловую систему, далее файловая система ищет другой плагин который реализует загрузку такого рода текстур и если он найден, то передает этот интерфейс ему. Теперь уже этот плагин выполняет обработку файла и формирует универсальный интерфейс текстуры IFTexture, который он возвращает основной файловой системе. Основная файловая система уже перенаправляет его подсистеме рендеринга, которая осуществляет загрузку, после чего интерфейс IFTexture освобождается из памяти.

На рисунке 7 приведена схема файловой системы DPE.

РРис. 7 Схема файловой системы DPE

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

Рис. 8 Перехват необрабатываемого исключения

Для реализации системы скриптования было решено использовать готовый скриптовый движок Lua.

Lua -- интерпретируемый язык программирования, разработанный подразделением Tecgraf Католического университета Рио-де-Жанейро (Computer Graphics Technology Group of Pontifical Catholic University of Rio de Janeiro in Brazil). Является свободно распространяемым, с открытыми исходными текстами на языке Си.

По возможностям, идеологии и реализации язык ближе всего к JavaScript, однако Lua отличается более мощными и гораздо более гибкими конструкциями, спроектирован с целью «не плодить сущности сверх необходимого». Хотя Lua не содержит понятия класса и объекта в явном виде, механизмы объектно-ориентированного программирования с поддержкой прототипов (включая множественное наследование) легко реализуются с использованием метатаблиц, которые также позволяют перегрузку операций и т. п. Реализуемая модель ООП (как и в JavaScript) -- прототипная.

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

Заключение

В ходе выполнения дипломного проекта был спроектирован игровой движок DeeProEngine.

Налажена работа коллектива по разработке подсистем движка.

Мною было спроектировано и реализовано ядро системы.

На данный момент движок в является уже работоспособным программным пакетом и применяется в ряде коммерческих проектов выполняемых компанией «DeeProSoft».

Следовательно можно с уверенностью сказать что все поставленные задачи были успешно достигнуты.

Библиографический список

Размещено на Allbest.ru