Как правильно грабить корованы?

Интернеты рекомендуют читать:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.149.9159&rep=re...

freeciv …(люди и АИ ходят по очереди, это неправильно, должны ходить параллельно/одновременно)

Freeciv — многопользовательская пошаговая…

По сути - шахматы. Вот-бы в шахматах ходили «параллельно/одновременно».

Есть такие реализации на JavaScript. Там фигура имеет «кулдаун», т.е. прилипает к месту на N секунд после того как передвинулась.

По сути мне нужна RTS (real time strategy). Все там ходят параллельно и всё у них хорошо.

Глупости. Во-первых, наивно думать что от многопоточности автоматом появляется какой-то выигрыш и эта архитектура «правильнее». См. закон Амдала для просветления (или проблему c10k, где тупо добавление потоков не работает, а выигрыш получается от мультиплексирования ввода-вывода, т.е.... опросом в цикле, он же «поллинг»). Ну и... Уж точно не для пошаговой игры. У гуя вообще мало прямого выигрыша от многопоточности (потоки за него конкурируют, а значит должны синхронизироваться и строиться в очередь для ввода-вывода), если то же самое легко решается... бэкграунд воркером 1 штука. Нужны потоки или нет зависит от задачи.

Уж точно не для пошаговой игры.

Чего это? Чем умнее АИ, тем интереснее игра.

По сути мне нужна RTS (real time strategy)

Это монопенисуально. RTS появились до массового внедрежа многопоточности. Возьми уже движок какого-нибудь клона C&C и убедись что потоки там не особо нужны.

Это тоже не зависит от многопоточности.

Зависит, чем больше доступно вычислительной мощности, тем выше потенциал.

При чем тут вычислительная мощность, але? Есть параллельность по данным, а есть параллельность по командам. «Потоки» — это только один из вариантов. Кури закон Амдала про выигрыш от потоков. Иногда они сюрприз-сюрприз наоборот просаживают производительность. Особено когда курят перед выхлопом в ГУЙ. А про «интеллект ботов» - посмотри например движки от Monolith (F.E.A.R.), которые в свое время удивляли обозревателей «эмерджентным» поведением. Там A.I. реализован через кучу правил. Потоки опять-таки не при чем.

Ты пытаешься решить алгоритмическую проблему изменение архитектуры. Наполни сначала бассейн ситом.

Логично сделать вывод, что такая игра должна быть написана на… haskell

Вобщем, объясните, чем haskell будет круче.

Ты переплюнул Кондратия, поздравляю.

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

GUI вообще лучше держать в одном потоке. Что Qt/C++, что Swing/Java, ориентированы на этот подход. Вроде бы как в MFC было по-другому (но это неточно). А вот вычислительных потоков можно сделать несколько.

И воообще, что значит «неправильно»? Это пошаговая стратегия, тут подразумевается, что ходят по очереди. Если тебе нужна RTS, просто поищи другую игру.

RTS — другой жанр

Моя цель добиться того, чтобы ИИ думал в то же самое время, пока думает игрок. Мне фиолетово, какой это будет жанр.

Не должно быть так, что игрок «завершает ход» и после этого игра на N минут отмораживается, пока ИИ подумает.

Если в RTS сделать задержку до тех пор пока игрок не нажмёт кнопку «дальше», это будет всё ещё RTS, или уже пошаговая?

В freeciv в мультиплеере люди-игроки двигают юниты вполне себе конкуррентно, пока все не понажимают «конец хода». Что мешает поступать ИИ так же? Вот этого я хочу.

Мне фиолетово, какой это будет жанр.

Тогда просто возьми любую RTS и отцепись от бедной цивилизации :)

Нет. Выше в сообщении я написал, почему.

Ну это ты в отредактированной версии уточнил :)

И что у вас там после нажатия «Конец хода» реально несколько минут проходит? Не просто ожидание отведённого времени?

это в блендере нужно клепать низкополигональных уродцев

