Как сделать интерфейс боя, если поле битвы фиксированное (как в героях, disciples, jrpg), а количество врагов жестко не ограничено и может быть любым?
Алсо, предлагайте свои задачки по геймдизайну в этом треде.
тупо размещаешь в ряды воинов
Ну так же как в Героях и можно сделать (внутри одной модельки легионы существ)
Нихуя непонятно, что именно ты спрашиваешь. Но, на всякий случай, напомню, что маленькие карты - один из главных признаков импотенции разработчика.
- Вася, 7 "Б".
>>501654
Ну это очевидный вариант, с которым все знакомы, - тут смекалочка не нужна, это и так понятно.
>>501662
>Нихуя непонятно, что именно ты спрашиваешь.
Попробуй перечитать оп-пост? Я обычно так делаю, если мне что-то непонятно.
>маленькие карты - один из главных признаков импотенции разработчика
Тред не про выбор размера карты, а про задачки по геймдизайну. Задачки - это когда даются некие ограничения, и тебе с учетом них нужно придумать решение.
Что мне даст перечитывание одного через жопу сформулированного предложения?
Вопрос в посте можно интерпретировать как: "как поместить юнитов площадью 100 квадратов на поле в 25 квадратов", или "как упаковать юнитов в зависимости от их количества", или "как сделать обзорную инфопанельку для всего происходящего", итд.
Во, это уже ближе к теме! Интересная идея, анон. Тогда получается что-то вроде тауер дефенса. Если скрестить это с идеей анона выше, то получится, что ты расставляешь отряды по сетке, как на его скрине, но за один раз спавнится только один юнит (или два-три юнита, типа спереди танк, сзади стрелок с магом). И, наверное, можно на ходу менять и переставлять юнитов местами. Получается эдакий бой на мосту, ну или абордаж корабля, или 300 спартанцев. Прикольно.
Но все-таки. Тогда в каждый момент боя на экране все еще фиксированное число юнитов. Так что идея классная, но все же не совсем то.
>>501695
Ну так задай конкретный вопрос, если тебе что-то конкретное непонятно. "Интерфейс боя" включает все перечисленные тобой в предыдущем посте аспекты, это разве не очевидно?
Если что, интерфейс - это способ взаимодействия пользователя с программой, а не расположение кнопочек и количество пикселей между ними. Ты ведь уже понял, о чем речь (так ведь?), так что я не вижу смысла устраивать тут терминологический спор на эту тему, хорошо?
Нет, я по-прежнему понятия не имею о чем ты.
Во многих ртс у юнитов нет жесткого взаимного коллайдера, и они ходят красивым строем только там где есть место развернуться, а в узких местах не стесняются схлопнуться хоть в одну точку.
Во многих микродрочерских пошаговых варгеймах юниты можно настакивать в один гекс, а также двигать все формирование (ну или ваще контрол/шифт-кликом выбирать) в одном направлении с определенной относительной скоростью.
Так что без конкретной задачи я в душе не ебу, чем тебя эти подходы не устраивают.
>предлагайте свои задачки по геймдизайну в этом треде
Здравствуйте, я Кирилл! Решите мне задачку, суть токова: Экшон-эрпогэ. Можно играть эльфами или орками и если ты эльф, то кругом лес домики деревянные набигают разбойники. А если ты орк, то тебя в наказание телепортируют в параллельный мир. Можно прислуживать мамке с дочкой.
Джва года решаю эту задачку.
>Во многих ртс у юнитов нет жесткого взаимного коллайдера
...а лимиты на количество юнитов есть ну за исключением аннигиляции-стайл игр. А еще там нету фиксированного игрового поля, как в героях, disciples и jrpg.
>Во многих микродрочерских пошаговых варгеймах юниты можно настакивать в один гекс
Я выше уже писал анону, что подписывать циферку с количеством юнитов под стаком - очевидное решение даже в оп-пост соответствующий пик прикрепил, так что не нужно быть геймдизайнером семи пядей во лбу, чтобы до него дойти - это common knowledge.
>чем тебя эти подходы не устраивают
Да всем устраивают, тред-то не про них.
>без конкретной задачи я в душе не ебу
Гхм... ну вот знаешь, есть такие сайты для программистов, они там задачки на придумывания алгоритмов решают без всяких конкретных задач. А можно придумывать не алгоритмы, а игровые механики. Обмен идеями - вообще штука полезная.
Лол, я об этом тоже думал. Концепция охуенная ФРАКТАЛЬНАЯ СУЩНОСТЬ БЫТИЯ, но реализовать на ее основе конкретную механику не так-то просто. Но - да, пока это лучшая идея в треде (и, более того, вообще единственно возможная, если строго соблюдать требование из оп-поста, лол).
>Гхм... ну вот знаешь, есть такие сайты для программистов, они там задачки на придумывания алгоритмов решают без всяких конкретных задач. А можно придумывать не алгоритмы, а игровые механики. Обмен идеями - вообще штука полезная.
Ты понимаешь что игровая механика может быть завязана на сеттинге, визуале, звуке? Это не абстрактный алгоритм из программирования. Механика вырванная из контекста игры смотрится совершенно по другому.
ОП вопрос содержит в себе противоречиеследовательно, хуйня твой вопрос. Механика в HoMM - наебка. Может быть по цифрам, количество юнитов в войске будет 999999, но на деле у тебя будет всего 8 спрайтов. Твои 5500 личей, это 1 лич с множителем 5500.
Ты пытаешься в рюкзак засунуть автомобиль, при этом вообще не говоришь зачем и как ты это делаешь.
>Ты понимаешь что игровая механика может быть завязана на сеттинге, визуале, звуке?
Понимаю, но какое это отношение имеет к итт треду?
>ОП вопрос содержит в себе противоречие
Укажи его.
>но на деле у тебя будет всего 8 спрайтов
Анон, я не знаю, сколько еще раз тебе нужно повторить, что раскидывание по стакам с подписыванием циферок - это всем очевидная и понятная механика, поэтому хоть она и подходит под требования, но обсуждать ее не интересно, потому что это просто и понятно без всяких обсуждений.
>Ты пытаешься в рюкзак засунуть автомобиль, при этом вообще не говоришь зачем и как ты это делаешь.
Ну так если тебе все еще непонятно, то скрой тред, делов-то? Тебя же никто не заставляет сюда писать. Выше три анона уже представили рабочие варианты по теме треда, причем последний из них попал в яблочко и угадал основную концепцию, на основе которой могут быть построены все такие механики, так что наверное дело все-таки в тебе, а не в треде.
>>Понимаю, но какое это отношение имеет к итт треду?
Самое прямое. Ты предлагаешь описывать механику без каких-либо данных об игре. Понимаешь что для поля 10х10 и для поля 100х100 могут быть совершенно механики? И дело не в масштабировании, а в том что ты нихуя не даешь данных для решения задачи.
>>ОП вопрос содержит в себе противоречие
>поле битвы фиксированное
>количество врагов жестко не ограничено и может быть любым
При фиксированном кол-ве гексов (как в HoMM) у тебя не может быть больше определенного числа пачек (т.е. врагов). Ты не понимаешь что реальный враг в HoMM не кол-во юнитов в пачке а сама пачка.
>>Анон, я не знаю, сколько еще раз тебе нужно повторить, что раскидывание по стакам с подписыванием циферок - это всем очевидная и понятная механика, поэтому хоть она и подходит под требования, но обсуждать ее не интересно, потому что это просто и понятно без всяких обсуждений.
Дебил, ты не понимаешь что в HoMM это не решение твоей проблемы? Это просто костыль, наебка. Лич он 1, но с множителем 5500. Но он по прежнему остается 1. И ты не можешь приводить этот способ как "подходящий под требования".
>>Ну так если тебе все еще непонятно, то скрой тред, делов-то? Тебя же никто не заставляет сюда писать.
Потому что ты и подобные тебе дауны засирают всё, до чего дотянутся их кривые рученки. Отбитые наглухо, не воспринимающие критики, снежинки-максималисты.
>>Выше три анона уже представили рабочие варианты по теме треда,
>Два предложения сделать как в HoMM
>Предложение спавнить юнитов за краем карты
Боле боя в этом случае нихуя не фиксированное. Или ты добавляешь механику появления юнитов, что опять таки требует хоть капли конкретики - придумать можно любой бред, но не далеко не все будет работать.
> Предложение фракталить карту.
Довен, у тебя будет бесконечный фрактал? Тогда ты уйдешь в бесконечный цикл. Фрактал будет конечным? Ну так это ни как не решает проблему, в минимальном фрактале ты всё равно придешь к тому, что 1 клетка = 1 юниту.
>Понимаешь что для поля 10х10 и для поля 100х100 могут быть совершенно механики?
Ну так опиши обе, тебе кто запрещает-то?
>не даешь данных для решения задачи
Я дал два ограничения, все остальное - на твое усмотрение. Не надо меня обвинять в отсутствие у кое-кого фантазии.
>При фиксированном кол-ве гексов (как в HoMM) у тебя не может быть больше определенного числа пачек
Конечно может, выше было описано, как именно. Вообще, неплохо бы тебе математику подучить. Алсо, не знаю, при чем тут гексагоны.
>Дебил
О, так я зря начал отвечать на этот пост. Скрой этот тред, до свидания.
Прибежал двач в надежде, что за него работу сделают.
>>501672
>Тред не про выбор размера карты, а про задачки по геймдизайну.
Тебе надо, сам и решай. Заплати, решу.
Ну не, это глупость какая-то.
Но я вспомнил одно решение, в принципе, оно реализует то, что надо опу. Можно сделать юнитов "прозрачными", но при этом не собирать в стаки. Так, как это сделано в starve.io. Заодно получим интересную систему фехтования и оптимизацию серверных ресурсов.
Почему глупость-то? Ты наверное просто не понял. Представь, например, total war\total annihilation, только с гораздо большим количеством юнитов. Вокруг этого вообще можно кучу интересных механик построить, типа собирания сотни мелких юнитов в один юнит побольше, и т.п.
>"прозрачными", но при этом не собирать в стаки
А чем это будет отличаться от стака (тем более раз ты говоришь про оптимизацию серверных ресурсов)? Это же и будет стак - быть может, с возможностью легко анстакать юниты и стакать их обратно.
Нет, это будет не стаковая система, а эдакая особая версия боёвки, которая даёт игрокам будет гораздо больше возможности маневрировать, чтоб не попасть под удар, или заставить противника ударить своего союзника. Посмотри на ютубе сражения в starve.io, может быть лучше поймёшь, что я имею в виду.
А, типа можно вставать на врага, и потом когда тебя бьют отбегать и удар засчитается врагу, типа такого? Прикольно, но я слабо представляю, как это будет скейлится на потенциально бесконечное количество юнитов, тут же 1 юнит = 1 игрок должен быть, нет? Видосы погуглю, спасибо.
> 1 юнит = 1 игрок
Типа того. И в целом гораздо больше направлений для того, чтобы передвигаться и следовательно, уворачиваться.
А насчёт один юнит - один игрок, да это так. Но теоретически сюда можно прикрутить какую-нибудь автоматизацию, возможность определить своим юнитам тактики, модели поведения, приоритет целей, выбрать им снаряжение. И получим довольно самобытную игру.
Лол, мне изначально эта идея как раз пришла после того, как я играл зеленой колодой в мтг и у меня под конец партии на столе было хуй знает сколько зеленых токенов, и я подумал, как можно было бы закодить интерфейс, который бы поддерживал вот такую хуйню. Карты-то на столе ты хоть как разложить можешь, чтобы было удобно и все видно, можешь взять бумажку и подписать: "вот тут у меня на самом деле 10 одинаковых токенов, а не один", можешь сказать "ну я корочи вот этих вот хуярю вот этим спеллом" и так далее.
Но опять же, у тебя идея по своей сути такая же, как у >>501694-анона - то есть просто избежать этой проблемы, выкидывая в бой за раз ограниченное число существ, так что общее их количество на поле боя ограничено. Это не совсем то.
Хотя можно подумать над тем, чтобы "неактивные" (то есть те, которые у тебя в руке) карты\юниты все-таки участвовали в бою, просто пассивно. Типа если у юнитов в руке есть какие-то активируемые способности, то они срабатывают в зависимости от того, что происходит на поле боя. Так они у тебя будут не просто в билд-очереди, а непосредственно принимать участие в бою. Плюс масс-дамаг спеллы могут дамажить в том числе и карты\юниты в руке, и так далее.
На самом деле интересно, тут есть над чем подумать.
Хм, я сейчас представил, что идешь ты такой типа одним юнитом, тебя замечает другой игрок и думает: "а, хуйня, одна говняшка какая-то идет, ща замочу ее", подходит поближе и тут ты такой хуяк! - и эта говняшка распадается на сотни говняшек, полэкрана в твоих говняшках, даже небо и аллах в говняшках, и ты хуяк-хуяк зерг-раш на того игрока, а он уже улетел на реактивной тяге своего пердака к аллаху а там тоже твои говняшки. Так-то куча таких WTF-моментов с этой фичей может быть, походу это действительно довольно прикольно, анон.
Кстати, а как называлась io-игра, где ты эдакими goo-ball'ами ползаешь по карте, растишь их и кушаешь других, и как раз можно одну говняшку расщеплять на сотню говняшек, а потом собирать их обратно в одну большую говняшку?
Игра от того же разработчика, oib.io. Хотя есть и другие.
А насчёт эдакого wtf, думаю, это не очень справедливо. Думаю, следует давать примерное представление о численности юнитов на одной площади, если перед этим давать возможность игровыми способами пилить себе огромные пачки.
>oib.io
Точно, она. Спасибо.
>это не очень справедливо
Лол, конечно несправедливо. Если нужна соревновательность, а не просто лулзы, то нужна какая-то механика наподобие стелса\разведки. С другой стороны, можно просто постулировать, что всегда следует ожидать худшего, и если ты на кого-то напал, а там оказалась армия в два раза больше твоей - то ты ССЗБ, надо было быть осторожным и сперва потыкать его палочкой, чтобы попытаться выяснить количество юнитов. Короче, вокруг этого много всяких изъебистых фич можно придумать, плейтесты решают.
давай поробуем еще раз. на самом деле, во "всех" стратегиях карта ограничена и эта проблема решена балансом (не производить 250001 юнитов на карте 500500, но это не про смекалочку). "героев" я помню, и поле боя это та же самая карта, только не 500500, а (грубо) 3030. может быть, я тебя неправильно понял? есть сущность клетка, есть сущность юнит. клеток N, юнитов M. N<=M (если одна клетка - один юнит). в первой цивилизации такого правила не было, в клетке могли находиться разные юниты (я не про поле боя, а про карту), хотя и имелся жесткий лимит на общее кол-во юнитов (связанный со средневзвешенной оперативкой, скорее всего). если правило сохраняем, то подмену понятий можно произвести по следующим фронтам: клетки, юниты, поле боя. в героях, например, юнитов вообще удалили. и сделали отряды однотипных юнитов. можно размер клетки сделать динамическим, чтобы увеличить N до M. т.е. внутри клетки находятся два юнита - рубим клетку пополам, картинки юнитов масштабируем, скорость перемещения юнитов измеряется по оригинальным клеткам. когда юнитов будет действительно много - ничерта не разглядеть. можно поле боя растиражировать: кликнули по клетке - открылось вложенное поле боя, из которого мы тягаем юнитов, если N<M. от клеток избавиться (от 0 до 1) уже предлагали. можно от поля боя избавиться во имя карт и одновременного действия 250001 юнитов. можно количество клеток на поле боя не захардкодить в 3030, а сделать динамическим, чтобы N>M - казуальность "героев" точно потеряем. больше ничего в голову не лезет. потому что из репертуара действий у меня только масштабирование, удаление, тиражирование. чем еще репертуар действий можно пополнить? или я еще какую сущность не разглядел?
Ну в принципе ты вроде бы подытожил все варианты, которые пока что были предложены, да. То есть можно их разделить условно на три группы:
1. Фрактальность - вложенные поля, зум, юниты собранные из других юнитов по принципу воксельных рендеров, все в таком духе.
2. Абстрактность (?) - отказываемся от боля боя как такового и заменяем его на карты в руке, циферки в табличках или что-то аналогичное.
3. "Хаки" - динамически ресайзим поле боя или клетки на нем, спавним юнитов по очереди, делаем юнитов "прозрачными" и т.п.
Я изначально при создании треда имел в голове первый вариант, и мне стало интересно, что еще придумают анончики. Как у меня это выглядело в голове: все юниты организованы в графы (в простейшем случае пусть будут деревья). Вершины - это сами юниты, ребра - это связи между ними. Корень - это сущность, представляющая игрока. Если от корня до вершины есть путь, то этот юнит принадлежит игроку. Идея в том, что ты спавнишь условных "генералов", они спавнят юниты уровнем пониже, те - еще ниже, и так далее. Большинство юнитов при этом подчиняются в своих действиях предопределенным правилам и не требуют от игрока микроменеджмента. Ну, вот очевидный пример: Гидра спавнит вокруг себя по Говняшке (слабый юнит без спецспособностей) каждую секунду. Сто Говняшек преобразуются в одну Хуйнюшку (сильный юнит со способностью обращать противника в камень). Каждая Хуйнюшка тоже спавнит по Говняшке каждую секунду. Гидра (и все ее потомки) атакует любую армию, атаковавшую ее хозяина (хозяин - эта та вершина, к которой Гидра прицеплена ребром графа). При этом можно еще задавать правила атаки внутри группы (допустим, Говняшки - это пехота, пехота всегда атакует кавалерию в армии противника, камень-ножницы-бумага, нутыпонел). Плюс можно навешивать триггеры с автоатакой, ну и так далее, тут можно долго расписывать. С точки зрения интерфейса это выглядит как абстрактное поле боя, на котором раскиданы (алгоритмами визуализации) графы игроков. Можно зумиться, можно выбирать одного юнита, можно выбирать юнита со всеми его потомками, можно выбирать все юниты одного типа в данной ветке графа. Ну а дальше геймплей сводится к изучению графов противников, выбору выгодных целей для атаки своими юнитами и своевременной активации их способностей.
Замечу, что пространственный аспект при такой модели вообще не учитывается (все юниты как бы действуют на расстоянии), но это необязательно должно быть так. Вполне можно, например, корень графа считать замком лорда или башней мага, вершины следующего уровня - городами, следующего - армиями, и т.п. Тогда перемещение армий между городами (то есть перекидывание ветки графа с одного родителя на другого) вполне можно высчитывать и визуализировать с учетом расстояния между этими городами.
Еще более лучший вариант с точки зрения сеттинга - межгалактические империи, где вершины - это галактики\сектора\звездные системы\планеты\флотилии. Тут "дальнодействие" можно объяснить гиперпрыжками кораблей, а игрока представить эдаким ГИПЕРСТРАТЕГОМ, который через такой вот хитровыебанный интерфейс рулит армиями галактического масштаба.
Короче, возможностей - куча, надо только алгоритмы визуализации графов задрочить (лол).
ОЧевидно, что 1 и 3 у тебя одно и тоже, а во 2 ты не отказался от поля боя, а просто переименовал его в места для карт, собственно тупой вопрос из ОП-поста и не предполагал какой-либо ответ кроме зума (который в отдалении все равно стаканьем отображается или стаканья. Итого побеждает зум.
/thread
>ОЧевидно, что 1 и 3 у тебя одно и тоже
Извини, анон, но ты не очень умный.
>и не предполагал какой-либо ответ кроме зума
...и остальных описанных в треде вариантов, верно. А о том, что правильный(с)(тм) ответ есть фрактальность написано еще в начале треда.
Спойлер: если не скроешь тред - твоя мать умрет через три дня.
>Фрактальность - вложенные поля, зум, юниты собранные из других юнитов по принципу воксельных рендеров, все в таком духе.
>Хаки" - динамически ресайзим поле боя или клетки на нем, спавним юнитов по очереди, делаем юнитов "прозрачными" и т.п.
Фрактальность включается в понятие динамический ресайз, прозрачные юниты это стаки, юниты собранные из других юнитов это стаки, спавним юнитов по очереди это значит у края карты стоит стак. Фрактальность вообще не правильный ответ, потому что если ты нарушаешь самоподобие из-за смрети юнита, то фрактал уже фрактал, значит правильный ответ зум.
Восхождение на трон jpg
Хоть какой-то от вас интерес, HOROSHO ХУИ СОСАТЬ
Пруфай, что задача не является концептуальной калькой какой-либо иной, не связанной с гд проблемы.
и на всякий случай сосни хуйцов
в крайнем случае свой сосни%%
гениальный геймдизайнер в частности
Не отрисовывать интерфейс поля боя.
Берем всех принимающих участие в сражении юнитов с обеих сторон и просто сравниваем армии.
Просчитываем, сколько времени понадобится например мили юнитам чтобы добежать до юнитов врага через заданный размер поля боя, сколько они за это время получат урона от дальнобойных юнитов противника и так далее. Опционально учитывать складки месности и прочий рельеф.
На экран выводить только текстовую информацию уровня "отряды под обстрелом двинулась вперед в количестве N и M с каждой стороны. Лучники в количестве X и Z поливали залпами вражеских солдат, в итоге на поле боя схлестнулись N-A и M-B солдат, вы проиграли РЯЕСС ЕИТЕЯ для загрузки"
Это охуенное предложение, анон, согласен. По-моему генерить действительно годные литературные описания - задача нетривиальная, но в принципе можно и как у тянки в римворлде, получается как минимум смешно.
Особый шик - генерить историю от лица каждого юнита, участвующего в битве. Чтобы потом можно было оценить ход битвы с разных сторон: от общего генеральского отчета до похождений всяких отдельных бравых швейков, пущенных на мясо. Для КРИЛ такое запилить - все призы твоими будут, лол. Но как это сделать не имею ни малейшего понятия.
Много готовых фраз, под каждое значимое событие в сражении (твоя пехота жидко обосралась, твои стрелки скосили почти всю пихоту врага, твоя пихота почти в полном составе добралась до стрелков врага и покрошила их в фарш ну и т.п.) пилится несколько "сценариев" - по сути как ты сказал - мини-историй от лица участников событий ну и по триггеру по наступлению тех или иных событий скармливается игроку. +всякие условия, зависящие от местности например или от состава армий... Да, после нескольких десятков часов игры скорее всего игрок так или иначе увидит все возможные описания, но поначалу будет смотреться необычно.
Мне кажется сложнее реализовать адекватную оценку соотношения сил, тип кто победит, какой отряд сильнее и так далее.
Ну я про это и говорил, что получится как в римворлде. Это прикольно, если делать в юмористическом ключе, но если пытаться претендовать на какую-то литературность, то нихуя не понятно, как избежать сразу же бросающейся в глаза шаблонности описаний. Можно попробовать взять нескольких писак и попросить их написать описания битвы в разном стиле - например, у одного это будут дневниковые записи, у другого - поток сознания, у третьего еще что-нибудь. Так будет хотя бы какое-то разнообразие (плюс одни и те же события из-за субъективности и различия стилей могут описываться абсолютно по-разному), но все равно это будет интересно один, максимум два раза - а потом опять же слишком будет бросаться в глаза шаблонность. Короче, тут стронг ЭйАй нужен, чтобы нормально сделать, лол.
>Мне кажется сложнее реализовать адекватную оценку соотношения сил
А что сложного? Зависит от дизайна конечно, в простейшем случае ты тупо берешь юниты с коэффицентами, перемножаешь, суммируешь и сравниваешь, лол. Потом можно добавить несколько стадий (дальний бой, ближний, етк) и считать их отдельно. Хотя в идеале конечно это должна быть полноценная симуляция каждого юнита, пошаговый бой без визуализации. То есть все по сути сводится к написанию вменяемого ии.
Алсо, прикольно было бы иметь возможность загружать произвольные карты. Ну типа из гуглмапс достать карту твоего города и устроить там бои, лол. Я не знаю, гугл строит карту высот по снимкам или нет?
ОПчик, вот такая идея: показывать отряды в виде окрашенных областей, как на тактических картах.
1) Площадь области символизирует количество единиц в отряде.
Для разных юнитов площадь на одну единицу может быть разная.
Таким образом, 100 мечников и 100 драконов будут занимать разную площадь.
2) Площадь поля битвы определена, примем её за 1.
Можно определить, какая её часть должна быть покрыта отрядами.
Пусть будет 50%.
Тогда все отряды всех игроков должны занимать площадь 0,5.
Нормализуем площади отрядов относительно этого значения.
3) Мы получили отражение количества воинов в отрядах и его положения в пространстве.
Но мы должны учесть, что 100 мечников и 100 драконов имеют не только разные размеры, но и силу.
Характеристику силы отряда на единицу можно теперь привести к силе на единицу площади и показать в виде цвета. Более насыщенный цвет говорит о высокой силе отряда, в то время как тусклые цвета указывают на слабый отряд.
Такая модель уже готова для того, чтобы ставить над ней тактические эксперименты.
Но можно пойти и дальше, и это "дальше" зависит от многих факторов:
1) Природа поля битвы. Дискретное оно или непрерывное? Однородное по свойствам или имеет области с модификаторами?
2) Механика контроля. Прямой или непрямой контроль?
3) Система управления временем.
4) Природа отрядов. Однородная (урон одной элементарной клетке уменьшает площадь всего отряда), статически-неоднородная (отряд по сути является совокупностью элементарных независимых клеток; клетка, получающая урон, обесцвечивается и умирает, не влияя на соседей), или кинематически-неоднородная (отряд в пределах своих границ представляет собой жидкость, текущую с некоторой скоростью из областей повышенной плотности в области пониженной плотности). Могут ли отряды разделяться?
В общем, вариаций масса. Если кому-то интересно, но остались вопросы, могу картинку нарисовать или даже симуляцию набросать.
Это охуенное предложение, анон! Правда, очень годно. И вопросы хорошие.
Единственное "но", которое я тут вижу - все-таки максимальное число юнитов фактически ограничено сверху. Хотя на практике это скорее всего не будет проблемой, особенно если, например, схлопывать более слабые отряды в более сильные по достижению лимита плотности.
Мне кажется, было бы круто набросать симуляцию, если у тебя есть время. Любопытно посмотреть, как оно будет чувствоваться.
1) Мне кажется концептуально все-таки непрерывное, нет? Мы же просто считаем, например, радиус кружка для данного количества юнитов. Области - думаю, обыкновенных непроходимых гор\рек достаточно, чтобы получить тактически интересные ситуации. Пересекающиеся с нашими кружками области, которые модифицируют статы части отряда (типа болота, например) - это уже посложнее, тут действительно нужна будет жидкостная механика (например, чтобы отряд сплющивался и вытягивался для марш-броска по дороге, как вода в трубочке)
2) Мне кажется логичным было бы игроку отдавать команды на передвижение отрядов, а дальше уже все само. Ну, возможно добавить финтифлюшки типа построений\режимов (бонусы к защите, бонусы к атаке, или например отступление - полностью убираем урон, но увеличиваем скорость отряда).
3) В такой симулятор было бы интересно поиграть по сети, так что ртс выглядит логичнее всего. Или ты что-то другое имел в виду?
4) Это самое интересное. Конечно, однородный вариант проще всего, так что для тестирования самой механики думаю сойдет. Остальные варианты - затратно обсчитывать, так или иначе быстро упрешься в пределы железа (кстати, в liquid war играл? Там как раз реализован вариант с жидкостью, исходники открыты и в сети есть описания их алгоритма патх-файндинга для точек).
Зашел сегодня в RotMG, поиграл немного, и после битвы с очередным "боссом" придумал простое в плане реализации и геймплея решение:
У каждой армии есть лидер, который сам по себе является боевой единицей с большим запасом здоровья. Чем сильнее его армия — тем сильнее и живучее лидер.
Лидер спавнит солдат — намного более слабых единиц, следующих за лидером/кружащимся вокруг лидера/тупо бегущих на врага — логика их поведения может быть любой. В каждый момент времени существует не более N солдат. Солдат умер — через несколько секунд генерируется новый.
При этом максимальное здоровье лидера может как убывать по мере расходования армии, так и оставаться неизменным, определяясь в начале боя.
Управление солдатами может быть и прямым, и непрямым.
Командный мультиплеер можно реализовать даже с динамическим подключением новых игроков — толстый лидер разделяется на двух более слабых при появлении нового участника, два лидера сливаются в одного при выходе игрока.
Дополню этого - в зависимости от состава армии "лидер" может получать дополнительные способности.
У него лишь "пихота" - он простой жирный мечник.
В его армии появились стрелки? Он может использовать условную абилку "выстрел" частота использования и урон будет зависеть от количества собственно стрелков в армии.
Кавалерия - у него будет эдакий "спринт", увеличивающий скорость передвижения или вовсе рывок- "чардж".
Пара драконов в армии даст возможность перелетать препятствия и дышать огнем. При этом он может "потратить" драконов например, призвав их на поле боя.
Эдакий менеджмент абилок и здоровья - что ты хочешь - получить спобность и буст к запасу здоровья. или призвать себе на помощь пару суммонов?
Иными словами условная "армия" становится одним персонажем, со своим запасом здоровья, моделью перемещения и набором способностей, что в совокупности полностью зависит от состава армии.
>А разве не скучно, что один игрок управляет всего одним лидером?
Можно как в босс-битвах с подкреплениями в Darkest Dungeon - фиксированное число слотов, но после смерти юниты заменяются новыми