x67

уравнение прямой выглядит так:
ax+by+cz=r,
где a,b,c,r - константы
Первым делом находишь коэффициенты для каждой линии. Это можно сделать, подставив известные точки и решив систему уравнений:
{ax1+by1+cz1=r, ax2+by2+cz2=r} (тут неизвестны величины a,b,c,r)
Повторяешь тоже самое для второй линии
Теперь имея уравнение для каждой прямой, решаешь их общую систему уравнений
{a1x+b1y+c1z=r, a2x+b2y+c2z=r} (тут неизвестными являются x,y,z - точка пересечения)
Стоит добавить, что линии могут не пересекаться или иметь бесконечное число пересечений - это надо учесть и проверить.
Упростить решение можно используя векторное представление и соответствующие библиотеки, но это уже ищи сам. Вот тут разжевано мат. описание прямой в векторном виде. На инглише, но это не страшно, все по картинкам можно понять.

У предмета есть вектор скорости и вектор ускорения. Также есть одна угловая скорость (на плоскости) и одно угловое ускорение.
Собственно разберем простой случай, когда при свайпе предмет мгновенно достигает нужной скорости и нужной частоты вращения.
Тогда можно аппроксимировать свайп в линию (запросы: линейная фильтрация, тренд по точкам, линейная интерполяция и тп). Возможно подойдет просто взять начальную и конечную точку, попробуйте. Тогда у предмета скорость по оси Х будет равна (x2-x1)*К/(t2-t1), где 1 и 2 - точки начала и конца свайпа, а К - какой-то коэффициент, который будет вам удобен. А по оси Y соответственно (y2-y1)*K/(t2-t1).
Закрутку считать так. Берете начальную и конечную точки свайпа, получаете из них линию, далее ищите самую далекую точку от линии (или для простоты ищите расстояние средней точки до линии). Угловая скорость будет пропорциональна этому расстоянию.
Как сделать так, чтобы предметы ускорялись плавно?
Во первых надо запомнить, что ускорение не должно быть постоянным, должна быть какая-то инфляция его во времени. Причем быстрая. Далее нужно решить, есть ли у предметов разная масса (насколько физична игра?) Если нету, то мы работаем напрямую с ускорением, если есть, то появится еще сила, воздействующая на предмет. Предположим массы нет, тогда можно сделать простое ускорение, равное какому-то числу. Конечную скорость считаем также, но при этом не сразу присваиваем скорость, а постепенно изменяем по следующей формуле:Vx=Vx+ax*dt. dt - интервал между фреймами (для девайсов с переменным фпс, чтобы игра не скакала,) ах - ускорение по оси х. При достижении скорости ускорение становится равным нулю.
Еще один вариант плавного разгона - Vx=K*Vx+(1-K)*Vxzad, где К может быть в интервале от 0 до 1, а Vxzad - расчетная скорость, которой надо достичь. Чем больше К, тем медленнее будет ускоряться предмет. Если надо, эту формулу можно написать немного в другом виде, тогда с ней будет приятнее работать (можно будет легко задавать, за какое время предмет будет достигать своей скорости).
Для угловой скорости все это работает точно также.
Ну и да, в принципе можно обойтись без ускорения или сил с массой, задавая скорость алгоритмически, но с ускорением удобно будет вводить разные эффекты вроде гравитации, трения и тп.

помимо сплайнов, есть еще много других видов фигур. Простейший вариант - задавайте точку назначения рандомно и для плавности движения используйте формулу newpos=K*pos+(1-K)posz, где pos - текущая позиция в векторной форме, posz - заданная позиция. Чем больше К, тем более плавными будут кривые, но без забросов. Можно усложнить для красоты, но тогда придется разбираться в дифф.урах.

Почему бы не сделать эти перекрестки вершинами графа? ребра - проходимость между вершинами, а параметры ребра - расстояние между перекрестками.

Там может быть все что угодно, от углов до скоростей или обычного мусора. Воспринимайте более абстрактно, просто как объект с 6 параметрами, где первые два параметра - координаты этого объекта по осям Х и Y. Тут вопрос скорее к вам - откуда вы получаете p-объекты (которые скорее всего просто точки, судя по вашим комментам) и зачем вы их получаете? Там и будут необходимые вам ответы.
Ии.. я не спец по js, но нормально ли то, что r - внешняя переменная для функции, однако вы ей что-то там присваиваете внутри функции? В большинстве языков такая конструкция или не сработает или называется костылем, который через n циклов разработки выстрелит вам в ногу

Просто рандомно генерируете купоны. Конечно в идеале нужна проверка на схожесть, но 100к перебирать не очень то удобно. Для оптимизации этой задачи при генерации одного купона нужно ввести какой нибудь показатель, например сумму всех ord() от каждого знака. Тогда проверять нужно будет уже не каждый купон, а только те, которые имеют одинаковую сумму. Это и позволит ускорить проверку. Ну а для самой генерации нужен просто равномерный рандом. Умеете писать код - проблем ни с генерацией, ни с проверкой не будет. Не умеете - учитесь или заказывайте. Причем можно заказать реализацию даже на низкоуровневых языках)

