Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > разработка игр, графический дизайн и моделирование > Gamedev - cоздание игр: Unity, OpenGL, DirectX
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 04.02.2014, 22:22   #71
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию Проектирование на уровне приложений и движков

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

Игра и сопутствующие приложения

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

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

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

Игровой редактор. Основная его функция – создавать и редактировать игровые локации, наполнять их различными игровыми объектами, редактировать происходящие в локациях события и связывать их в общий игровой мир.

А именно, с его помощью можно будет редактировать terrain локаций, статичные объекты в ней, добавлять используемые объекты, NPC и противников. «Оживлять» геймплей можно будет добавлением скриптовых сцен (для реализации которых также понадобятся объекты-триггеры), назначением различным объектам поведения с помощью скриптов, назначением NPC диалогов.
Скриптовые сцены и поведение, помимо прочего, предполагают проигрывание определенных звуков, демонстрацию всплывающих сообщений (такие как «Вы видите следы на земле», или реплики NPC, не предполагающие диалога: «Эх, хороша погодка!»), создание новых объектов, перемещение и изменение старых.

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

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

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

Редактор архивов. Не очень удобно хранить на диске сотни и тысячи файлов с ресурсами, особенно с учетом того, что обычно один игровой объект имеет несколько видов анимации (особенно их много у главного героя – анимации движения, нанесения различных ударов, применения скилла лечения, смерти и т.п.). Кроме создания кучи файлов, это несколько затрудняет передачу игровых модов (вспомним, что концепция проекта предусматривает активные создание и обмен пользовательскими модификациями).

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

Конечно, должна быть возможность работать с такими архивами как в игре, так и в игровом редакторе (см. ниже).
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 04.02.2014, 22:22   #72
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию Проектирование на уровне приложений и движков

Игровые движки

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

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

Структуру данных (а заодно и архитектуру классов) этого движка я собираюсь строить по аналогии с моделью, традиционной для 3D-игр (хотя моя игра и будет двухмерной): ключевым понятием является сцена, содержащая отображаемые объекты (и частично совпадающая со сценой и объектами, обрабатываемыми физическим движком), расположенные правильным образом, которые регулярно обновляют свое состояние (сами или согласно внешним сигналам), и при необходимости отображаются на экран (строго говоря – сначала в буфер или, иначе, текстуру). При этом рисуются (рендерятся) не все объекты, а только нужные; отбором последних занимается камера, знающая, какие из них находятся в области видимости, а какие – нет.

Объекты располагаются на различных слоях, определяющих порядок рендеринга. Я собираюсь использовать следующие слои (перечислены в порядке их отображения):
  • Текстуры ландшафта (земля, песок, дороги и т.п., неизменяемая основа всей карты)
  • Элементы ландшафта (объекты, которые по сути мало чем отличаются от самой земли; основное их назначение – располагаясь поверх текстур ландшафта, вносить в них разнообразие: это могут быть следы на земле, различные мелкие предметы типа листьев, шишек, травы и т.п.)
  • Подвижные и неподвижные объекты, участвующие в игровом взаимодействии (персонажи, монстры, непроходимые декорации, используемые предметы и многие другие)
  • Эффекты, являющиеся частью декораций игрового мира и допускающие отображение поверх всего вышеперечисленного (например, некоторые световые эффекты, погодные и другие)
  • Over-HUD (визуальные эффекты и всплывающие сообщения, относящиеся к отображению игровой механики, а не к игровому миру: полоски здоровья и прогресса, рамки выделения, цифры нанесенного урона и полученного опыта и другое)
  • HUD (различные элементы пользовательского интерфейса, окна, меню)

Эти слои можно также разделить на две группы (выделить два суперслоя): сцена и UI. Первые четыре слоя отображают состояние игрового мира, последние два – артефакты управления компьютерной игрой. При этом картинку со сцены можно рендерить в отдельную текстуру, которую затем, при необходимости, подвергнуть постобработке для создания дополнительных эффектов (например, применив какие-либо фильтры). UI как правило такой обработке не подвергается, да и отображается по несколько иным правилам, чем объекты игрового мира.

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