Не просто ожидание отведённого времени?

Да, проходит неопределённое количество времени. Бывает что до 15 минут. Большая карта, много юнитов, тупые ИИ.

а можно как в дварф фортресс разноцветные буквы сделать… и запускаться все будет в терминалеааааааааааааааааааа

Да, но не в тему. Сейчас именно процесс ограбления интересует, с точки зрения разных участвующих сторон, а не визуализация.

можно. Но ты не в ту тему отвечаешь. В стартовом сообщении есть ссылка на другую тему, про выбор графики.

Ну тогда надо смотреть. Дело явно не в «неправильном» языке. Могу тебя заверить, что для сишки средства организации многопоточности есть, самые что ни на есть низкоуровневые. А тормозную программу можно и в машинных кодах написать.

Дело в том, что когда начали писать freeciv приняли неверные решения. Я хочу принять другие и попробовать что может получиться. Язык тут конечно не при чём, но надо выбирать самый лучший, зачем брать старьё?

Дело в том, что когда начали писать freeciv приняли неверные решения.

Ты вот прямо так категорически решил? Исходники хоть смотрел?

Язык тут конечно не при чём

Уже лучше

надо выбирать самый лучший

По какой шкале критериев? Десктопное приложение с поддержкой гуя, сети и многопоточности можно написать на хреновой туче языков, и лучшим будет то, в котором у тебя больше опыта. С мобильными выбор поменьше, но всё равно есть. Один из вариантов я тебе в соседней теме предложил.

Могу ещё предположить, что если ты будешь писать на ФП-ориентированном языке (хоть на хаскеле, хоть на эрланге), ты сразу резко снизишь вероятность того, что к тебе в команду разработчиков кто-то вольётся. Знаток плюсов может подучить джаву, го или раст при необходимости за более-менее вменяемое время. Учить же хаскель он будет только при очень-очень сильной мотивации — слишком сильно надо мозги выворачивать.

лучшим будет то, в котором у тебя больше опыта.

Меня всё устраивает. По haskell я посмотрел три ролика на ютубе, про rust один, а про остальные ничего не знаю. Значит мой выбор верный.

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

фрицив тоже один разработчик пилит, хоть и си, но никто к нему не присоединяется.

Так что это не является критерием для выбора.

По haskell я посмотрел три ролика на ютубе, про rust один, а про остальные ничего не знаю. Значит мой выбор верный.

А, ну вперёд и с песней. :)))

Кстати, истинную параллельность ходов обеспечить вообще нетривиально. И дело даже не в языке и его средствах, а в алгоритме игры в принципе. В RTS на практике ведь тоже квазипараллельность, просто этого обычно достаточно для игры.

истинную параллельность ходов обеспечить вообще нетривиально.

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

В общем-то, в цивилизации юзер управляет каждым юнитом. Когда он выбрал конретный юнит, если юнит недалекоходящий - есть только 8 вариантов, куда он пойдёт. Пока юзер думает, вполне реально обсчитать все 8 вариантов. Если юнит дальнобойный - там, конечно, труднее, но можно попытаться предугадать. Например, если юзер весь предыдущий ход двигался прямолинейно - есть вероятность, что и текущий ход он продолжит двигаться в этом направлении. Т.е. выбор сужается.

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

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

Ну выбрал что-то там пользователь и выбрал, это дело интерфейса. Вот когда юнит реально сдвинулся, это да, это событие, на которое можно отреагировать.

А почему бы не облегчить себе жизнь? Если число вариантов ограничено, и вы успеваете просчитать их все.

Мысль всё равно не ясна. Просчитать их все, чтобы что? Чтобы знать как отреагировать? Ну вообще вся суть игры в этом состоит - знать что делать дальше.

В общем, какое-то странное предложение. И можно в восемь раз снизить нагрузку, если считать по факту.

Просчитать их все, чтобы что? Чтобы знать как отреагировать? Ну вообще вся суть игры в этом состоит - знать что делать дальше.

