Алексей Елецкий

1. Открываешь текстовый редактор.
2. Пишешь код.
3. Компилируешь.
4. Смотришь результат.
5. Если не устраивает, переходишь к п.1.
6. ?????
7. Profit.

Это называется long polling . Можно погуглить особенности решения по этому термину.

Вот случилось у меня 1000 CCU - будет ошибкой такое решение? 10000?

Глобально или на физический сервак? Это ж разные вещи. Как я понимаю, всё-таки в расчёте на физический сервак. Но и сервак-серваку рознь, как и само CCU беp "профиля нагрузки" мало что говорит.

В целом, ответы на такие вопросы проще получать экспериментальным путём (собрать простой прототип и натравить на него ботов).

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

Для прототипа и 1000 CCU точно хватит, если ходы не частые. Например, я по такому принципу сделал дебажный матчмейкер.

Если бы не было мультиплеера (когда пользователь просто ждёт что-то), то покатило бы и для прода.

В случае мультиплеера (когда пользователи ждут друг друга), не вижу преимуществ перед поддержкой обычного соединения, кроме сэкономленого времени на разработку MVP. Минусами же станус костыли для поддержки соедиенения и определения дисконектов. Для случая низкуоровневой работы с tcp есть куча мануалов и "стандартных" решений. В случае работы на уровне не ниже http могут возникнуть непредвиденные проблемы из-за промежуточного софта и самого протокола.

Кроме того, при простейшей реализации long polling одно из соединений будет забито на обработку одной команды и послать другое будет нельзя. А значит потребуется делать отдельные http запросы на каждую дополнительную команду. Теоретически можно загнаться и сделать передачу нескольких команд через такое соединение, но это уже ничем не будет отличаться от собственного протокола через tcp (кроме дополнительных тормозов и костылей).

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

Резюме:

- если есть экспертиза и время: делать нормальную коммуникацию через tcp
- если экспертиза не очень и сроки не горят, то делать нормальную коммуникацию через http с двумя командами (отправить изменения, получить текущее состояние)
- если нужно ещё вчера, то long polling подойдёт.

https://godotengine.org/features

Возможно имеется в виду technical artist. Правда они очень разные могут быть: от верстальщиков интерфейса до программистов шейдеров и прочего. В общем случае должность подразумевает знание и программирования и арта.

Возможно, но есть некоторые сложности.

1. ААА разрабатывают командами от 50-100 человек, так что в одиночку в любом случае будет очень долго. Скорее всего даже не сможете успевать за технологиями, чтобы соответствовать ААА :-D
2. Новые движки и либы почти (или уже совсем?) не пишутся на чистом С (может, разве что, в консолях каких он остался). Поэтому придётся линковаться с либами на С++, это может вызвать некоторые затруднения.
3. Для ААА придётся писать и набор всяких утилит (редакторов и прочего), на С. А GUI на нём уже давно не пишут.

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

к С++ и С# не расположен

Смиритесь с тем, что сейчас недостаточно знать 1 язык. Чтобы сделать что-то серьёзное и большое, по-любому придётся писать на нескольких ЯП.

Обычно игровая логика (это к примеру):
- управляемый персонаж
- способность персонажем взаимодействовать с миром (предметами)
- какие-то подвижные элементы в игре
- АИ врагов и НПС
- кнопки интерфейса, инвентарь.
И всё... Так если ты умеешь уже это делать и ты "типо программист на Юнити", то ты напишешь всё это гораздо раньше, чем начнется твоя первая зарплата. А чё потом делать?

Большинство программистов один элемент из этого списка качественно за месяц сделать не в состоянии.

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

P.S. для примера. Моей первой работой была вот эта игра: https://en.wikipedia.org/wiki/Order_of_War

Первые задачи на ней были примерно такие:

- реалистичный поворот башни танка, синхронизированный с логикой ~ 3 недели, дошло до того, что рисовал графики в excel, чтобы обосновать, почему именно такая визуализация правильная и почему нельзя сделать лучше.
- интерфейс управления отрядами (чтобы формацию сохраняли, не перестраивались лишний раз, etc) ~ месяц.
- оптимизация цикла обновления графики с двухпроходного на однопроходный ~ два дня :-D

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

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

Как альтернативу серверной чати рекомендую Python. Или Go, но для хобби и экспериментов больше подойдёт Python, так как более гибкий.

P.S. Если не хочется учить новые ЯП, а писать игры, то для сервера берите Node.js. Но лично мне он не нравится по идеалогическим причинам :-)

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

Если игра пошаговая, то либо в базу либо в кеш, но в обоих случаях надо сразу брать в расчёт максимальную ожидаемую нагрузку на них (сколько одноврмеенных запросов будет, сколько данных будет гоняться, как часто будут они обновляться). Это всё очень специфично для конкретного проекта.

Это вопрос тут раз в месяц появляется.

Сервера WoT на Python с большего, видимо можно.

Используйте https://en.wikipedia.org/wiki/Content_delivery_network и не парьтесь чёрной магией.

Например можно амазоновскую взять: docs.aws.amazon.com/AmazonCloudFront/latest/Develo...

Просмотрел свои rss и вижу что большинство блогов, на которые был подписан, мертвы. Я даже не знаю что рекомендовать, чтобы треша много не было.

Вот список живых и полуживых бложиков (правда они больше не про новости):

- вот тут круто: https://engineering.riotgames.com/
- https://www.reddit.com/r/gameai/
- https://www.deconstructoroffun.com/blog
- www.fantasticmaps.com
- blog.ihobo.com
- www.lostgarden.com
- projectperko.blogspot.com.by