Последний тип звуков должен воспроизводиться исходя из относительного положения источника и главного персонажа (почти всегда предполагается, что в колонках мы слышим то, что слышит он), так что здесь также должны присутствовать аналоги сцены и камеры из графического движка.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 04.02.2014, 22:22   #73
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию Проектирование на уровне приложений и движков

Несколько менее очевидный движок – это менеджер ресурсов. Его задача – обеспечить средства вывода (графического и звукового) всеми необходимыми для этого объектами – текстурами, звуками, шрифтами и т.п. Грубо говоря, при загрузке очередной локации (или, например, главного меню) кто-то сверху заявляет: «Ничего не знаю, но сейчас этим двум ребятам понадобится рисовать и проигрывать. Вот тебе список, обеспечь!» – и менеджер ресурсов обеспечивает.

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

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

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

Хотя обычно эта задача решается единственным вызовом библиотечной функции (типа LoadFile), в некоторых ситуациях приходится иметь дело не с реальной файловой системой, а с виртуальной. На самом деле этот движок может загружать ресурсы по сети или (что будет иметь место в моей игре) – из архивов, о которых я говорил выше. Но опять же – использующая его система не должна знать таких тонкостей: она лишь дает информацию о том, откуда брать нужные ресурсы («путь к файлу»), а движок самостоятельно решает эту проблему.

Еще два компонента – это оконный менеджер и система пользовательского ввода. Их назначение вполне понятно из названий и состоит в сокрытии работы с окном приложения и получении данных о мыши/клавиатуре/геймпаде за собственным интерфейсом.

Пожалуй, также можно выделить движок, отвечающий за UI – всевозможные окна, кнопки, меню и т.п. Естественно, что использовать в игре соответствующие компоненты из какой-либо библиотеки GUI – катастрофически плохая идея (надеюсь, пояснения излишни), поэтому необходимо реализовывать их самостоятельно или использовать специализированные библиотеки (например, MyGUI).
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 04.02.2014, 22:23   #74
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию Проектирование на уровне приложений и движков

Общая картина

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

Работа игры в общем проходит по следующему сценарию:

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

Здесь пользователь выбирает, желает ли он начать новую игру, загрузить старую, посмотреть список авторов, перейти в настройки, выйти из игры или сделать что-либо еще. «Авторы» и «настройки» можно не выделять в отдельные состояния – здесь мы просто представляем другие меню или окошко с бегущим текстом (опционально – подокна, в которых демонстрируются видеоролики).

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

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

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

В состоянии загрузки ресурсов мы имеем на входе список того, что нужно загрузить и инициализировать (при старте игры мы опираемся на тот список, который «вшит» в исполняемый файл игры; позже такой список является таким же ресурсом, загруженным ранее), и передаем его менеджеру ресурсов, который осуществляет необходимые действия. Пока он в отдельном потоке занят этим, отображается загрузочный экран, возможно – с полосой прогресса и/или анимированными текстурами, для обновления кадров которых понадобится «мини игровой цикл» (при старте игры этого не происходит; можно, однако, выделить отдельное состояние «предзагрузка», чтобы разграничить эти два случая).

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

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

Думаю, для создания общего представления об архитектуре кода этого достаточно. Более подробно каждый аспект я разберу в свое время. В следующем посте, как и говорилось, речь пойдет о конкретной реализации состояний и менеджера состояний.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 10.02.2014, 11:38   #75
intmain
Играюсь с Python
Форумчанин
 
Аватар для intmain
 
Регистрация: 12.12.2012
Сообщений: 340
По умолчанию

А я думал ты уже игру написал
Что ел то - в долг, что жил то - зря.
Для избранных. ))
Секретные разработки
intmain вне форума Ответить с цитированием
Старый 11.02.2014, 00:03   #76
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Ну как видим, еще нет. Собственно, если бы я писал только игру, то наверно как минимум альфу-то уже сделал. Написание постов занимает кучу времени, тем более что пишутся они в свободное время, которого то нет, то лень тратить на них. В декабре-январе проектом почти не занимался, в основном почитывал информацию по теме.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 20.06.2014, 18:57   #77
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию Проект возобновлен

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

Текущее положение дел

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

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

В числе таких полезных открытий можно назвать знакомство с небезызвестным C#, небольшую практику в TDD (Test-Driven Development) и кое-какой опыт работы с системой контроля версий Git.