Да.

И можно в восемь раз снизить нагрузку, если считать по факту.

Я так понял из вашего корневого поста, что нагрузку вы хотите, наоборот, увеличить - чтобы комп считал всегда, а не только после того, как пользователь походит.

Да, верно, я хочу нагрузку увеличить, чтобы комп считал всегда и всеми ядрами.

Но для этого необязательно читерить и пытаться переиграть пользователя нечестными способами.

Нечестность заключается в акцентировании «внимания» именно на ещё несовершенных действиях пользователя. Вот ПОСЛЕ того, как пользователь сдвинул юнит, реагировать на это честно.

О, да, можно брутфорсить в лоб.

Нужно. На реальном поле боя разведка не предоставит такой информации, какую ИИ может выцепить из пользовательского интерфейса в игре.

Поэтому алгоритм, который будет брутфорсить, будет одинаково сильно это делать и в игре и в реале.

Нечестность заключается в акцентировании «внимания» именно на ещё несовершенных действиях пользователя. Вот ПОСЛЕ того, как пользователь сдвинул юнит, реагировать на это честно.

А если я, когда играю в шахматы, думаю о том, как мой противник будет ходить дальше, это честно или нет?

Достаточно внести изменения в реализацию сервера.

Не должно быть так, что игрок «завершает ход» и после этого игра на N минут отмораживается, пока ИИ подумает.

ты хочешь, чтобы ИИ считал ответ на ход, который ты еще не сделал?

Я свой ход делаю маленькими шагами на протяжении длительного времени. Воть пусть ИИ считает всё это время те части, которые я уже подвигал.

если я, когда играю в шахматы, думаю о том, как мой противник будет ходить дальше, это честно или нет?

Это зависит от того, есть у тебя способность к телепатии или нет.

Если у тебя нет такой способности, то тебе придётся просчитывать все возможные ходы противника. Это нормально и честно. И брутфорс.

А если ты знаешь о чём противник думает (например томографом считываешь) и рассчитываешь контрмеры только к этому варианту, то это нечестно, так как экономит тебе усилия.

Человек выше как раз предложил подсматривать, что человек выбирает до того, как он передвинет юнит.

Воть пусть ИИ считает всё это время те части, которые я уже подвигал.

Для этого нужен особый алгоритм ИИ, а не многопоточность. Многопоточность может ускорить алгоритм (если он паралеллится), но не считать наперед.

Многопоточность может просчитать реакции 99 стран мира на большой карте земли в N раз быстрее, чем это бы делал однопоток.

Нет, по правилам игры они должны ходить по порядку, и ходы следующих зависят от предыдущих. Они вообще могут друг с другом воевать, ты в курсе, этот игровой мир не крутится вокруг тебя.

по правилам игры они должны ходить по порядку, и ходы следующих зависят от предыдущих.

Да, но это действует только для ИИ. И это легаси, проклятое наследство.

Игроки делают свои ходы против всех параллельно в одно и то же время. ИИ должны тоже иметь такие же права, как и игроки. Легаси должно быть вычищено.

ты хочешь, чтобы ИИ считал ответ на ход, который ты еще не сделал?

Ну шахматный ИИ так и делает.

ну так я и не возражаю, пусть делает

По haskell я посмотрел три ролика на ютубе, про rust один

Изучение ЯП по роликам на тутрубе. Поколение даже не ПИ, а Полный ПИ. И здесь я под ПИ подразумеваю совсем не пепси.

А если я, когда играю в шахматы, думаю о том, как мой противник будет ходить дальше, это честно или нет?

А если на «два хода?», а если на «четыре хода»? Вы читер! :)

Очевидное решение - это устроиться в какое-нибудь минсвязи и использовать служебное положение в личных целях. Если грабить корованы надо по-серьёзному и есть крыша.

У гуя вообще мало прямого выигрыша от многопоточности

Тайлы/слои, не? Или тру многопоточность это когда потоков автоматически дохрена?