ЕМНИП, мигание в начале - потому что точка появление игрока и ивента не может совпадать, и приходится его телепортировать в нужную пони. Я правильно понимаю, что нужно вынести часть скриптов на пустую загрузочную карту, а потом автоматически телепортировать игрока в нужное тело первого уровня? Если так, то я пробовал, но у меня что-то пошло не так, и стало только хуже из-за этих переходов - я так и не успел разобраться, как сделать всё по уму и красиво.
Согласен. Амбиции и идеи были несколько выше, но картёжник объявил забастовку, да и я не смог быстро и чётко придумать реализацию нужных механик. Поэтому выбор был между "Выпустить простенькую игру" и "(Никогда) не доделать более глубокую игру". Были планы сделать двери, которые откроют путь для третьей пони только если две другие встанут на специальные места в разных местах карты. Была задумана механика "наматывания шара", т.е. с каждым качением шар увеличивается в размере, и спустя несколько качений перестаёт влезать в проходы. И одна пони была сильной и могла бы катнуть его ещё пару раз. Ямы, в которые можно было бы уронить шар, сделав их проходимыми - другая пони могла бы эти ямы перепрыгивать. Какие-нибудь магические штуки, с которыми могла бы взаимодействовать только третья. И т.д. (Помимо банально большей продуманности самих лабиринтов, чтобы их нельзя было пройти 1 персонажем)
У меня есть сильное подозрение, что кадры съедает параллельный процесс прослушки клавиш (на котором и построена смена персонажей) и такой же процесс по отрисовки интерфейса. Я конечно указал в конце каждого события "ждать 60 кадров", но либо это работает не так, как я думаю, либо проблема чуть сложнее. Может быть дело в событиях, которые читают столкновение с другими событиями. Я пока не знаю.
Про плагины не понял, честно не понял.
YEP_KeyboardConfig - для листания диалогов на W/S. Как это можно реализовать иначе?
DK_Full_Input - для смены персонажей. А именно, читает код клавиши и сохраняет его в переменную. Я слежу за переменной и таким образом реализую кастомное доп. управление. Как это можно сделать иначе?
CTB_EventTriggerEventMV - для заталкивания кристаллов в порталы и разрушения рунных стен - с помощью снежных шаров. Т.е. события начинают видеть столкновения не только с игроком, но и с событиями. Можно ввести события-надзиратель, которое будет следить за координатами, и... это очень муторно и неавтоматизированно. Есть какие-то иные способы?
HIME_MultipleInventories - для разделения инвентаря на трёх персонажей. Тут я просто не знаю иных вариантов, в стандартном rmmv это кажется принципиально невозможно без плагина?
С музыкой я не знаю. Я пытался найти другую, но не нашёл. У меня нет музыкального слуха, поэтому здесь мне особенно тяжёло. Скажу лишь что я ставил несколько мелодий, но они были слишком... отвлекающими? Раздражающими? В общем, пока что я не нашёл подходящей.
Со сложностью всё относительноЯ, картодел и наш тестер не смогли пройти с первого раза ни одну карту, кроме вступительной
В остальном про карты согласен, но это скорее продолжение темы второго абзаца.
Правда здесь ещё одна тонкость, у меня что-то не получилось с сохранениями, поэтому большая длительность игры банально опасна -- из-за невозможности сохранить прогресс прохождения между сессиями. Все проблемы, как это обычно бывают, тянут друг друга...
Подытоживая:
По игре - нужно всё-таки реализовать игровые различия персонажей и сделать уровни более соответствующими сюжету и описанию игры про командную работу. Найти музыку.
По технике - отработать появление персонажа, найти причину просадок кадров, ЯННП про плагины, решить проблему сохранений.
Верно?
Социальные закладки