Отправлено: 08.10.09 16:50. Заголовок: Системный подход, автоматное программирование или как дойти до конца.

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

Выход из такой ситуации вы найдете ниже.

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

Увы, моя структура получалась сырая, но уже были проблески надежности подхода.

И вот совершенно случайно, как это обычно происходит, мне попадается сайт про автоматное программирование. Честно признаться, материал для меня показался весьма мутный, ибо много статей, презентаций, а азов «для чайников» почти нет. Но мне удалось на просторах этого сайта http://is.ifmo.ru раздобыть очень познавательную картинку. http://slil.ru/28057258

Здесь автомат - это неделимое пространство, в нашем QSP понимании - локация. Так что таблица "Автоматы" у нас будет таблицей "Локации".
«Описание состояния» можно интерпретировать отчасти как «описание локации», и, как видно из рисунка, таких описаний у одной и той же локации может быть несколько.
Простой пример:
ГГ появился или вошел в комнату - и идет описании локации №1, где описываются странные запахи или свет от лампы (или первые ощущения ГГ).
После ГГ выходил из комнаты и вновь её посетил. Если в этом случае опять выводить описание локации №1, то получится некое повторение, причем не совсем уместное - как, например, первых ощущений ГГ от незнакомой комнаты. Т.е. при повторном посещении нужно выводить описание локации №2. А теперь представьте, что погас свет и описание той же самой комнаты поменялось на описание №3. Или, скажем, какой-то предмет (или персонаж) появился/исчез (пришел/ушел) - опять описание локации будем другим.

Помимо описания локации, в описание состояния входят действия (мы видем стрелку на процедуру) - можно назвать это «действия при посещении» локации N в состоянии K.
Помимо действий, могут присутствовать и изменяться переходы на другие локации-состояния. Как видим, в переходе стоит условие выполнения перехода. По большей части мы используем безусловный переход GOTO ‘Новая локация’ (GT ‘Новая локация’), а вот операнд оператора GT это и есть номер нового состояния локации или, если быть точнее, номер локации – номер состояния локации.
Переход в нашем QSP представлении это не только переход из локации в локацию, здесь могут быть запрограммированы и действия, такие как "взять предмет" или "использовать", "поговорить с персонажем" и т.п. Так и на картинке можно видеть в таблице "Описание перехода" пункт «Действия» со стрелочкой на процедуру, которая также может зависеть от условий и менять состояния локации.
Пример: В локации есть мяч. В описании локации мы видим его, а в действиях (переходах) у нас есть действие "взять мяч". Условий пока не будем вводить для простоты, в итоге «Действие» в данном «переходе» на «локации» отсылает нас на подпрограмму GOSUB 'взять мяч'. Как можно заметить, описание локации, где мяч лежит на полу уже неактуально, поэтому нужно поменять описание локации на другое.

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


Вот такие у меня родились мысли и я готов это все обсудить.

 Отправлено: 08.10.09 17:13. Заголовок: Так сейчас примерно ..

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

Разумеется, можно всё свести к минимуму на благо автоматизации, но при этом потеряем гибкость.

 Отправлено: 08.10.09 17:25. Заголовок: Обычно забрасывают п..

Обычно забрасывают проекты не из-за сложностей с программированием, а из-за проблем с сюжетом игры.

 Отправлено: 08.10.09 22:47. Заголовок: Byte написать движок..

Byte написать движок намного легче чем игру.

 Отправлено: 09.10.09 08:51. Заголовок: Согласен, на этой ст..

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

 Отправлено: 09.10.09 09:30. Заголовок: Согласен, от част..

Согласен, от части, что забрасывают писать из-за отсутствия сюжета, который не отражен в обычном тексте, а почему не отражен?
Мне видится 2 варианта. Либо человека посетила муза и он фиксирует все на лету в QSP редакторе сразу в коде, вы можете представить какой это получается код, либо сценарист который все же написал сценарий, написал как умел и сценарий больше похож на книгу. Самое оптимистичное ожидание это набор локаций и действий в них которые ГГ совершает по сюжетной линии. Программисту нужно будет совместно или самостоятельно уже додумывать, а что если игрок не пойдет в комнату Б из комнаты А по сюжету, а пройдет сразу в комнату В. Теперь представьте что ГГ по сюжету посещает эти комнаты в разных последовательностях, что либо в них делает прибавьте сюда все возможные варианты посещения комнат без сюжетной линии, какой код мы получим всего в 3 локациях (комната А,Б,В). Допустим программист победил, муза не ушла и все 3 комнаты описаны как по сюжету, так и все несюжетные посещения, Добавляем комнату Г, Д представляете объем работы, который нужно будет внести в то что уже неписано, вернуться и дописать код который и так уже трещит по швам и переполнен проверочными флагами посещений учитывая все действия как сюжетные так и не сюжетные в них.

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

 Отправлено: 09.10.09 09:39. Заголовок: Ну так как раз по..

цитата:

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

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

 Отправлено: 09.10.09 09:39. Заголовок: гм... а я почему то ..

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

 Отправлено: 09.10.09 09:58. Заголовок: 123th пишет: гм... ..

123th пишет:

цитата:

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

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

HIman пишет:

цитата:

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

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

 Отправлено: 09.10.09 10:32. Заголовок: Ну я тоже выраб..

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

Родилась идея, прежде чем садиться за код, я сажусь за тетрадку и ручку. Тщательно записываю все обрывки пришедшей идеи (так как сначала она чаще всего не монолитна). Затем рисую общую канву игры - карту. Разбиваю её на локации - при этом, к примеру, дом может содержать и не одну локацию, поэтому рядом с ним пишу 4,5,6,7 - то есть здесь 4 локации с порядковыми номерами относительно всей игры.

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

И вот, когда набросали такой план - можно садиться за комп. По ходу программирования всё это собирается, дописывается, усовершенствуется и ветвится ещё больше, чем первоначально, но такой подход даёт 70% того, что игру вы допишите, ведь вы уже знаете ЧТО писать.

30% остаётся конечно же на то, что, расписав всё и вся, игру делать уже не захочется, к тому же, если план написан недостаточно чётко остаётся вероятность запутаться в переходах.

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

ИМХО Просто поделилась, вдруг поможет.

 Отправлено: 09.10.09 10:34. Заголовок: Примерно аналогично)..

Примерно аналогично) Я сейчас стараюсь максимум информации записать в гугл-блокноте, а уже потом начинать её переносить в код, зачастую копированием)

 Отправлено: 09.10.09 10:50. Заголовок: ыыы... а я всё держу..

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

сколько я ни пытался расписывать локации в блокнотах и тетрадках - ничего из этого не получается. видимо не для меня | ]

 Отправлено: 09.10.09 13:19. Заголовок: блаблабла

ап. Придумываю все на ходу.

Я недавно думал делать так, ток не тетрадке а в ворде... В тетрадке есть минус - писать долго. А рисовать можно. А вот на компе быстро сварганил, и делаешь.

 Отправлено: 09.10.09 19:53. Заголовок: Кстати, на начальном..

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

 Отправлено: 09.10.09 20:04. Заголовок: Ajenta пишет: Кстат..

Ajenta пишет:

цитата:

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

Кстати да, хороший совет :)