Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Морской бой. Минималистичный дизайн, возможность применить знания по теории вероятностей на практике, ну и просто убить немного времени. Вроде бы, есть способ вызвать на дуэль конкретного соперника, если добавить к адресу /#ID и далее любое число по договорённости. Если это действительно так, появляется практический шанс свести счёты с оппонентом, оказавшимся сильнее в научной дискуссии.
Я как-то размышлял про морской бой и решил, что существует какой-то алгоритм, который позволяет с большой вероятностью победить. А так же тактика, которая учитывает менталитет соперника (если ,конечно, он человек или не совсем тупой робoт). У меня тогда даже мысль была - предложить форумчанам: каждый пишет скрипт, который будет за него играть. А потом посмотреть, чей алгоритм одержал больше % побед.
Вот только как это реализовать - так и не придумал. Должна же быть какая-то общая платформа.
Я как-то размышлял про морской бой и решил, что существует какой-то алгоритм, который позволяет с большой вероятностью победить. А так же тактика, которая учитывает менталитет соперника (если ,конечно, он человек или не совсем тупой робoт). У меня тогда даже мысль была - предложить форумчанам: каждый пишет скрипт, который будет за него играть. А потом посмотреть, чей алгоритм одержал больше % побед.
Вот только как это реализовать - так и не придумал. Должна же быть какая-то общая платформа.
Можно через файл - клиенты пишут ходы в файл и из них же получают ответы, ведь с файлами все скрипты умеют работать? 
. Сервер можно написать на сях, для универсальности.
существует какой-то алгоритм, который позволяет с большой вероятностью победить.
Есть, например, такая статья. Правда, с теорией расстановки, изложенной в ней, я не вполне согласен, т. к. при игре с человеком принцип, скорее всего, будет моментально вычислен. Учитывая преимущества расстановки "кучей" и возле берегов, нужно применить больше фантазии. А алгоритм прострела с поиском четырёхпалубника в начале игры верен.
Скрипт для игры написать было бы интересно, я бы попробовал. Поле можно на AHK даже изобразить.
Дело не в том, что принцип будет моментально вычислен, дело в вероятности. Я провёл несколько тысяч игр, используя принцип расстановки 4x/3x/2x кораблей вдоль бортов, а однопалубных — в поле. Игры были с людьми, по нескольку сотен на одного человека.
Алгоритм поиска верен лишь отчасти, поскольку после нахождения 4x, надо будет искать 3x, а затем — ещё и 2x.
Update: как я дошёл до жизни такой — Eurisko - Wikipedia, the free encyclopedia.
Может это в отдельную тему вынести?
Alexii, опыт совсем не понятен, если можно, то поподробнее про используемый алгоритм и результат эксперимента.
Может это в отдельную тему вынести?
Сделал.
У меня тогда даже мысль была - предложить форумчанам: каждый пишет скрипт, который будет за него играть. А потом посмотреть, чей алгоритм одержал больше % побед.
Скрипт для игры написать было бы интересно, я бы попробовал.
Дык что, перейдём к реализации или нет? Я предлагаю организовать взаимодействие скриптов через сервер, это позволит каждому скрипту использовать удобные для него средства коммуникации(файлы, оконные сообщения, сокеты). Если все согласны, то остаётся придумать протокол и требования к клиентам.
Александр_, а скрипты не будут так же, как вышеупомянутая девочка, устанавливать последний корабль в последний момент 
?!
Александр_, а скрипты не будут так же, как вышеупомянутая девочка, устанавливать последний корабль в последний момент
?!
Нет , с сервером эта проблема легко решаема - оба скрипта передают серверу свою расстановку до начала игры. Без сервера эта проблема решается только криптографией.
Дык что, перейдём к реализации или нет?
Я готов. А кто будет сервер кодить?
Я готов. А кто будет сервер кодить?
Я готов начальный вариант готов написать начальный вариант, при необходимости ошибки потом поправим. Только прежде чем писать нужно требования сформулировать.
Для начала протокол. Предлагаю такой вариант:
все команды завершаются слешем("/")
после установки соединения клиент посылает сообщение "Bs1", идентифицируя протокол и версию. Сервер отвечает тоже самое, подтверждая начало игры.
клиент отправляет свой идентификатор, а в ответ получает идентификатор оппонента. Идентификатор должен быть уникальным, постоянным и определяться разработчиком. Состоять он может из латинских букв и цифр, длина не может превышать 63 символов.
клиент отправляет расстановку кораблей в виде строки из ста символов(0 - пустая клетка, 1- с кораблём).
сервер проверяет корректность расстановки и отправляет "OK" если его всё устраивает и "FAIL" если нет. Если расстановка не принята, то сервер ждёт повторного ввода.
когда обе расстановки одобрены сервер решает кто будет ходить и посылает ему сообщение "GO", другому клиенту сообщение "WAIT".
Атакующий клиент сообщает свой ход идентифицируя атакуемую клетку латинской буквой и цифрой(например "F10"), т.е. поле размечается так.
Сервер проверяет корректность кода и если он не возможен отправляет сообщение FAIL и ждёт повторного ввода.
Если ход корректен, то проверяет попадание. В случае промаха или ранения сообщает обоим клиентам "MISS A8" или "WOUND A8"(A8- координаты полученные на шаге 6) и переходит на шаг 5. В случае ранения или убийства корабля, сервер посылает сообщения вида "KILL A8".
Если убит последний последний корабль, то сервер сообщает об окончании игры(рассылая сообщения "WIN" и "LOSE") и завершает сеанс, иначе возвращается на шаг 5.
поле размечается так
Почему "K" пропущено?
Сервер проверяет корректность кода и если он не возможен отправляет сообщение FAIL и ждёт повторного ввода.
Если ввод некорректен, значит скрипт глючный и повторного ввода ждать не имеет смысла, можно сразу записать поражение.
В случае промаха или ранения сообщает обоим клиентам "MISS A8" или "WOUND A8"
Здесь идентификатор поля не нужен, по-моему, и так понятно, что это ответ на последний ход.
Мне кажется, без графики будет скучновато, вся игра сведётся к моментальному получению сообщения, выиграл твой клиент или проиграл, а интересно видеть сам процесс.
Да, и ещё. Клиента оповещать о том, попали в него или нет не обязательно, это ничего не изменит. Нужно только сообщать, когда его очередь ходить.
Почему "K" пропущено?
Не знаю, наверно ошибка . Столбцы нумеруются от A до J в алфавитном порядке.
Если ввод некорректен, значит скрипт глючный и повторного ввода ждать не имеет смысла, можно сразу записать поражение.
Логично.
Здесь идентификатор поля не нужен, по-моему, и так понятно, что это ответ на последний ход.
...
Клиента оповещать о том, попали в него или нет не обязательно, это ничего не изменит. Нужно только сообщать, когда его очередь ходить.
Так уж заведено, что игроки знают о ходах друг-друга, я предлагаю не отходить от классических правил. Тем более, что оппонентом вполне может выступать человек, а скрипт просто предоставлять ему интерфейс. Идентификатор поля, конечно излишен, просто он всё равно отправляется одному из клиентов и помогает сразу обнаружить ошибку, а то может получиться, что на сервере и на одном из клиентов ведутся разные игры.
Мне кажется, без графики будет скучновато, вся игра сведётся к моментальному получению сообщения, выиграл твой клиент или проиграл, а интересно видеть сам процесс.
Сервер может проводить большое количество партий, ему нужно только сказать имена скриптов и количество партий. Логи партий пишем в файл, чтобы их можно было потом посмотреть при желании.
Так уж заведено, что игроки знают о ходах друг-друга, я предлагаю не отходить от классических правил. Тем более, что оппонентом вполне может выступать человек, а скрипт просто предоставлять ему интерфейс.
Ещё это может подсказать тактику, которую использует соперник, для правильной расстановки кораблей в следующей партии.
Логи партий пишем в файл, чтобы их можно было потом посмотреть при желании.
Но всё равно графический интерфейс нужен, не от руки же потом рисовать!
Всё же куда интереснее иметь возможность следить за процессом во время игры, которой не обязательно пользоваться всегда.
Я правильно понял, скрипт-клиент свою расстановку сам должен делать?
Но всё равно графический интерфейс нужен, не от руки же потом рисовать!
Всё же куда интереснее иметь возможность следить за процессом во время игры, которой не обязательно пользоваться всегда.
Скрипты ведь будут принимать решения почти мгновенно, человек всё равно не будет успевать оценить ситуацию в реальном времени. Это лучше в отдельной программе(или даже в скрипте) сделать, с возможностью выбора раунда и хода для просмотра.
Я правильно понял, скрипт-клиент свою расстановку сам должен делать?
Разумеется.
Я правильно понял, скрипт-клиент свою расстановку сам должен делать?
Да. Например, планируется сыграть 100 партий против одного определённого соперника. Скрипт отслеживает тактику противника и корректирует свою тактику (как бы учится, а при смене соперника всё забывает).
(как бы учится, а при смене соперника всё забывает).
Приведённый выше протокол предполагает несколько иной подход - скрипт не знает ничего о партиях, каждый раунд для него как отдельная игра. Но у всех соперников есть идентификаторы, поэтому он может сохранять информацию о каждом сопернике в файл и при повторных встречах её использовать.
Скрипты ведь будут принимать решения почти мгновенно, человек всё равно не будет успевать оценить ситуацию в реальном времени.
А кто мешает реализовать два варианта: мгновенный, без графического интерфейса, много партий подряд; и "медленный", по таймеру, например, в одну секунду, где ход игры будет отображаться на реальном поле? Смотреть же на игру постфактум, когда результат известен заранее уже не так интересно, хотя и такую возможность можно сделать. Могу написать графический интерфейс на AHK.
как бы учится, а при смене соперника всё забывает
Ну, можно сделать свою базу данных для каждого идентификатора.
А кто мешает реализовать два варианта: мгновенный, без графического интерфейса, много партий подряд; и "медленный", по таймеру, например, в одну секунду, где ход игры будет отображаться на реальном поле? Смотреть же на игру постфактум, когда результат известен заранее уже не так интересно, хотя и такую возможность можно сделать. Могу написать графический интерфейс на AHK.
Ну мешает в основном лень, я тут за "линуксовый" подход - программа делает только одну вещь, но делает её хорошо . Может действительно сделать возможность выбора интерфейса. Т.е. после начала партии запускается ещё и скрипт интерфейса, которому в командной строке передаётся имя файла с логом.
Может действительно сделать возможность выбора интерфейса.
Да, тем более, что это не проблематично. Скрипт-интерфейс будет просто отслеживать изменения лога.
Да, а играть-то как, по сети что ли?
Да, а играть-то как, по сети что ли?
Не вариант. Поддержку сети можно сделать, но *.vbs скрипты не смогут её использовать. Я думаю нужно обязательно дать возможность общаться через файл(для vbs, js) и через оконные сообщения(для ahk). Способ коммуникации нужно указывать вместе с файлом скрипта.
Кстати формат лога какой будет? Туда ведь нет смысла всё подряд писать, нужно чтобы его потом было удобно парсить.
Ржач! Кто-то принял крестные муки!
Кстати формат лога какой будет?
Что-то типа ini-файла можно. Заголовок секции — идентификатор игры. Далее два ключа типа "[идентификатор клиента][pos]= ..." и далее позиции кораблей через разделитель. Два ключа "[идентификатор клиента][game]= A8M,B9W,B10K,...". Ключ "Winner=[идентификатор клиента]". Как-то так.
Ещё ключ "first=[идентификатор клиента]" — кто ходил первым.
Да, вместо 10 можно 0 для простоты.
Что-то типа ini-файла можно.
А это точно будет удобно? придётся ведь при каждом обновлении перечитывать весь файл. Может лучше дать возможность последовательной обработки? Чтобы всю начальную информацию о партии и раунде можно было получить регулярным выражением, а ходы через Loop. А добавление новых данных удобно проверять через File.AtEOF.
И вместо расположения кораблей проще всё игровое поле писать, его ведь потом всё равно в массив заносить.
А это точно будет удобно? придётся ведь при каждом обновлении перечитывать весь файл.
Я предложил ini, потому что в AHK с ними просто работать — указываешь название секции, название ключа и парсишь/изменяешь/добавляешь значение. Как в других языках, не знаю, будет ли так же удобно — тебе виднее (кстати, никто пока на vbs не подписывался играть).
И вместо расположения кораблей проще всё игровое поле писать, его ведь потом всё равно в массив заносить.
Ты, наверное, как-то по-своему всё это видишь. Зачем заносить всё поле, если можно занести только занятые клетки?
Я предложил ini, потому что в AHK с ними просто работать — указываешь название секции, название ключа и парсишь/изменяешь/добавляешь значение.
Я тоже про AHK_L писал, просто я боюсь, что лог окажется большого размера. Давай тогда попробуем с ini, если что поменяем формат. Я думаю файл будет примерно так выглядеть:
[general]
id1 = botVasya
id2 = MegaBotV101
TotalRounds = 100
CurrentRounds = 23
Score = 11-12
[Round1]
Area1 = ...
Area2 = ...
First = 1
Steps = 1A8M,2B9W,2B10K,...
[Round2]
...
1A8M - первый игрок выстрелил по A8 и промахнулся. Игрок указан чтобы было понятно чей ход, если писать ходы в разные ключи то будет непонятен порядок.
Ты, наверное, как-то по-своему всё это видишь. Зачем заносить всё поле, если можно занести только занятые клетки?
Я это вижу так:
Area := Object()
Loop, Parse, InputVar
Area[%A_Index%//10+1][Mod(%A_Index%,10)+1] = %A_LoopField%Дальше с Area удобно работать.
Можно и так, но если в ключи Area1 и Area2 писать все поля, как раз таки лог и получится гораздо больше. Может, проще придумать другой способ занесения в массив?
Можно и так, но если в ключи Area1 и Area2 писать все поля, как раз таки лог и получится гораздо больше. Может, проще придумать другой способ занесения в массив?
Ну процентов на 15 увеличится. Просто запись вида "Area1 = A1,B2B4,C7C10" будет не так удобно парсить.
Ну ладно, это не критично. А в каком виде клиент должен подавать серверу свою расстановку, и как сервер будет определять, что корабль убит?
А в каком виде клиент должен подавать серверу свою расстановку
Расстановку подаёт строкой из ста единиц и нулей, по одному символу на клетку(это было написано в 12-ом посте).
и как сервер будет определять, что корабль убит?
Это проблемы сервера(т.е. реализации). Я весь код клиента выложу вместе с исполняемым файлом.
В общих чертах ясно, я тогда пока с графики начну. В графическом режиме скрипту-интерфейсу, наверное, проще получать информацию через оконные сообщения, чем через файл.
В общих чертах ясно, я тогда пока с графики начну.
Ну да, а я завтра уже какой-нибудь вариант сервера выложу, может ещё не совсем готовый, но работоспособный. Сегодня наверно уже не успею. Ну и пример элементарного скрипта на ahk сделаю.
upd. Прошу прощения, сегодня не смогу ничего выложить, только сейчас взялся за работу. Постараюсь закончить как можно быстрее.
У меня такая наработка. Для поля
; клетки записываются сверху вниз и слева направо
str := "1000000000000001010100000101000000010000111001000000000000000100001100000100000100010010000001001000"
Letters := "abcdefghij"
Area := {} ; именованый массив для всего поля, ключи будут называться по буквам
Loop 10 ; в каждом буквенном ключе будет массив со значениями клеток
Area[Substr(Letters, A_Index, 1)] := []
Loop, Parse, str ; заполняем
Area[Substr(Letters, (A_Index - 1)//10 + 1, 1)][Mod(A_Index - 1, 10) + 1] := A_LoopField
Ships := [] ; массив для кораблей
Loop 10 ; делаем в массиве 10 подмассивов, в каждом будут идентификаторы (вида "h10") клеток одного из кораблей
Ships[A_Index] := []
i := 1
for Letter,Array in Area ; заполняем массив кораблей, анализируя массив клеток
for Number,Value in Array
if Value
{
IsPrev := ""
for k,v in Ships
for n,s in v
if ((SubStr(s, 1, 1) = Chr(Asc(Letter)-1) && SubStr(s, 2) = Number)
|| (SubStr(s, 1, 1) = Letter && SubStr(s, 2) = Number - 1))
{
v.Insert(Letter . Number), IsPrev := 1
break 2
}
if !IsPrev
Ships[i++].Insert(Letter . Number)
}
for k,v in Ships ; смотрим, что получилось
{
for m,n in v
List .= (A_Index = 1 ? "" : ", ") . n
List .= "`n"
}
MsgBox, % "Корабли:`n`n" List
Александр_, из описаний не понятные следующие моменты:
-- какой протокол передачи данных предполагается использовать
-- верно ли что реализация ориентирована в первую очередь на языки семейства AHK
-- возможно ли будет реализовать свой клиент на других скриптовых языках (например, js, perl, другие языки)
----
Лог игры должен быть простым как запись шахматной партии и информативным, чтобы можно было воспроизвести игру в пошаговом режиме - программно или вручную. Например:
координаты выстрела
попадание - например, символ ":" (двоеточие)
уничтожение - "+" (плюс), "x" (латинское икс)
Простая запись - один выстрелил на e1, другой - на k0.
e1 k0
Первый выстрелил три раза: два раза удачно на b1, a1 и мимо на c1.
Аналогичная запись для второго игрока.
b1:a1+c1 k9+h8
ba1+c1 k9h8
bac1 k9h8
Вообще-то достаточно возвращать координаты выстрелов.
Идея умерла так и не родившись?
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
