Так, прекращай даблпостить, пожалуйста. Если хочешь дополнить свое сообщение - используй кнопку редактировать.
Так, прекращай даблпостить, пожалуйста. Если хочешь дополнить свое сообщение - используй кнопку редактировать.
Tishka, а ты как хотел? Что бе мейкер за тебя всё делал?)
Спойлер Спрятал под спойлер:
Единственная сложна твоя задумка это всё связанное с костром. Если быть честным.
ну слушай, ты ведь даже в программе не разобрался. А уже приуныл...
Тебе бы потыкаться в программе прежде чем начинать серьёзные проекты делать. Ты там просто недооцениваешь мейкер, но никогда не делай не рпг на рпг мейкере. Если не хочешь боли в попе :3
Последний раз редактировалось DesKarD; 19.07.2016 в 11:52.
есть вероятность, что при повторении боёв с угрозами это превратиться, "Блин, как же задолбали болтать эти картонки!".
Особенно если противники будут нападать рандомно и без предупреждений.
А ещё вот тут есть кнопочка:
Спойлер Condition:
И там всё это настраивается..
1 Condition = 1 странице
Последний раз редактировалось DesKarD; 19.07.2016 в 11:59.
Tishka, если у тебя каждый враг будет уникален это ещё можно понять.
А если у тебя каждый шаг сопровождается битвой это скорее всего не успеют оценить
Спойлер оффтоп:
Прохлада и спокойствие мне вполне по душе
Спойлер :
き っ と 、 女 の 子 は お 砂 糖 と ス パ イ ス と 素 敵 な 何 か で で き て い る。
А чего там сложного? Там же обычный обсчет координат через переменные с активацией общего/параллельного события, которое раз в Х кадров добавляет герою и/или пати определенное количество ХП/МП/Евро/тугриков и т.п. Координаты не соответствуют - "реген прекращается".
//
Попросили пошагово объяснить...) Попробую. Запасайтесь чаем хД
Расскажу только про костер.
Итак, наиболее важными составляющими в RPG Maker являются четыре вещи. Ивенты (события, events), переключатели (свитчи, триггеры, switches), переменные (variable) и условия (conditional branch). Остальное тоже важно, но эти - основополагающие.
На них, в общем-то строится вся твоя будущая игра.
Немного отступлю и скажу, что поиск нестандартных решений в редакторе очень сильно развивает мышление. Ну и плюсик в эго, если все получилось)
Итак, ивенты. Надеюсь, не надо объяснять, как их создавать? (ЛКМ х2) Отвечают за все, что происходит у тебя на конкретной карте. Различные диалоги, подсчет значений и тому подобные вещи. В ивентах можно задавать значения переменных и прописывать условия, включать/выключать свитчи.
Начнем по порядку. Я понял так, что ты хочешь сделать костер местом отдыха. Твои пошаговые действия:
1. Создаешь ивент, в окне графики рыщешь и выбираешь огонь. Визуально твой костер готов. Будет ли он сейчас работать так, как хочешь ты? Нет. В играх ничего само по себе не работает, и это задача игродела - сделать так, чтобы все мечты воплотились в жизнь (газпром, конечно, может помочь, но не в нашем случае).
2. Итак, у нас есть графика костра. Мы хотим, чтобы рядом с костром здоровье героя или целой партии восстанавливалось. Наши действия? Сначала - принять во внимание, какими средствами обладает движок. В общем-то - достаточно обширными, чтобы реализовать эту задумку.
Теперь необходимо продумать алгоритм. Ага, мы подошли к костру и, находясь в определенной зоне (к примеру, три клетки) - получаем плюсик к ХП. Как только мы уходим - реген прекращается.
Отлично, мини-алгоритм есть. Теперь необходимо углубиться в способности мейкера.
3. Переменные. Отличный инструмент для создания самых разнообразных условий. С помощью переменных можно задавать самые различные значения (и не только задавать, но и брать их из данных игры) - здоровье героя, его атаку, уровень, игровое время, игровые шаги, координаты... Стоп. Координаты! Прекрасно! Значит, все здесь можно сделать через переменные, получающие из игровых данных координаты героя! Как же мы запишем координаты героя в переменную в реальный момент времени?
4. Здесь в дело снова вступают ивенты. Они бывают совершенно различны по степени активации. То от касания игрока, то он кнопки действия... А могут быть параллельными. (не путать с автоматическим). Параллельные ивенты выполняются бесконечное количество раз (грубо говоря, циклично), и в зависимости от тактовой частоты процессора твоего компа. Можно задать условие, при котором ивент будет осуществлять выполнение того, что записано у него в "теле". Но нам это не особо нужно, нам нужно обсчитывать координаты Х и У игрока! А чтобы не сильно нагружать процессор, мы можем поставить выполнение обсчета раз в секунду. Примерно так это будет выглядеть.
Итак, теперь игра каждую секунду времени получает данные о местоположении игрока и записывает их в переменные. Замечательно.
Что делать дальше? По логике, нам необходимо сравнить координаты героя и координаты костра. Разумно? Разумно. Это тоже лучше всего делать параллельным событием (гуру меня поправят).
5. Следующий пункт алгоритма вступает в действие. "Все познается в сравнении", верно?
Для того, чтобы что-то сравнивать, необходимо какое-либо условие. Математически их несколько (меньше, больше, меньше/равно, больше/равно, не равно). Вопрос выглядит простым, если герой стоит ПРЯМО на костре ( в таком случае необходимо лишь сравнивать координаты, и если они РАВНЫ, тогда выполняется действие). А как же быть с радиусом?
Да, в общем-то, тоже просто.
Зададим радиус регена ХП равный трем клеткам. Чтобы было более наглядно, возьмем координаты костра 10;10. Таким образом, на координатах 13;13 условие будет выполняться, а на 14;14 - уже нет. Аналогично с 7;7 и 6;6.
И тут из тени выплывает Ветвление условий (Conditional Branch) вместе с математическими действиями по переменным.
Небольшое отступление. Мы можем создать костер с заданными координатами (и тогда пропишем координаты лишь единожды). Но что делать, если в игре встретятся несколько таких костров? Неужели для каждого переписывать данные с координатами? Ну уж нет. Мы на такое не подписывались!
6. Запишем координаты костра в память игры так, как делали это с координатами игрока. (пусть это будут переменные КостерХ и КостерY, равные, для удобства и наглядности, 10).
Зададим радиус действия в переменную РадиусДействия1; он будет равным 3.
Что делать дальше?
Вводим еще две переменных (ИИГрокХ и ИИГрок У). Да, может, я перебарщил, но гуру форума меня, опять же, поправят)
Они необходимы для подсчета разницы между координатами игрока и координатами костра, чтобы при этом не трогать базовые переменные, занимающиеся ежесекундным обсчетом положения игрока.
Алгоритм таков:
ИИгрокХ=ИгрокХ
ИИГрокХ=ИгрокУ
//приравняли новые переменные к старым, старые при этом не трогаем
ИИгрокХ-=КостерХ
ИИгрокУ-=КостерУ
//Посчитали разницу между координатами игрока и координатами костра.
ЕСЛИ ИИгрокХ<0, ТО
ИИгрокХ*=-1
Если ИИГРОКУ<0, ТО
ИИГрокУ*=-1
//Задали условие для правильного подсчета: Если переменные, получившиеся в результате вычитания, меньше нуля, то меняем их знак на противоположный
А затем задаем условие - насколько получившиеся переменные меньше или равны переменной РадиусКостра1.
И если ОБЕ переменные МЕНЬШЕ или РАВНЫ значению РадиусКостра1, то всем членам пати раз в секунду восстановится 1 ХП.
Напомню, это событие так же параллельно.
Собственно, всё.
Разбирайтесь в мейкере, товарищ - это безумно интересно.)
Последний раз редактировалось NikZol; 19.07.2016 в 14:42.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Социальные закладки