Можно установить какой-нибудь лимит: по времени или глубине поиска (например, используя A* и ε-admissible эвристики). Так как 100% позиций требуют для оптимального решения 80 ходов или меньше, мы можем выбрать какую-нибудь верхнюю границу и просто останавливать поиск решения при ее достижении.
Дополнительные флаги, думаю, не нужны - если мы оптимизируем, исключая повороты, отзеркаливания и т.д., то можно хранить только набор уникальных позиций, и при создании новой игры случайным образом поворачивать пазл, отзеркаливать и т. д.
Допустим что игрок собирает пятнашки за 1 секунду,
Если мы не ищем оптимальные решения (а нам нужно найти хоть какое-то решение), то компьютер будет решать намного быстрее.
На Ryzen 9 7900X у меня уходит около 5мс на позицию, т. е. `16!` позиций можно проверить за ~1200 тысяч дней. Если написать алгоритм решения на Rust (мой написан на Java), взять более мощный процессор, решать в несколько потоков (и/или распараллелить на несколько машин), то вполне можно уложиться в несколько лет.
А еще можно дополнительно отбрасывать зеркальные позиции, позиции с числами в обратном порядке (может еще какие-нибудь конфигурации найдутся) - примерно еще раз в 8 объем сократим.
Если мы генерируем позицию, в которой пустая клетка в последней строке - да. Если мы будем размещать пустую клетку случайно, то нужная четность перестановок будет варьироваться в зависимости от строки, т. к. в классической версии ход по вертикали всегда меняет четность на противоположную.
Да, думаю можно и так. Вариант с 14 и 15, кажется, чуть проще в реализации, т. к. не нужно проверять наличие пустой клетки. Думаю, можно поменять любые два числа местами. Не проверял эту теорию для других конфигураций, но, кажется, должно и там работать.
Вы про алгоритм со случайными ходами? Если да, то тогда возникает та же проблема, как и с перемешиванием всего массива - нужно соблюсти четность, поэтому придется проверять решаемость. А в таком случае непонятно, зачем только пустую клетку перемещать, когда можно уже весь массив перемешивать.
Можно сделать через flavors или build types. В этом случае можно разнести эти активити по разным манифестам, положив каждый в нужный flavor/build type.
Можно установить какой-нибудь лимит: по времени или глубине поиска (например, используя A* и ε-admissible эвристики). Так как 100% позиций требуют для оптимального решения 80 ходов или меньше, мы можем выбрать какую-нибудь верхнюю границу и просто останавливать поиск решения при ее достижении.
Дополнительные флаги, думаю, не нужны - если мы оптимизируем, исключая повороты, отзеркаливания и т.д., то можно хранить только набор уникальных позиций, и при создании новой игры случайным образом поворачивать пазл, отзеркаливать и т. д.
Если мы не ищем оптимальные решения (а нам нужно найти хоть какое-то решение), то компьютер будет решать намного быстрее.
На Ryzen 9 7900X у меня уходит около 5мс на позицию, т. е. `16!` позиций можно проверить за ~1200 тысяч дней. Если написать алгоритм решения на Rust (мой написан на Java), взять более мощный процессор, решать в несколько потоков (и/или распараллелить на несколько машин), то вполне можно уложиться в несколько лет.
А еще можно дополнительно отбрасывать зеркальные позиции, позиции с числами в обратном порядке (может еще какие-нибудь конфигурации найдутся) - примерно еще раз в 8 объем сократим.
Но этот вопрос уже за рамками моей статьи :)
Если мы генерируем позицию, в которой пустая клетка в последней строке - да. Если мы будем размещать пустую клетку случайно, то нужная четность перестановок будет варьироваться в зависимости от строки, т. к. в классической версии ход по вертикали всегда меняет четность на противоположную.
Да, думаю можно и так. Вариант с 14 и 15, кажется, чуть проще в реализации, т. к. не нужно проверять наличие пустой клетки.
Думаю, можно поменять любые два числа местами. Не проверял эту теорию для других конфигураций, но, кажется, должно и там работать.
К сожалению, не знаком с механикой этой игры. На первый взгляд больше похоже на ханойскую башню.
Вы про алгоритм со случайными ходами? Если да, то тогда возникает та же проблема, как и с перемешиванием всего массива - нужно соблюсти четность, поэтому придется проверять решаемость. А в таком случае непонятно, зачем только пустую клетку перемещать, когда можно уже весь массив перемешивать.
Можно поменять последнюю и предпоследнюю ячейки местами:
После этого паззл станет решаемым.
Особенно прекрасно, когда это ограничение есть, но тебе об этом не сообщают.
То есть генерируешь пароль 20 символов, он по-тихому обрезается до 16, а потом войти не можешь, потому что в форме входа 20 символов уже можно ввести.
Если пользоваться мобильным приложением, а не веб версией, то сертификат обычно уже внутри есть.
Или без Сбера жить ?
Это вы говорите про minSdk, а с поднятием compileSdk проблем не будет.