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

У https://the-tale.org есть небольшая (клиентская) часть на JavaScript, которой не помешало бы дополнительное внимание.

Исходники: https://github.com/the-tale

Game Maker: https://www.yoyogames.com/gamemaker

Для 2д игр в качестве хобби — самое то. Есть куча готовых ассетов, примеров, многое разжёвано и упрощено, большое и активное сообщество.

Из недостатков - собственный ЯП, который вне GM никому не нужен.

Имеет ли смысл создавать свой собственный игровой движок?

Зависит от цели создания.

Если для конкуренции с существующими движками, то не имеет - весовые категории не те.

Смысл имеется, если целью ставится:

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

Какого уровня программисты занимаются созданием игровых движков?

Любого, в зависимости от цели.

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

Предложить можно всё, что угодно, но никто не согласится. Можно попробовать найти финансирование под разработку готовой игры с УНИКАЛЬНЫМ геймплеем на этом движке.

Имеет ли смысл переписывать компоненты существующих движков (например рендер-составляющую в Unity), для собственных нужд?

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

Программист 3D-графики и шейдеров ( OpenGL, DirectX ) = программист движка? :)

Смотря какой программист и смотря какой движок :-D

Вообще понятие «движок» очень расплывчатое, так что и да и нет.

Без опыта с такой суммой у вас почти нет шансов что либо сделать. Только если повезёт собрать профессиональную команду, а без опыта в индустрии вы её сразу не соберёте.

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

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

Что можно сделать:

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

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

А точно в nginx проблема? Посмотрите в логах nginx вермя отдачи данных.

Скорее всего перед nginx что-то стоит или сама сеть медленно работает.

Паттерн: «просто напиши этот код».

До тех пор, пока не будет указано каких-то особых требований/ограничений для задачи, сказать что-то про архитектуру нельзя. Тем более, что в большинстве случаев фильтрации данных именно этот паттерн себя очень хорошо зарекомендовал.

RawSQL и вообщеще запросов на SQL смущаться не надо :-) это вполне нормальная практика.

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

Поэтому, на мой взгляд, правильнее сложные запросы писать на SQL, а простые делать с помощью ORM, если так удобнее.

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

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

Если калькулятор сам на js, то достаточно какого-нибудь хостинга статических сайтов.

Например, этого: https://pages.github.com/

Зависит от скорости появления новых рассказов.

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

Для задач среднего портала этого хватит.

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