User

Никак, не надо смешивать мягкое с тёплым. Если хотите сделать два интерфейса, то делаете ядро приложения с API, web-приложение и gui-приложение, использующие API ядра. И все три запускаться должны отдельно.

Потому что первым отрабатывает функция get_text_messages. Зачем вы сделали a_task, которая тоже должна реагировать на текст не понятно. Оставляйте одну функцию и в ней делайте ветвление в зависимости от введенного текста.

Изучайте. https://core.telegram.org/widgets/login

Видео нужно тогда, когда ты прочёл книгу, вроде всё понял, но куда тыкать пока не понял. В видео можно посмотреть чисто практические приемы работы с IDE, с консолью, с системой. То, что слабо отражено в книгах. Чтоб не тыкаться как кутёнок в незнакомый интерфейс.
А собственно язык лучше по хорошей книге и затем кодить, кодить, читать исходники других проектов, вникать, дебажить.

Самое главное - понять, что язык программирования - это как лопата у агронома. Лопатой надо владеть? Надо. Достаточно ли агроному лопаты? Нет. Ему надо знать и уметь много чего - сорта, почвы, технологии, химию, а лопатой он делает только некоторую часть операций.
Программисту надо знать в той или иной степени информатику, алгоритмы, структуры данных, языки программирования, базовые библиотеки, БД и СУБД, API, ООП, фреймворки, сети, протоколы, ИБ, тестирование (в части, касающейся программеров), да много чего. Язык там не на первом месте.

Видосиками это не изучишь, как ни старайся.

Из более-менее полезного видео поищи «алгоритмы и структуры на Python» от МФТИ, там десятка полтора лекций Хирьянова. Но это лучше после книги «Изучаем Python» М.Лутца.

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

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

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

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

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

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

Какие известны хитрости, чтобы передавать меньше данных, не рискуя рассинхроном?

Чем меньше тик рейт сервера, тем меньше данных. Одно дело динамичный шутер(батла на 130 человек), а другое дело кооп игра на 4 человек. В одних случая критичен высокий тик рейт в других нет. Хотя... умереть в батле через секунду после того как ты забежал за стену благое дело...

Какие рассинхроны не критичны?

Опять зависит от игры.

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

Ну почитайте какие нибудь статьи вот например на хабре
Мультиплеер в быстрых играх (части I, II)
Мультиплеер в быстрых играх (Часть III: появление ...
Мультиплеер в быстрых играх (Часть IV: Хэдшот! Пут...

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

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

Я в таких случаях создаю фабричный метод.

@dataclass
class Person:
    first_name: str
    last_name: str
    bdate: date

    @classmethod
    def make(cls, first_name: str, last_name: str, bdate: str) -> 'Person':
        _bdate = datetime.strptime(bdate, '%Y%m%d').date()
        return cls(first_name=first_name, last_name=last_name, bdate=_bdate)

data = {
    'first_name': 'Adam', 
    'last_name': 'Smith', 
    'bdate': '20220617'
}
person = Person.make(**data)

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

Но вообще это неправильное распределение обязанностей. Обязанность датакласса - хранить данные, а не менять их представление. За смену представления пусть отвечает тот код, который получает значение строки.

Очевидно, запоминать куда-нибудь время последнего нажатия на кнопку и сравнивать его при очередном нажатии. Можно также при нажатии на кнопку убирать/изменять клавиатуру, но пользователь может успевать иногда нажать на кнопку 2-3 раза до исчезновения/изменения кнопки.