Привет! Это Dessly!

🎯 Кажется, что на рынке гоночных игр уже давно всё решено. Есть Gran Turismo, Forza, Assetto Corsa – настоящие гиганты. Но студия Maverick Games, в которой работают бывшие создатели Forza Horizon, решила, что место для новичка всё же найдется.

Они показали свой проект – Clutch. Это гоночный экшен с открытым миром, где главное место отведено сюжету. Журналистов пригласили на часовую презентацию, и теперь они делятся впечатлениями.

Напоминаем, что пополнить баланс Steam быстро и без лишних сложностей можно через Dessly.com

👉 Dessly делает процесс пополнения Steam кошелька максимально удобным, быстрым и безопасным!

Что понравилось журналистам в первую очередь

🎯 Автор GamesRadar+ признался, что Clutch производит очень хорошее первое впечатление. По его словам, игра ловко балансирует между серьёзными кольцевыми гонками и зрелищным киношным экшеном – быстрые гонки и погони, как в «Форсаже».

Главного героя зовут Тео, и он ведёт двойную жизнь. Днём он выступает в престижной серии R1K, а по ночам участвует в нелегальных заездах. Вместе с сестрой Кэсс он вынужден раскрыть тёмную сторону гоночной сцены на Французской Ривьере.

Сюжет с изнанки гоночного мира

🎯 Подпольная лига под названием Midnight Collective появляется не случайно. Часть гонщиков уходит из чемпионата R1K, потому что они возмущены активным внедрением искусственного интеллекта.

Глава R1K обещает, что ИИ поможет избегать аварий, но не всем это нравится. Над историей работал один из создателей сериала «Молокососы» – Джейми Бриттейн.

Поэтому в Clutch есть и реальные проблемы кольцевых гонок, и чистый экшен в духе средних частей «Форсажа». Например, в одной из миссий Тео придётся сесть в машину с гарпуном, выехать из окна пентхауса и зацепиться за пролетающий вертолёт.

Как игра выглядит и звучит

🎯 Игра работает на модифицированном движке Unreal Engine 5. Благодаря этому Clutch выглядит и звучит потрясающе.

Журналисты PC Gamer заметили: «Неудивительно, что действие частично происходит в Монако – вся игра просто сочится роскошью».

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

Достижения Unreal Engine 5 заметны и в крупных планах, и просто во время обычной езды по дороге.

Напоминаю, что Dessly можно найти в: Вконтакте | Telegram | Youtube | Tik Tok

👉 Dessly стремится сделать ваш игровой опыт, а также пополнение Steam кошелька ещё более комфортным и увлекательным.

Не только гонки: можно ходить пешком и использовать необычные гаджеты

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

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

Восторги и осторожные сомнения

🎯 Автор VGC написал: «Clutch меня просто поразила. Визуал, сами гонки, сценарий, все эти мелочи – игра мгновенно стала одной из самых ожидаемых для меня. Если Maverick Games сможет держать тот же темп на протяжении всей игры, то Clutch обязана стать новой большой гоночной франшизой».

Однако в GamesRadar+ выразили опасение: разработчики хотят слишком много и слишком быстро. Как бы не сложились завышенные ожидания. Кроме того, миссии в Clutch выглядят довольно линейными.

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

Когда выйдет и на каких платформах

🎯 Прокатиться с ветерком в Clutch можно будет весной 2027 года. Игра выйдет на ПК (в Steam и Epic Games Store), PlayStation 5 и Xbox Series.

Разработчики обещают текстовый перевод на русский язык.

🔥 Не тяни кота за подписку — жми "Подписаться" прямо сейчас! → VK Dessly

Сначала была просто большая карта

В проекте карта живет как мир 20000 на 20000 условных пикселей. Есть тайлы, метаданные, слой POI и координаты маркеров. Фронтенд показывает нужный кусок карты, сервер знает базовые параметры.

Параметры карты в сервере

