ТЕМА: Функции РТС

Добрый день.Есть ли возможность сделать постройку зданий с выбором места по него.?
Добычу ресурсов и прочее.

Да возможно , всё это делается через эвенты. Нужны подробности в личку , и таки да мать вашу когда уже вы будите писать версию МЕЙКЕРА!

Ну, в данном случае версия не так важна, так как функции аналогичны. Но замечание верное.

strelokhalfer пишет: Стрелок , захвата координат X,Y и ID карты нет в других мейкерах хроме ACE.

Nazrael пишет:
RPG maker VX ACE я тему создал не для того что-бы ещё делать лишние шаги мне нужен точный ответ здесь а не в твоих сообщениях.

SAIBER пишет:
Уфх... Хорошо , давай пиши какая именно тебе нужна система РТС, какие компоненты и части нужно реализовать. Телепаты в отпуске.

Шо? Захватить координаты X,Y и ID карты и сохранить их в переменную может любой мэйкер.

Agckuu_Coceg пишет: Хм , не замечал. Шаз гляну. Азазаз какое же я дно , да есть во всех.

SAIBER пишет: На мейкере нельзя сделать ртс, забудь об этом.

В теории то можно, но на практике тяжело и нужно.

Во славу Сотоне , можно сделать всё. Но смысла в этом нет.

Как писал в своём 1 посте.Систему добычи ресурсов.Установка зданий в нужное место игроку.

Зависит от того, какую делать RTS. Если мы говорим о RTS в классическом понимании (Dune, Warcraft, C&C) - то да, мэйкер совсем не то (сделать можно, но придётся перебить очень большую часть скриптов - без опыта программирования и желания с этим всем разбираться в такое вообще лучше не соваться). А вот упрощённые версии RTS немецкой школы (вроде Settlers или Anno) вполне реальны - однако это всё равно требует определённого подхода и знаний.

Касательно вопроса установки ивента здания, чтобы под VXA - для построения подобной системы можно использовать Event Spawner от Yanfly, слегка поиграв с кодом.
А вот с ресурсами всё куда сложнее. Чтобы построить необходимую схему, мне нужно вначале понять, какую механику ты собираешься использовать в своём проекте.

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

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

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

2) Используемое количество юнитов. Могут ли множество юнитов добывать ресурс в одном месте или добывать ресурс в одном месте может лишь один юнит? И если первое - то есть ли ограничение на количество юнитов, которым позволено добывать ресурс в одном месте?
В первом случае всё выглядит несколько сложнее, так как необходимо создать схему, при которой ожидания кадров будет уменьшаться в зависимости от количества юнитов, а также переменную, в которую забивается количество юнитов в месте добычи ресурса.

3) Бесконечное ли место добычи ресурсов или имеет фиксированный объём в переменной?

Юнитов на одно место добычи ресурсов может быть разное количество так как это место можно будет улучшать.
Запас ресурсов будет не бесконечным.А вот на счёт выбора подходящего варианты из предложенного я не знаю какой выбрать.

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

Второй вариант намного более трудоёмок, но зато позволяет создавать индивидуальных юнитов (по типу DF или Гномории) - так как это не ивенты, а персонажи - соответственно, с их помощью можно сделать игру разнообразнее, создавая "специалистов", каждый из которых будет занят своим делом. Проблема заключается в том, что игроку придётся управлять и переключаться на каждого юнита или прописанную заранее группу юнитов в игре вручную - автоматизированной системы ручного управления несколькими разными юнитами, которая характерна для RTS с микро-контролем, для RM на данный момент не существует. К тому же, все остальные персонажи, которые на данный момент не осуществляют никаких действий, не будут делать абсолютно ничего (конечно, можно попробовать написать простейший AI, но это довольно хардкорный вариант в том случае, если этих персонажей больше даже хотя бы десятка). К слову, я так же не знаю, будут ли они реагировать на врагов - я знаю ABS-боевые системы, которые позволяют делать автоматическое AI для боя NPC-ивентам (хотя и не на ACE, но тут надо поискать), которое можно было бы использовать в первом варианте - но вот насчёт второго я, к сожалению, не уверен.

Так что выбирай, что тебе будет легче и проще. Я бы лично предпочёл первый вариант, хотя оба имеют свои недостатки и достоинства.

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

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

Спасибо сейчас начну разрабатывать 1 вариант.