Как стать автором
Обновить
25
0

Android программист

Отправить сообщение

Можно установить какой-нибудь лимит: по времени или глубине поиска (например, используя A* и ε-admissible эвристики). Так как 100% позиций требуют для оптимального решения 80 ходов или меньше, мы можем выбрать какую-нибудь верхнюю границу и просто останавливать поиск решения при ее достижении.

плюс 7 бит на дополнительные флаги

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

Допустим что игрок собирает пятнашки за 1 секунду,

Если мы не ищем оптимальные решения (а нам нужно найти хоть какое-то решение), то компьютер будет решать намного быстрее.

На Ryzen 9 7900X у меня уходит около 5мс на позицию, т. е. `16!` позиций можно проверить за ~1200 тысяч дней. Если написать алгоритм решения на Rust (мой написан на Java), взять более мощный процессор, решать в несколько потоков (и/или распараллелить на несколько машин), то вполне можно уложиться в несколько лет.

А еще можно дополнительно отбрасывать зеркальные позиции, позиции с числами в обратном порядке (может еще какие-нибудь конфигурации найдутся) - примерно еще раз в 8 объем сократим.

Но этот вопрос уже за рамками моей статьи :)

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

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

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

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

Вместо того, чтобы ждать подходящей комбинации в цикле:
do {
  reset(); // reset in initial state
  shuffle(); // shuffle
} while(!isSolvable()); // make it until grid be solvable

Можно поменять последнюю и предпоследнюю ячейки местами:
shuffle();
if (!isSolvable()) {
  Arrays.swap(tiles, size - 1, size - 2);
}

После этого паззл станет решаемым.

Особенно прекрасно, когда это ограничение есть, но тебе об этом не сообщают.

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

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

Или без Сбера жить ?

Это вы говорите про minSdk, а с поднятием compileSdk проблем не будет.

Можно сделать через flavors или build types. В этом случае можно разнести эти активити по разным манифестам, положив каждый в нужный flavor/build type.

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность

Специализация

Mobile Application Developer
Lead
Android development
Java
Kotlin
Golang