MAP_ID = 481
DEFAULT_LAYER_ID = 760
MIN_ZOOM, MAX_ZOOM = 12, 18
TILE_SIZE = 256
MAP_WIDTH, MAP_HEIGHT = 20000, 20000

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

Поиск POI с учетом расстояния от машины

def search_markers(query: str, limit: int = 25):
terms = [t for t in query.strip().lower().split() if t]
snap = STATE.get_snapshot()
px, py = snap.get("map_x"), snap.get("map_y")

results = []
for marker in load_markers_data():
hay = " ".join(str(marker.get(k, "")) for k in (
"title", "category", "parent_category", "description", "desc"
)).lower()
if not all(term in hay for term in terms):
continue
item = dict(marker)
if px is not None and py is not None:
item["distance_px"] = round(math.hypot(
float(marker.get("map_x", 0)) - float(px),
float(marker.get("map_y", 0)) - float(py),
), 2)
results.append(item)
return results[:limit]

Дороги пришлось добывать из картинки

Вот тут началась та часть, которую нормальный человек, вероятно, назвал бы “а может, ну его”.

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

На словах это звучит как компьютерное зрение. На практике - как спор с картинкой, которая очень не хочет становиться JSON.

Первый заход был через OpenCV. Я не пытался “понять” карту как человек - я пытался вытащить из изображения схему дорог: белые линии, оранжевые магистрали, пунктир, разрывы. OpenCV делал черновую маску: фильтр по цвету, морфологическая очистка, склейка близких участков, потом скелетизация. Звучит умно, но на практике алгоритм с одинаковой уверенностью находил дорогу, подпись на карте и какой-нибудь декоративный пиксель, которому просто повезло быть нужного цвета.

Поэтому после распознавания пришлось сделать отдельный HTML-редактор карты. Не красивый “редактор уровней”, а рабочую утилиту для ремонта: открыть маску, стереть мусор распознавания, дорисовать недостающие проезды, заштриховать разрывы, сохранить ручные штрихи в JSON и заново собрать road_graph. В этот момент проект окончательно перестал быть “сейчас OpenCV все сам поймет” и стал нормальной инженеркой: автомат нашел основу, человек добил то, что без глаза и здравого смысла не чинится.

Фрагмент из build_road_graph_from_manual_mask.py - выделение дорожного цвета

def classify_pixels(base_rgb: np.ndarray) -> np.ndarray:
hsv = cv2.cvtColor(base_rgb, cv2.COLOR_RGB2HSV)
h, s, v = hsv[..., 0], hsv[..., 1], hsv[..., 2]
r, g, b = base_rgb[..., 0], base_rgb[..., 1], base_rgb[..., 2]

orange = (
(h >= 2) & (h <= 28) & (s >= 35) & (v >= 70) &
(r.astype("int16") - b.astype("int16") >= 35) &
(r.astype("int16") >= g.astype("int16") - 12)
)
return cv2.dilate(
orange.astype("uint8"), np.ones((5, 5), np.uint8), iterations=1
).astype(bool)

Автоматом это сделать полностью красиво не получилось. Карта содержит подписи, иконки, швы, разные цвета, декоративные элементы. Поэтому появился ручной слой правок: где-то стереть мусор, где-то дорисовать разрыв, где-то поправить место, где алгоритм слишком самоуверенно увидел дорогу.

В итоговом графе в метаданных остался след этой возни: 1387 ручных штрихов, из них 1153 draw, 155 erase, 79 erasePatch. Это не “я нажал одну кнопку и получил навигацию”. Это скорее “я убедил карту сотрудничать”.

Маска дороги -> скелет -> граф

После очистки маска превращается в скелет. Толстая линия дороги становится тонкой ниткой по центру. Потом эта нитка режется на узлы и ребра. Узел - точка на дороге. Ребро - проезд между двумя точками. У ребра есть длина и класс дороги.

Очистка маски и skeletonize

raw_mask = np.asarray(Image.open(args.mask).convert("L")) > 127
count, labels, stats, _ = cv2.connectedComponentsWithStats(
raw_mask.astype("uint8"), 8
)

