>>16119
>Наконец, можно строить дедуктивные системы, которые, например, решают проблему гуська, используя правила вида "объект X пойдёт вперёд только, если объект Y сдвинется с места".

>Какие ещё могут быть / используются варианты?
Дело в том, что "ходить гуськом" подразумевает, что некоторое количество персонажей двигаются за лидером. Могут быть разные формации, но в твоем случае это значит они выстроены в натуральную очередь, т.е. это очередь не только с точки зрения игры, а и с точки зрения ИРЛ. А значит у тебя эта очередь есть на руках в виде массива с индексами. А значит, ты можешь походить всех по очереди, не используя лишних параметров, просто кто за кем стоит, тот так и ходит.

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

P.S. Расскажи что-нибудь про свою игру, чтобы не обсуждать сферических гусей в вакууме.

На самом деле, то что ты описываешь называется simulated (хотя почему-то термин не гуглится). Есть хорошие примеры, серия игр UFO:After и например Ниваловская Проклятые Земли, из мне известного. Там игра происходит в реальном времени, где игрок может ускорять и замедлять процесс игры, а также ставить его на паузу, во время которой можно раздавать приказы для юнитов. Таким образом игра не совсем в реальном времени. В тоже время ты можешь ставить игру на паузу, к примеру каждую секунду, получается игра вроде и пошаговая, но прикрасно симулируется одновременность разрешения ходов.

>>16127
Да, рассматривать организованный отряд как единое целое, а неорганизованным толпам позволить "спотыкаться" друг о друга — тоже вариант.

> Расскажи что-нибудь про свою игру, чтобы не обсуждать сферических гусей в вакууме.

Был концепт игры, который в частности требовал быстрый turn-based multiplayer, и хотелось, чтобы игроки принимали решения, не дожидаясь друг друга, с синхронной реализацией и автоматическим разрешением конфликтов.

Но сейчас я этот вариант не рассматриваю, просто обдумываю single-player рогалик для души, а вопрос вырос из того, предыдущего концепта.

В общем, вопрос и задумывался как сферический теоретический.

>>16131
>Был концепт игры, который в частности требовал быстрый turn-based multiplayer, и хотелось, чтобы игроки принимали решения, не дожидаясь друг друга, с синхронной реализацией и автоматическим разрешением конфликтов.

Не знаю, порадует тебя это или нет, но кажется такую игру всё же сделали, называется Frozen Synapse: http://store.steampowered.com/app/98200

А как организовать рогалик с партией?

>>16130

Не знаю, правильно ли ты меня понимаешь, но UFO:After* и вправду довольно интересны комбинацией "клетчатого" игрового поля и непрерывного времени. Штука же, что ты описываешь, называется "активной паузой", но меня больше интересует не то, как игрок видит события и управляет ими, а то, как они симулируются и взаимодействуют друг с другом.

>>16133

> ○　быстрый turn-based multiplayer
> ●　кажется такую игру всё же сделали
> ●　Multiplayer is really versatile too, since you can just leave your turn and play another match (or even another game altogether) while you wait your opponent's; you can even set the game to send you an email when a new turn is awaiting you.
Не совсем то всё-таки, да и концепт был по сути не про "быстрый turn-based multiplayer", просто оно там вытекало с необходимостью из других требований.

> А как организовать рогалик с партией?
Какой интересный вопрос. Зависит от понимания "партии". Если это NPC, то Dwarf Fortress вполне себе пример. Если живые игроки, то, по-моему, предпочтительнее быстрая пошаговость, то есть по несколько секунд на простой ход, только нужна возможность бега в не-боевых ситуациях. Ну, и permadeath будет проблемой.

>>16136
Если это не секретные сведения, расскажи про игру, что планируешь.

>>16145
Могу только повторить >>16131:
> Но сейчас я этот вариант не рассматриваю, просто обдумываю single-player рогалик для души, а вопрос вырос из того, предыдущего концепта.

Тут рассказывать бесполезно — нужно делать прототип и показывать или не делать.

