Комментарии 5
На заметку: «таски» на 3.5+ отлично работают через await без уродских yield from.
Самое интересное начнется, если вы из прототипа будете делать игру. Внезапно окажется, что игровой логики станет столько, что при онлайне в 50 человек одного ядра процессора перестанет хватать, и захочется не только оторвать бизнес-логику от обработчиков вебсокетов, но и разделить ее на несколько серверов. Вот тогда будет настоящее бэкенд-проектирование.
Вот это уже интересно. А есть примеры проектов, распределяющих бизнес-логику одной локации на несколько серверов? Было бы интересно почитать как они с этим живут.
Мне кажется здесь скорее оптимизация уйдёт в недра Cython, либо иных низкоуровневых решений, свободых от GIL, чем в распределённую среду, которую проектировать и обслуживать сразу на порядок сложнее. Обычно онлайн игры стремятся наоборот изолировать наименьшее количество взаимодействующих игроков на отдельном шарде.
Мне кажется здесь скорее оптимизация уйдёт в недра Cython, либо иных низкоуровневых решений, свободых от GIL, чем в распределённую среду, которую проектировать и обслуживать сразу на порядок сложнее. Обычно онлайн игры стремятся наоборот изолировать наименьшее количество взаимодействующих игроков на отдельном шарде.
Как планируется высчитывать «попадание»?
Для каждой пули на карте каждые 20ms высчитвается новое положение, и проверяется есть ли пересечение с танком чтоб нанести урон, либо есть ли пересечение с внешним миром чтоб пулю уничтожить.?
Для каждой пули на карте каждые 20ms высчитвается новое положение, и проверяется есть ли пересечение с танком чтоб нанести урон, либо есть ли пересечение с внешним миром чтоб пулю уничтожить.?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Многопользовательский онлайн-шутер на WebGL и asyncio, часть вторая