mask = np.zeros_like(raw_mask, dtype=bool)
for label in range(1, count):
area = int(stats[label, cv2.CC_STAT_AREA])
if area >= args.min_component_area:
mask[labels == label] = True

skeleton = skeletonize(mask)
paths, skeleton_points, key_points = build_skeleton_paths(skeleton)

Узел и ребро - уже не картинка, а данные для навигации

COST = {
"white": 1.00,
"orange": 1.08,
"orange_dashed": 2.60,
"unknown": 9.50,
}


def add_edge(a: int, b: int, length: float, cls: str) -> None:
edges.append({
"from": nodes[a]["id"],
"to": nodes[b]["id"],
"length": round(length, 3),
"cost": round(length * COST.get(cls, COST["unknown"]), 3),
"road_class": cls,
})

Итоговый road_graph.json получился вполне взрослый: 14561 узел, 18612 ребер, шаг сжатия скелета около 6.595 px. Внутри есть классы дорог: white и orange, есть веса, компоненты связности и данные для runtime-достройки разрывов.

То есть когда на телефоне появляется синяя линия маршрута, за ней не CSS и не SVG-фокус. За ней лежит нормальный граф.

A*: потому что маршрут должен думать

Когда граф появился, понадобился поиск пути. Здесь используется A*. Алгоритм не просто ползает по всем дорогам, а идет по графу с учетом уже накопленной стоимости и примерного расстояния до цели.

На бытовом языке: “я еду по реальным дорогам, но не делаю вид, что вся карта одинаково интересна”.

Укороченный A* по дорожному графу

def shortest_graph_path(graph, start_idx, goal_idx, profile=None):
coords = graph["coords"]
adjacency = graph["adjacency"]
gx, gy = coords[goal_idx]

def heuristic(node_idx: int) -> float:
ax, ay = coords[node_idx]
return math.hypot(ax - gx, ay - gy)

heuristic_weight = float((profile or {}).get("heuristic_weight", 1.0))
open_heap = [(heuristic(start_idx) * heuristic_weight, 0.0, start_idx)]
came_from = {start_idx: None}
best_cost = {start_idx: 0.0}

while open_heap:
_priority, cost_so_far, current = heapq.heappop(open_heap)
if current == goal_idx:
path = [current]
while came_from[path[-1]] is not None:
path.append(came_from[path[-1]])
path.reverse()
return path, cost_so_far

for neighbor, _stored_edge_cost in adjacency[current]:
edge_cost = _route_edge_cost(graph, current, neighbor, profile)
new_cost = cost_so_far + edge_cost
if new_cost < best_cost.get(neighbor, float("inf")):
best_cost[neighbor] = new_cost
came_from[neighbor] = current
heapq.heappush(open_heap, (
new_cost + heuristic(neighbor) * heuristic_weight,
new_cost,
neighbor,
))

Почему веса важнее, чем кажется

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

Поэтому у разных дорог разные множители. Белая дорога - базовая. Оранжевая почти нормальная. Пунктир и неизвестные участки дороже. Синтетические мостики для ремонта разрывов тоже не бесплатные, иначе алгоритм полюбит заплатки больше настоящих дорог.

Стоимость разных типов дорог

ROAD_CLASS_MULTIPLIERS = {
"white": 1.00,
"orange": 1.08,
"orange_dashed": 2.60,
"synthetic_short": 2.40,
"synthetic_medium": 7.00,
"synthetic_bridge": 34.00,
"unknown": 9.50,
}

Итог серии

На этом этапе проект перестал быть “картой с живой точкой” и стал навигатором. Он умеет искать POI, понимать позицию машины, приклеивать старт и цель к дорожной сети и строить маршрут по графу.

Но дальше вскрылся главный враг. Не UDP, не JavaScript, не телефон. Развязки.

Потому что в 2D две дороги могут пересекаться, а в игре одна идет сверху, другая снизу, третья уходит рампой, и граф такой: “ну вроде все рядом, поехали”.

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