Может, можно на время хода проиграть движение "в реальном времени"? И для этих целей может подойти дифференциация логических координат и физических. Прям как в современных ААА-играх графика и физика. Вкратце как сделано там: для графики используется многополигональная карта, с бампингом и тесселяцией, а физика обрабатывается на ооочень упрощенной модели уровня.
Так и тебе, возможно, стоит для игровой логики использовать дискретное пространство, а для модуля, рассчитывающего движение - полноценную систему координат с флоатами или даблами и реальным временем.
Как я это реализовал бы: в течение хода каждый юнит движется к "полноценным" координатам центра соседнего целла дискретного пространства, находящегося по вектору цели хода. Радиус коллизии (при котором юнит не может двигаться, поскольку пространство занято другим юнитом) очевидно должен быть меньше физических координат целла (я б для начала поигрался бы с 0,6 - 0,8 размеров целла). Получаем, что юниты будут ходить от клетки к клетке по направлению хода все вместе.
Очевидно, что будут возникать ситуации, когда на одном целле два юнита. В случае "гуська" это норм и они нормально разрулятся - первый пройдет в следующий целл, второй пройдет в целл первого и они не столкнутся. Во второй половине случаев произойдет коллизия. Это, вероятно, будут те случаи, когда у юнитов различные векторы движения. Хоть я и не могу представить, как такое может получиться в описанной в ОП-посте задаче, но это нужно разрешить. Я б послал инициатора столкновения в обход, хотя можно и остановить юнит/послать на предыдущий целл (например "не дошел", так как вражеский персонаж раньше пришел). Соответственно хозяином целла считать того, кто ближе к его центру. Как только не осталось движущихся персонажей - ход завершен.
В итоге - во время хода юниты движутся как в этих ваших варкрафтах, между ходами ждут на своей клетке, а логика все это время видит их как в фасеточном зрении.

Немного сумбурно, простите за неровный почерк.

>>16174

Неплохо, и без нагромождения правил позволит симулировать сложные взаимодействия. Но что будет, если в комнате на n клеток сидит n мобов и туда убегая от игрока пытается набиться (n+1)-ый? Благодаря маленькому радиусу коллизии, "сидящие" смогут подвинуться, и временно места хватит всем, но дальше начнётся игра в музыкальные стулья, и как долго ждать, пока кого-нибудь выкинет? Наверное, систему можно стабилизировать, если посадить юниты на "короткие поводки" в исходных точках, и в любой непонятной ситуации начинать эти поводки натягивать. Главное, чтобы всякие ворота и другие перегородки не закрывались посреди раунда.

>>16202
>Благодаря маленькому радиусу коллизии, "сидящие" смогут подвинуться
Сидящие сами по себе никуда не двигаются же. Двигаются лишь те, у кого задана цель перемещения. А такие вещи, как
>на n клеток
>пытается набиться (n+1)-ый
элементарно решается в тот момент, когда наткнувшись на сидящего, граф движения по клеткам к цели перерассчитывается и репортит о том, что текущая позиция к целевой ближе при нынешнем расположении уже не станет. Тогда и остановиться можно или сменить цель. А если ходы в игре совсем-совсем дискретны донельзя, то, возможно, лучше даже отказать в таком ходе / предложить ближайшую свободную клетку еще на этапе задания цели.

То есть алгоритм вкратце такой:

Пока (у юнита есть цель) {
 ПостроитьГрафОтТекущейКлеткиДоЦелиПоЦентрамКлеток();
 если (нетпути || граф.длина < 2) {
  Остановиться();
  хватит;
 };
 попробуй {
 ПереместитьсяНа1ВершинуГрафа();
 }
 поймай (ИсключениеСКоллизией) {
 ВозвратНаПредыдущуюКлетку();
 }
}

>>16203
Это всё дискретный pathfinding. В >>16174, как я понимаю, предлагается "физическая" симуляция движения на более низком уровне: все уже решили, куда направляются (используя индивидуальный pathfinding и т.п.), приобрели векторы скорости, и дальше мы смотрим просто, кто куда протолкнётся (причём натурально можно реализовать механику толкания с учётом скоростей и масс юнитов). Но в некоторых ситуациях вот это конечное условие может оказаться трудновыполнимым:
> Соответственно хозяином целла считать того, кто ближе к его центру. Как только не осталось движущихся персонажей - ход завершен.
Если пример с комнатой слишком утрирован, представь станцию метро с несколькими входами и выходами, через которые соответственно входят и выходят юниты, но входящих больше. Те же, кто внутри, надеются продвинуться к выходам, поэтому вектор скорости у них ненулевой.

>>16219
>В >>16174, как я понимаю, предлагается "физическая" симуляция движения
Нет, я предлагал именно то, что что описал в >>16203. И это таки физическая симуляция движения по графу, вершины которого - клетки дискретного пространства, но само движение и коллизии считаются в обычных координатах.
>Но в некоторых ситуациях вот это конечное условие может оказаться трудновыполнимым
Элементарно выполнимо. Даже в вычислении того, кто ближе к центру нет необходимости - достаточно овнить клетку при успешном
>ПереместитьсяНа1ВершинуГрафа();
т. е. когда не произошло коллизии. Таким образом, заходить в переполненное метро никто не будет.