GTRxShock

Новое поколение создателей "своих 10к ммо серверов" подросло? :) ну ок

Тср или удп выбирается в основном по критерию насколько динамичная будет эта "новая эпичная сага". Если стрелялка, то удп скорость компенсирует качество. Если это "убийца вов, л2" то тср, там важно чтобы действия клиента были доставлены от и к серверу. А затем конечно самое сложное - не бросить это дело через месяц оставаясь без прогресса и наблюдая лаги и глюки. Чтобы сделать игру плавной придется делать адаптивную логику которая будет учитывать задержки сети как на клиенте так и на сервере. Легче всего сделать сначала клиент который будет бегать независимо от сервера, а затем постепенно добавлять туда шаг за шагом контроль со стороны сервера, отточить движение, затем взаимоотношение с миром (удачи с синхронизациец физики), бой итд.
Вобшем не ты первый, не ты последний. Ждем шедевр. Я если че буду десять тысяч первый игрок ;)

P.S. по теме :) . смотри в сторону архитектуры на основе пакетов и очередей. Только так ты выстроишь масштабируемое взаимоотношение клиент-сервера которое не будет загинаться от 20 одновременных подключений

DevOps отличается от обычного сисадмина тем, что не может сказать "это задача программистов".

https://tproger.ru/translations/how-to-learn-gamed...

Изучаю С# на сайтах, но это довольно скучно, хочется применять на практике, а идей либо нет, либо они слишком сложные.

Без практики изучение бесполезно. Гуглите простые задачи на шарпах. Для геймдева простыми можно считать какой нить Asteroids, змейку, арканоид, пинбол.

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

Как изучить c# с основ до зарабатывания денег?
Путь изучения движка unity?
Где можно изучить Unity + C# с нуля?

Ну и куча всего здесь...
Как изучить unity

how to create your own React course

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

Сделайте общий метод getUsersQuery(), который просто возвращает пользователей без какой либо сортировки. Свой метод getUsers() измените так, что бы он использовал первый метод. Плюс, добавьте метод getUsersSorted(), где будете возвращать данные, отсортированные в нужном виде. Не зная структуры проекта сложно написать какие то примеры кода, но я бы сделал примерно так:

function getUsersQuery() {
    // ...
}
function getUsers() {
    return getUsersQuery()->orderBy('id');
}
function getUsersSorted() {
    return getUsersQuery()->orderBy('name');
}

какие паттерны применяются чаще всего на практике и где

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

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

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

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

EYPPNM,
раз:
amatrosov.blogspot.com/2012/02/tangled-web.html

два:
JavaScript Security
Год: 2014
Автор: Y. E. Liang
Издательство: Packt Publishing
ISBN: 978-1-78398-801-3
Язык: Английский

три:
Security for Web Developers
Using JavaScript, HTML, and CSS
Author: John Paul Mueller
ISBN-10: 1491928646
Year: 2015
Language: English

1. PHP умирает на каждый запрос. Это его главное преимущество и особенность. Это допускает очень много вещей, т.е можно не париться закрытием файлов, завершением подключения к БД и т.п. Как только вы захотите писать асинхронно вам про всё это нужно будет помнить.

2. Итак, плавно переходим к тому что помнить, вобщем то, нужно будет не только вам. 99% всех библиотек/фреймворков etc. для PHP не пригодны к работе асинхронно.

3. "полностью асинхронным" = отсутствие блокировок? Первое на чем вы споткнетесь - банальные запросы к базе. С дефолтным драйвером они идут синхронно. Точно так же как синхронно работает куча других подключений, и всякие Swoole etc. вынуждены писать над всем этим свои обертки и свои драйвера к БД.

Вобщем, асинк в PHP это огромное усложнение на пустом месте, и при наличии блокирующих операций не имеет никакого смысла. Сильно проще сменить язык программирования, если вам нужна асинхронщина.
По описанию вашего вопроса - гляньте RoadRunner, интересная штука. Как раз чтобы сократить оверхед на инициализацию.
Есть ещё всякие штуки аля https://github.com/php-service-bus/service-bus , но повторюсь, проще подходящий ЯП взять.

Вот и вот