MAGICON.FB
Игровая механика для текстовых игр. Изначально разрабатывалась под плеер QSP v.5.7.0, однако в перспективе будет работать и на более поздних версиях плеера. Учтите, все принципы, описываемые ниже, и на других страницах, опираются на возможности QSP 5.7.0., хотя и могут применяться на иных плеерах.
История движка
Разработка игровой механики Magicon.FB (далее я буду называть её "движок") началась очень давно, где-то в 2008 году. Изначально она не была полноценной механикой, а лишь простеньким механизмом, обслуживающим несколько предметов. По мере разработки игры "Магикон" в механизме обнаруживались недостатки. Во-первых, разнообразие предметов, которое мы обычно наблюдаем в RPG, здесь не поддерживалось. Во-вторых, предметы были привязаны к пунктам панели "инвентарь", что не позволяло делать многоуровневые вложения предметов. В-третьих, каждый предмет фактически обслуживался собственным механизмом, что на порядки увеличивало объём повторяющегося кода. В итоге, чтобы обслуживать всего лишь пятьдесят предметов, пришлось написать громоздкую базу механизмов, занимавшую почти 800 кбайт чистого текста.
В то же время, когда я усиленно трудился над сокращением механизмов работы с предметами, такие механизмы, как обслуживание игрового времени, механика боя, казались мне незначительными и второстепенными. Работа с персонажами и локациями так же отнимала много сил и времени, и наступал момент, когда количество локаций и персонажей, данные которых приходилось отслеживать самому, превышало критическую отметку. А это совсем небольшие числа: всего двадцать локаций и около десяти - пятнадцати персонажей.
Проследив за повторяющимися кусками кода я сделал вывод, что каждому предмету ни к чему иметь собственный механизм обработки, и что каждый предмет является всего лишь набором данных, которые должны где-то храниться и как-то распознаваться движком. Так же я обратил внимание на то, что в QSP весь текст, заключённый в угловые скобки, при включенном режиме распознавания html, скрывается от игрока. Это дало возможность создавать предметы с кучей различных данных, которые помещались между угловыми скобками, и игрок их попросту не видел. К сожалению предметы всё ещё хранились в виде пунктов панели "инвентарь", что затрудняло обработку без участия игрока. Тогда-то и возникла идея хранить предметы в специальной таблице, и воспроизводить в панели "инвентарь" по-мере необходимости.
Сложно было не заметить, что в той же самой таблице можно хранить не только "ножи и вилки", но и "локации", и различные качества героя, и персонажей, и много чего ещё. Так я подошёл к новому концепту (идее) движка: всё - объекты.
С той поры движок представляет собой то, что он представляет. Прошло чуть больше года, однако за это время удалось сделать не в пример больше, чем за предыдущие четыре. Мало того, по-сравнению даже с гибкостью самых первых механизмов, игровая механика в нынешнем виде позволяет реализовать всё, что угодно за счёт (не побоюсь этого слова) расширяемой архитектуры. Фактически, движок позволяет, не изменяя его коренным образом, расширять возможности объектов (не предметов, а именно объектов).
К сожалению пока реализованы не все задумки. Механизм боя, механизм работы с персонажами, и несколько десятков мелких механизмов существуют лишь в виде идей. К тому же по-настоящему обкатать функциональные возможности движка удастся только при разработке игр. Какие-то широко употребимые функции наверняка упущены. Всё это будет поправляться и изменяться, как поправляется и изменяется вот уже почти год, и в скором времени примет достойный вид.
Пока же остановимся на принципах работы различных механизмов, чтобы не морочить голову авторам, которым уже неймётся всё опробовать. Историю же разработки движка под новым соусом можно почитать здесь.
