История изменений

Я вижу проблему в том, что если смартфону легального клиента будет требоваться с нашим хитрым алгоритмом скажем секунда на то чтобы посчитать одну последовательность ходов, то читер запустит на видеокарте и проверит за секунду тысячи\миллионы вариантов, даже если это и не будет оптимально, в любом случае это будет лучше чем сможет сыграть человек. Так что кроме как сервера отправляющего сид в ответ на ход вариантов не вижу.

Моя идея была:

Например, можно обеспечить это дорогим алгоритмом регенерации поля после хода.

Например так:

• регенерируемые фишки зависят от первых k ходов игрока. Условно сид генерации на ходу n = sha256(сид карты | ходы игрока 1..min(k, n-1) ).
• серверу при генерации придется перебирать всё дерево чтобы найти мин и макс. бонусы, но для него получить сид генерации не проблема так что он переберет легко.
• а вот клиенту он вместо сида карты отправит зашифрованные() сиды для всех вариантов первых k ходов игрока. Тут правда вопрос в том на сколько k хватит нескольких килобайт разрешенных в условии, но если у игрока 3-4 варианта хода то k = 4 или 5 можно обеспечить. Соответственно задача сводится к тому чтобы () - зашифровать число так чтобы шифровалось оно быстро, а для его расшифровки требовалась ~1секунда. Тогда легальному клиенту придется расшифровать только k вариантов, а читеру придется для перебора расшифровать 3**k вариантов (но не больше чем влезет в сид, а это всего несколько тысяч).

Я вижу проблему в том, что если смартфону легального клиента будет требоваться с нашим хитрым алгоритмом скажем секунда на то чтобы посчитать одну последовательность ходов, то читер запустит на видеокарте и проверит за секунду тысячи\миллионы вариантов, даже если это и не будет оптимально, в любом случае это будет лучше чем сможет сыграть человек. Так что кроме как сервера отправляющего сид в ответ на ход вариантов не вижу.