многие идеи, которые приходят ко мне, уже кем-то реализованы или скоро будут реализованы (цитата из Интернета) Еще в 2001 году я, любитель стратегий в реальном времени, был поражен игрой «Казаки» .Теги: #разработка игр #программирование #разработка игр #скрипт действийЯ был поражен ОГРОМНЫМИ толпами людей, бродившими по карте.
Удивительно было то, что эти толпы довольно резво бегали на тогда еще маломощных компьютерах.
Но я тогда работал в скорой помощи и был далек от программирования, поэтому тогда ограничилось восхищением.
Уже в наше время мне хотелось сделать игрушку примерно с таким же количеством движущихся единиц – чтобы «эпопея» просто зашкаливала (!).
И чтобы эти агрегаты не просто двигались, а двигались наружу(!) осмысленно.
И чтобы (самое главное) все это великолепие работало на слабых мобильных платформах.
Возник вопрос – как? С графикой вопросов нет — на любой современной платформе есть графические библиотеки разной производительности, которые позаботятся о выводе толпы на экраны.
Главный вопрос в том, как программно реализовать осмысленное (или бессмысленное) что-то, что бы однозначно воспринималось игроком — это толпа, подчиняющаяся каким-то стимулам, а не просто набор мелькающих фигурок.
Я уверен, что есть много рекомендаций, литературы и даже реализаций.
Но меня интересовало что-то «простое», что можно было бы использовать в простой игрушке для «мобиля» и собрать «на коленке».
Те.
дешево и сердито, а главное - понятно для меня(!).
Год назад я прослушал замечательную записанную лекцию от КРИ 2008 Михаил Блаженов (это АУДИО - печатную версию найти не удалось) «Специфика процесса разработки мобильных игр: планирование, портирование, тестирование» .
Важный для меня вывод из статьи — при написании логики приложения с большим количеством данных нужно использовать дата-ориентированную парадигму.
(Тадааам!).
Суть идеи, возникшей после прослушивания, заключалась в следующем.
Теперь нужно было написать сам механизм.
- Все (ВСЕ) разнообразные «мотивы личности» в игре должны описываться системой векторов (порядок, страх, ненависть, лень, глухота, инерция.
).
В течение одного игрового цикла (или каждого десятого, не важно) с этими векторами проводятся различные манипуляции.
Результатом всех манипуляций будет сумма векторов, которая в простейшем случае будет определять направление движения персонажа (одно из сотен, а то и тысяч).
- У каждого «индивидуума» должен быть одинаковый набор векторов – ради стандартизации вычислений.
Тогда определение поведения отдельного «особи» в толпе может осуществлять небольшой, многократно повторяющийся фрагмент кода — конвейер.
Прелесть конвейера в том, что ему абсолютно все равно, «кого» он обрабатывает — толстяка, катящееся колесо, труп… Главное для него — набор «мотивов».
Благодаря этому мы получаем не просто толпу, а разнообразную(!) толпу.
Но какого черта?! Ведь если вам пришла идея, то есть большая вероятность, что до вас ее уже посетило еще сто миллионов человек.
А может быть, кто-то из этого миллиона вообще создал подходящий инструмент? Какая-то библиотека? Такой инструмент найден – система частиц.
.
Я выбрал КРЕМЕНЬ .
Кратко опишу основные инструменты для конкретной реализации системы частиц:
- система частиц идеальна для прототипирования
- расчеты внутри системы частиц основаны на законах классической механики – т.е.
в наше время уже существует бесчисленное множество различных алгоритмов, которые можно адаптировать под собственные нужды программирования
- К системе частиц можно прикрепить любой рендер из сторонней библиотеки.
- Эту версию системы частиц написал автор Фреймворк Entity System Ash от Ричарда Лорда (это отдельная песня).
Мне, конечно, в мечтах кажется, что с помощью «векторов мотивации» можно даже сделать РПГ с кучей «независимых» персонажей в отряде со своим мнением, но начинать нужно с чего-то простого .
- излучатель ( Эмиттер2D ) — реальный экземпляр класса, отвечающий за генерацию частиц по заданным параметрам и дальнейшее «обслуживание»
- Emitter2D.addInitializer(инициализатор) — метод, с помощью которого эмиттеру добавляются «свойства», которые будут присвоены частицам при их генерации.
- Emitter2D.addAction(действие) - Используя этот метод, к эмиттеру добавляются правила контроля частиц, которые будут применяться к частицам в течение их жизни.
Я выбрал жанр Tower Defense. Только в игре хочется видеть не тонкую струйку «танков», а массу врагов (!), чтобы их можно было разбрасывать взрывами, как обломки, давить, сплющивать, разбрасывать.
Уф.
конец предисловия.
Но я думаю, что это важно.
Реализация идеи
Начнем с самой простой задачи:
- построить маршрут любой сложности
- персонажи следуют по заданному маршруту, при этом
- не «лезть» друг на друга
- «смотреть» по направлению движения
1. сформировать маршрут любой сложности
Те.— путь состоит из точек ( путевые точки ).
Частицы должны двигаться последовательно от точки к точке.
К сожалению, соответствующей акции в библиотеке не оказалось.
Но я шпионил выполнение в другой библиотеке (которая, кстати, написана на основе выбранной мной) — двигатель звездной пыли .
Единственное, что мне не нравится в найденной реализации, это то, что в точках пути частицы группируются вместе и не следуют «широким фронтом» на всем пути следования.Поэтому я немного модифицировал класс под свои нужды Путь - имя класса, неуклюжее «наследство» от оригинала путевая точка Суть класса заключается в хранении перпендикуляра к касательной пути.
При генерации частицы, используя действие FollowWaylines , сохраняют данные об их взаимном положении на перпендикуляре.
А потом, двигаясь, они «стараются» придерживаться этого положения — так они не группируются в узлах пути — они распределяются перпендикулярно касательной в этой точке (кстати, экземпляр класса несет ответственность за это Линия , из самых чудесно полезных Библиотеки кривых Безье ).
package waylines.waypoints {
-
Джанна Наннини Шведская Страница
19 Oct, 24 -
Фридман, Милтон
19 Oct, 24 -
Мой.com. Оно Взлетит? Не Взлетит?
19 Oct, 24 -
Стать Акционером
19 Oct, 24 -
Forbes Поговорил С Основателем Digg.com
19 Oct, 24
