Wataru, это я обошёл использованием идеального хеша, вычисляемого из текущего состояния и использованого для прямого позиционирования по битовому массиву... и искать ничего не нужно и доступ мгновенный, один минус для каждой задачи хеш-функцию переписывать
Wataru, не храню. в процессе поиска делается каждый след возможный ход - выбирается который из них кратчайший - зацыкливается. не туда пойти нельзя, т.к. мы идём от нужного состояния к старту, а значит проход всегда есть, т.к. узел был создан.
Wataru, Возможно при многих игроках свои ньюансы, у меня игрок всегда один и на каждом этапе ему доступно один из X возможных ходов, потому не задумывался... Но эти тонкости не имеют отношения в вопросу.
кто сказал, что он пустой?
Смотрите в отладчике браузера где все элементы, они могут иметь нулевой размер, быть за зоной видимости, иметь такой же цвет, как у формы и т.д.
разница будет в любом случае и в любом случае LinkedList будет шустрее, т.к. в нём O(n) про операции чтения, а в List O(n) про операции записи, которые всегда медленнее. И чем больше список и, в случае List, сами элементы, тем более заметна будет разница
Какой сигнал пришёл на сервер первым, тот первый и был, чего засекать то?
Если у клиента медленный интернет и страница с кнопкой грузится 5 мин, то он не может по определению отреаагировать быстрее стабильного клиента. А если не стоит следить за нечестными игроками реализация вообще не важна.
а чем это нарушает правила? если у тебя есть номер телефона, телеграм сам по нему в поиске найдёт пользователя... если API создано, значит его можно пользовать
Тут стоило бы уточнить постановку задачи. Можно тупо сравнивать растр попиксельно, то тогда одинаковые картинки со сдвигом в 1 пиксель могут дать погрешность в ~90%. Если стоит задача именно в сравнении похожести изображения, а не пикселей (т.е. например повёрнутая на 37° картинка была бы распознана, как максимально похожая) то тут не так всё примитивно
