Разработка механики геймификации
Определение, классификации и ограничения геймификации. Проектирование геймификационного решения. Определение допустимых действий игроков и реакции игры. Процесс создания формы и содержания игрового процесса. Рейтинг и пороги квалификационных уровней.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 04.08.2018 |
Размер файла | 1,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
геймификация игрок решение действие
Таблица 5. Рейтинг и пороги квалификационных уровней
Баллы |
Уровень |
|
0-77 |
0 |
|
78-154 |
1 |
|
155-194 |
2 |
|
195-286 |
3 |
|
287-495 |
4 |
|
496-682 |
5 |
|
683-792 |
6 |
|
793-880 |
7 |
|
881-.... |
8 |
Рассмотрим «Возможный» вариант со средним количеством посещений за месяц и максимальным количеством баллов как модельный для калибровки достижений:
Ср. кол-во баллов за мес.: (1 б. * 8 прод. + 1 б. * 8 опл.) * 22 дня + 2 б. * 65% * 176виз. = 581 б
· Сколько неспросроченных оплат от одного клиента награждаются бейджом: 8 опл * 22 дня / 80 клиентов = 3 оплаты
· Сколько визитов с координатами награждаются бейджом 176 виз. * 85% (из целей геймификации) = 150 визитов
Таким образом, дополненные рассчетами элементы механики геймификацции составляют следующий список:
· Баллы за совершенную продажу. За каждую продажу агент получает 1 балл независимо от объема заказа. Таким образом, агенты, продающие дешевые товары, будут уравнены в рейтинге с агентами, продающими дорогие товары. В один день за одного клиента баллы можно получить один раз.
· Баллы за принятую оплату. 1 балл независимо от объема и срока давности задолженности. См. пункт про заказ. В один день по одному документу-основанию баллы можно получить один раз.
· 2 балла за визит со снятыми координатами
· Рейтинг по заработанным баллам от 0 до 881 балла
· 9 квалификационных уровней в рейтинге
· Сообщения от игры для смягчения проблемных точек
· Бейджи за:
§ Выполнение плана продаж
§ Достижение предпоследнего уровня рейтинга (793 балла)
§ Достижение последнего уровня рейтинга (881 балл)
§ 3 непросроченные оплаты от одного из клиентов течение периода
§ На момент 20 числа месяца не более 10% клиентов с просроченными оплатами
§ 150 визитов с координатами на момент 30 числа месяца
§ Наименьший уровень в рейтинге На момент 20 числа месяца среди всех игроков
§ Последнее место в рейтинге На момент 20 числа месяца среди всех игроков
§ Ни в одном визите за месяц не сняты координаты
Таким образом, итоговый геймифицированный процесс представляет из себя процесс «как есть» с регулярной обратной связью исполнителям, регулируемой логикой, изложенной в механике выше. Эта обратная связь и позволит достичь целей геймификации и сформировать у исполнителей процесса необходимое поведение.
Сюжет игры, сеттинг
Для случая-примера компании YYY, который используется в данной работе, разработан следующий сеттинг/сюжет (в скобках указаны соответствующие элементы механики):
Все игроки - животные. Целый день они рыскают в поисках пищи (баллов). Лес, в котором поселились животные, не простой, а волшебный. Чтобы питаться в нем, необязательно убивать других животных или причинять вред растениям - можно ездить по волшебным кормушкам и находить пищу там! (работа торгового представителя на маршруте, кормушки-клиенты) Чтобы найти пищу в кормушке, необходимо победить охраняющих ее монстров - Продажу и Оплату. За победу каждого монстра в кормушке дается кусочек еды. Победить Продажу несложно, а Оплата хитрее - победив ее, обязательно проверь, добил монстра или нет (полностью внесены деньги или нет). Победив монстров, не забудь пометить эту кормушку! (снять координаты GPS). Чем больше ты побеждаешь монстров и чем чаще помечаешь кормушки, тем больше ешь! Каждый зверь появляется в лесу птенцом и эволюционирует, питаясь. Каждый житель леса мечтает стать царем зверей! (рейтинг по заработанным баллам). Выполняя специальные действия, ты будешь получать крепкие когти, сокрушительные зубы, сильные лапы и острый нюх, которые помогут в борьбе с монстрами. (достижения)
Таким образом, цель игры - больше продавать, собирать больше оплат и чаще снимать координаты, выбиваясь в лидеры рейтинга и становясь львом. Сюжет - эволюция каждого игрока от птенца до льва.
Данный сеттинг-сюжет обладает следующими привлекательными чертами:
· Используется тематика животного мира, которая знакома всем
· Многообразие природы создает большой потенциал для развития сеттинга и сюжета
· Сравнение людей и животных - это традиционное поле для шуток (добавили элемент ироничности)
· Несмотря на то, что цель - эволюционировать до льва, система рейтинговых уровней имеет еще два секретных уровня для мастеров игры
Ниже в табл. 6 представлена интерпретация элементов механики в контексте игрового сюжета и сеттинга:
Таблица 6. Интерпретация элементов механики
Элемент механики |
Интерпретация |
|
Баллы за продажу |
Еда за победу над мостром продажей |
|
Баллы за оплату |
Еда за победу над мостром оплатой |
|
Баллы за GPS |
Метки территории |
|
Рейтинг |
Эволюционная гонка |
|
Уровни |
Вид зверя игрока; этапы эволюции |
|
Сообщение: «Не забудьте уточнить дату погашения задолженности» |
«Запланируй, когда вернешься и добьешь монстра» |
|
Сообщение: «Заработайте Х баллов, погасив эту задолженность в следующий визит» |
«Получи дополнительную еду, победив этого монстра в следующий раз!» |
|
Выполнен план продаж |
Территория очищена от монстров-продаж! |
|
Достигнут предпоследний уровень |
Эволюционировал в дракона |
|
Достигнут последний уровень |
Эволюционировал в спрута |
|
3 непросроченные оплаты от одного из клиентов течение периода |
Гроза оплат - три победы в одной кормушке есть! |
|
На момент 20 числа месяца не более 10% клиентов с просроченными оплатами |
Территория очищена от монстров-оплат! |
|
150 визитов с координатами на момент 30 числа месяца |
Территория помечена и строго охраняется |
|
Наименьший уровень в рейтинге На момент 20 числа месяца среди всех игроков |
Игрок = неоперившийся птенец |
|
Последнее место в рейтинге На момент 20 числа месяца среди всех игроков |
Голодные времена. Главное - выжил! |
|
Ни в одном визите за месяц не сняты координаты |
Добыл еду, а территорию не пометил |
KPIs геймификационного проекта
Объект геймификации - процесс работы торгового агента на маршруте - имеет свои собственные KPI, приведенные в списке ниже:
· Процент выполнения плана продаж.
· Процент клиентов, вовремя погашающих задолженности, от всех клиентов на территории.
· Частота заполнения анкеты в торговой точке за отчетный период
· Поддержание представленности.
Эти KPIs продолжают отслеживаться в обычном режиме. По их динамике предполагается определять успешность всего геймификационного проекта.
Для операционного контроля геймификации предлагается использовать показатель вовлеченности, подробно описанный в разделе выше. Ниже в таблице показано, какие из разнообразных метрик вовлеченности и как будут использоваться в нашем случае-примере:
Таблица 7. Использование метрик, составляющих KPI вовлеченности
Метрика |
Как используем |
|
Количество игровых сессий |
Количество обращений к игре на одного сотрудника за рабочий день. Целевое значение: 5 |
|
Длительность игровых сессий |
Среднее время между двумя запросами к игре в течение недели. Целевое значение: 96 минут |
|
Количество приглашенных друзей |
Не используем - игра рассчитана на определенную команду агентов |
|
Обратная связь о продукте, оценки, комментарии |
Результаты опроса торговой команды внутри игры или вне ее. Используем для сбора качественных данных и улучшения механики игры. |
|
Уровень позитивных эмоций от продукта, любопытства |
Результаты опроса торговой команды внутри игры или вне ее. Используем для сбора качественных данных. Используем для сбора качественных данных и улучшения механики игры. |
|
Сосредоточенность, субъективное восприятие времени во время игры |
Не используем - метрика не согласуется с ограничением на время в игре (см. раздел «Цели и ограничения» |
Кроме того, будут использоваться два KPIs, обусловленных целями геймификации. Как и KPI процессов, эти показатели могут отслеживаться вне игры, в КИС дистрибьютора, поддерживающие процессы продаж. Это следующие показатели:
· Процент визитов с координатами - отношение количества визитов с координатами ко всем визитам за период
· Процент клиентов с просрочкой - отношение клиентов с просроченной оплатой ко всем клиентам, работающим с дистрибьютором
Стоит отметить, что соответствие значений метрик целевым приобретает значимость спустя какое-то время после запуска игры. Должно пройти время, пока утихнет ожидаемый бум и сотрудники свыкнутся с новыми элементами их работы. В этот «ознакомительный» период, значения метрик могут быть как значительно ниже, так и значительно выще целевых. Однако сохранение метрик на значениях, значительно уступающих целевым, должно стать тревожным сигналом об отсутствии какого-либо интереса к игре, поэтому проводить замеры необходимо с самого запуска игры. Это же относится и к влиянию геймификации на KPIs процесса.
Техническая реализация геймификационного решения
Обзор существующих способов реализации
Техническая реализация геймификационного решения - это, во-первых, реализация игры и, во-вторых, реализация корпоративной информационной системы. В данном разделе работы будут рассмотрены способы классифицировать игры (прежде всего обратим внимание на классификации, напрямую влияющие на технические характеристики) а так же будет составлена классификация геймфикационных решений по месту системы в IT-ландшафте компании.
В современной литературе существуют различные классификации компьютерных игр. Их можно разделить на жанровые - т.е. делящие игры по жанрам - и остальные (например, классификация по форматам игрового мира или по используемым графическим стандартам).
Жанровые классификации, это, в основном, работы последних десятилетий ХХ века, т.е., составленные на заре появления компьютерных игр. Несмотря на технологический рывок, соверщенный с тех пор, жанровая специфика игр практически не изменилась. В данной работе использована классификация [16]. Ее преимуществом является многоуровневость и деление жанров, зависящее от основных действий, требуемых игрой от игрока (т.е., в некотором смысле, от механики игры).
Итак, автор в [16] выделяет две большие группы игровых жанров, каждая со своими подгруппами:
· Skill-and-action games - игры, где управление персонажем (одушевленным или нет) происходит в реальном времени. Повинуясь воле игрока, персонаж перемещается по игровой карте и выполняет различные игровые действия. Такие игры делают большой акцент на графическом и звуковом сопровождении и требуют от игрока, главным образом, хорошей реакции и координации движений. Большинство самых распространенных игр относятся именно к этой группе.
§ Боевые игры (Combat games) - игры, представляющие из себя битву, драку или иное боевое противостояние. Смысл такой игры - наносить урон противнику, при этом максимально избегая его аттак. Самый знаменитый пример - Mortal Kombat (издатель Warner Bros. Interactive Entertainment)
§ Игры-лабиринты (Maze games) - игры, в которых игроку необходимо двигаться по лабиринту, не задевая препятствия и выполняя второстепенные игровые задания. Самая знаменитая игра-лабиринт - это Pac-man (издатель Namco)
§ Спортивные игры - игры, моделирующие на компьютере существующие спортивные игры. К ним относятся разнообразные симуляторы футбола, воллейбола, тенниса, шахмат и т.д. Такие игры появились как предложение для консервативных покупателей, которым компьютерные игры были в новинку, и для которых их ценность была непонятна. Отдельно стоит отметить опыт компании Nintendo в использовании для этих игр технологий дополненной реальности, благодаря которым игроки в процессе симуляции выполняют ровно те же действия, что и в оригинальной спортивной игре.
§ Игры с шариком (PONG-based games) - здесь игрок использует платформу, стреляющую шариком, для того, чтобы уничтожать препятствия. Являются развитием симулятора пинг-понга
§ Игры-гонки (Race games) - различные симуляции гонок: автомобильных, лыжных и проч. Отличаются от спортивных игр только тем, что моделируют неигровые виды спорта (гонки).
· Стратегические игры (strategy games) - игры, требующие от игрока скорее обдумывания, чем прямой манипуляции. Играются они, чаще всего, не в реальном времени (например, по ходам), кроме управления игроком могут требовать других действий (постройка, решение логических задачек и т.п.). В отличие от Skill-and-action games, стратегические игры не предъявляют требований к реакции и моторике игрока и могут быть реализованы в самых простых интерфейсах (например, как текстовая игра без графики или звука). К стратегическим играм автор в [16] относит следующие жанры:
§ Игры-приключения - самый широкий жанр в классе стратегических игр. В этих играх игрок исследует игровой мир, выполняя задания, требующие умественных усилий (например, разгадывая загадки). Механика игр-приключений может быть самой разной - это и квесты, и сборники логических загадок, и многие другие.
§ Игры типа «подземелье и драконы» (D&D games) - весь класс пошел от одной одноименной игры, бывшей изначально настольной. Данный тип игр абсолютно нетребователен к интерфейсу, однако для интересной игры необходим очень опытный ведущий и хорошо продуманный им сюжет игры. По сути, каждая партия D&D - это отдельные игры со схожей механикой, все параметры которой находятся в ведении ведущего.
§ Симуляторы войны - аналог combat games, но в классе стратегических игр. Как правило, в симуляторах войны игроку необходимо собрать армию, наладить обеспечивающую ее инфраструктуру и разбить армии врагов. Самый известный пример этого жанра - это серия Heroes of might and magic от издателя 3DO.
§ Игры со случайностью - симуляторы самого древнего подкласса игр. К таким играм можно отнести компьютерные кости, пасьянсы и т.п. Обобщая, к таким играм можно отнести вообще любую игру, где есть случайная составляющая. Так, например, получившая известность в последние годы игра Hearthstone от издателя Blizzard Entertainment является симулятором коллекционно-карточной настольной игры, где раздача карт игроку происходит случайным образом. Таким образом, эта игра может быть причислена к жанру игр со случайностью, хотя случайность и не является центральным элементом ее механики.
§ Обучающие и детские игры - в основном это развивающие игры для детей. К обучающим играм можно отнести игры, развивающие логику, смекалку, счет, знание алфавита, различные компьютерные викторины. При этом, например, авиасимулятор, используемый для обучения пилотов, к таким играм отнести нельзя, поскольку он не относится к классу стратегических игр (такая игра будет спортивной).
Кроме жанровой классификации, игры можно классифицировать по многим другим признакам. Большой выбор таких альтернативных классификаций предлагают авторы в [17]. В данной работе приведены те из них, которые могут повлиять на выбор способа реализации:
· Классификация по платформе
§ Игры для ПК - запускаются с персонального компьютера, как правило, с использованием дистрибутива. Для того, чтобы играть на ПК с разными ОС, необходимо использовать отдельные издания игры для конкретных ОС.
§ Игры для консолей и приставок - игры, запускающиеся только на специальных игровых устройствах. Консоли и приставки не предназначены для других задач, кроме воспроизведения игр.
§ Игры для мобильных устройств - игры для мобильных телефонов, КПК, смартфонов. Как и в случае с играми для ПК, необходимы разные издания игры для разных ОС.
§ Игры для игровых автоматов - очень популярные в прошлом и крайне ограниченно распространенные в современности игры. Создаются под конкретные автоматы, делятся на аркадные и азартные.
§ Браузерные игры, флеш-игры (игры на виртуальной интернет-платформе) - игры, которые можно запустить с любого устройства, используя интернет-браузер. Технология таких игр базируется на возможности интернет-страниц запускать внутри себя программы и проигрывать флеш-видео. Универсальны и не требуют от пользователя усилий по установке, однако требовательны к стабильному интернет соединению.
· Классификация по технологии графического изображения:
§ Отсутствие графики (текстовые игры, псевдографика). Малая мощность компьютеров первых поколений ставила перед разработчиками игр массу ограничений. Из-за этого во многих старых играх применялась не графика, а текстовое оформление. Игры такого вида больше похожи на интерактивную книгу, а не на видеоигру. Но и в наше время встречаются подобные игры.
§ Двухмерная графика (векторная, растровая). 2D-графика - наиболее естественный вид графики для двухмерных экранов мониторов. Изображения составлены из отдельных пикселей - цветных квадратов. Эпоха популярности 2D игр прошла в 1990-х годах, но оставила свой след в игровой культуре в виде пикселизированного стиля графики. В конце 2000-х годов, на волне успеха инди-игр, мода на 2D-игры вернулась. Так же существует технология векторных изображений, при которой объекты состоят не из пикселей, а из точных геометрических координат, соединяемых линиями. Такой вид изображений позволяет отрисовывать более плавные линии, без пикселизации. При увеличении изображения не портится его внешний вид.
§ Трехмерная графика. Благодаря применению тригонометрических формул у разработчиков игр появилась возможность создавать иллюзию трёхмерного мира, отображаемого на двухмерной плоскости экрана. В компьютере вычисляются настоящие 3D-модели, а на экран выводится математически вычисляемые 2D-проекции этих трехмерных объектов. Идеи трехмерных изображений были заложены ещё в 1970-х годах, а настоящая трехмерная графика появилась только в начале 1990-х. На сегодняшний день 3D-графика - самый популярный формат графики в компьютерных играх.
§ Объемное изображение (стерео очки). Объемность изображений - это небольшое улучшение 3D-графики. Кажущаяся объемность объектов достигается за счёт того, что зрителю поступают разные изображения для левого и правого глаза. За счет разности изображений человеческий мозг может вычислить примерное расстояние до объекта, и получается эффект объемности. Технология стерео-изображения пока не доведена до идеального состояния, поэтому, несмотря на некоторые преимущества, она редко используется в компьютерных играх.
§ Дополненная реальность (мобильные устройства с видеокамерой). Подобные игры доступны лишь на мобильных устройствах с видеокамерой. Через экран объектива видеокамеры отображается реальный мир, но с добавлением виртуальных объектов. Игрок водит видеокамерой, ищет появляющиеся объекты или прицеливается и уничтожает их. Дополненная реальность - интересная и необычная идея, но широкой популярности она не получила.
§ Виртуальная реальность (шлем виртуальной реальности). Подразумевает полное погружение игрока в виртуальный мир, когда игрок ощущает, что в видеоигру помещено всё его тело, все его органы чувств. Развитие игры до полноценной виртуальной реальности (ВР) на сегодняшний день невозможно. На данный момент существуют шлемы виртуальной реальности, в которые транслируется стерео-графика. Сенсоры, закрепляемые на руках, могут отображать реальные движения рук в виртуальном пространстве. Но всё это - лишь первые шаги к ВР.
Для успешной реализации геймификационного проекта необходимо определить, какая КИС будет использована и какое место она займет в IT-ландшафте компании. На данный момент в литературе отсутствует формализованные описание или классификация возможных геймификационных продуктов. Анализ успешных кейсов геймификации (в [18] и [9]) позволяет составить следующий перечень:
Таблица 8. КИС для геймификации
Формат продукта |
Примеры успешных кейсов геймификации |
|
Надстройка над КИС, автоматизирующей геймифицируемые процессы, от вендора этой КИС (дополнение к продукту) |
SalesWorks (вендор SoftServe Business Systems) для мотивации торгового персонала компании InBev |
|
Надстройка над КИС, автоматизирующей геймифицируемые процессы, от стороннего вендора (плагин к продукту)* |
Плагин для Salesforce CRM от компании Iactionable для дополнительной мотивации сотрудников отдела поддержки Veeam Software (Продукты для резервного копирования информации) Платформа Badgeville для создания игровых плагинов к CRM системам |
|
Сторонняя КИС, в которой сотрудники работают параллельно с основной КИС, автоматизирующей геймифицируемые процессы** |
Геймификация отдела продаж в Yota |
|
Построение игры на базе корпоративной социальной сети |
Геймификационные функции в Yammer (бейджи, видео-ролики) |
* Плагин может быть выполнен в виде браузерного приложения или непосредственно встроен в интерфейс основной КИС
** Как правило, браузерные игры
Выбор решения для компании-дистрибьютора
Критерии выбора
Как показано в разделе выше, при разработке технологического решения для геймификационного проекта необходимо выбрать:
· Жанр игры
· Платформу
· Графическую технологию
· Формат продукта (КИС) и его место в ИТ-ландшафте компании
Для того, чтобы определиться с выбором по данным параметрам, необходимо снова обратиться к целям геймификации, KPI, ограничениям. Выбранный жанр, платформа и формат должны помогать достигать целей и поддерживать статистику по необходимым метрикам; технологии, используемые в продукте (в особенности для графического сопровождения), должны укладываться в обозначенные ограничения выполнимости.
Из-за полевой работы торговых представителей, очевидно, что геймификационное решение должно работать на мобильной платформе. Вследствие ограничения производительности устройств, 3D-графика и стерео-изображение в качестве графических технологий для проекта недоступны.
Для того, чтобы не нарушить ограничения по времени и ресурсам, следует максимально упростить разработку. Основная трудоемкость разработки для мобильных игр заключается в графике и разработке синхронизации базы данных на устройстве и центральной базы (эта синхронизация необходима для поддержки рейтинга игроков, требуемого механикой). В связи с этим необходимо использовать жанр текстовой игры и реализовать решение на базе платформы с уже существующей синхронизацией.
Из форматов КИС требованиям выше соответствуют плагин к существующей КИС, доработки существующей КИС или решение на базе корпоративной социальной сети. Однако в компании YYY не внедрена корпоративная социальная сеть, что сокращает выбор форматов КИС до двух вариантов. Ограничение по ресурсам (только собственная разработка) позволяет выбрать лишь плагин к существующей КИС.
Таким образом, требования к предполагаемому решению:
· Жанр игры - текстовая игра
· Платформа - мобильное устройство (смартфон или КПК)
· Графическая технология - графика отсутствует / псевдографика
· Формат продукта (КИС) и его место в ИТ-ландшафте компании - плагин к существующей КИС на базе платформы с реализованной синхронизацией мобильной и центральной базы данных.
Данные требования, очевидно, являются неполными - так, например, не специфицированы требования к структуре базы данных, требования по информационной безопасности решения, устойчивость будущей системы к пиковым нагрузкам и др. Однако приведенные критерии и выбранные значения дают отличное верхнеуровневое представление «где искать» и «что разрабатывать»
Результат
В качестве технической реализации геймификационного решения выбран Telegram-бот.
В данном решении верхнеуровневые требования реализуются следующим образом:
· Благодаря API легко настроить синхронизацию с любым источником данных (в т.ч. с КИС дистрибьютора), т.е. синхронизация между мобильной и центральной базой данных не потребует существенных разработок
· Сообщения в Telegram, отсылаемые ботом, являются реализацией текстовой игры
· Telegram - это мобильный мессенджер, таким образом, требование по платформе так же соблюдено.
В данном решении ограничения соблюдаются следующим образом:
· Ограничение по времени в игре. Основные игровые действия - зарабатывание баллов, достижений - могут проводиться без активности со стороны игрока, в режиме уведомления от текстовой игры (сообщения от бота) - таким образом, игра работает в режиме направленного стимулирования, подсказок. Вся логика обработки данных, генерируемых торговым представителем в течение рабочего дня, происходит на стороне бота, то есть в фоновом режиме. Активного вмешательства в игру требует только запрос рейтинга игроков.
· Ограничение на ресурс для разработки. Разработка ботов для Telegram не требует дополнительных лицензий, доступа к специализированным ресурсам или сложнополучаемых навыков. Таким образом, данная активность соответствует компетенциям и возможностям IT-специалиста дистрибьютора.
· Ограничение по ТСО. Данное решение является одним из самых доступных. Рассмотрим стандартные компоненты ТСО применительно к Telegram-боту:
§ Покупка и продление лицензий - Telegram имеет бесплатную пользовательскую лицензию, которая позволяет создавать ботов и работать с ними
§ Разработка - оплата труда IT-специалистов дистрибьютора
§ Внедрение - установка Telegram для пользователей, обучение, запуск проекта. Не требует материальных затрат.
§ Аппаратное обеспечение для функционирования системы - не требуется. Для функционирования базы данных можно использовать бесплатные хостинги (т.к. участников проекта всего 30 и объем генерируемых ими данных не велик). Мобильное приложение предполагается запускать на тех же устройствах, что и SFA-систему (КИС, с которой уже работают торговые представители).
§ Затраты на интернет для игроков - не возрастут, т.к. передаваемые данные - это короткие тексты сообщений бота.
§ Затраты на обновление - разработка + обучение, перекладывая на деньги - оплата труда IT-специалистов
§ Оплата сопровождения системы - поддержка приложения Telegram бесплатна; поддержка бота включает в себя оплату труда IT-специалистов
§ Затраты на хостинг - отсутствуют (см. выше)
§ Дополнительный ввод и обработка данных в систему - не требуется, все необходимые для функционирования бота данные уже сейчас генерятся в ходе работы торговых представителей.
Особые преимущества данного решения:
· Популярность мессенджера Telegram в России
· Гибкость создания бота, благодаря чему игру можно постоянно совершенствовать и оперативно реализовывать, а так же пилотировать изменения в механике
Недостатки данного решения:
· Возможная блокировка Telegram на территории России. Данный риск митигируется общедоступными способами обхода блокировок - VPN- и Proxy-сервисами.
· Скудное графическое сопровождение. Данный риск является следствием описанных выше ограничений. Привлекательность игры можно повысить за счет сюжета и механики, митигировав, таким образом, этот риск
Архитектура решения
Общая схема
Принципиально, бот состоит из backend и frontend части. Frontend часть - это клиент мессенджера на устройстве торгового представителя. Frontend выполняет следующие функции:
· Информирует игрока о его прогрессе в игре (сообщения о новых баллах, достижениях) путем рассылки собщений
· Обрабатывает запросы пользователя (вывод рейтинга игроков, вывод всех достижений пользователя)
Подробнее логика, по которой рассылаются сообщения, изложена в разделе «Логика работы бота» ниже
Backend часть - это база данных с интерфейсом для вывода отчетов, интеграцией с frontend и ERP дистрибьютора. В базе содержатся все данные необходимые для работы игры. Данные делятся на две смысловые группы:
1. Данные о прогрессе пользователей в игре: рейтинги, заработанные достижения, баллы.
2. Данные о рабочем поведении пользователей: продажи, оплаты и прочее - все, на базе чего формируется игровое стимулирование и благодаря чему зарабатываются баллы, достижения. Предполагается, что эти данные импортируются из ERP системы дистрибьютора с определенной периодичностью. В данной работе интеграция заменена ручным вводом.
Так же в backend происходит обработка событий (появлений новых продаж \оплат и формирование соответствующих сообщений пользователю) и обработка запросов игрока с формированием необходимого сообщения-ответа
Кроме этого, с помощью backend хранятся, расчитываются и выводятся (через интерфейс формирования отчетов) KPI геймификации.
Подробнее структура базы данных для работы бота описана в соответствующем разделе ниже
Общая схема решения представлена на рис. 4
Рисунок 4
Структура базы данных backend
База данных backend выполнена в виде реляционной базы данных и состоит из набора таблиц. Подробная схема представлена в приложении на рис. 7. Описание сущностей и связей - в таблицах ниже. Условные обозначения: pk - primary key (внутренний ключ), fk - foreign key (внешний ключ), uq - unique (только уникальные значения), nn - not null (атрибут не может быть пустым)
Сущность «Пользователь» - соответствует игроку, часть данных импортируется из ERP дистрибьютора. Каждый игрок идентифицируется, с одной стороны, своим ID из ERP дистрибьютора (для учета его заказов и продаж), с другой - ID Telegram для адресации сообщений.
Таблица 9. Пользователи
Название атрибута |
Тип данных |
Комментарий |
|
ID Пользователя (pk, uq. nn) |
Целое число |
Уникальный идентификатор. |
|
ID Telegram |
Строка |
Идентификатор пользователя Telegram для рассылки сообщений. NULL означает, что сотрудник не вступил в игру |
|
ID ERP (nn) |
Строка |
Соответствует идентификатору сотрудника в ERP дистрибьютора |
|
План продаж |
Целое число |
План по продажам за период для этого пользователя (меняется раз в период) |
|
Процент выполнения |
Дробное число |
Процент выполнения плана продаж=отношение суммы продаж этого пользователя за период к его плану (обнуляется раз в период) |
|
Текущее количество баллов |
Целое число |
Количество баллов, заработанных пользователем. NULL эквивалентно нулю. Поле очищается раз в период. |
|
Рейтинг (fk, nn) |
Целое число |
Идентификатор рейтинга игрока из таблицы рейтингов (обнуляется раз в период) |
Сущность «Клиент» - соответствует торговой точке, посещаемой игроком. Все данные по клиентам импортируются из ERP дистрибьютора.
Таблица 10. Клиенты
Название атрибута |
Тип данных |
Комментарий |
|
ID Клиента (pk, uq, nn) |
Целое число |
Уникальный идентификатор. Соответствует идентификатору в ERP дистрибьютора |
|
Название (nn) |
Строка |
Название магазина |
|
Тип (nn) |
Строка |
АВС-классификация клиентов |
|
Количество дней отсрочки |
Целое число |
Количество дней, в течение которых клиент обязан внести деньги за отгруженный товар. 0 или NULL означают оплату по факту |
Сущность «Продажа» определяет отгрузку, произведенную пользователем клиенту. Отгрузка возможна только в рамках визита. Вся информация импортируется из ERP дистрибьютора.
Таблица 11. Продажи
Название атрибута |
Тип данных |
Комментарий |
|
ID Продажи (pk, uq, nn) |
Целое число |
Уникальный идентификатор документа. Соответствует идентификатору в ERP дистрибьютора |
|
ID Пользователя (fk, nn) |
Целое число |
Идентификатор пользователя, совершившего продажу |
|
ID Клиента (fk, nn) |
Целое число |
Идентификатор клиента, на которого оформлена продажа |
|
ID Визита (fk, nn) |
Целое число |
Идентификатор визита, к которому относится продажа |
|
Сумма (nn) |
Дробное число |
Сумма продажи |
|
Дата (nn) |
Дата |
Дата совершения продажи |
|
Конец строки (nn) |
Символ (char) |
Наличие символа в этой строке означает, что внесение строки в базу данных завершено. Техническое поле. |
Сущность «Оплата» соответствует документу оплаты, создаваемому пользователем по факту получения денег от клиента (приходно-кассовому ордеру). Вся информация импортируется из ERP дистрибьютора. Оплаты могут производиться как в рамках визита, так и вне его (в случае безналичной оплаты юридическому лицу дистрибьютора).
Таблица 12. Оплаты
Название атрибута |
Тип данных |
Комментарий |
|
ID Оплаты (pk, uq, nn) |
Целое число |
Уникальный идентификатор документа. Соответствует идентификатору в ERP дистрибьютора |
|
ID Пользователя (fk) |
Целое число |
Идентификатор пользователя, работающего с клиентом |
|
ID Клиента (fk) |
Целое число |
Идентификатор оплатившего клиента |
|
ID Визита (fk, nn) |
Целое число |
Идентификатор визита, к которому относится оплата |
|
Сумма (nn) |
Дробное число |
Сумма оплаты |
|
Дата (nn) |
Дата |
Дата совершения оплаты клиентом |
|
ID документа-основания (fk) |
Целое число |
Идентификатор документа продажи, по которому идет оплата |
|
Сообщение |
Текст |
Сообщение об оплате вне визита |
|
Конец строки (nn) |
Символ (char) |
Наличие символа в этой строке означает, что внесение строки в базу данных завершено. Техническое поле. |
Сущность «Рейтинг» определяет дискретный рейтинг пользователя, зависящий от количества набранных баллов. Так, например, пользователь имеет рейтинг «лев», если он набрал 100 баллов за период, и т.п.
Таблица 13. Рейтинги
Название атрибута |
Тип данных |
Комментарий |
|
ID Рейтинга (pk, uq, nn) |
Целое число |
Уникальный идентификатор рейтинга. |
|
Иконка |
Строка |
Текстовый код картинки-обозначения рейтинга для вставки в сообщение |
Сущность «Достижение» - это бейджи, которые выдаются пользователям за особые результаты.
Таблица 14. Достижения
Название атрибута |
Тип данных |
Комментарий |
|
ID Достижения (pk, uq, nn) |
Целое число |
Уникальный идентификатор рейтинга. |
|
Цель достижения |
Дробное число |
Цель достижения, если она может быть выражена количественно |
|
Сообщение о достижении (nn) |
Текст |
Сообщение, которое высылается при получении достижения |
|
Иконка (nn) |
Строка |
Текстовый код картинки-обозначения рейтинга для вставки в сообщение |
Сущность «Пользователь-Достижение» является технической сущностью для создания отношения многие-ко-многим между сущностями «Пользователь» и «Достижение». В этой таблице содержится информация о прогрессе всех пользователей по всем достижениям.
Таблица 15. Пользователь-Достижение
Название атрибута |
Тип данных |
Комментарий |
|
ID строки (pk, uq, nn) |
Целое число |
Уникальный идентификатор строки. |
|
ID Достижения (fk, nn) |
Целое число |
Достижение |
|
ID Пользователя (fk, nn) |
Целое число |
Пользователь |
|
Прогресс |
Дробное число |
Прогресс пользователя по достижению. Null означает нулевой прогресс. Поле очищается каждый период. |
Сущность «Визит» обозначает визит пользователя в торговую точку и является таблицей фактов. Большая часть сообщений в боте высылается игроку на основе данных о визите. Таблица очищается раз в период. Часть данных импортируется из ERP дистрибьютора. Данные импортируются только за текущий период.
Таблица 16. Визиты
Название атрибута |
Тип данных |
Комментарий |
|
ID Визита (pk, uq, nn) |
Целое число |
Уникальный идентификатор строки. |
|
ID Пользователя (fk, nn) |
Целое число |
Идентификатор пользователя, свершившего визит |
|
ID Клиента (fk, nn) |
Целое число |
Идентификатор клиента, к которому был совершен визит |
|
Дата |
Дата |
Дата совершения визита |
|
Координаты |
Строка |
GPS-координаты, снятые во время визита |
|
ID cообщения (fk, nn) |
Текст |
Сообщение, отсылаемое пользователю по итогам визита |
|
Конец строки (nn) |
Символ (char) |
Наличие символа в этой строке означает, что внесение строки в базу данных завершено. Техническое поле. |
Сущность «Сообщение» - это текст, который может быть выслан ботом игроку.
Таблица 17. Сообщения
Название атрибута |
Тип данных |
Комментарий |
|
ID Сообщения (pk, uq, nn) |
Целое число |
Уникальный идентификатор сообщения. |
|
Текст (nn) |
Текст |
Текст сообщения |
Сущность «Обращение» - это факт вызова игроком команды в интерфейсе бота. Данная сущность техническая, необходима для отслеживания KPI геймификации.
Таблица 18. Обращения
Название атрибута |
Тип данных |
Комментарий |
|
ID Обращения (pk, uq, nn) |
Целое число |
Уникальный идентификатор обращения. |
|
ID Telegram (fk, nn) |
Строка |
Автор обращения |
|
Дата (nn) |
Дата |
Дата обращения |
|
Время (nn) |
Время |
Время обращения |
В качестве аппаратного обеспечения для базы данных выбраны google-таблицы в виду следующих преимуществ:
· Бесплатные лицензии (для объема данных, генерируемых командой торговых представителей за период), поддержка
· Нет необходимости в дополнительной инфраструктуре (серверах, ПО)
· Готовое API упрощает интеграцию с front-end и ERP
· Готовый интерфейс вывода
· Простой и распространненный синтаксис для создания алгоритмов (Excel-функции)
Логика работы бота
Принцип работы разработанного геймификационного решения состоит в параллельном выполнении шести процессов. Три из них выполняются для каждого игрока в соответствии с разработанной выше механикой геймификации:
1. Рассылка сообщений по итогам визитов (при появлении новых строк в таблице визитов или оплат)
2. Вывод прогресса пользователей по достижениям
3. Вывод рейтинга всех пользователей по заработанным баллам
4. Ввод нового пользователя в игру
5. Выход пользователя из игры
Последний необходим администратору игры для контроля ее успешности:
6. Расчет и вывод KPI геймификации
Процессы описаны ниже поэтапно:
Рассылка сообщений по итогам визитов:
1. Игрок совершает визит к клиенту в ходе обычной рабочей деятельности
2. Данные о визите через SFA-систему попадают в ERP дистрибьютора.
3. Происходит импорт необходимых данных в базу данных backend. В таблице визитов появляется новая строка. Так же новые строки могут появиться в таблицах оплат, продаж.
1. При появлении новой строки в таблице визитов происходит автоматический расчет текста сообщения в соответствии с логикой, представленной в таблице 23 в приложении.
2. При появлении новой строки в таблице оплат происходит расчет текста сообщения в соответствии с логикой, представленной в таблице 24 в приложении.
3. При появлении новых строк в таблицах визитов или продаж или оплат происходит перерасчет количества баллов, рейтинга и процента выполнения плана продаж для пользователей. При начислении баллов учитывается только один документ продажи для одного клиента за одну дату (т.е. за продажу, разбитую на две и больше накладных, начисляется 1 балл). Аналогично учитывается только один документ оплаты для одного клиента и одного документа-основания за одну и ту же дату (т.е. за оплату по одной и той же продаже, разбитую на два документа, начисляется 1 балл). За каждый документ оплаты и продажи (с учетом условий, описанных выше) начисляется по 1 баллу. Процент выполнения плана продаж пересчитывается при изменении суммы продаж, выполненных игроком. Рейтинги пересчитываеются в соответствии с таблицей 19.
4. При появлении новых строк в таблицах визитов или продаж или оплат происходит перерасчет прогресса пользователей по достижениям в соответствии с таблицей 20.
4. Запускается периодическая процедура поиска новых визитов. Данная процедура ищет новые строки в таблице визитов (необработанные, заполнено поле «Конец строки») и высылает пользователю, указанному в строке, рассчитанное сообщение
5. Запускается периодическая процедура поиска новых оплат. Процедура ищет новые строки в таблице оплат (необработанные, заполнено поле «Конец строки») и высылает пользователю, указанному в строке, рассчитанное сообщение (при его наличии)
6. Запускается периодическая процедура контроля достижений. Если пользователь достиг прогресса 100% в необработанной строке таблицы «Пользователь-Достижение», ему высылается сообщение о выдаче достижения с его иконкой.
Вывод прогресса пользователей по достижениям:
1. Игрок запускает команду «Мои достижения» в интерфейсе бота
2. В сообщение-ответ выводятся все строки из таблицы «Пользователь-Достижение» с соответствующим идентификатором пользователя
Вывод рейтинга пользователей по заработанным баллам (cм табл. 19):
1. Игрок запускает команду «Гонка эволюции!» в интерфейсе бота
2. В сообщение-ответ выводятся все строки из таблицы пользователей (только имя, количество баллов и иконка набранного рейтинга), отсротированные по убыванию количества баллов.
Таблица 19. Логика расчета рейтингов
Количество баллов игрока |
ID Рейтинга |
|
0-77 |
Птенец |
|
78-154 |
Мышь |
|
155-194 |
Волк |
|
195-286 |
Медведь |
|
287-495 |
Горилла |
|
496-682 |
Слон |
|
683-792 |
Лев |
|
793-880 |
Дракон |
|
881-.... |
Спрут |
Таблица 20. Логика расчета достижений
Достижение |
Условие выполнения |
Сообщение |
|
Спрут |
Набран 881 балл |
Твои щупальца вытянут из клиентов все до последнего кусочка! Поздравляем с достижением уровня мастера: теперь ты Спрут! |
|
Дракон |
Набрано 793 балла |
Мощные крылья, огненное дыхание, когтистые лапы - все для продаж и оплат! Поздравляем с достижением экстра-уровня: теперь ты Дракон! |
|
Царь зверей |
Набрано 682 балла |
Ты на вершине пищевой цепи! Поздравляем с с достижением царского уровня: теперь Ты Лев! |
|
Санитар леса |
Выполнен план продаж для конкретного пользователя |
Территория очищена от монстров-продаж! Продолжай следить за ними и добывать еду! |
|
Стабильность - признак мастерства |
3 непросроченные оплаты от одного из клиентов течение периода |
Проверенная кормушка - все, что нужно для счастья в лесу. А, ну еще зубы. И когти. Монстры не дремлют! |
|
Рога и копыта |
На момент 20 числа месяца не более 10% клиентов с просроченными оплатами |
Рога и копыта помогут тебе и дальше держать оплаты в страхе! Продолжай в том же духе |
|
Ревнитель территорий |
150 визитов с координатами на момент 30 числа месяца |
Каждая твоя кормушка помечена, чтобы другим соваться было неповадно |
|
Неоперившийся птенец |
Наименьший уровень в рейтинге на момент 20 числа месяца среди всех игроков |
Стряхните пух и покажите им, кто здесь лев, в следующем периоде! |
|
Голодные времена |
Последнее место в рейтинге на момент 20 числа месяца среди всех игроков |
Главное - выжил. Наверстай на пирах в следующем периоде! |
|
Секретные железы |
Ни в одном визите за месяц не сняты координаты |
Пахучие железы помогут вам чаще помечать территорию в следующем периоде. Успехов! |
Выход пользователя из игры
1. Игрок запускает команду «Выйти из игры»
2. В сообщение-ответ выводится прощальное сообщение
3. Из таблицы «Пользователи» в строке этого игрока очищается ID Telegram
Ввод игрока в игру
1. Игрок запускает команду «/start» (стандартная команда начала работы с ботом)
2. В сообщение-ответ выводится приветственное сообщение, инструкции к игре
3. Игрок вводит свой ID из КИС дистрибьютора
4. Если у игрока с таким ID еще нет номера в колонке ID Telegram, то номер формируется. Если есть, выводится сообщение «Вы уже в игре»
Просмотр KPIs геймификации
Просмотр KPIs осуществляется через интерфейс сводной таблицы, базирующейся на таблице обращений в базе данных backend. Логика расчета KPI представлена в табл. 21
Таблица 21. KPIs геймификации
KPI |
Логика расчета |
|
Количество игровых сессий |
Количество обращений за неделю (табл. Обращения) / количество игроков (табл. Пользователи) |
|
Длительность игровых сессий |
(Время последнего обращения за неделю - время первого обращения за неделю) / количество обращений (табл. Обращения) |
Методика построения геймифицированных процессов
На основе проведенной работы по анализу приемов и методов, используемых при разработке геймфикационных решений, проведенной работе по разработке решения для компании YYY, предлагается методика построения геймифицированных процессов. Методика позволит, имея на входе сформированный бизнес-процесс, определить его проблемы и характеристики, цели его геймификации, способы достижения этих целей и специфические (относимые к геймификации) параметры нового процесса, выбрать и/или разработать технологическое решение для его автоматизации. Данная методика состоит из:
· Плана и структуры работ. Все работы по методике делятся на три этапа:
o Обследование процесса. На этом этапе необходимо понять, какие проблемы в процессе существуют, можно ли решить их с помощью геймификации, определить цели геймификации и прверить согласованность их с целями процесса. Так же необходимо собрать информацию об ограничениях процесса и ограничениях для проекта разработки решения. Выбирается объект и определяются границы геймификации.
o Проектирование геймификационного решения. На этом этапе необходимо определить все, что будет касаться процесса игры - механику, точки удовольствия и т.д.
o Разработка технологического решения. На этом этапе большое внимание уделяется выбору формата КИС для реализации игры (будет ли это плагин к существующей системе, новая сторонняя система, новая in-house система), а так же выбору формата графического сопровождения игры, платформы и т.д. Выбор производится в соответствии с полученными на предыдущих этапах ограничениями.
· Рекомендаций по методам для разработки различных частей решения.
Подробнее эти составляющие описаны ниже в этом разделе.
Преимущества разработанной методики:
· Поиск решения отталкивается от процесса. Для обследования процесса используются стандартные, зарекомендовавшие себя методы и инструменты.
· Благодаря этапу обследования процесса и поиска проблем, цели геймификации и желаемый эффект можно четко определить и сформулировать. Проблемы разделены на классы, для каждого класса определена возможность использования геймификации для решения
· Для расчета числовых параметров геймификации используются числовые параметры процесса
· Благодаря определению целей геймификации через цели и проблемы процесса, итоговое решение максимально соответствует запросам бизнеса и ситуации в компании
· Описан способ разработки наградной системы в зависимости от типа игрока.
· Благодаря описанному анализу ограничений, производимому в самом начале построения геймифицированного процесса, и рекомендациям для выбора технологического решения, методика подойдет для большого спектра компаний - в том числе и для тех, кто хочет попробовать дешево внедрить геймификацию ради эксперимента.
· Описан метод выбора точек удовольствия с использованием Customer journey mapping. Предполагается, что при использовании данного метода геймифицированный процесс позволит участникам получать больше удовольствия от работы по сравнению с негеймифицированной ситуацией и стандартными геймификационными решениями.
· Широкие возможности для кастомизации, гибкость. Благодаря вариативным рекомендациям и наличию этапов исследования процесса, методику можно использовать для совершенно непохожих друг на друга компаний, процессов, индустрий.
План и структура работ
1. Обследование процесса
1.1. Определение целей процесса
1.2. Поиск проблем процесса.
1.2.1. Есть проблемы с логикой - не использовать геймификацию для их решения. Эти проблемы необходимо решить до продолжения работ.
1.2.2. Есть проблемы с управлением процессом - не использовать геймификацию для их решения. Данные проблемы могут негативно повлиять на результативность геймификации для решения проблем других классов
1.2.3. Есть проблемы с компетенциями исполнителей - зафиксировать проблему и желаемый результат (результат после исправления)
1.2.4. Есть проблемы с мотивацией - зафиксировать проблему и желаемый результат (результат после исправления)
1.3. Сбор количественной информации о процессе (максимумы, минимумы, среднее)
1.4. Определение целей геймификации
1.4.1. Выбор формата цели с использованием информации о проблемах
1.4.1.1. Если проблемы с компетенциями - получить желаемую компетенцию / сформировать правильное поведение / убрать неверное поведение
1.4.1.2. Если проблемы с мотивацией - сформировать правильное поведение / убрать неверное поведение / дополнительно мотивировать сотрудников путем нематериальной награды
1.4.2. Определение целей с использованием желаемого результата, выявленного на этапе 1.2
1.4.3. Проверка непротиворечивости целей геймификации и целей процесса
1.5. Выбор подпроцесса (объекта и границ геймификации). Для выбора необходимо определить, в рамках каких подпроцессов может быть осуществлен прогресс по целям геймификации
1....
Подобные документы
Анализ игровых жанров для мобильных устройств и целевой аудитории. Разработка концепции игрового приложения, основной механики, меню и интерфейса игры. Описание переменных скриптов. Реализация выбора цели и стрельбы. Настройка работоспособности игры.
дипломная работа [1,4 M], добавлен 19.01.2017Разработка аналога игры "Крестики-нолики", где игроки выбирают размер поля. Правила игры. Интерфейс программы. Главная функция main. Класс XO. Метод вывода поля и хода игроков. Методы поиска крестиков, ноликов. Методы проверки выигрышных ситуаций игроков.
курсовая работа [281,5 K], добавлен 30.01.2018Написание игры "Lines" на языке Object Pascal в среде Delphi. Алгоритм работы программы. Описание метода генерации поля. Используемые константы и переменные. Форма приложения после старта игрового процесса. Основные элементы формы и обработки событий.
курсовая работа [225,0 K], добавлен 12.04.2012Реализация программы для решения матричных игр. Задание матрицы игры вручную и случайным образом, нахождение оптимальных стратегий игроков итерационным и методом чистых стратегий. Проектирование и листинг программного кода, сохранение матрицы игры.
контрольная работа [716,7 K], добавлен 11.06.2011Разработка компьютерной игры "Эволюция" с помощью игрового движка Unit. Сравнение критериев игры-аналога и разрабатываемой игры. Разработка графического интерфейса пользователя. Настройки камеры в редакторе Unity. Структура файла сохранения игры.
дипломная работа [3,6 M], добавлен 11.02.2017Разработка программного продукта, предназначенного для имитации физического взаимодействия между объектами на основе игрового симулятора. Проектирование программы "LonelySpaceRanger", код которой представлен на языке VisualС++. Разработка интерфейса.
дипломная работа [3,2 M], добавлен 30.11.2011Техническое задание на проектирование системы автоматизированного решения задач механики. Разработка комплекта математических моделей систем с распределенными параметрами при действии динамических нагрузок. Выбор базового программного обеспечения.
дипломная работа [679,7 K], добавлен 15.01.2010Изучение существующих подходов к использованию компьютерных игр в образовательном процессе. Разработка и реализация проекта игрового обучающего приложения на мобильной платформе. Выбор платформы и средств реализации игрового обучающего приложения.
дипломная работа [3,4 M], добавлен 12.08.2017Теоретическое обоснование и разработка программы создания мини игры "Магический квадрат". Анализ содержания понятия "магический квадрат". Методы построения магических квадратов. Разработка программ создания мини-игр на языке программирования Delphi.
курсовая работа [3,5 M], добавлен 18.01.2011Разработка технологии обработки информации, а также структуры и формы представления данных. Подбор алгоритма и программы решения задачи. Определение конфигурации технических средств. Специфика процесса тестирования и оценки надежности программы.
курсовая работа [959,1 K], добавлен 12.12.2011Преимущества операционной системы Android. Проектирование интерфейса приложений. Визуальные редакторы и средства кроссплатформенной разработки. Оптимизация игрового процесса, выбор фреймворка и библиотек. Классификация и характеристика игр по жанрам.
дипломная работа [2,6 M], добавлен 10.07.2017История судоку, правила игры и цель головоломки. Разработка диаграммы классов. Реализация программы в объектно-ориентированном стиле по принципам модульности, иерархичности, ограничения доступа. Алгоритм генерации случайного игрового поля судоку.
курсовая работа [315,9 K], добавлен 01.02.2013Исследование спецификации логической игры "Сапёр". Системное и функциональное проектирование приложения. Разработка программных модулей. Обзор классов, необходимых для создания интерфейса данного приложения. Инструменты для реализации логической игры.
курсовая работа [1,2 M], добавлен 13.01.2016Анализ деятельности группы компаний "Инрэко ЛАН". Общая характеристика, основы проектирования и разработка операционной системы Android. Этапы разработки программного игрового приложения с использованием физики. Скриншоты, отображающие игровой процесс.
отчет по практике [2,7 M], добавлен 19.07.2012Проект игры "Ловушка", созданный при помощи языка программирования C++. Описание заголовочных файлов. Правила и цель игры "Ловушка". Отображение движущихся объектов игры на экране с помощью заголовочного файла "gameclass.h". Описание игрового процесса.
курсовая работа [70,6 K], добавлен 14.10.2012Постановка задачи нелинейного программирования. Определение стационарных точек и их типа. Построение линий уровней, трехмерного графика целевой функции и ограничения. Графическое и аналитическое решение задачи. Руководство пользователя и схема алгоритма.
курсовая работа [2,5 M], добавлен 17.12.2012Создание математической модели, приведение ее к виду задачи линейного программирования. Геометрическая трактовка решения. Определение области допустимых значений. Составление симплекс-таблиц. Разработка опорного плана задачи методом минимального элемента.
контрольная работа [260,2 K], добавлен 22.12.2013История создания компьютерных игр. Обзор современных игровых жанров. Выбор используемых инструментов. Руководство пользователя. Разработка игры в жанре 3D шутера от первого лица. Конструктор игр Game Maker. Создание уровня с несколькими регионами.
курсовая работа [961,8 K], добавлен 22.06.2015Матричные игры и линейное программирование. Итеративный метод решения матричных игр. Игры на выживание, игры-погони. Критерии принятия решений. Персонал, набранный с помощью резерва в результате решения статистической игры по различным критериям.
курсовая работа [629,3 K], добавлен 08.10.2014Особенности и преимущества 3D-моделирования. Базовые функции нелинейного редактирования и комбинирования видео. Проектирование 3D-модели для игрового проекта по созданию дома и моста. Просмотр взаимодействий с игроком объектов в Unreal Engine 4.7.
дипломная работа [3,6 M], добавлен 14.06.2015