Но тут внезапно повезло. В Forza есть Data Out - нормальная телеметрия по UDP. Это та же идея, которой пользуются приборки, симрейсинговые панели и всякие dashboard-приложения. В настройках включаешь Data Out, указываешь IP 127.0.0.1 и порт, у меня это 5700, и игра начинает сама отправлять пакеты.

Самый красивый хак в проекте - это вовремя не хакать то, что уже умеет работать официально.

С этого момента схема стала приземленной: Python-приложение на ПК слушает UDP, принимает байты, распаковывает телеметрию и дальше уже кормит телефон нормальным JSON. Телефон вообще не знает, что где-то внизу летят бинарные пакеты. Для него это просто веб-страница с живым состоянием машины.

UDP-пакет - это не милый JSON

Я бы очень хотел написать, что игра отправляет что-то вроде {speed: 120, x: 123, y: 456}. Но нет. На вход прилетает бинарный пакет, и его нужно читать строго по структуре: где int, где float, где byte, где signed byte.

Из полезного для навигатора там есть почти все, что хотелось: PositionX, PositionY, PositionZ, Speed, VelocityX/Y/Z, Yaw, Gear, CurrentEngineRpm, EngineMaxRpm, Accel, Brake, DistanceTraveled. Скорость приходит в метрах в секунду, yaw - в радианах, педали - байтами 0-255, координаты - в игровых единицах, которые пока вообще не имеют отношения к картинке карты.

Укороченный фрагмент из fh6_live_map_server.py - схема пакета телеметрии

def build_fh6_fields():
fields = []
def add(name, fmt):
fields.append((name, fmt))

add("IsRaceOn", "i")
add("TimestampMS", "I")

for name in [
"EngineMaxRpm", "EngineIdleRpm", "CurrentEngineRpm",
"AccelerationX", "AccelerationY", "AccelerationZ",
"VelocityX", "VelocityY", "VelocityZ",
"Yaw", "Pitch", "Roll",
]:
add(name, "f")

for name in [
"PositionX", "PositionY", "PositionZ",
"Speed", "Power", "Torque", "DistanceTraveled",
]:
add(name, "f")

for name in ["Accel", "Brake", "Clutch", "HandBrake", "Gear"]:
add(name, "B")

return fields

FH6_FIELDS = build_fh6_fields()
FH6_STRUCT_FORMAT = "<" + "".join(fmt for _, fmt in FH6_FIELDS)
FH6_STRUCT_SIZE = struct.calcsize(FH6_STRUCT_FORMAT)

Дальше все не романтично, зато надежно: проверяем длину пакета, распаковываем через struct, складываем значения в словарь. Это тот самый момент, где проект перестает быть красивой фантазией и начинает пахнуть настоящей программой: байты пришли, Python их понял, координаты появились.

UDP listener - скучная часть, без которой магии не будет

def parse_packet(data: bytes):
values = struct.unpack(FH6_STRUCT_FORMAT, data[:FH6_STRUCT_SIZE])
return dict(zip((name for name, _ in FH6_FIELDS), values))


def udp_listener(bind: str, port: int, stop_event: threading.Event):
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((bind, port))
sock.settimeout(0.2)

while not stop_event.is_set():
try:
data, _addr = sock.recvfrom(2048)
except socket.timeout:
continue

if len(data) < FH6_STRUCT_SIZE:
STATE.mark_short_packet(len(data))
continue

STATE.update_from_packet(parse_packet(data), len(data))

Вторая радость быстро закончилась: координаты игры не координаты карты

Когда я впервые увидел живые PositionX и PositionZ, было ощущение: ну все, победа. Сейчас нарисую точку на карте и поедем.

А потом мозг такой: подожди, карта у нас - картинка 20000 на 20000 условных пикселей, а игра отдает свои координаты мира. Это не одна и та же система. Просто взять x и z и вставить в CSS нельзя. Получится не навигатор, а зеленая точка, которая уверенно едет в другой вселенной.

