ява — выбоины в автоматизированной многопользовательской игре, где игроки могут использовать свои собственные алгоритмы
О тегах
Я отметил это как Java а также вопрос C ++. Это означает, что я не ищу конкретные языковые ответы. Я пометил C ++ и Java только потому, что хорошо владею ими и, скорее всего, пойму ваши примеры кода, если они написаны на этих (или похожих) языках.
Что я ищу?
указатели а также в поле зрения на безопасность меры, которые я должен учитывать при разработке программного обеспечения, в основном игры, такой как описанный ниже. Под безопасностью я подразумеваю проверку и двойную проверку того, что пользователь не действует в путь не предназначен. Это может означать поведение, такое как отправка его / ее обновленной коллекции наиболее вредоносных вирусов, существующих на сервере / другим клиентам, или иным образом ставить под угрозу взаимодействие с другими игроками, например, путем взлома.
Ожидаемые комментарии и ответы
Вы спрашиваете, как не дать людям взломать вашу игру?
Это не во всяком случае, мой вопрос, так как это путь слишком широк для этой темы. Однако, если вам все-таки придется найти простой способ выиграть в каждой игре (обманывая), то, пожалуйста, сообщите мне.
Этот вопрос лучше подходит для X
Я задал этот самый вопрос в CodeReview и в Программистах; в обеих сетях пост был плохо получен. Это было плохо получено здесь, чтобы быть справедливым (ссылаясь на комментарий ADTC), отсюда и награда. После размещения награды я переписал этот пост, чтобы лучше соответствовать стандартам SO. Однако, если вы все еще думаете, что этот пост здесь не подходит, скажите, пожалуйста, почему. Мне было трудно определить, действительно ли это лучше подходит для SO или для программистов, так что не думайте, что это просто дамп, который я разместил здесь, не задумываясь об этом ни секунды.
Чтобы создать соединение между двумя машинами, вы должны использовать сокеты. Погугли это.
Я не ищу такую техническую помощь. Я знаю, как реализовать программное обеспечение, и это не первый раз, когда я делаю это. Пожалуйста, посмотрите на фактический вопрос, который я задал.
Почему я спрашиваю это?
Программное обеспечение в вопросе
Я разрабатываю многопользовательскую игру, похожую на змею, в которой игроки могут использовать свои собственные алгоритмы, чтобы определить следующий ход своей змеи. Игроки связаны друг с другом соединением клиент-сервер, то есть один игрок будет выступать в качестве хоста. Можно предположить, что код сервера будет ждать, пока все игроки не выполнят свои очереди, пока не обновит игровое состояние между всеми клиентами.
Об игре
Моя игра ищет в папке любые совместимые файлы .jar, основной класс которых расширяет определенный абстрактный класс. Затем игрок может подключиться к другому игроку (-ам) по сети, напрямую подключившись к ним или выполнив поиск игры в лобби.
Во время игры каждый игрок будет использовать свой собственный алгоритм для определения следующий ход их змеи. Продолжительность каждой игры может сильно различаться, в зависимости от частоты обновления, которая была указана для игры, но большую часть времени они бывают быстрыми и, скорее всего, заканчиваются менее чем через 30 секунд.
Я не так далеко, как реализация реального сетевого мультиплеера.
Исходный файл шаблона для логики выглядит следующим образом:
package template
import snake.*;
public class TemplateLogic extends SnakeLogic {
@Override
public void onLaunch() {
}
@Override
public String getMove() {
return "UP";
}
}
Итак, что я планирую сделать, так это с точки зрения хост-плеера получить следующий ход плеера по сети в формате String («вверх», «вниз», «влево», «вправо»), поэтому не будет никаких проблем с безопасностью на этом фронте. Фактическая программа, которую каждый клиент использует для определения своего следующего хода, будет всегда запускаться только на компьютере соответствующего клиента.
Я надеюсь, что вы следите за мной до сих пор. Во всяком случае, сейчас меня беспокоит любая другая выбоина, которую я мог упустить из виду. Определение всех этих выбоин может быть слишком утомительным для выполнения задачи, поэтому я не буду спрашивать об этом в первую очередь. Дать мне понимание этого вопроса — вот чего я ожидаю. В идеале я могу получить большую картину из нескольких ответов разных людей.
Вопрос, который плавает поверх других, состоит в том, что могу ли я запретить любому из клиентов использовать методы в своих программах, которые могут поставить под угрозу взаимодействие с другими игроками? Такие методы могут быть, например, Thread.sleep(): было бы довольно неприятно, если бы игрок заставлял свой алгоритм ждать 10 минут между каждым ходом. Для этой конкретной проблемы я решил установить ограничение по времени для каждого хода, после чего отстающий / злонамеренный игрок будет выгнан или назначен ход по умолчанию, чтобы игра могла продолжаться в обычном режиме.
Off-примечание:
Ответ @ Darinth напомнил мне об очень важном аспекте игры: ввод пользователя разрешен, Это означает, что следующий ход змеи может быть определен человеком-игроком, то есть в игру можно играть с клавиатуры. Кроме того, ничто не ограничивает вас в выборе между чистым ИИ и решением только для клавиатуры: вы можете смешивать их вместе и, например, управлять змеей самостоятельно и позволить ИИ вступать во владение, когда он заметит, что вы загоняете себя в ловушку.
Завернуть это
Я что-то упустил из виду? Я планировал сделать это небольшим проектом для меня и моих друзей, чтобы убить время, но я немного энтузиаст.
Пожалуйста, отвечайте без колебаний, независимо от того, насколько мала ваша идея. Позже вы можете отредактировать ответ, чтобы он был более полным, если вы подумаете о большем количестве интересных мест. Я буду регулярно проверять любые ответы на изменения.
Спасибо за ваше время.
Соответствующие идеи, которые я получил из ответов или самостоятельно
-
Сравнивайте хэш состояния игры со всеми клиентами после каждого хода. Все, кроме игроков с одинаковым хешем, будут выгнаны, с минимальным требованием, чтобы хост оставался в игре (если есть 4 игрока, из которых 2 игрока имеют один хеш, а другие 2 игрока имеют другой хеш, группа, не включающая хост, будет выгнана и т. д.). Я придумал этот, однако это благодаря @ToYono, так что заслуга ему.
-
Перед началом игры сравните контрольную сумму каждого игрока. Все игроки с отличной контрольной суммой от хозяина будут выгнаны (или даже не впущены в игру). Кредит переходит к @ToYono.
-
Рандомизировать любые ранжированные матчи Предотвращает эффективное использование нескольких соединений с одного компьютера для игры в одной игре. Если один игрок сыграет несколько змей в одной игре, у него может быть один алгоритм, который пытается играть в игру законно, и два алгоритма, которые просто саботируют другого игрока. Кредит идет на @Surt.
-
Пользовательский ввод разрешен. Это было разработано, чтобы быть частью игры с самого начала, но я забыл упомянуть об этом. Благодарим @Darinth за то, что он предоставил мне такую возможность и напомнил мне об этом важном аспекте.
Решение
Если игрок может обмануть, некоторые игроки будут обманывать. Итак, какие самые простые способы обмануть?
1) Изменить состояние игры, эффективно отменить предыдущие ходы.
-
все остальные игроки и / или сервер должны проверить обновление, так как это небезрассудные ценности, с которыми вы не должны столкнуться. Проверок на стороне клиента может быть достаточно, но проницательный хакер может взломать чек, изменив чек на что-то вроде
bool allowMove () {
вернуть истину;
… оставшийся оригинальный проверочный код здесь
}
Которому затем нужно противопоставить контрольную сумму кода, SHA3? как MD5 приближается к концу своей безопасной эпохи.
Пример: WoW teleport hack, x, y, z рассчитывается на клиенте и отправляется на хост.
- читеры взломать клиента, чтобы получить желаемый результат.
- Bliz делает контрольные суммы на клиенте.
- Мошенники только что вставили новый сетевой пакет с x, y, z, чтобы телепортироваться, где они хотели.
- Bliz проверяет внешние программы, делающие это.
- читеры рандомизируют свои внешние программы.
- Близ возражал против проверки расстояния на стороне сервера.
- мошенники возражают против ограничения телепортации на разрешенное расстояние, в результате чего люди ходят по воздуху без полета.
- Bliz противостоял дальнейшим проверкам работоспособности на стороне сервера, по-видимому, решающим большую часть проблемы.
2) Реагируйте с нечеловеческой скоростью, эффективно устраняя человеческие задержки.
Не проблема в вашей игре, если быстрее не дает больше ходов, но это между программами, поэтому … они всегда могут быть быстрее, чем люди.
- если время реакции часто бывает быстрее, чем возможно у человека, то мошенник должен быть на другом конце. Разница во времени ответа и пинга недостаточно велика.
3) Автоматическое нацеливание, обеспечивающее негуманную высокую частоту попаданий
- у игрока намного лучший показатель попаданий, чем у второго лучшего подтвержденного игрока-человека.
Пример: шутер XXX
- внешняя программа ловит координаты игрока и передает скорректированный таргетинг в игру через Windows API.
4) Использование других внешних вспомогательных программ
- намного лучше ИИ, чем другие игроки
Пример: онлайн-игры в шахматы, где читер использует шахматную программу, чтобы помочь с ходами.
- Ваши игроки могут создать программу, которая сохраняет игровое состояние и заставляет внешнюю программу обрабатывать данные и делать следующий ход, который затем загружается программой читеров и отправляется как следующий ход.
- Проверяя любую загрузку в программах, игроки могут законно хотеть иметь экономию для анализа эффективности своих программ.
- Используя оптимизированный многопоточный многопоточный векторизованный алгоритм, мошенник может исследовать большинство или все игровые состояния.
- почти невозможно проверить, помогают ли внешние программы, вы можете проверить генерацию событий внешних окон, но будет много ложных срабатываний. Вы можете попытаться предотвратить любую загрузку / сохранение читов, но читеры могут атаковать на уровне IP.
- самая большая защита состоит в том, что усилие сделать это может перевесить любые выгоды.
5) Мульти-бокс, у некоторых игроков может быть несколько компьютеров, сотрудничающих для победы
- использование нескольких компьютеров или экземпляров программы может увеличить вероятность того, что основной экземпляр мошенников выиграет, поскольку другие саботируют других игроков.
Пример: может случиться в шутере?
- мошенник посылает приманку или подразделение подавления, ведя огонь или мешая движению противника, в то время как реальный игрок стреляет в противника или зарабатывает очки другими способами
- трудно проверить, так как 2 человека могли законно играть из одного места.
- если MAC-адрес компьютера одинаков для нескольких игроков, это может свидетельствовать о мошенничестве, так как они будут летать на одном компьютере. Но даже это не могут быть мошенники, поскольку они могут играть с закрытых виртуальных машин.
6) Предварительно рассчитайте все игровые состояния, чтобы мошенник мог использовать наиболее оптимальную стратегию.
- игроки, не делающие этого, будут выбирать неоптимальные стартовые ходы.
Пример: крестики-нолики
- можно рассчитать все игровые состояния. (Вы можете сделать это в своей голове для крестики-нолики).
- Рейтинг игроков здесь должен помочь, но мошенник все же мог легко выиграть.
- например, для шахматных программ обычны последовательности открытия перед компиляцией.
- Единственный способ победить это очень рандомизированные карты и стартовые позиции с таким большим состоянием, что его невозможно рассчитать заранее.
7) Создание новых личностей, чтобы побить рейтинги.
- Мошенники перепуганы победой, они создадут для себя новых «игроков» с низким рейтингом, чтобы снова «победить».
- это происходит, даже если игроки не мошенничать, они будут создавать новые личности, чтобы они могли победить легких жертв.
8) выиграть торговлю
- 2 мошенника обмениваются победами друг с другом
Пример: WoW поля битвы
- использование внешних программ для увеличения шансов получить право противник.
-
отключить, чтобы избежать его регистрации, если не в паре с право противник. Разъединения часто происходят даже без обмана (не играйте по беспроводной связи или на мобильных телефонах, если хотите уменьшить это).
-
Определите, играют ли 2 Mac-адреса с разными именами, и выигрывает только один на каждом Mac.
9) Отключайтесь, когда проигрываете.
X) неизвестное неизвестное (в отличие от известного известного, неизвестного известного, известного неизвестного)
- всегда есть кто-то, кто придумывает новые способы обмана, о которых мы не думаем.
Пример: уклонение от уплаты налогов
-
всегда есть лазейки, недостающие или ложные отчеты о доходах, новые вычеты, которые являются мошенническими и т. д.
-
К счастью, всегда есть способ узнать, кто-то обманывает верхнюю позицию, вы можете проверить алгоритм, который они представили программе, и увидеть его обман. Помните, что программа, которую вы получите, может быть подделкой, но проверить, могла ли она так много выиграть, было бы тривиально.
- умный читер останется чуть ниже радара.
Другие решения
Этот ответ суммирует чат, сделанный выше в разделе комментариев.
- Как один из игроков должен принять игру, что если обманщик был хозяином ?
Если мошенник является хостом, это означает, что он запускает код сервера. Это подразумевает, что он может влиять на всю игру, поскольку он работает с ядром.
Хорошим решением было бы для каждого игрока вычислить контрольную сумму и сравнить ее с контрольными суммами всех других игроков, участвующих в одной игре. Если одна контрольная сумма не совпадает, игра отменяется. Эта контрольная сумма может быть уникальной версией, основанной на одной строке.
- Может ли хост взломать эту систему?
Поскольку каждый игрок проводит свое собственное сравнение, всем игрокам придется взломать игру одинаково, что крайне маловероятно. И, как отметил @Olavi Mustanoja, система контрольных сумм будет отлично взаимодействовать с клиентом обновлений.
Редактировать:
Первоначальная идея ОП заключалась в том, чтобы сравнивать состояния игры на каждом ходу между всеми игроками.
Состояние игры хранится в массиве int, где 0 означает доступное пространство, -1 означает кусок змеи, -2 означает голову змеи и 8 означает яблоко (или печенье). После каждого хода игра сравнивает все массивы состояний и завершает игру, если в какой-то момент некоторые состояния отличаются от других. Это можно легко сделать, отправив хэш-код массива.
Эта идея не является несовместимой с моей идеей контрольной суммы, это может быть двойная безопасность.
Многое зависит от того, что вы намерены ограничить. Это нормально для алгоритма, чтобы спросить пользовательский ввод? Должен ли быть предел в отношении информации, к которой имеет доступ алгоритм? Использование кода Java / C ++ дает алгоритму возможность делать практически все, что угодно. Вы можете настроить окно, чтобы выбрать путь для змеи, чтобы они могли работать с человеческим интеллектом, но с машинной точностью. Вы могли бы дать возможность переключаться между различными алгоритмами, которые могли бы активировать режим «выхода», чтобы выйти из неприятной ситуации, или режим атаки, чтобы специально попытаться поймать игрока, которого вы заметили, в плохом месте. Если это то, чего вы хотите избежать, я рекомендую предоставить язык сценариев (например, Lua или Javascript). Их можно легко настроить, чтобы ограничить их возможности и запретить пользователям доступ к тому, что им не нужно. Делайте это прилично, и вы можете безопасно отправлять эти сценарии всем клиентам / серверам, и все они могут безопасно запускать симуляцию и сравнивать шаги / результаты.
Если вы в порядке с этими вещами, то единственное, о чем я мог бы подумать, это хосты, использующие взломанные клиенты, о которых уже упоминалось.
Основная проблема — сервер. Он имеет игровое состояние и ему нужно доверять. Клиент в вашем случае может быть изменен, поскольку клиенту разрешено делать все, что требуется, чтобы определить следующий шаг. Вы не можете доверять серверу, если он выполняется на удаленной машине. Он может манипулировать всеми контрольными суммами и цифровыми подписями, поскольку самому устройству не доверяют.
Я могу подумать о 3 вещах, которые вы могли бы сделать, чтобы сделать ваш сервер надежным:
- Запустите сервер на одной машине, которой вы управляете -> игровые клиенты подключаются к серверу. ИМХО лучшее решение проблемы
- Разместите сервер на UserA. UserB и UserC используют этот сервер для игры. UserA и UserD могут играть на сервере, размещенном @ UserB. Никто не заинтересован во взломе / изменении кода клиент / сервер. => сложно реализовать, но вам не нужна серверная инфраструктура (только игровое лобби …)
- Все клиенты имеют локальный сервер. Только если два участника согласны с результатом игры, он засчитан =>, вы можете обнаружить, что кто-то делает что-то плохое, но не кто именно. Вы можете создать счетчик на сервере, и если один пользователь часто манипулирует совпадениями, вы можете исключить их и их результат.