Презентация, Аудиозапись, Статья, Материалы
Основной задачей являлась разработка приложения для исполнения кода, написанного пользователем на особом языке стекового калькулятора. Особое внимание при разработке было уделено скорости интерпретации кода. Также необходимо было предоставить пользователю инструментарий для более удобной разработки на этом языке.
Основной компонент программы — это класс Interpreter, выполняющий код на языке стекового калькулятора, одну команду за другой. Некоторые инструкции языка позволяют «подменить» адрес текущей команды, что вызовет пропуск участка кода или его повторное исполнение, однако с точки зрения интерпретатора код остается линейным.
Все переменные, создаваемые пользователем, помещаются в оперативную память виртуальной машины, организованную по принципу стека. Стек — это структура данных, реализующая метод доступа к данным LIFO: первый сохраненный (push) в нее элемент будет извлечен (pop) последним. Такая концепция доступа к данным лучше всего «ложится» на принцип работы интерпретатора. Так как стек не позволяет получить доступ только к последнему сохраненному в нем элементу, а пользователю может потребоваться значение переменной, которая была создана ранее, был предусмотрен так называемые регистр: место промежуточного хранения переменных. Пользователь может «переложить» переменную из стека в регистр, а потом вернуть ее обратно.
Участок кода, начиная с некоторого адреса и заканчивая командой return, называется функцией. При вызове функции будет сохранен адрес возврата, то есть адрес команды, которая выполнится после функции. Все адреса возвратов также помещаются в стек. Если в коде встретится нескольких последовательных вызовов функций, последовательный переход по сохраненным адресам возвратов позволит «распутать» цепочку вызовов.
Каждой команде языка стекового калькулятора сопоставлена функция на языке C++, выполняющая некоторую операцию со стеком, регистром, стеком адресов возвратов или адресом текущей команды. Оповещение пользователя об ошибках происходит с помощью исключений.
Важно отметить, что интерпретатор работает не с текстовыми названиями команд, такими как call, goto, sin и т.д., а с их числовыми кодами, так как сравнение чисел происходит гораздо быстрее, чем строк. Разумеется, разработчику было бы неудобно пользоваться такой системой команд, поэтому было разработано вспомогательное приложение — транслятор. Транслятор производит замену текстовых названий на их числовые коды, удаляет из кода лишние переносы строк и комментарии, подставляет фиктивный нулевой аргумент для команд, не требующих аргумента. Результат работы записывается в бинарный файл с расширением CALC.
Так как система команд может меняться, для выявления проблем совместимости используется сигнатура. Сигнатура — это четыре символа, записанные в самом начале файла. Перед началом работы интерпретатор проверит сигнатуру в исполняемом файле и, в случае несоответствия, выдаст ошибку.
В реальной жизни нередко возникает ситуация когда человек-фотограф заменяется просто фотоаппаратом, делающим снимки автоматически, что естественно для современного общества. На более профессиональном уровне используются фотосистемы. Однако фотооборудование в отличие от человека не может выбрать, какой кадр удачный, а какой нет. А выбирать из нескольких десятков кадров тот, на котором хотя бы присутствует лицо, занятие весьма утомительное.
Задача обнаружения лица на изображении является более чем простой для человеческого зрения, однако при попытке построения автоматической системы обнаружения лиц приходится сталкиваться со многими сложностями.
Задача обнаружения лица на изображении (face detection) часто является "первым шагом", предобработкой в процессе решения задачи более высокого уровня (например узнавания определенного лица, распознавания выражения лица и др). Однако и сама информация о присутствии и, возможно, количестве лиц на изображении или в видеопотоке может быть полезна для таких приложений, как охранные системы и содержательная индексация базы данных изображений или видеофрагментов.
Цель проекта – автоматизировать выборку фотографий на основе алгоритма обнаружения лица.
Задачей работы была разработка простого и удобного приложения с дружественным интерфейсом для автоматического выбора наиболее удачных фотографий.
Примером использования программы стала автоматическая фотосистема аквапарка. Камера в заранее выбранном месте с наилучшим обзором интересующей нас части горки фотографирует проезжающих людей. Профессиональное оборудование производит съемку по команде датчика движения, и затем из многих фотографий требуется выбрать хотя бы те, на которых лицо направлено в сторону камеры. Также желательно выбрать то лицо, которое расположено в верхней части (въезжает на горку, а не выезжает с нее).
Для этой цели необходимо распознать лицо. Программа делает изображение монохромным и производит фильтрацию по алгоритму Собеля, а затем бинаризизацию по методу Отса. Далее изображение сравнивается с эталоном, созданным на основе статистки. Условия правильной работы программы: все фотографии получаются с одной неподвижной камеры. Поэтому перед запуском приложение позволяет сократить время его работы, а именно на одной из фотографий выделить область, в которой может находиться лицо (сокращает область поиска) и выделить глаза человека (сокращает количество вариантов).
Программа написана на языке С++ с использованием кроссплатформенной библиотеки интерфейса Qt. Это также позволяет сократить время программы, так как ускоряется работа с изображениями и их отображениями на экран.
Презентация, Аудиозапись, Материалы
Целью работы является разработка компьютерной игры «Degeneration» (жанр Тамагочи), в основе которой находится искусственный интеллект, который может сам выбирать свои действия, приводящие к определённым последствиям.
Программа заключается в следующем. Существует некий объект, обладающий «интеллектом», и моделируется жизнь этого объекта, причём он сам «выбирает» свои действия. Пользователь может влиять на ситуацию, меняя условия и, в итоге, улучшая или ухудшая состояние своими действиями.
В процессе разработки искусственного интеллекта основной парадигмой разработки было выбрано автоматное программирование. На это большей частью повлияло то, что автоматное программирование является наиболее удобным для создания данного типа интеллекта, благодаря понятию состояния автомата и облегчённому поиску ошибок, так как несоответствия между предполагаемым и реальным поведением удавалось обнаружить почти сразу.
Основная работа над интеллектом заключалась в том, чтобы правильно составить алгоритм действий и при этом сохранить более-менее реалистичную модель поведения и состояний
Создание программы состояло из трёх этапов. Первый этап – собственно создание интеллекта. Интеллект создаётся в виде алгоритмической таблицы, вводятся команды, какие действия выполнять, при каких условиях. Затем наступает второй этап. Интеллект рисуется в MS Visio в виде алгоритмической схемы, и при помощи Visio2Auto схема переводится в исходный код. Третий этап заключается в дописывании полученного кода и приведении программы в конечный вид.
Интеллект состоит в следующем: рассматривается состояние объекта и, если состояние чего-либо критично, то выполняется наиболее приоритетное действие, затем опять рассматривается его состояние и опять выполняется действие и так далее.
Презентация, Аудиозапись, Материалы, Сайт проекта
Целью работы являлось создание анимационной игры Bomberman.
При написании использовалась среда Dev-Cpp и компилятор GCC.
Содержание игры состоит в следующем: два человечка (Bomberman`ы) бегают по полю и кидаются бомбами. Но у них на пути есть препятствия (подрываемые и неподрываемые стены). Также на карте лежат бонусы (ускорение, количество бомб, длина взрыва). Цель игры – человечки должны друг друга подорвать.
Первая часть работы состоялась в том чтобы написать первый прототип игры Bomberman.
Вторая часть работы состояла в том, чтобы написать карту и стены, редактор карт и генератор карт. В редакторе карты можно добавлять стены и бонусы, удалять их и менять местоположение bomberman`ов. При редактирования карты можно менять местоположение bomberman`ов. Затем можно сохранить карту с расширением .bmm (BomberMan Map).
Задачей третьей части работы было осуществить игру по сети с помощью WinSock2.
Презентация, Аудиозапись, Материалы
LLVM – это относительно новый компилятор, поддерживающий основные языки программирования общего назначения (такие как C, C++, FORTRAN, Java и т.д.). LLVM транслирует эти языки во низкоуровневый, универсальный для всех платформ и языков байт-код, который может быть сохранён в файл. LLVM умет компилировать этот байт-код в машинный код, может его интерпретировать, а так же может его компилировать прямо в процессе исполнения по мере надобности (так называемая, JIT-компиляция).
В Институте системного программирования (ИСП) РАН проводится исследовательский проект по динамической перекомпиляции кусков кода с учётом профиля программы. Подобные техники уже эффективно применяются в высокоуровневых языках, таких как Java и C# и есть надежда, что динамические оптимизации будут эффективны и для низкоуровневых языков. Работа проводится на базе JIT-компиляции LLVM с использованием инструмента OProfile для сбора профиля.
Презентация, Аудиозапись, Материалы
Целью работы явилось создание и последующее тестирование сетевого движка, разработанного на языке C++ для использования в OS Windows. Для реализации движка используются технологии сокетов.
Сокеты (sockets) представляют собой высокоуровневый абстрактный интерфейс взаимодействия с различными протоколами связи, что делает их доминирующей технологией, используемой при создании сетевых приложений.
Движок рассчитан на использование в сетевых приложениях с архитектурой клиент-сервер. Сервер – это главная часть системы. Он занимается обработкой информации и организацией работы дочерних элементов системы – клиентов. От сервера зависят возможности и скорость работы всей системы.
Движок имеет развитую объектно-ориентированную архитектуру, которая делает его использование более удобным. Код движка полностью документирован, в его документацию включены уроки, поэтапно описывающие процесс создания сервера и клиента. Чтобы использовать движок, достаточно обладать только базовыми знаниями языка C++.
В презентации приведены результаты тестирования движка на скорость работы и занимаемый объем оперативной памяти. Исходные коды движка полностью открыты.
Презентация, Аудиозапись, Материалы
В работе представлена программа, решающая японский кроссворд – головоломку, ответом на которую является чёрно-белая картинка. Базовая задача – научиться заполнять отдельную строку, которая может быть как пустой, так и частично заполненной. Для этого динамически строится конечный автомат, описывающий любую строку, содержащую чёрные блоки заданной длины. Чтобы избежать конечного перебора, на основании автомата строится таблица, содержащая информацию о возможных вариантах заполнения клеток строки. Также рассматривается вариант решения «сложного» случая: когда, располагая имеющимися данными, невозможно однозначно определить цвет ни одной клетки.
Презентация, Аудиозапись, Материалы
Целью данной работы являлась разработка и реализация алгоритма визуализации ландшафта. За работу с ландшафтом отвечает класс XTerrain, включённый в состав движка XEngine. Для рисования рельефа местности классу необходимы:
Конечно, неудобно передавать всё это в функцию создания ландшафта или писать в файле карты. Поэтому были введены файлы вида .xterrain, которые по структуре абсолютно одинаковы с файлами типа xcfg (файлы конфигурации движка XEngine). В них содержится вся информация о том, как визуализировать ландшафт. Чтобы отобразить ландшафт надо в файле xlvl (файлы карты движка XEngine) описать его.
Далее ландшафт превращается в меш (сетку треугольников), который представляется классом XMesh. Этот класс основан на использовании интерфейса ID3DXMesh из DirectX и класса движка XMaterial. Этот класс – оболочка для ID3DXMesh. В связи с некоторыми неудобствами в его использовании: например, материалы в нём не хранятся. При превращении ландшафта в меш он делится на субмеши (части меша). Это необходимо для использования технологии LoD (levels of detai, уровней детализацииl) к ландшафту, которая в настоящее время разрабатывается. Также превращение ландшафта в меш оптимизирует его, так как в DirectX есть стандартные функции оптимизации меша. Таким образом мы имеем возможность не обособлять ландшафт относительно других мешей. Обособление происходит, если ландшафт имеет свои буферы индексов и вершин в DirectX.
После этого в функции Render класса XTerrain остаётся только вызвать Render от всех его частей, которые они хранятся в классе ландшафта.
Таким образом, класс XTerrain движка XEngine отвечает за загрузку, рисование и удаление ландшафта. В этом ему помогает класс XMesh, представляющий произвольный меш. Эта технология уравнивания мешей, созданных самостоятельно и мешей, загруженных из файлов, позволяет не приводить алгоритмы, предназначенные для любой сетки треугольников к какому-либо частному случаю – например в ситуации с алгоритмом LoD и ландшафтом.
Презентация, Аудиозапись, Материалы
Множество Мандельброта вопреки распространённому мнению является не просто красивым фракталом, а несёт в себе глубокий смысл, характеризую динамическую систему, заданную каким-либо отображением комплексной плоскости. Всем известная "красивая фрактальная картинка" является изображением множество Мандельброта Z2 + C. Для других отображений его отображение может выглядеть совсем иначе. Так как множество Мандельброта задаётся математически, мы можем описывать это множество на основе "особых" точек (состояний) динамической системы отображения, не прибегая к построению самого множества. На основе сопоставления численных расчетов динамической системы, полученных в maple и изображения множества Мандельброта в программе fractal explorer была выдвинута гипотеза о том, как именно связаны "особые" точки с областями множества. Далее потребовалось проверить эту гипотезу, а также выдвинуть какую-либо более фундаментальную, но для этого требовалось сопоставить достаточно большое количество численных расчетов с изображениями множества, поэтому этот процесс стал слишком трудоёмким. Чтобы облегчить задачу было принято решение о написании программы, которая решала бы следующие проблемы:
С помощью разработанной программы был проверен ряд гипотез о структуре множества Мандельброта, она также применяется для выдвижения новых. Так как исследование множество будет продолжаться, возможности программы будут расти по мере надобности.
Для быстрого построения была применена технология распределённых вычислений NVIDIA CUDA. В докладе и статье вводятся необходимые определения и описываются методы, используемые для описания и построения множества, а также приводятся результаты работы программы.
При проведении телевизионной съёмки массовых мероприятий, таких как футбольные матчи или концерты, режиссёрам для получения эффектной и яркой картинки приходится прибегать к различным ухищрениям, устанавливать камеры в нестандартных местах. Всё это позволяет получить лишь статичные кадры. Динамичную картинку из любой точки можно получить только с камеры, «летающей» над снимаемым пространством.
Для реализации подобной функциональности в компании «Роботизированные съёмочные системы» разрабатывается тросовая система свободного перемещения в пространстве RobyCam. Камера подвешена на четырёх тросах, идущих в углы снимаемого пространства. Длинами тросов можно управлять с помощью прецизионных роботизированных электролебёдок. Управляя длинами тросов можно задавать любое перемещение камеры.
Лебёдками по цифровому каналу управляет вычислительный сервер. Он в реальном времени осуществляет расчет всех параметров системы, принимает команды от пульта управления и рассчитывает скорости вращения лебёдок, необходимые для перемещения камеры в нужном направлении. Пульт управления получает данные от джойстиков, с которыми работает оператор, передаёт команды управления вычислительному серверу, а так же выводит на экран основную информацию по состоянию системы: схематичное изображение снимаемого пространства, текущее положение камеры и некоторые числовые параметры.
Большое внимание при разработке системы уделяется безопасности. Оператор может задать границы в снимаемом пространстве, за которые камера попасть не может. При возникновении неполадок в лебёдках, проблем со связью между любыми модулями системы, проблем с вычислением состояния системы и при других подобных проблемах производится экстренное прекращение работы.
В будущем планируется разработка автоматического управления системой на основе заранее записанных движений или заранее заданных траекторий.
Презентация, Аудиозапись, Материалы
В последнее время компьютерная 3d графика в реальном времени становиться всё более популярной. Многие компьютерные программы, в которых она используется (в основном компьютерные игры) имеют схожий функционал, связанный с графикой частью и используют одинаковые графические алгоритмы и методы. Игровой движок – это основа 3d программы (в основном игр), реализующая базовые алгоритмы. В основные задачи игрового движка входит загрузка ресурсов игры, управление ресурсами, их отображение и обработка, а также расчёт взаимодействия игровых объектов и управление игровыми объектами.
В настоящее время существует множество как платных, так и свободно распространяемых игровых движков. Однако бесплатные игровые движки не лишены многих серьёзных недостатков, например, таких как низкая производительность, нестабильная работа, плохая переносимость на другие компьютеры, неработоспособность на старых маломощных компьютерах, закрытый исходный код и сложность расширения функциональности. Значительная часть недостатков в той или иной мере обусловлена тем, что многие из этих движков разрабатывались как универсальные движки для решения любых задач. Эта универсальность понижает, прежде всего, производительность и стабильность работы движка. Некоторые движки поддерживают сразу несколько различных графических API (например, OpenGL и DirectX). Многие из них являются мультиплатформенными. Одним из достоинств таких движков может оказаться относительная удобность использования и расширяемость, но из-за универсальности движка архитектура становится сложной и запутанной, а такая архитектура нередко понижает производительность движка и надёжность его работы. С другой стороны в сложной архитектуре затруднительно вносить изменения, так как они могут нарушить работу движка в целом. Нередко такие движки основываются на управляемых языках программирования (например, на C#), что ещё больше замедляет их работу.
Целью работы является создание собственного игрового движка, названного XEngine. Он предназначается для разработки многоагентных игровых автоматных систем. Разработка собственного движка оказалась необходимой по причине того, что в виду специфичности предназначения и высоких требований проанализированные бесплатные игровые движки оказались не подходящими для создания многоагентных автоматных систем. Главными требованиями, предъявляемыми к движку, являются высокая производительность, простая и понятная архитектура, обеспечение стабильности его работы на различных компьютерах, а также на маломощных старых компьютерах. Ещё одно из основных требований – это поддержка управления игровыми объектами с помощью конечных автоматов. Для реализации этой возможности было использовано инструментальное средство Visio2Auto. При всём этом движок должен поддерживать множество различных популярных форматов ресурсов для облегчения разработки ресурсов в сторонних редакторах. Исходя из этих требований, было принято несколько архитектурных решений. С целью повышения производительности было решено отказаться от поддержки нескольких платформ, а также нескольких графических API, в результате в основе движка лежит графический API DirectX, а сам движок работоспособен на операционных системах семейства Windows.
Архитектура игрового движка XEngine включает в себя понятие модуля и ядра движка. Ядро занимается синхронизацией работы модулей. Модуль движка – это автономная подсистема, обеспечивающая какую-либо функциональность. Например, на данный момент в движке присутствуют графический модуль, модуль звуковой системы, физический модуль (отвечающий за расчёт взаимодействия объектов), система игровых объектов (отвечающая за поведение объектов), система скриптов (поддерживаются скрипты на языке lua). Функционал движка может быть расширен путём добавления нужного модуля.
В результате работы была создана первая версия игрового движка XEngine, которая удовлетворяет поставленным требованиям. Движок используется в автоматной многоагентной системе Auto2Kill.
Презентация, Аудиозапись, Материалы
Целью доклада является рассказ о командной разработке платформы автоматного моделирования и методах, которые применялись в процессе разработки для повышения эффективности работы команды. Разработка проекта началась в марте 2009 года. Сначала команда разработчиков состояла из двух человек, начиная с ноября 2009 года, команда стала состоять уже из пяти человек.
Сложность реализации данного проекта состоит в большом объёме работы и маленьких сроках выполнения. Очевидно, что в таких условиях необходима командная разработка. Командная разработка, безусловно, ускоряет процесс создания платформы, но в то же время возникают некоторые дополнительные сложности в процессе разработки, которые не настолько значимы, когда проект разрабатывается одним человеком, однако при командном подходе они могут даже замедлить разработку или полностью остановить её. Эти трудности в первую очередь связаны с синхронизацией. Различные люди разрабатывают части одного большого проекта, которые необходимо синхронизировать и собирать платформу в целом. Чем менее взаимосвязаны эти части, тем менее проявляется проблема синхронизации, но части одного проекта не могут быть невзаимосвязаны. В качестве решения этой проблемы было использовано хранилище данных (сервис dropbox). У каждого разработчика имеется собственная папка, в которой он постоянно выкладывает свои результаты на данный момент. Через определённое количество времени происходит общая синхронизация и сборка проекта. После этого результат общей сборки является следующей версией проекта и также содержится на dropbox.
Разработка проекта была разделена на два этапа. Первым этапом разработки было прототипирование платформы с использованием стороннего игрового движка NeoAxis. Прототип послужил для исследования возможности создания платформы автоматного моделирования и выявление проблем, которые могут появиться при её разработке. С помощью прототипа становится возможным тестирование различных элементов проекта и подходов, определение наилучших путей их реализации без больших затрат временных ресурсов. К началу лета 2009 года прототип был создан и имел некоторую часть функциональности платформы. Однако на этом этапе разработки проекта обнаружились сложности, которые оказались не преодолимыми при продолжении использования движка NeoAxis. Поскольку среди доступных бесплатных игровых движков не нашлось подходящих для создания платформы и удовлетворяющих всем требованиям, было принято решение о написании собственного игрового движка. Второй этап разработки начинается после принятия этого решения. Он делится на две задачи: написание собственного игрового движка и создание самой платформы автоматного моделирования на основе собственного движка.
В процессе командной разработки платформы, оказалось, необходимо чётко определять минимальный набор задач, который следует реализовать к определённому сроку для достижения требуемой функциональности платформы. Эти задачи нужно распределить по разработчикам, которые их будут выполнять и для каждой задачи определить срок её выполнения. В противном случае работа команды становится неэффективной, так как выполняются лишние задачи, а необходимые задачи остаются не выполненными, что в результате приводит к не успеванию в срок. Другим важным фактором является приоритет задач. В зависимости от приоритета, сложности выполнения задачи, а также риска невыполнения задачи определяется порядок, в котором задачи должны быть реализованы. Для этого используется квадрат “риск-приоритет”.
Презентация, Аудиозапись, Video (EN, SIGGRAPH-2009), Demo (EN, SIGGRAPH-2009)
Современные GPU, благодаря своей программируемости, могут быть использованы не только для выполнения традиционных задач растеризации, но и для ускорения альтернативных подходов построения изображения. Такие подходы, как трассировка лучей и REYES, хорошо зарекомендовали себя в индустрии фотореалистичного и кинематографического рендеринга, но при этом являются весьма сложными для расчета в реальном времени.
В данном докладе автор показывает, как современные GPU и технология NVIDIA CUDA могут быть использованы для достижения интерактивной скорости работы данных алгоритмов, а также рассказывает об общих приемах решения задач с нерегулярной нагрузкой на параллельных вычислительных системах.
Презентация, Аудиозапись, Материалы
Различные виды шумов были изучены на примере создания эффекта "нарисованного" интерфейса. Для искажения неестественных прямых линий использовались :
Наилучший результат показал Шум Перлина, поэтому было отдельно исследовано его применение в одномерном (как функция на координатной прямой), двумерном (для создания статических процедурных текстур) и трёхмерном (для создания динамических процедурных текстур) видах.
Презентация, Аудиозапись, Материалы
Скелетная анимация - это метод создания анимации, который широко используется в 3D графике и позволяет ценой небольшого понижения скорости программы экономить большое количество памяти. В скелетной анимации начальная модель оснащается вершинами, которые меняют своё положение, и костями, которые собственно влияют на вершины. В двумерной анимации затраты на загрузку и рендеринг сокращаются до минимума и остаётся только одна задача - скиннинг. В докладе будут рассмотрены алгоритмы скиннинга (нахождения положения вершин на основе костей), авторазвесовки (нахождения веса каждой кости, то есть величину её влияния на вершины, без участия пользователя) и натягивания - изменение уже существующей модели в растровом формате в соответствии с перемещением вершин.
Очевидные плюсы рассмотренного подхода - снижение затрат на анимацию, так как промежуточные фреймы можно без потери качества рассчитать автоматически, а также снижение веса файла. Большинство алгоритмов скиннинга незначительно искажают качество исходного изображения.
Данная работа является частью крупного командного проекта Auto2Kill, использующего автоматное программирование для искусственного интеллекта.
Цель работы – реализация интерпретатора конечных автоматов с загрузкой из XML-файла. Язык XML был выбран по причине его простой структуры и универсальности.
Интерпретатор написан на языке C++ с использованием ООП, наследуемых классов и технологии исключений. При помощи наследования была реализована поддержка отдельного модуля загрузчика, что позволяет использовать разные источники загрузки (не только XML). Также была реализована поддержка двух архитектурно разных режимов взаимодействия клиентского приложения и интерпретатора. В качестве XML-загрузчика (парсера) было предложено использовать библиотеку tinyxml. После исследования её интерфейса было решено написать собственный парсер с более удобным интерфейсом и большей скоростью загрузки. В качестве интерпретатора логических выражений в настоящее время используется движок Lua, но в дальнейшем он будет заменен на собственный анализатор.
Библиотека XML-парсера также написана на языке C++. Она состоит из двух элементов — лексического анализатора, разбивающего входную строку на поток лексем, и синтаксического анализатора, строящего дерево элементов из лексем. Лексический анализатор написан с использованием алгоритма Рабина-Карпа. Синтаксический анализатор использует технологию конечных автоматов и рекурсивный разбор.
После загрузки автоматной модели из XML-файла выполняется её первичный разбор. Все встречающиеся выражения разбиваются на лексемы, состояниям присваиваются порядковые номера. Затем, в зависимости от требуемой модели взаимодействия, клиентское приложение должно либо загрузить указатели на переменные и функции выходных воздействий, либо установить указатели на функции обмена данными (callback). Выполнение автоматной модели пошаговое и находится в отдельной функции. Во время очередного шага выполнения каждое выражение-условие преобразуется в строку с разыменованием всех переменных. Полученное логическое выражение проверяется на правильность и вычисляется. Затем (в случае перехода) изменяется текущее состояние и выполняются все выходные воздействия.
При реализации были использованы технологии ООП с использованием наследования, виртуальных и шаблонных классов.
Работа выполнена в среде приложения Adobe Flash, язык программирования – ActionScript 2.0. Целью работы являлось создание анимационной игры-головоломки. В различной сложности лабиринтах имеются кольца разного цвета. При соприкосновении колец одного цвета они исчезают. Цель игры – уничтожить все кольца. Трудность игры состоит в том, что колец одного цвета обычно нечетное количество, либо кольца расположены так, чтобы их трудно было совместить друг с другом. В игре ведется журнал команд, что позволяет отменять сделанные шаги, а также сохранять найденное решение, которое при желании можно загрузить и просмотреть. Лабиринты загружаются из текстового файла, что позволяет легко добавлять к игре новые головоломки.
Работа выполнена в среде приложения Adobe Flash, язык программирования – ActionScript 2.0. Цель программы - создание игры «Паззлы» из любых изображений, даже непосредственно заданных пользователем, например, в образовательных целях. При этом сложность игры (число деталей, на которые нарезается картинка) выбирается пользователем. Сборка пазлов из схем, таблиц, фотографий помогает лучше их запомнить. Работа с паззлами проходит в игровой форме, и поэтому может служить дополнительным учебным пособием для учеников младшей школы.
Работа выполнена в среде приложения Adobe Flash, язык программирования – ActionScript 3.0. Целью работы было создание игры, в которой моделируется движение объектов (ракет и снарядов) в среде с настраиваемой плотностью, с различной силой притяжения как со стороны «планет», так и со стороны ракет.