Пришлось делать калибровку. Берем несколько точек, где известно соответствие: в игре машина стоит вот здесь, на карте это вот этот пиксель. Потом подбираем аффинное преобразование. В итоге две игровые координаты превращаются в две координаты карты.

Перевод координат Forza в координаты карты

A, B, C = 0.652837, 0.000763, 10387.027
D, E, F = -0.003754, -0.657135, 9846.097


def forza_to_map(position_x: float, position_z: float):
return (
A * position_x + B * position_z + C,
D * position_x + E * position_z + F,
)

Вот это был первый момент, когда я прям физически почувствовал: оно ожило. Не просто цифры бегут в консоли, а машина реально едет по карте примерно там, где должна. После этого уже можно было заниматься интерфейсом. До этого - только гадать над float-ами и делать вид, что все под контролем.

Направление движения: yaw есть, но он не всегда король

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

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

Направление по фактическому движению, а не только по yaw

def compute_screen_heading_deg(yaw_rad, velocity_x, velocity_z, speed_mps):
if speed_mps > 1.5:
vx_map = A * velocity_x + B * velocity_z
vy_map = D * velocity_x + E * velocity_z
return map_vector_to_screen_angle_deg(vx_map, vy_map)

forward_x = math.sin(yaw_rad)
forward_z = math.cos(yaw_rad)
fx_map = A * forward_x + B * forward_z
fy_map = D * forward_x + E * forward_z
return map_vector_to_screen_angle_deg(fx_map, fy_map)

Пауза в игре и телепорт в подвал мироздания

Отдельный прикол: когда игра на паузе, в меню или теряет фокус, телеметрия может стать странной. В интерфейсе это выглядело так, будто машина внезапно исчезла с дороги и решила пожить где-то в координатном аду.

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

Защита от прыжка координат при паузе

pause_coordinate_hold = bool(
speed_mps <= 0.20 and gear == 0 and self.last_good_position is not None
)

if pause_coordinate_hold:
pos_x, pos_y, pos_z, map_x, map_y, held_yaw, held_heading = self.last_good_position
effective_yaw_rad = held_yaw
effective_heading_deg = held_heading
else:
pos_x, pos_y, pos_z = raw_pos_x, raw_pos_y, raw_pos_z
map_x, map_y = raw_map_x, raw_map_y
self.last_good_position = (
pos_x, pos_y, pos_z, map_x, map_y,
effective_yaw_rad, effective_heading_deg,
)

Как телефон вообще это видит

На ПК одновременно работают две вещи: UDP listener и локальный HTTP-сервер. Телефон открывает страницу по Wi-Fi, например 192.168.x.x:8766. Страница каждые 120 миллисекунд спрашивает /api/state, а сервер отдает уже нормальный JSON: скорость, передачу, обороты, map_x, map_y, heading, статус LIVE/HOLDING/WAITING.

То есть телефон не подключается к игре. Он подключается к моей локальной программе. И это очень приятная архитектура: игра ничего не знает про телефон, телефон ничего не знает про бинарную телеметрию, а посередине сидит Python и делает вид, что так и было задумано.

Локальный API для телефона

# server side
if path == "/api/state":
self.send_json(STATE.get_snapshot())
return

# browser side
async function pollTelemetry(){
try{
const r = await fetch('/api/state?ts=' + Date.now(), {cache:'no-store'});
telemetry = await r.json();
updateHud();
handleMemeLayerTelemetry(telemetry);
} finally {
setTimeout(pollTelemetry, 120);
}
}

Итог серии

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

После этого уже можно делать все остальное: поиск точек, маршрут, heading-up, dashboard, мемные звуки, мини-карту в приборке и прочий цирк. Но фундамент простой: UDP -> struct -> координаты -> калибровка -> JSON -> телефон.

В следующей серии будет интересно про карту: как обычная картинка превратилась в дорожный граф, почему прямая линия до цели - это позор, и зачем мне понадобились 14561 узел и 18612 ребер.