Конечно, в корне менять концепцию и переходить на разработку игры на шарпе я не собираюсь по целому ряду причин (хотя бы потому, что C++ и Qt я по-прежнему знаю гораздо лучше, чем C#), но познакомиться с новым хорошим языком, его философией и методологией всегда полезно.

Гораздо большее прикладное значение имеет практика в TDD и создании юнит-тестов вообще. К сожалению, в отличие от NUnit, который доступен в MS VS из коробки, Google Test и Qt Creator мне еще предстоит подружить, и не факт, что это будет просто.

Что же касается Git, то мое знакомство с ним принесло проекту наиболее крупные потрясения. Коль скоро главный козырь Mercurial - более низкий порог вхождения - более неактуален, я решил отказаться от этой системы контроля версий в пользу гита как, быть может, самого популярного продукта в этой области. В частности это означает, что для проекта будет создан репозиторий на GitHub со всеми вытекающими.

Новая группа ВКонтакте

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

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

Так что если вы желаете всегда быть в курсе всех новостей проекта - проходите по ссылке и вступайте в обновленную группу!

В ближайшей перспективе

Напоследок скажу пару слов о том, что ожидает вас в самом скором времени.

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

И еще много интересного ожидает вас в дальнейшем!
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 20.06.2014, 19:11   #78
eval
Подтвердите свой е-майл
 
Регистрация: 29.08.2012
Сообщений: 4,022
По умолчанию

пора на юга на месяцок, отдохнуть
eval вне форума Ответить с цитированием
Старый 29.06.2014, 15:54   #79
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию Менеджер игровых состояний и конечные автоматы

Как и обещал в прошлом посте, здесь я рассмотрю вопрос реализации менеджера игровых состояний и подробно разберу концепцию конечного автомата (КА), являющуюся ключевой в этом вопросе. Для начала я опишу КА с точки зрения математики, а затем рассмотрю возможность его применения для управления игровыми состояниями.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 29.06.2014, 15:54   #80
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию Менеджер игровых состояний и конечные автоматы

Конечные автоматы в математической логике

Так что же из себя представляют КА? Для начала посмотрим на то, какие функции они выполняют.

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

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

Некоторые из состояний являются выделенными – имеется одно начальное и несколько конечных. Подразумевается, что когда КА начал считывать буквы с ленты, он находился в начальном состоянии; если после считывания последней переданной ему буквы он оказался в одном из конечных – это «хорошо», если нет – «плохо».

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

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

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

Теперь рассмотрим, как (почти) строго задать конечный автомат. Пусть имеется некоторое конечное множество Q, которое мы назовем множеством состояний (а его элементы – состояниями). Выберем из этого множества элемент q[SUB]0[/SUB], который назовем начальным состоянием, а также подмножество F – множество конечных состояний.

Возьмем также некоторое конечное множество Σ, которое назовем алфавитом. На декартовом произведении Q*Σ зададим всюду определенную функцию δ, принимающую значения на множестве Q – функцию перехода. Пятерку (Q, ∑, δ, q0, F) называют полным детерминированным конечным автоматом (ПДКА).

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

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

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

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

Есть также другие типы КА, например, недетерминированный конечный автомат (НКА) и ε-НКА (они оба эквивалентны ДКА), но здесь я их рассматривать не буду. Они оказываются удобны в некоторых задачах, но для рассмотрения вопроса о реализации менеджера игровых состояний лучше подходят детерминированные автоматы. Впрочем, в полной мере их будет недостаточно, и придется упомянуть также т.н. конечные автоматы с магазинной памятью, которые распознают более широкий класс языков, нежели ПДКА.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Электронно учебное пособие gloomy_jr Общие вопросы Delphi 1 23.05.2012 14:07
Создание игры::особенности коллективной разработки флеш приложений АТИКОН Gamedev - cоздание игр: Unity, OpenGL, DirectX 9 21.08.2011 19:51
Мультимедийное учебное пособие world12_tk Помощь студентам 4 21.04.2011 17:37
статья - Может-ли ПО работать быстрее или взгляд изнутри Pblog Обсуждение статей 0 27.02.2011 23:10
Электронное учебное пособие Zeibel Помощь студентам 10 31.05.2010 10:55