undeadter

https://docs.djangoproject.com/en/1.10/ref/templat...

Просто делаете RESTful API на бэке, а в качестве клиента - используете всё что угодно: SPA, натив, мобильное и т.д.
Т.е., никогда не связывайте: логику, обмен данными и их представление.
По аналогии с машинами: клиент - рычаги, сервер - механизм, передача данных - тяги.
Проектируйте - точно также, исходя из того, какие данные и как должны выглядеть на клиенте и какие "рычаги" предоставить пользователям.

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

Если же проект контентный и будет часть доступная поисковикам, анонимвм и все такое - все сложнее и скорее, при сильном желании использовать angular придется делать много SPA. И выборочно.

Все дело в том, что с развитием проекта, когда встанут вопросы о поисковиках, скорости и всяком таком, окажется, что angular совершенно к этому не годен. Вещи вроде prerender решают проблему исключительно в простейших случаях и при развитии функционала требуют не тривиальный подходов и другой лабуды. Здесь речь идет о редиректах, 404, возможности ставить мета теги, noindex и все такое.
Люди могут заявлять, что и 404 и 301/302 prerender поддерживает, но усилия в которые все это выливается в 100 раз превосходят те, что требуются при стандартном подходе, когда html отдает бекенд.

Т.е. angular и ему подобные приносят пользу только в случае правильного применения.

В вопросе не прозвучало о специфике проекта, потому, возможно мои слова не к месту, однако - предупрежден - вооружен.

Спасибо.

1 подход - 2 репозитория, один для фронтенда, другой для бэкенда.
2 подход - фронт внутри бэкенд проекта. Единственное что будет, в одном репозитории коммиты для обоих частей, но я не могу сказать что это большая проблема, в конце концов фильтровать, индексировать коммиты для определенных частей и.т.д. Я так работал, не могу сказать что это было не удобно. Просто у вас появляется возможность поднять весь проект целиком и сразу. Иначе нужно настраивать роутинг и.т.д.

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

И если с мобильными приложениями все понятно, то с фронтэндом могут быть замуты. Например, вы хотите сделать страничку логина просто на Symfony/Django, и потом редиректить уже на SPA после того, как будет получен аутентификационный токен.

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

или еще интереснее. Какой-то прелоад данных. Например мы можем захотеть заинлайнить в html какие-то данные, которые генерит бэкэнд. Чтобы эти данные были доступны клиенту еще до того, как загрузится ангуляр. В этом случае опять же мы можем генерить точку входа при помощи готового html шаблона, поставляемому нам со стороны фронтэнда и силами какого-нибудь twig/jninja инлайнить json в тело страницы:

function data() {
    return {{data | json}};
}

Но это оооочень редкие кейсы.

Два потока: графика и логика.

Логика пошаговая с шагом 0.1-0.2 секунды, в зависимости от потребностей. Пошаговость означает, что реальное время в ней не учитывается, игра идёт по ходам: 1, 2, 3, 4...

Логика шлёт в графику команды, которые управляют отображением. Например, если юнит сдвинулся на X метров, то логика шлёт команду в графику: "сдвинуть юнит на X метров за время 0.1 секунды". Команда выполняется на каждой перерисовке и постепенно сдвигает спрайт/модельку юнита в нужную позицию (при 60 FPS он будет сдвинут за 6 перерисовок, каждый раз на x/6 метров). Одновременно отображение юнита может изменяться несколькими командами, например, одна перемещает танк, а другая вращает его башню.

Поток может быть и один, но принци тот же остаётся. Так в большинстве AAA игр делается, в частности, в Order of War.

но разве этого хватит для плавной игры с таким количеством действий

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

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

У каждого юнита три одинаковых структуры, renderInfo, bufferedInfo и aiInfo. Там могут быть координаты, курс, HP, ссылка на следующего — всё, что угодно. Ссылка на следующего — это важно, ведь юниты могут появляться и исчезать.

Поток интеллекта работает с aiInfo; где-то здесь есть и код мультиплеера. Закончив шаг, поток захватывает мьютекс и для всех юнитов (понятие «все» определяется по aiInfo) даёт bufferedInfo = aiInfo.

Поток прорисовки захватывает тот же мьютекс и для всех юнитов («все» по bufferedInfo) даёт renderInfo = bufferedInfo. А затем, освободив мьютекс, делает с этим renderInfo что хочет.
Под мьютексом будем сидеть очень мало: ни прорисовки, ни мультиплеера там нет.

Поскольку юнит исчезает из памяти только тогда, когда на него пропадают ссылки во всех трёх структурах, надо делать или объектный пул (т.е. юнит, будучи созданным, остаётся навсегда, но впоследствии этот блок памяти можно будет задействовать на другой юнит), или какие-нибудь «мусорные» указатели наподобие std::shared_ptr.

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

Разбивать интеллект на потоки откровенно тяжело, и в игре с мультиплеером я просто не знаю, как. RTS обычно передают по сети короткие пакеты наподобие «выделить юнитов в квадрате (X,Y) — (X,Y)», «добавить к выделению юнита 1234» и «отправиться в точку (X, Y)». Эти команды, будучи выполненными на разных компьютерах, выполняются одинаково.

Если объединить эти две конструкции — повторяемые расчёты и асинхронный рендеринг — возможны неточности, и, надеюсь, они будут приемлемыми — на экране (renderInfo) юнит попадает в отмеченный квадрат, а в aiInfo уже нет, посколько сдвинулся.

Отдельный вопрос — компенсация пинга в играх по интернету. Не думал пока над этим. Наверно, придётся иметь officialAiInfo и lagCompensatedAiInfo…

ЗЫ. Подсказывают, что такт игры в такой ситуёвине длится порядка 0,1 с, т.е. может продлиться несколько кадров. Тогда во всех этих …info надо описать движение так, чтобы в любой момент получить промежуточное x(t), y(t), yaw(t)… Для танка — bodyYaw(t) и turretYaw(t), для человечка — фазу анимации…

ЗЗЫ. Если игра трёхмерная и вид хоть как-то настраивается, одна из команд игры будет выглядеть «выделить юнитов в квадрате (X,Y) — (X,Y) с матрицей преобразования A».

ЗЗЗЫ. Чтобы игра была повторяемой (важно для мультиплеера), все расчёты, влияющие на течение игры, проводить в фиксированной запятой. Все переменные, с этим связанные, чем угодно, хоть нулём, но инициализировать.

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

Если Вы удалили модуль migrations, то Django не будет следить за изменением схемы моделей. Создайте этот модуль снова (директорию migrations и пустой файл __init__.py в ней) и после этого выполняйте makemigrations

Вас ждут большие открытия )
Apache и mod_python - это из мира PHP

Питон может быть, например, сам себе сервер: https://docs.python.org/3.5/library/http.server.html

но тем, о чем спращиваете, в Питоне занимаются [Django/Flask]+[Gunicorn/uWSGI]+[Nginx/Apache]

обычно uWSGI+Nginx + фреймворк или свое приложение

смотрите:
https://www.digitalocean.com/community/tutorials/h...

https://www.digitalocean.com/community/tutorials/h...