Детерменированный метод - точность до константы:
Пусть, вероятность попадания - 40%, 30%, 30%. Пришло сообщение на распределитель, у него есть персональный номер (внутри распределителя по крайней мере), если остаток от деления на 10 меньше или равен 3, он идет в первый поток., от 4 до 7 - второй поток, от 7 до 9 - в третий. Нужна точность вплоть до процента? Делим номер на 100, а не на 10, ну и тд. Нужна высокая точность и более равномерная загрузка? Легко, A+B+C=100%, выражаем вероятности B и C через А и некую дельту вот так А+(А+d1)+(A+d2)=100%, Предположим у нас те же 10 сообщений. Сначала d1 сообщений пойдет в поток 2, потом по очереди по А сообщений пойдет в каждый поток по порядку и наконец d2 сообщений пойдет в поток 3. И счет начинается сначала. Можно еще больше оптимизировать, но это уже сами додумывайте или нанимайте человека, который потратит на это время за ваши деньги.
Стохастический метод:
Наиболее интересный, на мой взгляд, но точность его при малом количестве сообщений будет очень низкой. Берем генератор равномерного псевдорандома и превращаем его в генератор заданной вероятности (если сами не додумаете как, на тостере этот вопрос неоднократно задавался, да и наверняка есть готовыые библиотеки), задаем вероятности и при каждом новом сообщении "бросаем кости". Куда генератор укажет, туда сообщение и попадет. Проблем с загрузкой каналов при большом количестве сообщений у него нет.

если проблема в потере данных, очевидно что данные нужно каким-то образом не терять. Так как вы системный администратор, очевидно, писать нормальный помехоустойчивый и защищенный от потерь код за программистов не будете, но наверняка найдете решение по настройке вашего и западного оборудования так, что бы на более низком (если следовать терминологии osi) уровне реализовать защиту от потерь пакетов, пусть и ценой увеличения задержки/ширины канала. Вот статья без практической реализации, но как отправная точка.

Ничего сложного для вашего сервера тут нет. Все считается очень быстро. Формализуете условия(сближение на 250 метров к примеру в течении минимум секунды и 4 тактов из 5, ибо шум, ошибки и тп), а потом прогоняете все данные. Уж как расстояние найти между двумя точками, вы наверное знаете. Еще важным фактором в решении задачи будет то, в каком виде представлены данные. Это координаты? Если так, то в какой системе координат? Может это скорости? Тогда нужно будет их еще и проинтегрировать и определиться с возможными ошибками и способами их нейтрализации.
На каком языке будете реализовывать?

Алгоритм:
Пока не достигли цели, движемся к цели.
Реализации:

if 1==1 then
     UserLoseTheGame( );
else
     UserWin( );
end if

Сгенерируйте массив аэропортов по всему миру для начала. Дайте им названия. И игроку понятнее и вам проще. По ним уже выбираете начальную точку и формализовав условия (а иначе никак!) составляете маршрут.

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

Для массива А(10)
1. Считаешь дельту между каждыми соседними точками - синий график Б(9)
2. Считаешь мат. ожидание - оранжевая линия
3. Считаешь разницу между мат. ожиданием и дельтой в каждой точке, получая С(9)
3. Считаешь площадь на интервалах одинаковой длины в массиве С. Пусть интервал будет равен 3. Получаешь массив Д(9/3=3) Чем больше площадь на интервале, тем выше там плотность. Ищешь максимумы или минимумы площадей на интервалах нужной тебе длины. Там точки или будут кучковаться или самыми редкими. Чем больше временных точек в целом, тем красивее графики.

может изменить структуру данных - хранить в одной таблице запись-ключ, а в другой для каждого клиента хранить матрицу или словарь с парами ключ - приоритет(ключ уникален для задания, значит мы получим сопоставление задания с приоритетом). Каждое добавление записи/задания влечет добавление записи в таблицу 1 и изменение записи в таблице 2. Изменение приоритета задания влечет только одно изменение записи в таблице 2. Сортировка, сопоставление происходит на стороне клиента, на сервер посылается уже готовый новый словарь. Каждый запрос будет больше весить, но что нам 1 запрос размером в 15 пар ключ-приоритет для среднего пользователя?
1 ваш вариант, имхо, сферический костыль, консервированный в жидком вакууме
2 вариант красив, но его нужно проработать и просчитать
3 вариант вообще не вариант естественно)

K=K+- (b-a)*di, где di = 1/10 в данном случае, а вообще это шаг интегрирования. Только если будет больше итераций, чем запланировано, то К линейно падать и дальше будет.

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